DEV Community: nahat ser

MCP: A Complete Guide from Zero to Maximum, from Tools to Cross-Regional Discovery with Cryptographic Trust Scoring.

nahat ser — Tue, 07 Jul 2026 05:26:04 +0000

MCP stands for Model Context Protocol, and although most people treat it like just another API standard, the truth is that it is much more than that. At its core, it is a standardized protocol for context exchange between AI applications and servers, with built-in discovery and transport-layer authentication. It can be extended to serve as a compliance and governance layer depending on how you architect it, but its real power lies in the discovery mechanism and the standardization it brings. If you only use MCP to connect your agent to an API you are using 10% of what it can do. This article is for you to understand the other 90%, from the simplest concepts to the deepest ones, without needing to be a protocol expert, although by the end you will be a little more of one.

To understand why MCP is different, think about how a REST API works today, you have to read the documentation, understand the endpoints, build the calls, handle authentication, write code for every integration, and if the API changes your code breaks, with MCP the agent discovers everything in real time, you do not need external documentation because the MCP server describes itself, you do not need to hardcode URLs because the server tells you where it is, you do not need to handle authentication manually because the protocol injects the tokens for you, it is the difference between giving someone a map and giving them a GPS that updates itself, and when you understand this you realize that MCP does not compete with REST, it competes with the lack of standardization that makes every integration a new project.

The protocol runs over JSON-RPC 2.0, which is a lightweight standard for making remote calls, and each MCP server exposes three things, tools that the agent can invoke, resources that the agent can read, and prompts that the agent can use as templates, but the interesting part is not what it exposes but how it exposes it, because the MCP server does not just tell the agent "I have these functions", it also says "these are the parameters each one expects, these are the validation schemas, this is how you authenticate", all in a single JSON message, and if the server needs to update its API it simply changes its description and the agent adapts automatically, no code updates, no releases, no downtime.

There are two available transports as defined by the MCP specification, each with different use cases. Stdio for local development where the MCP server runs as a subprocess of the agent, and Streamable HTTP for production with remote servers where network latency matters. Most servers in production use Streamable HTTP because it is the most compatible with existing load balancing and TLS infrastructure, but discovery does not distinguish between transports — the agent receives the URL and decides how to connect based on the schema.

This is where MCP gets really interesting, because an agent should not need a configuration file to find tools, it should discover them automatically. The MCP spec defines initialization with capability negotiation and standard discovery methods like tools/list, but beyond that, you can build a multi-phase discovery architecture. The following is a proposed six-phase system based on my research and experience:

The first phase is local cache — if you have discovered servers before they are stored in memory and you use them instantly with no network calls. The second phase follows OAuth 2.0 Protected Resource Metadata (RFC 9728), where the agent requests a well-known configuration endpoint and the server responds with its capabilities, auth requirements, and tool definitions in a standardized JSON format. The third phase checks if known hosts have a /.well-known/mcp/server.json file following RFC 8615, which is like a business card that any server can have. The fourth phase queries the Anthropic Registry API at registry.modelcontextprotocol.io/v0.1/servers which is the public directory of MCP servers, like an app store but for agent tools. The fifth phase uses P2P gossip between trusted nodes where agents share discoveries like when your friends recommend a restaurant. The sixth phase checks community indexes on GitHub Topics and crates.io. All of this can happen in less than 2 seconds in hot cache mode and less than 10 seconds in cold mode, and the result is a list of verified servers with their capabilities, authentication, and trust level.

But discovering a server is only the first step, because once you have the list you need to know if you can trust each one, and this is where MCP has a security model that most people ignore until it is too late, and I am not exaggerating, MCP security research from Invariant Labs discovered tool poisoning vulnerabilities in public MCP servers, and the OWASP MCP Top 10 (2025) includes server-side risks like Tool Poisoning, Command Injection, and Supply Chain Attacks, so trust scoring is not optional.

