MCP (Model Context Protocol)
An open standard for plugging tools and data into AI apps, so one server works with any assistant instead of a bespoke integration each.
See it
What it is
MCP is an open protocol (JSON-RPC over stdio for local servers, HTTP for remote ones) that standardises how an AI client discovers and calls outside capabilities. A server exposes three things: tools the model can invoke, resources it can read, and prompts the user can pick. The host app owns the model and any permission prompts; your server answers requests and re-checks that whoever asked is allowed to. The point is the M times N problem: write one Linear server and every MCP-speaking client gets Linear, instead of every client building every integration.
Reach for it when you want your product usable from inside assistants and editors, or when a capability your own agent needs is worth reusing across projects. If the tool is only ever called by one codebase, plain tool calling in that codebase is less machinery for the same result.
Gotcha: every connected server's tool definitions sit in the context window on every turn. Ten servers with fifteen tools each is tens of thousands of tokens of menu, and tool selection gets worse as the list grows, so keep servers narrow and descriptions one line. Second gotcha: an MCP server is untrusted input, not just code. Tool descriptions and tool results land in the prompt, so a hostile or compromised server is a prompt injection channel with your credentials attached. Third gotcha: the tool annotations (read-only, destructive, and friends) are advisory hints for the host, not enforcement. Nothing in the protocol makes a client stop and ask before running a write, so the confirmation gate is the host app's job and authorization is still yours to check on every call.
Ask AI for it
Build an MCP server for our REST API using the official TypeScript SDK. Expose 5 tools (search, get, create, update, archive), each with a zod input schema and a one-line description written for a model to choose between, and return compact text results rather than raw JSON dumps. Set the read-only and destructive annotations correctly on every tool, then treat them as hints rather than protection: implement (or, if the host is not ours, document) an approval gate that previews the exact arguments before any write tool runs. Read the API key from an environment variable and never from tool arguments, and authenticate and authorize every call inside the server itself instead of assuming the client asked first. Validate every argument server side. Ship a stdio entrypoint for local use, and include the exact JSON config block a user pastes into their client to install it.