Shipping MCP server mode — Niyra as a tool other agents can use

MCP — Model Context Protocol — is the cleanest interop standard the agentic-AI space has produced in the last year. Anthropic shipped the spec; the ecosystem picked it up; and as of last week, Niyra is now both an MCP client (calling 55+ tools through it) and an MCP server that other clients can call. This post is about why being on both sides of the protocol matters. ## What MCP actually is A standard for plugging tools into AI agents over a stable JSON-RPC wire. The agent says: "give me your tools." The server returns a list of tool definitions (name, input schema, description). The agent calls them with JSON arguments; the server returns JSON results. That's it. No vendor SDK. No agent-specific glue code. The same MCP server works with Claude Desktop, Cursor, and any agentic runtime that speaks the protocol. The big deal is composability. A single MCP server I write today is reachable by every MCP-aware agent that exists tomorrow. ## Niyra as a client (the part you already use) Most of Niyra's 55+ integrations are MCP-style under the hood. The OAuth-backed ones (Gmail, Notion, Linear) come through Composio. The custom ones — your internal company API, that niche industry tool — come through user-configured MCP servers added directly in chat. The user experience: tell Niyra "add this MCP server at https://internal-tools.acme.com/mcp." She inspects the tools, learns their inputs, and adds them to her runtime live. No restart. No deploy. Five seconds later she's calling them. That's MCP-as-client, and it's powered the integration story for months. ## Niyra as a server (the new part) What's new: Niyra now exposes a POST /mcp endpoint that speaks the MCP wire protocol back. Authenticated via OAuth (the same OAuth provider service we shipped Phase A of in early June). The first two tools live there: `niyra_ask` (let an external agent ask Niyra anything in her constrained context) and `niyra_get_task` (let an agent retrieve a task state Niyra is tracking). The flow looks like this: you wire Niyra as an MCP server into Claude Desktop. Claude can now call `niyra_ask` as a tool. So when you ask Claude "what's on my calendar today?", it can route that to Niyra, who actually has the calendar integration, and return the answer. This is the symmetric design. Niyra delegates to other tools when she needs them; she's also a tool other agents can delegate to. ## Why it matters The agentic-AI space is heading toward a world where you have multiple specialized agents — one for code (Cursor, Claude Code), one for chat and research, one for personal ops (Niyra). MCP is the standard that lets them talk to each other without you having to copy-paste context between tabs. Without MCP server mode, Niyra is a closed system — useful, but isolated. With it, she's a node in a larger agentic graph. Your code-writing agent can ask her about the meeting context before generating a Slack post. Your research agent can hand off the synthesis to Niyra for filing in Notion. The specialization wins remain (each agent stays good at its job), and the integration cost drops to zero. ## What's hard Two things kept us honest while shipping. **Authentication.** Personal AI tools have unique auth challenges — the calling agent isn't Niyra's user, but the work needs to happen on her user's data. We use OAuth 2.1 with a per-installation token, scoped to specific tools. Token rotation and revocation work through the same /oauth surface we ship for human auth. **Cost attribution.** When Claude calls `niyra_ask` and Niyra does inference to answer, whose credits get charged? Niyra's user. The calling agent doesn't pay; the agent's user (Claude's user, who is also Niyra's user) does. Mechanically straightforward; conceptually worth thinking through because future versions might allow third-party agents to access Niyra on behalf of users who aren't theirs. ## The pattern we want to encourage If you're building agentic AI, ship the protocol-server side early. MCP is the obvious one; there'll be more as the space matures. The asymmetry — being a client without being a server — is fine for a closed product, but personal AI specifically benefits from being reachable by every other tool the user already uses. We're still early on Phase B (more tools, richer authorization scopes, batch-mode for high-volume agents). Phase C will probably add streaming responses. But the wire is open. If you want to try the server side: docs at /docs/mcp-servers. If you want to add your own server to Niyra's client side: same place. Both directions, one protocol.