MCP

MCP (Model Context Protocol) is an open protocol that standardizes how AI applications reach external systems: data sources, tools and prebuilt workflows. It is not a model or a hosted service, but an interface description implemented independently on each side.

It carries JSON-RPC 2.0 messages and defines three roles: the host is the application that initiates connections, clients are the connectors inside the host, and servers provide context and capabilities. One host can run several clients, each holding one session with one server, and the host is what enforces the security boundary.

What a server can offer

Servers may expose three primitives, each driven differently:

• Resources: context and data identified by URI, such as files, database schemas or documents. Application-driven: the host decides how they enter the context.
• Prompts: templated messages and workflows that the user selects.
• Tools: functions described by JSON Schema that the model calls. Model-driven, so they get the tightest supervision.

What is actually available is settled during the initialization handshake, where both sides declare capabilities; anything not declared cannot be used. Clients discover tools with tools/list and call them with tools/call, and resources can be subscribed to for change notifications.

How the two sides connect

Two transports are standard, and both carry JSON-RPC messages:

• stdio: the client starts the server as a local subprocess and exchanges newline-delimited messages over standard input and output.
• Streamable HTTP: the server is an independent process exposing a single endpoint for POST and GET, optionally opening an SSE stream for server-to-client messages. It replaced the earlier HTTP+SSE transport.

The protocol is transport-agnostic, so custom transports are allowed as long as they keep the message format and lifecycle rules. Version and capabilities are negotiated at connect time, and over HTTP the protocol version travels in a header.

Where it fits in our stack

MCP is the language of our tool layer. Hermes Agent gets its capabilities through it, and MCPHub gathers the servers behind one entry point where we can see what each one offers and scope access. Process glue lives in n8n, and the servers run in containers. Small, single-purpose servers work best here, because that is what keeps permissions narrow.

What to watch

MCP’s own documentation states that the protocol cannot enforce security principles itself: consent, authorization and logging are up to the implementation.

• Tool descriptions are untrusted input. Annotations and descriptions must be treated as untrusted unless they come from a trusted server, and a description is not a decision.
• Human in the loop. A tool call can be arbitrary code execution, so the spec requires explicit user consent before a tool is invoked.
• Local servers are real risk. A server running locally with the user’s privileges can be a path to code execution, with little visibility into what it does.
• Authorization. The documented attack list includes the confused deputy problem, token passthrough, SSRF, state handle hijacking and mix-up attacks, all sharing one pattern: an intermediary acting with the wrong authority. Narrow scopes, exact redirect URI matching and per-client consent are the countermeasures.
• HTTP specifics. Origin validation is mandatory, local servers should bind to localhost only, and connections should be authenticated.

With those in place MCP is a predictable contract between the model and our systems. At CyberElectro every tool integration we build connects to the agents through this protocol: the capability is described once, and the system uses it from there.

Further reading

• Specification - the protocol text itself, versioned.
• Introduction to MCP - the short overview and entry point of the official documentation.
• modelcontextprotocol/modelcontextprotocol - repository of the specification and the schemas, with the TypeScript schema as the basis of the official text.