I was in the same boat in regards to trying to find the actual JSON that was going over the wire. I ended up using Charles to capture all the network requests. I haven't finished the post yet, but if you want to see the actual JSON I have all of the request and responses here https://www.catiemcp.com/blog/mcp-transport-layer/

I had the same frustration and wanted to see "under the hood", so I coded up this little agent tool to play with MCP (sse and stdio), https://github.com/sunpazed/agent-mcp

I really is just json-rpc 2.0 under the hood, either piped to stdio or POSTed over http.

For MCP I found the tutorials at https://github.com/block/goose made it click for me.

It's shown in the link below. It's kind of crazy that they have this huge corporate announcement with 50 logos for something that under the hood seems sort of arbitrary and very fragile, and is probably very sensitive to things like exact word choice and punctuation. There will be effects like bots that say "please" and "thank you" to each other getting measurably better results.

https://google.github.io/A2A/#/documentation?id=multi-turn-c...

https://modelcontextprotocol.io/docs/concepts/transports#mes...

https://modelcontextprotocol.io/quickstart/client

You weren't kidding with the endorsements. It's endorsed by KPMG, Accenture and BCG. McKinsey and PwC are not in the partner list but are mentioned as contributors. Honorable mention to SAP as another company whose endorsements are a warning sign

https://www.youtube.com/watch?v=5_WE6cZeDG8 - I work at an industrial software company. You can kind of think of us as an API layer to factory data, that is generally a mess. This video shows you what MCP can do for us in terms of connecting factory data to LLMS. Maybe it will help. A2A is new to me, and I need to dig in.

Basically if we expose our API over MCP, agents can "figure it out". But MCP isn't secure enough today, so hoping that gets enhanced.

