MCP Connectors and Integrations

MCP Connectors and Integrations

What a connector is

A Model Context Protocol (MCP) connector is the structured interface that links an AI agent to an outside system. A connector — implemented as an MCP server — exposes a catalog of tools, resources, and prompts, each with a declared schema. That schema is what lets an agent discover a capability and call it safely, without embedding API logic or credentials in the model itself.

Connectors exist for local utilities (files, a local database) and for remote platforms (hosted databases, source control, CMS APIs). Collectively they form the fabric that makes agentic AI practical: the model reasons, the connector acts.

For the roles and transports referenced below, see MCP Foundations and Architecture.

Anatomy of a connector

Layer Purpose Examples
Server Implements the MCP endpoints and defines the tools and resources. supabase-mcp, chrome-devtools-mcp
Descriptor A JSON entry that tells the client how to launch or reach the server. mcp.json, a client’s mcpServers config
Transport How messages flow — stdio for local, HTTP for remote. npx @supabase/mcp or https://mcp.supabase.com/mcp
Host integration How the user’s AI environment registers and uses the connector. Claude Desktop config, Cursor settings

All traffic is JSON-RPC 2.0 (tools/call, resources/read) against declared JSON schemas, which is what gives connectors cross-client portability.

Two integration patterns

Local (stdio). The client launches the server as a subprocess via a CLI command (npx, uvx) and talks to it over standard I/O. Best when an agent inside a local IDE needs the filesystem or a local tool. Strengths: privacy and direct system access, no network exposure.

Remote (HTTP). The server runs behind a public https://.../mcp endpoint. Best for cloud services and shared enterprise APIs. Strengths: broad client compatibility and centralized operation. Requires real authentication (OAuth 2.1 with scopes).

Example connectors

Connector Purpose Integration notes
Supabase MCP Database and auth access for agents. Remote HTTP; OAuth 2.1; grouped by feature.
Chrome DevTools MCP Browser debugging and performance analysis. Uses the DevTools protocol; suited to developer agents.
WordPress.com connector Read access to WordPress.com site data. Official integration over OAuth 2.1.
Context7 Memory MCP Persistent agent memory and retrieval context. Multi-agent context sharing; vector queries.
Google Developer Knowledge MCP Access to official Google developer docs. Covers Firebase, Android, Google Cloud; needs a Google Cloud key.

SDKs for building connectors

You rarely hand-write the JSON-RPC loop. Established SDKs handle transport, schema validation, and lifecycle:

SDK Language Notes
FastMCP Python Lightweight framework for quickly standing up a server.
MCP PHP SDK PHP Framework-agnostic; suits WordPress and Symfony/Laravel stacks.
MCP TypeScript SDK TypeScript Builds npm-published servers such as the Chrome DevTools MCP.

Each abstracts the boilerplate and provides helpers for declaring tools, validating schemas, and managing the server’s startup and shutdown.

Discovery and security

  • Discovery is dynamic: a client calls tools/list and resources/list to learn a server’s capabilities at connect time, rather than being compiled against them.
  • Authentication differs by transport. Remote servers should require OAuth 2.1 with scoped tokens; local servers inherit the system user’s trust boundary.
  • Auditing belongs to the Host: record the full JSON-RPC exchange so tool calls can be reviewed and governed.

For the full security stack — token structure, sandboxing, and compliance — see MCP Security and Compliance.

Designing a good connector

  1. Keep scope tight. One server, one clear domain (analytics, CMS, storage). Narrow surfaces are easier to reason about and secure.
  2. Version explicitly. Use semantic versioning on the server and its tools so clients can handle breaking changes.
  3. Write schemas an agent can read. Explicit types and plain-language descriptions measurably improve tool-selection accuracy.
  4. Fail with structure. Return typed errors with codes, not free text, so an agent can self-correct.
  5. Default to read-only. Mark retrieval tools readonly; reserve state-changing tools for deliberate opt-in.
  6. Gate mutations. Require a human confirmation step for any operation that writes or deletes.
This entry was posted in . Bookmark the permalink.