Each MCP server should have a cryptographically signed card with SHA-256, and if you use Sigstore you can verify the signature without needing a central authority, like when you verify that a signed email really comes from who it says it comes from, there is also SLSA provenance which is an OpenSSF certification level that tells you how the server was built, whether it was built in a controlled environment, whether the dependencies are secure, whether the binary is bit-for-bit reproducible, SLSA L2-L3 attestations are recommended for production-grade MCP servers.

Trust scoring combines all of this into a formula that you can adapt to your needs. A simple version could be: Score = w1 × LatencyNorm + w2 × TrustScore + w3 × ComplianceMatch + w4 × Freshness, where TrustScore looks at the SLSA level, whether it has Sigstore, how fresh the last audit is, how many community endorsements it has, all weighted by region and by sector. Because if you are in Europe a server with high latency from Asia is not useful, and if you are in finance a server without SOC2 compliance is not useful either. Note that this formula is a proposal based on my experience — the MCP spec does not define a trust scoring system, so this is something each team builds for its own needs.

This is where MCP becomes truly complex and also truly interesting, because there is not a single MCP in the world, there are seven regional ecosystems that evolve differently and with different levels of maturity. In the United States the main registry is from Anthropic, backed by AWS Bedrock Gateway with OAuth Dynamic Client Registration, but a common challenge is that many servers still rely on static API keys rather than OAuth 2.1, which is a security concern because a leaked API key cannot be selectively revoked. In China the MCP ecosystem is still emerging, with domestic providers exploring MCP compatibility through community-driven adapters and bridges, but no unified registry exists due to data sovereignty regulations.

In Europe there is no central registry because the European digital strategy is federated, and each MCP server should ideally have a published security posture including OAuth 2.1 auth support, tool descriptions with input schemas, and transparency about data processing location, and the EU AI Act imposes transparency requirements in Article 13 and record-keeping in Article 12 that directly affect how MCP servers maintain audit trails.

In Japan the approach is zero trust with corporate SSO and physical hardware tokens for write operations, because METI establishes that autonomous decision-making requires explicit human intervention, and IPA promotes isolation in microsandboxes to prevent toxic agent flow attacks, where poisoned data from an external tool compromises the LLM, Japanese researchers have extensively documented this pattern and recommend hardened containers to prevent lateral movement.

In Korea Naver Cloud is integrating MCP compatibility into its HyperCLOVA X models, and there are community bridges like kimcp that map Naver Search, Maps, News, and Kakao APIs to MCP tools, Samsung uses a risk zone system of Green, Amber, and Red based on the potential impact of each tool execution, and PIPA establishes strict limitations on cross-border data transfer, meaning Korean domestic data must remain in Korean local infrastructure.

In the Middle East the UAE AI Act of 2026 classifies AI systems into four risk tiers, and organizations deploying MCP servers in regulated sectors should align their tool governance with these requirements, in Saudi Arabia SDAIA enforces AI Ethics Principles and PDPL which mandates absolute data localization, and authentication is through UAE Pass, a national electronic identity.

In India MeitY published the AI Governance Guidelines with 7 sutras requiring that MCP servers have extensive tool descriptions, transparent data lineage, and detailed telemetry for impact assessments, Singapore has IMDA AI Verify Toolkit v2.0 which is a testing framework rather than a registry, but financial sector MCP servers must pass AIVT Veritas integration plugins to demonstrate fairness and robustness before being authorized for autonomous execution.

Google launched A2A, Agent-to-Agent, in 2026 as a direct competitor to MCP, but the fundamental difference is that MCP is a client-to-server protocol where the agent discovers tools, while A2A is an agent-to-agent protocol where agents communicate with each other to coordinate and delegate tasks, and although they compete in some aspects, they are actually complementary, MCP for discovering and executing tools, A2A for agents to collaborate with each other.

