A system worth building gets reached more than one way. A person uses it through the web, the mobile app, or the desktop app. A developer reaches the same platform from their own code, an SDK or a bare curl call carrying an API key or a bearer token instead of a login. An AI agent connects through an MCP server and does the work its owner would have done by hand. Each is a real need, and each raises the same questions about every single route in the product. Who is allowed to call this. Is it in the SDK a customer installs. Can a key reach it, or only a signed-in session. Can an agent call it through an MCP server, and if it can, is it safe to let it. A platform is thousands of answers to those questions, one route at a time, and where the answers live decides whether the platform holds together.

In most systems the answers are spread out. The permission check sits in the handler, or in a middleware table read three files away. Whether an endpoint is public was decided in the API gateway. Whether the client library exposes it is a line in a hand-maintained SDK. Whether an agent can reach it is a config file in whatever bolted the agent on last quarter. Each answer is somewhere reasonable. No single place holds all of them for a given route, so no one can look at a route and say with certainty everything that is true about who may call it and how.

None of the scattered answers is a mistake anyone makes on purpose. They are what happens when the answer to who can call this route lives in four places kept by four different habits. The gateway config drifts from the handler check. The hand-written SDK lags the API by a release. The agent scope was set once, under a deadline, and never revisited. Every one was right the day it shipped. The platform's real access rules end up as the intersection of four things nobody reads together.

That intersection is where the incidents live. An endpoint public that should have been internal. A permission enforced in the handler but not in the generated client, so the interface offers a button the API then refuses. An agent handed a tool nobody remembered was destructive.

Every route in Giant Context is defined by an OpenAPI schema, and the schema is where all of those answers live, next to the route itself, in its x- extensions.

That block is the whole configuration of the route. Its role requirement, its place in the public SDK, whether an unattended key may call it, whether an agent may call it, and what an agent should know about the risk of calling it are all declared in one place and read straight off the route they govern.

The same block carries more than access. A route exposed to an MCP server brings its own instructions for how the tool is used, and the hints that tell the server whether a call only reads or can change something that cannot be taken back. It carries the routes the tool applies to, so the in-app assistant offers it where it helps and holds it back where it would get in the way, like editing a page from the very dashboard you are editing it in. All of that travels with the route, in the schema, rather than in a separate prompt that drifts from what the route actually does. A route that runs on a clock carries its schedule, and nothing but the scheduler reaches it. A route meant only for development carries a flag that keeps it out of production entirely. A webhook declares the event it answers to. Whatever a route needs the rest of the system to know about it is said here, in the schema, and nowhere else.

This is why supporting many callers is not many problems. Every route already answers, in its own schema, who may reach it and through which surface. A person in the browser, a script with a key, and an agent with a granted scope are three callers arriving at the same routes rather than three integrations with three notions of access, and the same x- lines govern all of them. Add a way to sign in and you have added a way to arrive, not a new set of answers to write. The answers were finished when the routes were.

Most platforms treat a new way in as a new thing to secure, so their exposure grows every time their reach does. Here reach and access were never the same concern. Reach is how a caller arrives. Access is what the route already declared. Growing the first does not touch the second.

The simplest credential shows it. A script with an API key reaches exactly the routes that declared themselves reachable that way, gated by exactly the x-permissions a signed-in person meets. Once one caller is governed by the schema, the second and the third are not new engineering but new ways to arrive at routes that already define whether, how, and by whom they can be reached.

The agent is where declaring this early pays for itself. An agent is not a new kind of caller that needs a surface of its own. It is handed the routes that marked themselves callable, as tools, with the read-only and destructive hints the schema already carried. What an agent may reach and what it should fear come from the same lines that governed the route for everyone else, read by one more consumer.

An agent deciding whether to run a tool can read, from the tool itself, whether it only reads or whether it changes something that cannot be taken back. The route describes its own consequences rather than carrying a caution added at the agent layer, and the MCP server calling it is given that description because a machine has no other way to know.