Tools with contracts
Clear schemas, bounded outputs, useful errors, and permissions scoped to each action.
AI systems / MCP
Drag or use arrow keys to orbit
MCP servers
Secure, typed tool servers that connect models to the systems where useful work happens.
What we build
Clear schemas, bounded outputs, useful errors, and permissions scoped to each action.
Authentication, observability, retries, and deployment designed around the current protocol.
Tool descriptions and responses stay concise enough to preserve the model’s working context.
The route to production
We map the real workflow, risks, users, and success measure before choosing an implementation.
Working software lands in visible increments, with the hardest assumptions tested first.
We validate against production-shaped data, failure paths, performance, and real use.
Deployment, monitoring, documentation, and a clean handover are part of the build.
Verified client reviews
“Everything was set up perfectly and worked exactly as we needed. Super professional, easy to communicate with, and delivered right on time.”
“Very knowledgeable. Deployed my project successfully and was kind and patient throughout.”
Before you ask
MCP is the protocol a model uses to discover and call your tools at runtime. An MCP server is the layer that publishes a curated set of those tools — each with a schema, a permission scope and a bounded response — so an agent can act inside your systems instead of only talking about them. You need one when a model has to decide which capability to invoke, rather than following a sequence you already wrote.
Ask who makes the calling decision. If your code decides what to call at development time — a webhook handler, a scheduled sync, a checkout hitting a payment API — direct integration is faster, more predictable and easier to debug. MCP earns its place only where an agent chooses the capability at runtime. The two are not rivals: an MCP server is almost always ordinary API integration underneath, applied at the boundary where an agent meets your tools.
No. An MCP server is normally a thin layer in front of the API or service layer you already run, re-presenting a curated slice of it in the shape an agent can use. If the underlying API is clean, this is genuinely a layer on top. If it is tangled, the tool design tends to surface that — uncomfortable, but better found now than after an agent starts calling it.
Tool schemas are injected into the model's context on every request, whether or not a tool is called, so verbose descriptions tax every turn permanently. We measured 20 popular servers with our open-source tooltax: they range from 237 tokens to 17,430, and loading all of them at once would consume 36.7% of a 200,000-token window. We design tools to a token budget and measure it, rather than discovering the cost in the bill.
It can be, but the safety is not automatic. An MCP server hands your authority to a probabilistic caller that can be influenced by content it reads, so the threat model differs from a normal API. Per-user token scoping, OAuth rather than a static long-lived key, strict output schemas and explicit gates on destructive actions are the load-bearing work. We treat the security pass as required, not a formality.
You cannot make the model immune, so the defence is containment. The agent builds tool arguments from context that may include text an attacker wrote — a web page, a support ticket, an uploaded file — so we give each tool the least authority it needs, validate inputs, constrain what tool results can instruct, and gate anything irreversible behind approval. A manipulated model should have a small blast radius.
You can, and it demos quickly, but it usually makes a poor product. Generation produces one thin tool per endpoint, leaving the model to chain overlapping tools and regularly pick the wrong one — while paying for all of their descriptions on every request. It is a reasonable proof of concept. A server people depend on wants hand-designed, task-shaped tools with descriptions written for the model that reads them.
In layers. The MCP Inspector proves the wire works, not that the tool is usable. Contract tests drive the server through a real client so schemas, errors and permissions are exercised as they will be in production. Evals cover the model's side of the contract — does it pick the right tool and call it correctly — and traces show what actually happened once it is live. Errors are written as messages the model can act on, not stack traces.
Both, chosen to match the system the server sits in front of. The discipline is the same either way: stdout belongs to the protocol rather than your logging, a blocking call stalls the whole server, the type hints and schemas are the API the model actually sees, and a tool should return less than it has so the response does not flood the context window.
The MCP spec and the clients that implement it are still changing, so a server is not a one-off artefact. We ship with observability on tool calls, keep transport and authentication current as the protocol evolves, and re-measure schema cost when tools change. Where a client updates in a way that breaks a call pattern, the traces show it before your users do.
From the journal
Start with a paragraph, a Figma, or a Loom.
Build this properly.Reply within one business day · one clear scope · one fixed number