The coming months will bring forced OAuth 2.1 standardization because today only 8.5% of servers use dynamic authentication and that is a huge security problem, SLSA L2-L3 attestations are recommended for production-grade MCP servers, integration with European verifiable credentials systems that will allow an MCP server to prove its origin without revealing its exact location, and KV cache sharing where MCP servers will be able to share inference cache between calls, meaning that if two agents ask the same question to the same server the second one gets the response in milliseconds instead of seconds, an order of magnitude improvement for shared cache patterns in agent meshes.

If you are building agents, your next move is not to build an API, it is to expose an MCP server, because the difference between an API and an MCP server is the difference between giving fish to an agent and teaching it to fish, an agent with a hardcoded API only knows how to do one thing, an agent with MCP discovery can find new tools, learn to use them, and adapt to new contexts without you touching a single line of code, and in a world where language models are increasingly capable but integration protocols are increasingly complex, the advantage goes not to the one who builds the smartest agent but to the one who builds the most connected ecosystem.

Glossary

A2A — Google's protocol for agents to talk to each other, similar to MCP but peer-to-peer.

CAC — Cyberspace Administration of China, regulates Chinese data sovereignty.

DNS-SD — Internet standard for discovering services by name, like searching for printers on a network.

Gaia-X — European initiative for data sovereignty, a federated data internet.

HITL — Human In The Loop, a person must approve certain operations before execution.

JSON-RPC 2.0 — Lightweight protocol for making remote calls, the language that MCP servers speak.

KV Cache — Temporary storage of previous model computations to avoid repeating them.

MCP — Model Context Protocol, protocol for agents to discover and use tools.

OAuth 2.1 — Delegated authentication standard, like allowing an app to access your data without giving it your password.

PIPA — Personal Information Protection Act of Korea, similar to GDPR but Korean.

SHA-256 — Hash function that generates a unique digital fingerprint of a file.

Sigstore — Cryptographic signing system without needing a central authority.

SLSA — Software supply chain security framework, levels 1 to 3.

Streamable HTTP — MCP transport over HTTP for remote servers.

UAE AI Act — United Arab Emirates AI Law 2026, classifies AI systems into 4 risk levels.

Verifiable Credential — Digital certificate verifiable without calling a central authority.

Why AI Agents in Banking Need a Proof Layer

nahat ser — Thu, 25 Jun 2026 08:05:39 +0000

The Question No One Can Answer

Picture this: a bank deployed an AI agent to help with transaction approvals. Three weeks later a regulator shows up and asks a simple question: "On June 3rd your agent approved transaction #8492 for $47,000 — why?"

The bank goes to check the logs. The logs say "approved." But they don't say why. The agent's reasoning is gone, the context is lost, and the logs live on the same server where the agent runs. There's no way to prove to an external auditor that the decision was correct without asking them to trust the bank's own infrastructure.

This is not a hypothetical problem. Banks right now are starting to use AI agents for real things — moving money, making decisions, talking to customers — and the question of "how do I prove what my agent did last week?" is one that most of them cannot answer today.

I know because I've been researching this for months. And I built something that tries to fix it.

The Problem With Logs

Logging is the default solution for tracking AI agents. Every framework writes logs. Every platform stores them. But logs have three problems that make them useless for regulated environments:

Logs can be changed. If someone with access to the server wants to modify a log entry, there's usually nothing stopping them. No signature, no chain, no external verification. A log is just a text file.

Logs depend on the server that produced them. If you want to verify what an agent did, you need to access the original system. You need to trust that the system wasn't tampered with. In banking, regulators want to verify things without needing to trust the bank's infrastructure.

Logs don't capture reasoning. Most logs record "what happened" but not "why the agent decided that." An AI agent's reasoning process is where the compliance value is. Logs usually just record the outcome.

Banks are required by regulations like the EU AI Act (which becomes active in August 2026) to keep records of high-risk AI system decisions. Article 12 specifically talks about automatic record keeping. But the regulation doesn't tell you how to do it — it just says you must.