It seems companies figured introducing "protocols" or standards helps their business because if it catches on, it creates a "moat" for them: imagine if A2A became the de facto standard for agent communication. Since Google invented it and already incorporated in their business logic, it would suddenly open up the entire LLM landscape to Google services (so LLMs aren't the end goal here). Microsoft et al. would then either have to introduce their own "standard" or adopt Google's.

It is quite hard to reliably and consistently connect deterministic systems and goals with nondeterministic compute. I don't know if all of this will ever be exactly what we want.

Agreed. At the end of the day we are talking about RPC. A named method, with known arguments, over the wire. A simple HTTP request comes to mind. But that would just be too easy. Oh wait, that is what all of these are under the hood. We are so cooked.

    from fastmcp import FastMCP

    mcp = FastMCP("Demo ")

    @mcp.tool()
    def add(a: int, b: int) -> int:
        """Add two numbers"""
        return a + b

Take a look at the samples: https://google.github.io/A2A/#/documentation

Hi there! If you load the CLI demo in the github repo (https://github.com/google/A2A/tree/main/samples/python/hosts...) you can see what the A2A servers are returning. Take a look!

>the endorsements at the end somehow made this seem worse

holy cow you weren't kidding. legit the last people i would trust with software development.

I wasn't around for WSDL so please correct me if I am wrong - but the main weakness of WSDL was that no applications were able to take advantage of dynamic service and method discovery? A service could broadcast a WSDL but something needed to make use of it, and if you're writing an application you might as well just write against a known API instead of an unknown one. LLMs promise to be the unstructured glue that can take advantage of newly-discovered methods and APIs at runtime.

Some of us are still building new products with XML RPC techniques.

WSDLs and XSDs done right are a godsend for transmitting your API spec to someone. I use .NET and can call xsd.exe to generate classes from the files in a few seconds. It "just works" if both sides follow all of the rules.

The APIs I work with would be cartoonish if we didn't have these tools. We're talking 10 megabytes of generated sources. It is 100x faster to generate these types and then tunnel through their properties via intellisense than it is to read through any of these vendors' documentation.

We have already been through some generations of this rediscovery an I've worked at places where graphql type importing, protobuf stub generation etc. all worked in just the same way. There's a post elsewhere on HN today about how awesome it is to put your logic _in the database_ which I remember at least two generations of, in the document DB era as well as the relational era.

If there's one thing I've observed about developers in general, it's that they'd rather build than learn.

XHTML 2.0,WML,SOAP, APPN,WAP...for each new technology there's thousands of failed protocol.

software engineering IS perpetual rediscovery of the Same.

don't forget CORBA and OSGi

haha, funny, I was thinking the same thing!

Hi there (I work on a2a) - A2A works at a different level than MCP. We are working with partners on very specific customer problems. Customers are building individual agents in different frameworks OR are purchasing agents from multiple vendors. Those agents are isolated and do not share tools, or memory, or context.

For example, most companies have an internal directory and internal private APIs and tools. They can build an agent to help complete internal tasks. However, they also may purchase an "HR Agent" or "Travel Assistant Agent" or "Tax Preparation Agent" or "Facilities Control Agent". These agents aren't sharing their private APIs and data with each other.

It's also difficult to model these agents as structured tools. For example, a "Tax Preparation Agent" may need to evaluate many different options and ask for specific different documents and information based on an individual users needs. Modeling this as 100s of tools isn't practical. That's where we see A2A helping. Talk to an agent as an agent.

This lets a user talk to only their company agent and then have that agent work with the HR Agent or Travel Booking Agent to complete complex tasks.

> I think I can safely say which one will still be around in 6 months

LangChain is still around but that doesn't mean much. MCP isn't much better.

If an agent could wrap itself in an MCP server, would that make A2A redundant?

Every decade or so we just forget that in-band signaling is a bad idea and make all the same mistakes again it seems. 1960s phone companies at least had the excuse of having to retrofit their control systems onto existing single-channel lines, and run the whole operation on roughly the processing power of a pocket calculator. What's our excuse?

From the spec:

https://modelcontextprotocol.io/specification/2025-03-26/ser...

“ For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations.

Applications SHOULD:

Provide UI that makes clear which tools are being exposed to the AI model Insert clear visual indicators when tools are invoked Present confirmation prompts to the user for operations, to ensure a human is in the loop”

Should security be part of the protocol? Both the host and the client should make sure to sanitize the data. How else would you trust a model to be passing "safe" data to the client and the host to pass "safe" data to the LLM?

Thanks for sharing your notes! I will add them to Awesome MCP Security https://github.com/Puliczek/awesome-mcp-security :)

> the patterns it encourage

Let's start with fixing the examples...

https://github.com/modelcontextprotocol/servers/issues/866

It seems the industry as a whole just forgot about prompt injection attacks because RLHF made models really good at rejecting malicious requests. Still, I wonder if there have been any documented cases of prompt attacks.

I agree with your opinion here, not sure we should refer to it as MCP security however, given that 'MCP doesn't have security flaws in the protocol itself'

we also recently published our approach on MCP security for mcp.run. Our "servlets" run in a sandboxed environment; this should mitigate a lot of the concerns that have been recently raised.

https://docs.mcp.run/blog/2025/04/07/mcp-run-security

Feels critical right now to sandbox mcps in containers while the security side of things catches up.

great writeup! so what's the solution?

is it only use pre-vetter "Apple Store" of known good MCP integrations from well known companies, and avoid using anything else without proper review?

the interface is light, but we're taking this in a direction to better secure/govern MCP

https://github.com/eqtylab/mcp-guardian/

https://www.eqtylab.io/blog/securing-model-context-protocol

That's the first step to creating a protocol. The next step is to formalize it, publish it, and get others to adopt it. That way, it's one less thing for LLMs to hallucinate on. Otherwise everyone has different conventions and LLMs start making stuff up. That's all these are.

Eventually agents from different providers will come into play. It's important to agree on a standard for accurate interoperability.

Ideally, the model providers would then build for the protocol, so the developers aren't writing spaghetti code for every small difference

> Can't we just have a set of best practices around API endpoints/functions? Like, imo we could just keep using Rest APIs and have a convention that an agent exposes endpoints like /capabilities, /task_status ...

To make this work at scale we all need to agree on the specific routes names, payloads, behaviors, etc. At that point we have defined a protocol (built on top of HTTP, itself a lower level protocol).

>so they can sell it back to you via “search.”

>transfer your private textual data to them

Who is "they" (or "them") in these sentences? It's an open protocol with 50 partner companies, which can be used with AI agents from ~anyone on ~any framework. Presumably you can use this protocol in an air-gapped network, if you'd like.

Which one of the 50 partner companies is taking my data and building the moat? Why would the other 49 companies agree to a partnership if they're helping build a moat that keeps them out?

This is insanely cynical. The optimistic version is that many teams were already home-rolling protocols like A2A for "swarm" logic. For example, aggregation of financial data across many different streams, where a single "executive" agent would interface with many "worker" high-context agents that know a single stream.

I had been working on some personal projects over the last few months that would've benefitted enormously from having this kind of standard A2A protocol available. My colleagues and I identified it months ago as a major need, but one that would require a lot of effort to get buy-in across the industry, and I'm happy to see that Google hopped in to do it.

I’ll just demand my data in machine readable form under GDPR?

https://gdpr-info.eu/art-20-gdpr/

Hi there (I work on a2a) - reposting from above.

We are working with partners on very specific customer problems. Customers are building individual agents in different frameworks OR are purchasing agents from multiple vendors. Those agents are isolated and do not share tools, or memory, or context.

For example, most companies have an internal directory and internal private APIs and tools. They can build an agent to help complete internal tasks. However, they also may purchase an "HR Agent" or "Travel Assistant Agent" or "Tax Preparation Agent" or "Facilities Control Agent". These agents aren't sharing their private APIs and data with each other.

It's also difficult to model these agents as structured tools. For example, a "Tax Preparation Agent" may need to evaluate many different options and ask for specific different documents and information based on an individual users needs. Modeling this as 100s of tools isn't practical. That's where we see A2A helping. Talk to an agent as an agent.

This lets a user talk to only their company agent and then have that agent work with the HR Agent or Travel Booking Agent to complete complex tasks when they cannot be modeled as tools.

Morden software consists of separation of responsibilities between services and a higher plane orchestrating the data flow for business logic.

If you believe there is value in fuzzy tasks being done by LLMs then from that it follows that having separate "agent" services with a higher order orchestrator would be required. Each calling LLMs on their own inside.

It's not so much about what you _can do_ but about the messaging and posturing, which is what drives the adoption of standards as a social phenomenon.

My team's been working on implementing MCP-agents and agents-as-tools and we consistently saw confusion from everyone we were selling this into (who were already bought in to hosting an MCP server for their API or SDK) for their agents because "that's not what it's for".

Kinda weird, but kinda simple.

They are thinking about Enterprises. Shirley from accounting isn't going to install an mcp service to pull the receipt photos from Dropbox and upload them to SAP/Concur (expense reimbursement)

I suppose Google wants us to pretend that "agents" can't be "resources." MCP is already well established (Anthropic, OpenAI, Cursor, etc), so Google plastering their announcement with A2A endorsements just reeks of insecurity.

I figure this A2A idea will wind up in the infamous Google graveyard within 8 months.

That looks interesting from abstract. Can you please explain how these two can be interconnected ?

It's not so much about what you _can do_ but about the messaging and posturing, which is what drives the adoption of standards as a social phenomenon. My team's been working on implementing MCP-agents and agents-as-tools and we consistently saw confusion from everyone we were selling this into (who were already bought in to hosting an MCP server for their API or SDK) for their agents because "that's not what it's for".

Kinda weird, but kinda simple.

Would have made a similar comment if I hadn't found yours. Google starts to inspire the same bloaty feeling as MS. I feel sad

This is the type of comment that keeps me coming back to HN

Well done sir

MCP is stateful. They are currently developing stateless support. https://github.com/modelcontextprotocol/modelcontextprotocol...

I don't know if it would be right to call MCP pure request/response, since unlike HTTP, it's a stateful protocol.

> Worst case, writing a shim for an exact MCP capable server is a) probably not a big deal, and b) will probably be on GitHub this week or so.

