Plugging Any System Into Your AI: How Alhena's MCP Support Turns Any API Into an Agent Tool

The N×M Problem Every Ecommerce AI Team Hits

Your AI agent needs to check orders in Shopify, look up subscriptions in a homegrown billing system, file tickets in Jira, and push segments to Klaviyo. That's four backends, four external services, four authentication schemes, and four custom adapters your team has to maintain. Add a fifth system next quarter, and every agent that needs it gets another round of integration work.

The Model Context Protocol (MCP) was designed to kill this problem. One protocol, one technology layer for connecting external systems to any backend. Alhena's MCP support takes that further: register an MCP server once in the dashboard, and every agent you assign it to can discover and call its tools at runtime. No redeployment, no code changes.

This post walks through how Alhena implements Model Context Protocol integration, from dashboard registration to runtime execution, with three integration patterns and the safety model that keeps everything locked down.

A Quick MCP Primer

MCP is an open protocol (donated by Anthropic to the Linux Foundation in December 2025) that standardizes how AI agents and LLMs connect to external tools and data sources. The client sends JSON-RPC 2.0 requests to an MCP server, and that server exposes tools and information the agent can discover and call. With 97 million monthly SDK downloads across Claude, ChatGPT, and other LLMs, and over 17,000 public protocol servers indexed by early 2026, MCP is today the default integration layer for agentic AI systems.

The MCP specification defines three primitives: Tools (functions the model can invoke), Resources (contextual data), and Prompts (templated workflows). For ecommerce AI, tools are the star. A single MCP server wrapping your order management system might expose get_order_status, initiate_return, and apply_store_credit as callable tools, each with a typed input schema and documentation the LLM uses to generate correct arguments.

Our ACP vs UCP vs MCP breakdown covers how MCP fits alongside commerce-specific protocols. This post focuses on implementation so you can learn how to get started quickly.

Dashboard Registration: Endpoint to Live Tools in Five Minutes

Connecting an MCP server starts at Integrations → Custom Extensions → MCP Integrations → Add new MCP server. The flow has four steps.

