MCP Connectors: Client and Server

Part 6 of the VIMS Blog Network. The Model Context Protocol is the universal standard for connecting AI agents to external tools. VIMS speaks it in both directions.

---

The Integration Problem

Agents need tools. An agent that can only reason but cannot act is a chatbot. The question is: how does an agent connect to external tools?

Historically, every agent framework solved this differently. Custom function definitions, proprietary tool schemas, framework-specific integrations. If you wrote a tool integration for framework A, it did not work with framework B. The integration surface was fragmented.

The Model Context Protocol (MCP) changes this. MCP is an open standard for connecting AI systems to external tools, data sources, and services. It defines a protocol for tool discovery, invocation, resource reading, and prompt rendering, independent of any specific agent framework.

VIMS was designed to speak MCP natively, in both directions. As a client, it connects to any MCP-compatible tool. As a server, it exposes its own toolset to any MCP-compatible agent. This makes VIMS a universal bridge in the agent ecosystem: a node in an open network.

VIMS as MCP Client

The VIMS MCP manager supports both transport types defined by the protocol:

Stdio Transport

Stdio MCP servers run as subprocesses on your machine. VIMS launches the server process, communicates via standard input/output, and manages the lifecycle. This is how local tool integrations work: GitHub CLI, Docker, Playwright, file system access, and similar tools that need to execute commands on your host.

Every stdio connector has a command allowlist. The commands that the MCP server is permitted to execute are explicitly configured. Anything not on the list is refused. This prevents an agent from using an MCP connector as a shell escape: if the GitHub connector is only allowed to run gh commands, an agent cannot trick it into running rm -rf.

HTTP Transport

HTTP MCP servers run remotely. VIMS connects to them over the network, with support for OAuth flows for authenticated servers. This is how cloud service integrations work: Stripe, Notion, Linear, Jira, AWS, and similar services that expose an HTTP API.

Every outbound URL is validated by the netguard layer. The URL is checked against allowlist patterns to prevent SSRF attacks: an agent cannot use an MCP connector to reach internal services (e.g., http://localhost:8080/admin) through an HTTP MCP server.

The Connector Catalog

VIMS ships with 30+ pre-configured MCP connectors:

• Developer tools: GitHub, GitLab, Linear, Jira, Docker
• Cloud platforms: Cloudflare, AWS, Vercel
• Productivity: Notion, Slack, Google Drive
• Browser automation: Playwright
• Creative: Blender (3D generation)
• And more, with custom connectors easily added via configuration

Each connector is registered with a unique ID, a display name, a connection status, and a list of exposed tools. The tool list is discoverable: VIMS calls tools/list on the MCP server and caches the result, so agents can see what tools are available before invoking them.

The Browser MCP Client

The same MCP catalog is available in browser surfaces. The useMCP hook gives web apps full access to MCP connectors: tool discovery, invocation, resource reading, and prompt rendering. The browser client communicates with the MCP manager through the same provider gateway, so browser-based agents have the same tool access as desktop agents.

This is part of the VIMS shared package pipeline: the MCP client code is transport-free, consumed by both desktop and browser through the same package. (Blog 06: P2P Surfaces, Blog 12: SDK, Coder, and Terminal)

VIMS as MCP Server

VIMS is both an MCP consumer and a provider. The built-in VIMS MCP server exposes the entire VIMS toolset to any external MCP-compatible agent. This means an agent running in Claude, Cursor, or any other MCP-aware platform can use VIMS tools.

The exposed tools include:

• Browse: fetch and parse web pages
• Files: read, write, and manage files in the VIMS workspace
• Agents: list, start, stop, and manage agent instances
• Channels: send messages through configured channels (Slack, Discord, email, SMS, Telegram)
• Chat: send messages through the VIMS provider manager
• Drive: manage files in the VIMS Drive
• x402: manage micropayments and registered services
• Database: execute SQL, describe tables, list connections
• Knowledge Base: search, index, and manage KB documents
• Schedule: manage calendar events, bookings, and availability
• Meeting: manage meeting rooms and agent peers

The public MCP endpoint makes these tools accessible to any agent on the internet. An external agent can query your VIMS knowledge base, search your database, schedule a meeting, or dispatch a task to one of your agent instances, all through the standard MCP protocol. (Blog 04: Data and Knowledge)

MCP Prompts and Resources

MCP defines three primitives: tools, resources, and prompts. VIMS supports all three.

Resources are addressable content: documents, files, or other data that an MCP server exposes. VIMS lists its resources via resources/list, and external agents can read them via resources/read. This is how an external agent discovers what knowledge base documents or database schemas are available.

Prompts are reusable message templates. VIMS exposes prompt templates via prompts/list, and external agents can render them via prompts/get with arguments. This enables templated interactions ("summarize this document," "analyze this schema," "generate a flow for this use case") without the external agent needing to know the internal structure.

MCP and the Marketplace

The VIMS agent marketplace is programmatically accessible via MCP. An external agent can list available agents, fetch agent details, and even hire agents through the MCP endpoint, with payment settled through the on-chain PaymentSplitter. This means an agent running outside VIMS can discover, hire, and interact with VIMS agents without ever opening the VIMS UI. (Blog 10: Agent Marketplace)

MCP and Flows

Flow nodes can invoke MCP tools directly. A flow that needs to create a GitHub issue, send a Stripe invoice, or query a Notion database includes an MCP node that calls the appropriate connector. The MCP node handles the tool invocation, captures the result, and passes it to the next node in the DAG.

Flows are not limited to VIMS-native tools. Any MCP-compatible tool (pre-configured connector or custom server alike) is available as a flow node. The flow engine treats MCP tool calls like any other node, with retry policies, error handling, and condition-based branching. (Blog 11: Flow and Teams)

The Security Perimeter

MCP expands the agent's reach: more tools, more data sources, more capabilities. It also expands the attack surface. VIMS addresses this at three levels:

1. Transport security: Stdio command allowlisting prevents arbitrary command execution. HTTP URL validation prevents SSRF. These are enforced at the transport layer, not at the agent level; even a prompt-injected agent cannot bypass them. (Blog 03: Security First)
2. HITL gates: MCP tool calls that are classified as high-risk trigger approval gates. An agent that tries to delete a repository via the GitHub connector or charge a customer via the Stripe connector hits the approval wall.
3. Audit trail: Every MCP tool invocation is logged: the connector, the tool, the arguments, the result, the correlation ID. When something goes wrong, the audit trail shows exactly which MCP call caused it.

The Bridge

MCP is the bridge between VIMS and the broader agent ecosystem. VIMS aims to be the most capable node in an open network. By speaking MCP in both directions, VIMS ensures that:

• Agents inside VIMS can use any MCP-compatible tool
• Agents outside VIMS can use VIMS tools
• Flows can orchestrate MCP tools alongside native tools
• The marketplace is accessible to external agents
• The security model extends to the connector layer

The result is an agent platform that is both powerful in isolation and useful in composition.

---

Previous: Data and Knowledge Next: P2P Surfaces: Desktop and Browser