Json-rpc Based Protocol
A json rpc based protocol sends remote method calls using plain JSON text. Clients send a method name, input data, and a unique call ID to a server. Engineering teams use this design to run tools, query databases, and link backend services. Still, teams often grant broad permissions to the client role during initial setup. When that role has wide permissions, any method call can change or delete production data. How a json rpc based protocol works in practice The client and the server talk th
JSON Web Tokens (JWT) + Model Context Protocol (MCP) Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A json rpc based protocol sends remote method calls using plain JSON text. Clients send a method name, input data, and a unique call ID to a server. Engineering teams use this design to run tools, query databases, and link backend services. Still, teams often grant broad permissions to the client role during initial setup. When that role has wide permissions, any method call can change or delete production data.
How a json rpc based protocol works in practice
The client and the server talk through a simple, stateless message format. Every request carries three main parts inside a single JSON object. First, the method field names the exact action the server should run. Second, the parameters field holds the input values as an array or object. Third, the ID field gives the request a number or string tag.
The server reads the JSON text and looks up the named method. It runs the local function using the input values from the request. Then the server builds a reply object with the exact same ID tag. If the call works, the reply holds a result field with the output. If the call fails, the reply holds an error object with a code.
Clients can also send notification messages when they do not need a reply. A notification looks like a standard request, but it leaves out the ID field. The server runs the method and sends nothing back to the caller. Teams also group many calls into a single array to run batch work. The server processes the whole list and returns an array of matching replies.
Transport options and native permission setup
This protocol does not lock teams into one single network transport. Teams run it over HTTP, raw TCP sockets, WebSockets, or standard input pipes. Local tool runners often use standard input and output pipes on the same machine. Remote services usually pick HTTP or WebSockets so they can cross network borders.
Because the protocol itself has no built-in login rules, transport layers handle identity. Teams set up API keys, bearer tokens, or mutual TLS on the transport channel. Once the channel check passes, the server trusts the caller for that session. Many teams tie the server process to one shared service account or database role. Every method inside that server then runs with those exact same backend rights.
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.
What native setup solves and where gaps remain
Transport checks and service roles solve the basic problem of who can log in. They stop unknown hosts on the network from reaching the remote server endpoint. They also keep setup simple for developers who build new internal tools.
Still, transport checks only look at the outer connection when the session starts. They do not read the method name or the parameters inside each JSON call. A caller with a valid token can run read methods and destructive write methods alike. Standard web logs also record only the single HTTP path, not the inner method name. Security teams cannot see which specific actions ran or what data came back. Also, raw responses can return sensitive fields like emails, phone numbers, or card numbers. Masking rules must rewrite matched fields in results before they reach the client.
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 JSON-RPC differ from a standard REST API?
REST uses many URL paths and HTTP verbs to represent data resources. JSON-RPC sends all requests to one endpoint and puts the action name inside the JSON body.
What happens when a JSON-RPC call leaves out the ID field?
The server treats a request without an ID as a one-way notification. It runs the requested method right away, but it sends no reply back.
Why do standard HTTP logs miss JSON-RPC method details?
Every call hits the exact same URL path using the same HTTP POST verb. The actual method name and input values stay hidden inside the request body.