1. Server name, endpoint, and auth headers. Enter a human-readable name, the MCP server URL (for example, https://mcp.example.com/api or a Zapier MCP URL), and authentication headers. Most servers use bearer tokens or API keys. The MCP specification (updated in 2025) also supports OAuth 2.1 authorization. Sensitive header values can be toggled hidden, and all credentials are stored encrypted.

2. Test Connection. Alhena opens a session, performs the MCP initialize handshake, and confirms the server is reachable and speaks MCP. Transport is auto-detected: Streamable HTTP by default, SSE if the endpoint suffix indicates it (for example, /sse). You don't choose; the system negotiates.

3. Auto-discover tools. Alhena calls the server's list_tools method and renders a table of every tool with its name, description, and JSON input schema. You see exactly what the server offers before enabling anything.

4. Enable, assign, finish setup. Toggle individual tools on or off, assign each to a specific agent, and click Finish Setup. The server and its tool-to-agent mapping persist in Alhena's Remote Tool Registry. This is where the planner-led architecture meets MCP: the planner routes queries to the right specialist, and each specialist only sees the MCP tools you assigned.

The Remote Tool Registry

Most MCP clients call list_tools on every startup. That works locally, but in enterprise production with dozens of agents across thousands of conversations, round-tripping to every MCP server on cold start creates latency and hard availability dependencies.

Alhena's Remote Tool Registry stores two things when you register a server: server metadata (endpoint, encrypted auth headers, ownership) and tool registry entries (one row per tool with name, description, JSON schema, enabled/disabled state, and agent assignment). Agents load tool definitions from this registry at startup, not from the live server. The MCP server only gets called when an agent actually invokes a tool. A 300-second cache sits in front of list_tools to prevent hammering when many agents spin up at once.

This gives you fast startup (agents boot with their full catalog in milliseconds), explicit permissioning (only enabled tools appear, even if the server exposes fifty), and resilience (agents get a clean error on invocation if a server is down, not a missing definition at boot).

Refresh Tools

When your MCP server adds or removes tools, click Refresh Tools. Alhena re-queries list_tools, diffs the result, surfaces new tools for review, and flags removed ones. No redeployment needed.

Dual-Scope Assignment

Alhena supports Model Context Protocol tools at two scopes, backed by two parallel registries (RemoteMCPMetadata and AgenticRemoteMCPMetadata).

Bot-profile-level makes a tool available to every agent under that profile. Good for universal capabilities any agent can access like get_customer_profile. Agent-level restricts a tool to one specialist. Your billing agent sees get_invoice and apply_credit; the product expert can't touch them. The LLM powering the product expert never even knows those tools exist, because they aren't in its catalog.

This isn't just convenience. It's a security boundary. An LLM can only call tools it can see, and dual-scope assignment controls visibility. The planner routes to each specialist accordingly.

Runtime Mechanics

When a shopper asks "Where's my order?" and the answer requires an MCP tool call, here's what happens:

1. Check for MCP servers. The agent looks up its MCP registrations.
2. Instantiate a connection manager. Server objects are created synchronously and wired into the agent; actual network connections happen inside the async event loop.
3. Open connections in parallel. All MCP sessions open concurrently (90 to 120 second handshake timeout, 300-second read timeout for SSE streams).
4. Merge tool catalogs. Every enabled MCP tool joins the LLM's tool list alongside Alhena's built-in tools. A short capability prompt tells the LLM that external tools are available. The LLM can't distinguish MCP tools from native ones.
5. Run the LLM loop. When the model picks an MCP tool, the Alhena client routes the tools/call request to the correct server, awaits the response, and feeds it back into context.

The action layer handles fan-out when an agent needs tools from multiple servers simultaneously.

Three Integration Patterns Worth Stealing

Pattern 1: Zapier MCP for Long-Tail Automations

The Zapier MCP server (launched in 2025) exposes over 30,000 actions across 9,000+ apps. Register it in Alhena, enable actions like slack_send_message, google_sheets_add_row, or jira_create_issue, and assign them to specific agents. Long-tail automation without a single custom adapter.

Pattern 2: Custom Internal MCP Server

Wrap your OMS or subscription platform in a lightweight MCP server exposing tightly-scoped tools: get_order_status, cancel_subscription, pause_subscription, initiate_refund. Each tool gets a typed inputSchema. Because the MCP server sits between Alhena and your backend, you control cloud-side rate limiting, audit logging, and data filtering. The AI agent never touches your database directly.

Pattern 3: Same Endpoint, Different Credentials

Register the same MCP server URL twice with different API keys. One read-only registration goes to the product expert agent. The other read-write registration goes to the order management agent. The server returns different tool sets from list_tools based on the credential. Same codebase, two permission boundaries. This is explicitly supported and especially useful when you can't modify the server itself.

Safety and Governance

Alhena's MCP implementation has five control layers:

• Admin-only registration. Only organization admins or bot-profile members can add, modify, or remove MCP servers.
• Plan-gated access. MCP access is gated to enterprise plans (currently Pro).
• Encrypted headers. Credentials are encrypted at rest and injected only during live connections. They never appear in logs or the dashboard after entry.
• Test Tool Call. Fire a test invocation from the dashboard with canned arguments before exposing a tool to customers in live conversations.
• Instant disable with cascade. Disabling a tool takes effect on the next conversation. Deleting a server cascades: all its tools disappear from every agent.

Dashboard endpoints that talk to the AI server require authenticated service-to-service credentials, preventing unauthorized MCP calls through.

For more on how Alhena's December product update expanded the integrations framework MCP builds on, see the full product update.

What This Means for Your Stack

MCP turns "build N custom adapters" into "expose N standard servers." Alhena adds orchestration on top: scoped assignment, cached registries, and a planner that treats MCP tools the same as native ones. One MCP server can expose dozens of actions without registering each separately. Tool schemas come from the source of truth, so they're always in sync. And the growing MCP ecosystem gives your agents reach without custom code.

Ready to connect your systems? Book a demo with Alhena AI to see MCP in your stack, or start for free with 25 conversations.

Alhena AI

Schedule a Demo

Frequently Asked Questions