Agent Tooling & MCP Servers

Problem

Agents are only useful against real systems if they get real access, and ad-hoc access to production APIs is a security hole. This tooling had to expose backend reads with the same rigour as any other service boundary: explicit contracts, validated inputs, least privilege, and an auditable output path.

What I built

• A stdio MCP server exposing backend reads as typed tools, with validated inputs, declared output schemas and read-only annotations.
• One sanitise boundary that every returned row passes through.
• A conventions skill that turns wrapping a new endpoint into a repeatable ten-minute job instead of a design debate.
• Workflow tooling for the team: typed service generation and design-token enforcement, encoded as reusable skills.

Technical decisions & trade-offs

• Read-only by default. Writes are an explicit, individually justified opt-in rather than a capability that arrives by accident.
• Database text is treated as untrusted content, never instructions, so injection is handled at the boundary rather than by hope.
• One sanitisation chokepoint instead of per-handler escaping, so a security review has a single place to look.
• Tool names and descriptions are treated as the real API surface — schema design is what determines whether an agent uses a tool correctly the first time.
• Conventions live as versioned documents beside the code, so the practice survives team changes.

Challenges solved

• Designing tool schemas an agent uses correctly without a retry loop, where the naming is the interface.
• Making the injection surface auditable rather than diffuse.

Outcome

Plain-language queries against production reads, safe by construction, now standard practice on the team. These servers run against production systems, so the credentials and data boundaries stay private — the reusable patterns live in the published packages instead.