--- title: "Talk to Any ibl.ai Agent From Claude Code, Cursor or Claude Desktop" slug: "iblai-agents-in-claude-code-cursor-claude-desktop-mcp" author: "Blanca Amigot" date: "2026-11-08 10:00:00" category: "Premium" topics: "MCP, Model Context Protocol, Claude Code, Cursor, Claude Desktop, AI agents, agent governance, enterprise AI" summary: "Since November 5, 2026 every agent deployed on ibl.ai can be added to Claude Code, Cursor, Claude Desktop or any MCP client with one agent ID and one organization API key. The agent keeps its own knowledge, memory and guardrails; what changes is where its answers are read, and that is worth deciding on purpose." banner: "" thumbnail: "" linkedin: | Every agent you deploy on ibl.ai can now be added to Claude Code, Cursor or Claude Desktop, and talked to from there. It is the same agent you built in Agentic OS: the same instructions, the same documents, the same memory, the same guardrails. Setup is one agent ID and one API key that belongs to your organization and only reaches agents in that organization. One thing worth deciding on purpose: the agent's guardrails govern what the agent says. Once its answer lands in Claude Code or Cursor, that tool and the model behind it read the answer too. So the right agents to expose this way are the ones whose answers you are comfortable having inside your people's working tools, which for most organizations is most of them. The agent comes to where people work. The knowledge, the limits and the audit trail stay with you. With ibl.ai you own all the code and the data. #iblai #MCP #ClaudeCode #AIAgents #EnterpriseAI --- ## The Short Answer **Any ibl.ai agent can be added to Claude Code, Cursor or Claude Desktop over MCP with one agent ID and one organization API key, and it answers with its own knowledge, memory and guardrails. The agent stays governed where it runs, on ibl.ai, where you own all the code and the data; decide which agents' answers belong in those tools.** The change shipped on November 5, 2026 and is documented step by step in the [release note](/updates/builtin-mcp-servers-agent-chat). This post covers what it means for the people who decide which agents get exposed. ## How do you add an ibl.ai agent to Claude Code, Cursor or Claude Desktop? With two values. The agent's **Unique ID** is under the agent's name, then Settings, in Agentic OS. An **API key** comes from Integrations, then API, then Create New, and is shown once. In Claude Code that is a single `claude mcp add` command pointing at the agent-chat MCP endpoint, with the key and the agent ID passed as headers. Cursor and Claude Desktop take the same three values as a JSON block in their MCP settings. [Claude Code's MCP documentation](https://code.claude.com/docs/en/mcp) covers the client side. Each connection is one agent, so a team can add several and name each for what it answers: the advising agent, the policy agent, the prior-authorization agent. ## Is the agent in Claude Code the same agent that runs in Agentic OS? Yes. The [Model Context Protocol](https://modelcontextprotocol.io/), which Anthropic [introduced in November 2024](https://www.anthropic.com/news/model-context-protocol), is only the connection. The answer is produced by the agent on ibl.ai, with its instructions, its grounding documents, its memory and its safety settings. In the test published with the release, a university advising agent was asked three questions from Claude Code. By the third turn it recalled the student's name, her transfer plan and her roughly 45 credits, so the agent kept the conversation's context across the connection. ## Who can reach an ibl.ai agent over MCP? Only someone holding a key from the organization that owns the agent. The API key belongs to an organization and works only for agents in that organization, so a key from one tenant cannot reach another tenant's agent. On a self-hosted deployment the endpoint is the organization's own server rather than ours. ## What should an organization decide before exposing an agent this way? Where its answers may be read. The agent's guardrails govern what the agent says. Once an answer arrives in Claude Code, Cursor or Claude Desktop, that tool and the model provider behind it process the answer as part of the user's conversation. For most agents that is the point: a registrar in Cursor or an analyst in Claude Desktop gets the institution's answer without switching windows. For an agent grounded in records that should never leave the organization's own interface, the right choice is not to issue that agent a connection.
What stays with the agent on ibl.ai What the MCP client sees
Instructions, grounding documents and datasetsThe question asked and the answer returned
Memory across turnsWhatever the answer itself repeats
Guardrails, safety settings and audit trailOnly their effect on the answer
## Why does ownership matter when agents leave the portal? Because an agent that travels into every working tool is only governable if its knowledge, limits and logs stay in one place the organization controls. On ibl.ai the agent runs on the organization's ibl.ai tenant, or inside its own deployment when self-hosted, and the MCP connection is a door it opens, not a copy it hands over. On ibl.ai you own all the code and the data, run it model-agnostic across any LLM, and pay with no per-seat pricing — so you can deploy anywhere, from your own cloud to a fully air-gapped network. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on. The same week, the [November 6, 2026 update](/updates/platform-update-2026-11-06) added a platform MCP server and grew the v1 API facade behind the built-in MCP tools from 50 to 79 routes, 29 of them analytics. The full list is in the [MCP Servers](/developer/platform/mcp/mcp-servers) developer reference. *Related: [Why Model Context Protocol (MCP) Is the Missing Piece in Education AI](/blog/why-mcp-is-the-missing-piece-in-education-ai) — the integration argument for MCP on campus, from the agent's side of the connection.* *Related: [K-12 AI Agents: OIDC Sign-In, Capability Flags, and the Sandbox Default to Change on Day One](/blog/k12-ai-oidc-sso-capability-flags-sandbox-defaults) — the identity and control changes that shipped the same week.* ## Why does owning the AI stack matter? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.