Wiring Internal Tools Into Cursor With MCP
A practical build log on exposing an internal service to the editor through the Model Context Protocol — and why it changed how the team works.
Context switching is the silent tax on engineering. Every time you leave the editor to check an internal dashboard, you pay it. MCP let me bring that context to where the work already happens.
The Problem
Our deploy status, feature flags, and error rates all lived in separate tools. Answering "is this safe to ship?" meant four tabs and two Slack messages.
Investigation
MCP standardizes how a tool exposes capabilities to an AI client. Instead of building a bespoke plugin, I could describe a handful of resources and let the editor consume them.
The Solution
server.tool(
'deploy_status',
'Get the current deploy status for a service',
{ service: z.string() },
async ({ service }) => {
const status = await ops.getStatus(service)
return { content: [{ type: 'text', text: format(status) }] }
},
)
The Result
Ship decisions now happen inline. "Is this safe to deploy?" gets answered without leaving the file being edited. The whole team adopted it within a week.
Lessons Learned
- Expose read-only tools first; earn trust before writes.
- Return human-readable text, not raw JSON dumps.
- Name tools for intent, not implementation.