What I Built — TraceProof

TraceProof is an open-source system I built in Rust that creates a signed record of each AI agent decision. Think of it like a chain of evidence that follows every step the agent takes, signed with cryptographic keys so anyone can verify it later without needing to trust the system that produced it.

Here is how it works at a high level:

Agent decides something → Record is created → Signed with private key
→ Added to the chain → Anyone can verify later with the public key

Each record contains:

What the agent decided
Why it decided that (the reasoning, inputs, context)
When it happened (timestamp)
A signature that proves the record wasn't changed after it was created

The key difference from logging is that TraceProof records can be verified offline by anyone who has the public key. A regulator can take the record, check the signature, and confirm that it is authentic without needing to contact the bank or access their servers.

Why Rust?

I chose Rust for TraceProof for three reasons:

Safety. Rust's type system prevents entire categories of bugs at compile time. When money is involved, memory safety is not optional. The Rust compiler catches problems that would be runtime crashes in other languages.

Performance. Cryptographic operations are CPU-intensive. Rust's zero-cost abstractions mean I don't have to choose between clean code and fast code. TraceProof handles signing and verification without adding noticeable latency to agent operations.

Ecosystem. Rust has excellent cryptographic libraries (Ed25519, SHA-256) that are well-audited and widely used. The cargo tooling makes dependency management predictable, which matters for supply chain security in regulated environments.

How It Connects to the FINOS Ecosystem

TraceProof is designed to work with the FINOS AI Governance Framework (AIGF). FINOS is the Linux Foundation project where Goldman Sachs, Citi, Morgan Stanley, and other major banks collaborate on open-source financial infrastructure.

I designed TraceProof to plug into the AIGF MCP Server (contributed by Citi in June 2026) as an evidence layer. The AIGF MCP Server handles governance policies for AI agents — what they can do, where they can access data, how they should behave. TraceProof adds the proof layer — the cryptographic records that show those policies were actually followed.

This combination is important because FINOS members have the governance frameworks but nobody has solved the evidence problem yet. That's the gap TraceProof fills.

The Current State

TraceProof is still early stage but the core is working. I've been building it since January 2026, it has 9 modules each with a clear responsibility, the core protocol for creating and verifying signed records is functional, and the MCP server integration allows it to connect with tools like filesystem and terminal access.

What I have today:

A working attestation protocol with Ed25519 signatures
A chain of records that can be verified offline
Memory systems (vector search, full-text search) for storing and retrieving records
Security layers: path sandbox, rate limiter, injection detection, budget controls
MCP server integration for filesystem and terminal access

What I'm working on next:

Full AIGF MCP Server integration
Better documentation and examples
Making it easier for banks to try without changing their whole setup

Why This Matters

The EU AI Act enforcement starts in August 2026. CNSA 2.0 (post-quantum cryptography) becomes mandatory in January 2027. Financial institutions that are deploying AI agents today need to start thinking about how they will prove what those agents did — not just log what they did.

I believe cryptographic attestation will become a standard part of AI agent infrastructure, just like logging and monitoring are today. TraceProof is my attempt to build that standard before the regulations force everyone to invent their own solutions in a hurry.

Try It or Contribute

TraceProof is source-available (PolyForm Shield license — free for non-commercial use, learning, and auditing) and available on GitLab:

https://gitlab.com/zuo-labs/zuo-vector-nexus

If you're from a regulated financial institution and want to evaluate it under a commercial license, reach out via the repository.

If you're working on AI governance in finance or just curious about cryptographic attestation, I'd love to hear your thoughts. Open an issue, send a PR, or leave a comment below.

If this article was useful, consider sharing it with someone who works on AI governance or banking compliance. Follow me on DEV.to for more about Rust, AI agents, and cryptographic infrastructure.

The repository is undergoing internal documentation and test organization for regulatory compliance — it will be publicly available on July 1, 2026.