How Model Context Protocol (MCP) connectors bridge AI agents and external systems. Covers connector architecture, local (stdio) versus remote (HTTP) integration patterns, worked examples for databases and developer tools, the SDKs available for building servers, and best practices for discovery, authentication, and safe integration design.
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/listandresources/listto 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
- Keep scope tight. One server, one clear domain (analytics, CMS, storage). Narrow surfaces are easier to reason about and secure.
- Version explicitly. Use semantic versioning on the server and its tools so clients can handle breaking changes.
- Write schemas an agent can read. Explicit types and plain-language descriptions measurably improve tool-selection accuracy.
- Fail with structure. Return typed errors with codes, not free text, so an agent can self-correct.
- Default to read-only. Mark retrieval tools
readonly; reserve state-changing tools for deliberate opt-in. - Gate mutations. Require a human confirmation step for any operation that writes or deletes.
Related reading
- Model Context Protocol (MCP)
- MCP Connectors
- Agentic Integration
- Tool Discovery
- JSON-RPC
- Transport
- OAuth 2.1
Ask Lynx Assist
More Guides
Run disciplined SEO A/B tests in seven steps — one metric, two variations, randomized segments, run to significance, track, analyze the winner, and iterate.
Build a topic cluster in seven steps — select and score a pillar, validate it, map subtopics, align to intent, architect internal links, publish, and measure.
Prepare your site for AI search in five steps — content architecture, entity consistency, E-E-A-T, structured data, and machine-readable structure.
Get your content cited by AI in seven steps — answer capsules, link-free extraction, original data, digital PR, community presence, consistent messaging, and tracking.
A seven-step walkthrough for setting up Google Search Console on a new site — property type, DNS verification, sitemap, GA4 link, users, URL checks, and a monitoring routine.