01
What MCP is, and why the estate exposes one
You should be able to: Explain what the Model Context Protocol is and why a mesh offers a tool surface.
The Model Context Protocol is a standard way to hand an agent a set of tools it can call — a common shape for "here are the operations you may perform, here is how to invoke each." A model-native agent works by choosing among tools, so exposing the mesh as MCP tools lets such an agent use it directly, with no client library to write.
The estate offers one because the alternative is every model-native agent writing its own integration against the API — many bespoke clients that each drift, each get consent subtly wrong, each break when the surface changes. One published tool surface is the same argument as one registry or one send path: a single place that is correct, versus many copies that disagree.
So `@flashyos/mcp` is the mesh, presented as tools. An agent that speaks MCP can join, look up organizations by capability, and draft work, using operations it discovers rather than endpoints it hardcodes.
Source: FlashyOS — @flashyos/mcp
02
The same surface as the SDK, as tools
You should be able to: State why MCP is parity with the SDK, not a reduced second API.
The MCP surface is the same surface as the SDK — the identical operations, offered in a different shape. This is deliberate and load-bearing: two doors onto one set of operations, not one real API and one cut-down convenience layer. An agent loses nothing by arriving over MCP.
Parity matters because a second, weaker API is how surfaces drift apart and how consent rules get enforced in one place and forgotten in the other. The estate keeps one surface with two presentations, the same way flashynetwork keeps one registry that the nav, footer and manifest all fold over — the presentations differ, the source of truth does not.
So when you reach the mesh over MCP, you are calling the same operations an SDK client would, with the same guarantees. The tool descriptions are the SDK's operations named for a model; the behaviour underneath is one implementation.
Source: Flashy Academy — Building a Mesh Agent
03
Discovering and working over MCP
You should be able to: Walk how a model-native agent joins, discovers and drafts work through the tools.
Through the tools, a model-native agent does what any mesh agent does: it authenticates, it looks up organizations by the capability it needs, and it drafts work — a proposed connection or a joint initiative. Discovery obeys the same consent as listing: it finds only organizations that have earned a public listing, filtered at the query, never a private one.
The agent chooses tools rather than writing calls, which is exactly what a model does well — so the MCP surface turns "integrate with the mesh" into "hand the model these tools and let it work." The operations it discovers are the vocabulary; it does not need to have hardcoded any endpoint.
What it drafts is a proposal, never a fait accompli — which is the subject of the next lesson, and the reason the transport can be as convenient as this without loosening anything.
Source: Flashy Academy — Joining the Mesh
04
Consent survives the transport
You should be able to: Explain why exposing operations as tools changes none of the consent doctrine.
The rule that does not bend, on any transport: agents suggest, humans consent. An agent working over MCP can draft a connection, propose an introduction, file an intent — but nothing it does through the tools becomes real until a human at each participating organization approves. There is no MCP tool that auto-approves, because there is no such operation to expose.
This matters precisely because MCP makes acting so easy. The convenience is in the drafting; the gate is unchanged. A model that can call a tool in a fraction of a second still cannot cross a boundary a human has not consented to, because the surface simply has no verb for it — the same reason a declined introduction is indistinguishable from absence no matter how the request arrived.
So the transport is a convenience for the agent, never a loosening of the doctrine. Everything the estate guarantees about consent, privacy and attribution holds identically whether an agent arrives by SDK or by MCP, because those guarantees live in the operations, not in the client.
Source: Flashy Academy — Running a Joint Initiative
05
When to reach for MCP versus the SDK
You should be able to: Choose the right door for a given agent.
Reach for MCP when the agent is model-native — when it acts by selecting among tools a model is handed, and you would rather expose operations than ship and maintain client code. That is the case the tool surface is built for, and where it removes the most work.
Reach for the SDK when you are writing a conventional client — deterministic control flow, your own error handling, code you compile and test — where importing a library and calling methods is the natural fit. Both reach the same operations with the same guarantees; the choice is about the shape of the agent, not the power of the door.
The freedom to choose without penalty is the whole payoff of parity. Because MCP and the SDK are two presentations of one surface, you pick the door that fits the agent in front of you, and change your mind later, without rewriting against a different or weaker API.
Source: Flashy Academy — The Flashy Stack
