Remote MCP

A server that exposes tools over HTTP. An agent connects to it as a client and calls those tools without ever touching your website.

The problem it solves

Some questions have nothing to do with a page. "Has my order shipped" does not require a browser, a session, or a rendered interface. Making an agent open your site, log in, and read a table to answer it is a lot of machinery for one field.

MCP is a standard shape for that: your tools, described well enough that a model can decide which to call and with what arguments, over an ordinary HTTP request.

How an agent finds yours

A document at /.well-known/mcp.json, which a browser reads in the same pass as your skills index.

{
  "name": "acme-billing",
  "description": "Look up invoices and subscription status.",
  "transport": "streamable-http",
  "url": "https://api.acme.example/mcp",
  "authentication": { "required": true, "scheme": "bearer" },
  "tools": ["get_invoice", "list_subscriptions"]
}

What it costs

This is the expensive option of the three, for four reasons worth knowing before you start.

• You are running a service, with everything a public API needs: deployment, monitoring, uptime, versioning. That is what it is.
• Authentication falls to you. Anything user-specific needs a credential, so you need a token flow, storage, rotation and revocation. The specification points at OAuth 2.1 for good reasons, and implementing it properly takes longer than a weekend.
• Your tool descriptions become a product surface, because a model picks tools by reading them. A vague description is a bug that surfaces as the agent calling the wrong thing, and your test suite will not catch it.
• It cannot see the page. Bypassing the browser is both the strength and the limitation, so if a task depends on what the user is looking at right now, this is the wrong track.

Start with reads

Read-only tools need no consent flow and cannot damage anything, and most of the value tends to sit there anyway. Ship those first, watch what agents actually call, then decide whether a write tool is worth the authentication work.

Two habits worth adopting from the start. Mark read-only tools as read-only, so a client can offer them without a confirmation. And mark anything returning text a stranger wrote as untrusted content, so the calling model treats it as data rather than instruction.

We run one

This directory has an MCP server built the way described above. Reads need no credential, writes need a token, and every tool is annotated. If you want a working example to read, it is the shortest path to one.

{
  "mcpServers": {
    "skylark-skills": { "type": "http", "url": "https://skills.skylarkbrowser.com/mcp" }
  }
}

Reading

• Model Context Protocolthe specification and SDKs
• MCP discovery URI draftwhere mcp.json comes from
• Web skillsthe cheaper option, if a page is involved