RWA MCP Server
A production MCP server giving internal AI assistants typed, audited access to company systems.
Why there is no measurement
Measured internally at RWA — not mine to publish
No measurement
Why not
This ran in production and its effect was measured internally, but those numbers are RWA's rather than mine and are not mine to publish. I would rather show the gap than publish a figure I cannot let anyone check, or quietly leave the project off the site because the result is inconvenient to evidence.
Problem
Internal AI assistants were being wired to company systems one integration at a time. Every new tool meant another bespoke client, another auth path and another place for a model to be handed more access than the task needed. The cost was not novelty — it was that nobody could answer, in one place, what the assistants could actually reach.
Approach
A single MCP server as the boundary. Tools are declared with typed schemas so the model's calls are validated before they reach a system rather than after, access is scoped per tool rather than per assistant, and calls are logged so the question "what did it do" has an answer that does not depend on the model's own account of itself.
Why a server rather than more integrations
The failure mode with assistant tooling is not that any single integration is hard. It is that the tenth one is written the same way as the first, and by then no one person can enumerate what the assistants can reach. Access ends up described by whichever engineer last touched a client.
Putting one MCP server in front of the systems moves that question to a place where it can be answered. The set of tools is a list. The scope on each tool is a property of the tool, not of the caller. Adding capability is an edit to a declaration rather than a new code path with its own auth story.
The typed boundary
Tool schemas are the part that earns its place. A model producing arguments for a tool call is producing structured output under exactly the conditions that make structured output unreliable — long context, ambiguous instructions, a plausible-looking wrong answer available.
Validating at the boundary means a malformed call fails as a validation error with a message the model can act on, instead of reaching the downstream system and failing there as something harder to attribute. It converts a class of silent misbehaviour into a loud, local one.
What is deliberately absent here
No client names, no internal metrics, no architecture diagram of an RWA system. The employer boundary in this site’s content rules is not a formality: this is a live production system belonging to my employer, and the interesting details are exactly the ones that are not mine to give away.