Json Rpc Protocol

Published
Length
3 min read

Luis Felipe Dias

All posts

The json rpc protocol lets apps call remote methods using plain text messages. A client sends a method name and inputs, and the server returns a result. Teams often set up this system to link internal services or AI tools. When teams grant broad permissions, any client can run sensitive remote methods. How the json rpc protocol works This spec uses a simple message format to run remote functions across networks. Every request holds a version tag, a method name, and input values. It also holds

JSON Web Tokens (JWT) + Model Context Protocol (MCP) Security: the complete guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free white paper. No spam. Unsubscribe anytime.

The json rpc protocol lets apps call remote methods using plain text messages. A client sends a method name and inputs, and the server returns a result. Teams often set up this system to link internal services or AI tools. When teams grant broad permissions, any client can run sensitive remote methods.

How the json rpc protocol works

This spec uses a simple message format to run remote functions across networks. Every request holds a version tag, a method name, and input values. It also holds a unique ID so the client can match responses.

The server reads the incoming message and finds the matching local function. It runs the logic using the input values from the client request. Then, the server sends back a reply with the exact same ID.

That reply holds either a result object or a structured error block. If a client does not need a reply, it sends a notification instead. Notifications leave out the request ID, and the server sends nothing back.

Apps can also group many calls into a single batch request array. The server processes each item in the batch and returns one combined response. This design works over web sockets, standard web calls, or local data streams.

Why transport rules leave method gaps

Standard network setups check who can reach the server endpoint at login. Teams often use API keys or transport certs to gate the initial link. Once a client passes that check, the transport pipe stays wide open.

The base spec does not include built-in rules for per-method permissions. Every method lives behind the same single network address and port. Standard web firewalls only see a generic post call to one path.

JSON Web Tokens (JWT) + Model Context Protocol (MCP) Security: architecture patterns and best practices

Continue reading? Get the full guide.

Free. No spam. Unsubscribe anytime.

Because all calls share one endpoint, network rules cannot block specific functions. A valid client can call a safe read method or a delete method. The server must check permissions inside the app code for every function.

When developers build new methods fast, they sometimes skip these manual checks. One missing check lets an approved client run dangerous commands in flight. Also, basic server logs only record the network hit, not the payload body.

How to secure remote method calls

First, teams should split read methods and write methods onto separate server endpoints. This step lets network rules block write calls from basic client roles. Second, validate all input shapes before the server runs any business logic.

Strict schema checks stop bad inputs from crashing the backend service process. Third, parse the message body to log the exact method name and caller. Clear logs help security teams audit which user ran a specific action.

Finally, redact sensitive fields in flight before responses reach the client app. Masking rules can rewrite emails, phone numbers, card numbers, or national IDs. This stops raw personal data from leaking into client logs or tool outputs.

Govern statements and responses across databases and APIs

Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.

First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.

Frequently asked questions

How does the json rpc protocol differ from REST?

REST maps actions to many URL paths using standard web verbs. This spec sends all method names inside payloads to one single endpoint.

What is a notification in this spec?

A notification is a one-way message that leaves out the request ID. The server runs the method but does not send a reply back.

How do batch requests handle single method failures?

The server runs every call in the batch on its own. It returns an array containing individual results and error objects for failed items.

Save the open-source gateway.

hoop is MIT-licensed infrastructure for controlling how AI agents reach production data. Star hoophq/hoop so you can inspect it, deploy it, or share it when your team starts governing agent access.