That sounds exactly like the kind of thing I would outsource to an LLM. I think people over think the need for protocols here. Most AIs are already pretty good at figuring out how to plumb relatively simple things together if they have some sort of documented interface. What the interface is doesn't really matter that much. I've had good results just letting it work off openapi descriptions. Or generating those from server source code. It's not that hard.

In any case, MCP is basically glorified remote procedure calls for LLMs. And then Google adds a bit of probably necessary complexity on top of that (auth sounds important if we're connecting with third party systems). Long lived tasks and out of band data exchange sounds like it could be useful.

For me the big picture and takeaway is that a future of AIs using tools, some of which may be other AIs using tools communicating with each other asynchronously is going to be a thing. Probably rather soon. Like this year.

That puts pressure on people to expose capabilities of their SAAS services in an easily digestible form to external agents. That's going to generate a lot of short term demand from various companies. Most of whom are not really up to speed with any of this. Great times to be a consultant but beware the complexity that design by committee generates.

I largely agree with most of this. My only concern is that the spec is a bit underspecified.

For example I wish they'd specify the date format more tightly - unix timestamp, some specific ISO format, precision. Which is it?

The sessionID is not specified. You can put all sorts of crazy stuff in there, and people will. Not even a finite length is required. Just pick some UUID format already, or specify it has to be an incrementing integer.

Define some field lenght limits that can be found on the model card - e.g. how long can the description field be before you get an error? Might be relevant to context sizes. If you don't you're going to have buffer overflow issues everywhere because vibe coders will never think of that.

Authentication methods are specified as "Open API Authentication formats, but can be extended to another protocol supported by both client and server". That's a recipe for a bunch of byzantine Enterprize monstrosities to rear their ugly heads. Just pick one or two and be done with it.

The lesson of past protocols is that if you don't tightly specify things you're going to wind up with a bunch of nasty little incompatibilities and "extensions" which will fragment the ecosystem. Not to mention security issues. I guess on the whole I'm against Postel's Law on this.

I think MCP could totally evolve to support the same features A2A offers. Most of what A2A does feels like it could be layered onto MCP with some extensions — especially around auth, discovery, and out-of-band handling. If MCP maintainers are paying attention, they'd probably just adopt the good bits. Wouldn’t be surprised to see some convergence.

MCP docs say it's like USB for your AI model. A2A sounds more like a networking stack for multiple AI models.

Hi there - I work on a2a. Thanks for the reaction - lots of good points here. We really do see a2a as different and complementary to MCP. I personally am working on both and see them in very different contexts.

I see MCP as vital when building an agent. An agent is an LLM with data, resources, tools, and services. However, our customers are building or purchasing agents from other providers - e.g. purchasing "HR Agent", "Bank Account Agent", "Photo Editor Agent", etc. All of these agents are closed systems and have access to private data, APIs, etc. There needs to be a way for my agent to work with these other agents when a tool is not enough.

Other comments you have are spot on - the current specification and samples are early. We are working on many more advanced examples and official SDKs and client/servers. We're working with partners, other Google teams, and framework providers to turn this into a stable standard. We're doing it in the open - so there are things that are missing because (a) its early and (b) we want partners and the community to bring features to the table.

tldr - this is NOT done. We want your feedback and sincerely appreciate it!

An endpoint implementing this protocol would describe the agent and its capabilities, including examples. So I guess you could index that and create a discovery service.

I'm glad someone else saw this. This is one of the few areas you wouldn't want to show off what you're doing with AI.

This is the reality, unfortunately.

Lots of jobs that focus on communication and data organization are out the window, including recruiters.

It's not so much about what you _can do_ but about the messaging and posturing, which is what drives the adoption of standards as a social phenomenon.

My team's been working on implementing MCP-agents and agents-as-tools and we consistently saw confusion from everyone we were selling this into (who were already bought in to hosting an MCP server for their API or SDK) for their agents because "that's not what it's for".

Kinda weird, but kinda simple.

Hi there (I work on a2a) - reposting from above.

A2A works at a different level than MCP. We are working with partners on very specific customer problems. Customers are building individual agents in different frameworks OR are purchasing agents from multiple vendors. Those agents are isolated and do not share tools, or memory, or context.

For example, most companies have an internal directory and internal private APIs and tools. They can build an agent to help complete internal tasks. However, they also may purchase an "HR Agent" or "Travel Assistant Agent" or "Tax Preparation Agent" or "Facilities Control Agent". These agents aren't sharing their private APIs and data with each other.

It's also difficult to model these agents as structured tools. For example, a "Tax Preparation Agent" may need to evaluate many different options and ask for specific different documents and information based on an individual users needs. Modeling this as 100s of tools isn't practical. That's where we see A2A helping. Talk to an agent as an agent.

This lets a user talk to only their company agent and then have that agent work with the HR Agent or Travel Booking Agent to complete complex tasks.

A2A isn't a layer of abstraction over MCP, it functions in parallel and they complement each other. MCP addresses the Agent-to-Environment question, how can Agents "do things" on computers. A2A addresses the Agent-to-Agent question, how can Agents learn about other Agents and communicate with them. You need both.

You CAN try and build "the one agent that does everything" but in scenarios where there's many simultaneous data streams, a better approach would be to have many stateful agents handling each stream via MCP, coupled with a single "executive" agent that calls on each of the stateful agents via A2A to get the high-level info it needs to make decisions on behalf of its user.

Of course, there is Ironwood announce too: https://blog.google/products/google-cloud/ironwood-tpu-age-o...

The way they're framing this attempts to stave off disintermediation, which is the real threat.

Partner list includes Accenture, Capgemini, Cognizant, HCL, InfoSys, KPMG, and Wipro. I think it’s fair to say that the generative capability of A2A is the generation of billable hours.

As I understand it, it enables SaaS for Agents, along with the associated consumption and billing. All of those partners are going to have some kind of agent subscription for you to plug into your enterprise LLM of choice.

I see this as Slack bots 2.0. Maybe this will create real revenue opportunities where the original chatops didn't.

Adapting the capabilities of existing SAAS software for use by agentic AIs. This is not a small market. Anybody with any kind of software that does anything mildly valuable is going to look at ways to get in on the action via protocols like this. I know of several companies that have been exploring possibilities for this.

That depends very much on which of the dozen+ definitions of "agent" you are using.

agents are just the rebranded version of automated workflows and sometimes its an LLM doing the validation

[dead]

How does MCP not use existing standards when the reference transport is SSE on HTTP with a JSON RPC payload?

Something else I just thought about:

Agent2Agent in an unsupervised environment could easily lead to the first Agentic worms. It's not hard to imagine a few agents talking to one another with the right prompt injection attacks that could end up spreading to other agents via A2A.

This is of course just speculation but I could definitely see this as being a big enabler of that possibility.

The google angle here isn't even so much on the LLM side but on Google Cloud

See all those shiny badges for consulting firms? If you are a truely thought leadershiping executive, you should get one of them in ASAP to build you an A2A Registry [1] for your "Enterprise Agents" [2] to communicate via an A2A NotificationService [3] (brought to you by GCP!)

Indicative that the blog post example isn't help book a holiday but help hire a software engineer

1: https://google.github.io/A2A/#/topics/agent_discovery

2: https://google.github.io/A2A/#/topics/enterprise_ready

3: https://google.github.io/A2A/#/topics/push_notifications

edit:

> Updates to Agentspace make it easier for customers to discover, create and adopt AI agents. We're also growing the AI Agent Marketplace https://console.cloud.google.com/marketplace/browse?filter=c... , a dedicated section within Google Cloud Marketplace where customers can easily browse and purchase AI agents from partners.

https://blog.google/products/google-cloud/next-2025/

MCP was originated at Anthropic, and has been adopted by OpenAI, Github, Cloudflare, and more.

It's completely open, with active engagement and direction from the community:

https://github.com/modelcontextprotocol/modelcontextprotocol

I don't think it would have such wide adoption so rapidly if it were an "over-engineered implementation".

> MCP itself is also an over-engineered implementation of AI plugins by OpenAI

I'm confused by this comment and a reply that both seem to be under this assumption... first, it's from Anthropic, and second, it's hardly over-engineered. If you actually go and try and implement a specific MCP server's functionality from first principles into, say, some chat client of your choosing, you will quickly run into the problems that MCP addresses.

Marginally technical executives are really dangerous here. My CTO is "all in" on MCP but fails to see it's an over-engineered attempt by one player to own the thin veneer on top of the bog-standard plumbing that's actually doing all the work. It's like OpenAI made an ODBC database connector and is saying "we created relational databases!"

"The better approach is to simply use open standards that already exists"

Which ones?

Wasn't XML supposed to be this holy grail of interop as well?

Now we can have 4 router startups on top of this

1. Agents don't know the APIs. This is a way for you to declare them.

2. You get to decide what functionality you want to expose agents to.

3. An API enables reliable tool use.

yeah - I don't get it. I'm all for abstraction but the entire point of using agents at the UX-level is you didn't need a single agreed-upon protocol to make it work. Feels like they're using the old Microsoft fire and motion strategy to keep people busy on their tech, or artificially introduce structure & coupling that - suprise - benefits the maker of shovels, not the diggers.

shhhh - that's the big announcement for next year - the "Agnostic" General Interface (AGI) ... works with any endpoint no more lengthy MCP or A2A setup!

Did you watch the video? Do you have opinions on it? On MCP? On A2A? What is a title of youtube video and a link to it supposed to add here? Just start a new submission if you just want to link to it.

See how they didn't choose lawyers, bankers, or government civil servants?

Analysts, digital artists, customer service support and journalists of all levels have already been replaced.

Software engineers (of all levels) are the next knowledge workers to be replaced by agents.

If A2A doesn't bring in ad revenue, it will be in the graveyard in a year or two.