Json-rpc Protocol
You use the json rpc protocol to send remote procedure calls formatted in JSON text. A client sends a method name and parameters, and the server returns a response object. Teams often set up this transport with shared keys or broad network access rules. When permissions are too wide, any client with a key can run high-risk server methods. How the json rpc protocol works in remote calls This remote call standard is a stateless and light way to run actions across systems. It does not care which
JSON Web Tokens (JWT) + Model Context Protocol (MCP) Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You use the json rpc protocol to send remote procedure calls formatted in JSON text. A client sends a method name and parameters, and the server returns a response object. Teams often set up this transport with shared keys or broad network access rules. When permissions are too wide, any client with a key can run high-risk server methods.
How the json rpc protocol works in remote calls
This remote call standard is a stateless and light way to run actions across systems. It does not care which transport pipe you use to send the text messages. Teams often send these messages over standard web connections, raw sockets, or local pipes. Every single request message uses a basic text map with four main parts. First, the message specifies the exact protocol version so both sides agree on the rules. Second, it states the method name, which tells the server which action to run. Third, it includes the parameters, which hold the input data for that specific action. Fourth, it carries an ID tag so the client can match answers to requests.
When the server finishes the job, it sends back a response with the same ID. If the action works, the response carries a result field with the output data. If the action fails, the response carries an error block with a code and message. Sometimes a client needs to send a fast event without waiting for any answer. In this case, the client sends a notification message that leaves out the ID tag. The server reads the notification and runs the task, but it sends nothing back. A client can also pack many call objects into one list for batch work. The server runs each item in the list and returns all answers together.
What transport setup solves and what it misses
Because the standard defines only message text, it includes no built-in security or login rules. Teams must wrap the message pipe in transport encryption and add a login check. Usually, engineers set up web servers to check bearer tokens or static keys at login. This step proves which app or user is trying to reach the remote endpoint. It blocks outside attackers who do not hold a valid key from sending requests.
Still, transport login checks only control who can reach the main server endpoint. Unlike web APIs that use different URLs for each action, this standard uses one path. Every single method call goes to the exact same network address as a text payload. Standard network firewalls and basic web checks only see traffic hitting that single path. They do not read inside the text body to check which method is running. Once a user logs in, they can often call any method on that server. They might run admin actions or pull large records with emails and phone numbers. Transport setup decides who logs in, not what individual calls do in flight.
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.
Managing method rules and sensitive data in flight
To secure these services, teams must check each call at the method level. App code can check user roles before running sensitive functions, but code checks vary across services. When a team runs dozens of internal services, keeping role checks even is hard work. A better design inspects the message body before the call reaches the back-end app. Checking the method field lets teams block dangerous admin calls from regular user roles. Teams also need clear audit logs that record the exact method name and caller identity. Finally, inspecting response payloads lets teams spot sensitive fields like card numbers or national IDs. Masking rewrites matched fields in results so raw private data does not leak to clients.
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 runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How does the json rpc protocol handle requests that need no reply?
The client sends a notification message by leaving out the request ID field. The server runs the requested method right away and sends no response message back.
Why do standard web firewalls struggle to restrict specific remote methods?
All calls in this protocol usually travel to one single URL endpoint as text payloads. Standard web rules check URL paths and headers rather than parsing the inner method name.
Can a client send multiple procedure calls in a single network request?
Yes, a client can group several request objects inside one JSON array as a batch. The server processes the calls and sends back an array of matching response objects.