More developers now integrate tools by describing what they want to a coding agent — Cursor, VS Code, Claude Code — rather than clicking through a dashboard. The Model Context Protocol (MCP) is what lets those agents act on real systems. Here’s how we think about building an MCP server that agents can use to do actual work, not just answer questions.
What MCP is, briefly
MCP is a standard way to expose tools (callable actions) and resources (readable context) to an AI agent. Instead of every product inventing its own agent plugin, an MCP server describes its capabilities in a common format, and any MCP-capable agent can discover and call them. For a product like Qanary, that means an agent can create referral links, set commission rules, or read program stats — from the terminal.
Design principles for an agent-usable server
1. Tools should map to intent, not endpoints
A thin wrapper over your REST API (“call POST /v1/links”) makes the agent do all the reasoning. Better: expose a tool like create_referral_link(affiliate, campaign) that encapsulates the sensible defaults. The closer a tool is to what a user wants, the more reliably the agent uses it correctly.
2. Make inputs self-describing
Every tool parameter needs a clear name, type, and description. Agents choose arguments from these schemas, so ambiguity there becomes a wrong call. Enumerate allowed values, mark required fields, and validate server-side.
3. Return structured, actionable results
When a tool succeeds, return the created object and a next step. When it fails, return why in plain language the agent can act on (“commission rate must be between 0 and 100”) rather than an opaque code. Good error text turns a dead end into a self-correcting retry.
4. Be safe by default
Agents will call your tools autonomously. Scope credentials tightly, make destructive actions explicit and confirmable, and never expose a tool that can’t be undone without a guardrail. Idempotency keys help when an agent retries.
The setup experience this unlocks
With a well-designed MCP server, installing an affiliate program becomes a conversation: the developer describes the program, the agent creates the links, wires the webhook, and sets commission rules over MCP — no dashboard tour. That’s the core of Qanary being “agent friendly,” and you can see the end-user side of it on the AI agent page.
Under the hood this still relies on solid first-party attribution — MCP is the control surface, not the tracking.
FAQ
What is an MCP server?
A server that exposes tools and context to AI agents through the Model Context Protocol, so any MCP-capable agent can discover and call them in a standard way.
Why expose a product through MCP instead of just an API?
An API assumes a human (or bespoke code) does the reasoning. MCP lets an AI agent discover intent-level tools and act directly, which is what makes terminal-driven, no-dashboard setup possible.
How do you keep an MCP server safe for autonomous agents?
Tightly scoped credentials, explicit and confirmable destructive actions, server-side validation, and idempotency so retries don’t cause duplicate effects.
More engineering posts are in the Building Qanary hub.