MCP at the boundary of the real world

The cursor/plugins repository uses MCP configuration to connect an agent to capabilities that live outside the plugin directory. This chapter focuses on that boundary. It distinguishes a connection declaration from the host runtime, the authentication context, the provider, and the guidance that tells an agent when to use the connection. The practical result is a way to inspect an integration without assuming that a small JSON file contains the whole service.

The retained checkout contains 89 mcp.json files and 89 server configurations. Static parsing finds 86 explicitly typed HTTP servers, one explicitly typed stdio server, and two configurations that use the default type. Those counts describe this checkout at acquisition time. More important than the counts is the variety of boundaries they represent. Some servers are remote. Some launch locally. Some depend on user credentials. Some require administrator-provided variables. The same marketplace mechanism has to hold all of them without hiding their differences.

What MCP adds to the marketplace

A marketplace entry and plugin manifest make a capability discoverable. An MCP declaration gives the host a connection shape. It can identify a server name, a URL, a transport type, a local command, arguments, headers, authentication values, or other connection properties. The declaration tells the host how to attempt the connection without embedding the provider’s implementation in the repository.

That separation matters for composability. A plugin does not need to reimplement a CRM, document store, browser, or meeting service. It can describe the boundary through MCP and place the user-facing setup beside it. The host can then expose the resulting tools to the agent. The plugin remains a package that connects behavior to a capability, not a replacement for the capability provider.

The repository’s integrations show three useful shapes. Google Drive uses a Cursor-hosted remote HTTP endpoint and OAuth sign-in. GitHub uses a remote HTTP endpoint with an authorization header whose value comes from a configured personal access token. Gong uses a remote endpoint with client credential variables in the plugin manifest, then requires a separate per-user OAuth flow. In each case, the static configuration is only one part of the connection story.

Playwright provides the contrasting local shape. Its MCP configuration launches a local process through npx, and the README says the machine needs Node.js and network access for the first browser download. No provider credential is required, but the integration still has dependencies. The host must be able to launch the process. The package must be obtainable. The browser environment must be available. A local server removes one remote boundary while adding a machine boundary.

Remote and local transport change the failure surface

A remote HTTP integration fails at a network or provider boundary. The host may reach the URL but receive an authentication error, a missing tool, a provider-side rejection, or an unavailable service. The server can change its tool schemas after the plugin repository was cloned.