MCP Marketplace: Connecting External Tools to Your AI Agent

Why an agent needs doors, not just a room

The ReAct agent at the heart of Simmetric Chat already knows how to reason and act: it searches your knowledge base with hybrid RAG, writes to workspace memory, and processes documents. But an agent sealed inside its own skills is a closed system. The Model Context Protocol (MCP) is the open standard that turns it into an open one - a shared protocol through which an AI assistant can discover and call external tools, and through which external tools can reach into the assistant's own capabilities.

Simmetric Chat's MCP story is bidirectional. Outbound, your agent connects to external MCP servers and gains their tools as skills. Inbound, the platform can expose its own RAG knowledge to other MCP clients, such as IDE assistants. This article covers the outbound side end to end: the marketplace, connections, and the controls that decide what your agent can actually reach in a given conversation.

The marketplace: a curated catalog of tool servers

Administrators get the marketplace from the sidebar - the entry is admin-only, because installing a tool server grants it a path into your workspace's conversations. The catalog presents available MCP servers as cards with the details that matter before an install:

• Category badges - servers are grouped by domain (developer tools, databases, communication, and more), with category pills that filter the grid. Categories are generated from the catalog data, so the filters reflect what actually exists.
• Verification tiers - official servers come from recognized maintainers, verified_community servers have been reviewed, and unverified entries are listed but not vetted. The tier is on the card, so trust level is visible before you click.
• Health status - each server's endpoint is probed on a 30-minute cycle, and its card shows whether it is currently healthy, stale, or down, plus the last commit date so you can judge whether the project is actively maintained.
• Tool list - every tool the server exposes, with its name and description, is shown on the detail page before you install anything.

A search bar filters the catalog by name or description in real time. Nothing here is fetched through a cloud intermediary you cannot inspect: the catalog is a set of server endpoints, and the health badges tell you which ones are alive right now.

One-click installation, workspace-scoped

Installing a server is a single click from a card or its detail page, with one prerequisite: a workspace must be selected, because every MCP connection is scoped to a workspace. Behind the click, the system creates a connection record with the server's default name, attempts to connect immediately, and registers the discovered tools in the agent's skill registry.

What you get is the union of the workspace's connections: every enabled, connected MCP server contributes its tools to the agent. The connection is created even if the server cannot be reached at install time - it lands marked disconnected, and you can fix its URL or transport from the connection settings and retest.

Uninstalling is the deliberate inverse: it deletes the connection record, closes the runtime connection, and unregisters all of its tools. The action is destructive - the configuration is removed, not soft-deleted - which is the honest behavior for a permission surface this powerful.

Managing connections in Settings

Every connection, marketplace-installed or manually created, lives in Settings → MCP Connections. The table shows the display name, the server URL with its transport, a live status dot, and an enable/disable toggle:

• Transports. Two connection types are supported: Server-Sent Events (sse) and streamable HTTP (streamable-http). Editing a connection can change the URL, name, or transport, and editing an enabled connection triggers an automatic reconnect.
• Live status. The table polls every 30 seconds: green for connected, gray for disconnected, red for error. A Test action disconnects, reconnects, and reports the number of tools discovered - with a 10-second timeout, so a dead endpoint costs you ten seconds, not an afternoon.
• Enable versus disable. Disabling closes the runtime connection and unregisters the tools while keeping the configuration in the database, so a seasonal integration can be turned off without deleting anything.

For the transport-mismatch cases in the wild, the client falls back sensibly: a connection configured for streamable HTTP that answers with a 4xx retries as SSE, while an explicitly declared sse connection stays on SSE.

Per-chat pinning: least privilege for conversations

Workspace-level enablement is a broad brush. The finer control is per-chat pinning, available from the console panel next to any conversation: a dropdown lists the workspace's MCP connections with a status dot and a toggle for each.

Pin a connection to make it the deliberate toolset for that chat - useful for focused conversations, sensitive discussions, or testing how the agent behaves with a specific subset of tools. The pinning model is strictly additive: pinning connections never removes the tools of other active, connected workspace connections; unpinning everything reverts to the default union of all enabled connections. Pins persist across reloads and restarts, stored per chat, with an optimistic toggle that reverts and surfaces an error if persistence fails.

The result is a least-privilege model for agent tools: the workspace decides what exists, the connection toggles decide what is generally available, and each chat decides what this particular conversation may reach.

The inbound direction: exposing RAG over MCP

The same protocol runs the other way. The platform can act as an MCP server, exposing the hybrid RAG search over its knowledge base so that external MCP clients - IDE assistants are the canonical example - can ground their answers in your curated, RBAC-protected knowledge. Your documents stay where they are; the IDE assistant calls in, gets cited search results, and never needs a copy of the corpus.

This turns the knowledge base into infrastructure: the same indexed documents serve the internal chat workspace and any MCP-aware tool your team already uses, with the same access rules enforced at the boundary.

Where the tools run in the agent loop

MCP tools enter the agent as first-class skills. When the ReAct orchestrator runs, MCP-provided tools sit alongside the built-in skills - knowledge-base search, workspace memory, document processing - and the agent decides per turn whether a tool call helps answer. Tool names are namespaced per connection so identifiers never collide, and every streaming event that references tool use carries the human-readable source name, so the chat's activity trace shows which connection served which tool call.

Health checks on installed connections run as scheduled jobs through the platform's Postgres-backed queue, so a marketplace that goes stale is noticed by infrastructure rather than by users. The whole surface - catalog, connections, pinning - is protected by the platform's RBAC: admin gates on the marketplace and connection management, and the per-chat pinner stays inside the chat surface users already have.

Getting started

1. Open the marketplace from the sidebar (admin role) and pick a verified server whose tools match a real workflow.
2. Select a workspace, install, and confirm the status dot goes green.
3. Open a chat, check the tool appears in the console panel, and pin it if this conversation should be restricted to it.
4. Ask a question that requires the tool - the agent's activity trace shows the call, its source, and its result.

External MCP servers are just servers: run one on your own infrastructure, point a connection at it, and your agent's capability surface grows without any code change to the platform.

Read the full guide in the docs →