Scovant
Sign in Scan free →
Scovant Blog

How to Add an MCP Interface to Your Website So AI Agents Can Discover and Use It

AI agents are no longer just reading pages. They're clicking buttons, filling forms, completing purchases, and booking appointments. If your site doesn't expose a structured interface those agents can discover and use, you're leaving them to guess — and guessing fails.

The Model Context Protocol (MCP) gives you a standard way to say: here's what my site can do, here's how to call it, here's what you get back. This guide walks through exactly how to add that interface so agents can find and use it reliably.

What MCP Actually Is

MCP is an open protocol for exposing tools, resources, and prompts from a server to an AI agent. Think of it as an API contract written in a language LLMs already understand. Instead of an agent scraping your checkout page and hoping the DOM makes sense, it calls a declared tool like create_booking with typed parameters and gets a structured response.

The protocol covers three core primitives:

Step 1: Create Your MCP Server

Your MCP server is the backend that handles agent requests. It can be a standalone service or a thin layer in front of your existing API.

You need to implement two things:

  1. A tools/list endpoint that describes every tool you expose
  2. A tools/call endpoint that executes a tool when the agent calls it

A minimal tool definition looks like this:

{
  "name": "search_products",
  "description": "Search the product catalog by keyword and return matching items.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "The search term"
      }
    },
    "required": ["query"]
  }
}

The description field matters more than you think. Agents use it to decide whether to call the tool at all. Write it like documentation for a junior developer who has never seen your site.

Step 2: Publish a Discovery File

Agents need to find your MCP server before they can use it. The convention is a well-known URL:

https://yourdomain.com/.well-known/mcp.json

This file tells agents where your MCP server lives and what transport it uses. A minimal example:

{
  "mcpServers": {
    "your-site": {
      "url": "https://yourdomain.com/mcp",
      "transport": "http"
    }
  }
}

Serve this file with Content-Type: application/json and make sure it's publicly accessible — no auth, no redirects. Agents crawl it the same way they'd crawl robots.txt.

You can see a live example of this pattern at https://scovant.com/.well-known/mcp.json.

Step 3: Define Tools That Match Real Agent Tasks

Don't expose your internal API surface verbatim. Think about what tasks an agent actually needs to complete on your site and build tools around those tasks.

Good candidates:

Each tool should:

Step 4: Handle Authentication

Most tools need some form of auth. MCP supports OAuth 2.0 as the standard mechanism, and the important part is that the entry point is discoverable.

If your server answers initialize with a 401, publish RFC 9728 protected-resource metadata at /.well-known/oauth-protected-resource on the endpoint's origin, listing its authorization servers. Scovant fetches that document unauthenticated and flags an auth-required endpoint that declares no discoverable authorization server — from an agent's point of view, an endpoint that demands credentials without saying where to get them is simply closed.

From there the flow is the ordinary one:

  1. The agent (or the platform running it) discovers the authorization server and completes the OAuth flow
  2. The agent passes a bearer token with every tool call
  3. Your server validates the token before executing anything

For tools that don't touch user-specific data — search, catalog browsing, availability checks — you can skip auth entirely. Keep the authenticated surface as small as possible.

Step 5: Test Against Real Agents

This is where most implementations fall apart. You can declare a perfectly valid MCP server and still have agents fail on it because:

Static checkers won't catch any of this. They verify that your discovery file exists and your schema is valid JSON. They can't tell you whether a real agent can actually complete a purchase flow end to end.

Scovant probes your declared MCP endpoint read-only — a real initialize handshake and one tools/list, never a tools/call — and inspects every tool's name, description and schema for ambiguity, collisions, injection markers and hidden Unicode. The browser agents run separately against the human UI: real AI agents attempting actual purchase and booking flows, across every LLM agent in the Scovant catalog, so you catch the cases where one model handles your site fine and another gets confused. Both layers plug into CI, and the interface diff between two runs reports a removed tool or a changed input schema as a regression before it reaches production.

Step 6: Add Structured Data and Robots Hints

Not every agent will use MCP. Some still crawl. Cover both bases:

These don't replace MCP — they complement it. An agent might use your MCP tools for transactional flows and fall back to crawling for discovery.

Common Mistakes

Vague tool descriptions. If your description says "gets stuff," the agent won't know when to call it. Be specific.

Missing error handling. Agents retry on failure. If your server returns an unstructured error, the agent has no way to recover gracefully. Return structured errors with a message field.

No protocol-version header. MCP servers should return the mcp-protocol-version response header on the initialize handshake; Scovant flags servers that complete the handshake without it.

Colliding or reserved tool names. Two tools whose names normalize to the same string, or a tool named ping or tools/list, make name-based dispatch ambiguous.

Instructions hidden in descriptions. Prompt-injection markers or invisible Unicode in a tool description are treated as a security finding, not a style nit.

Testing only the happy path. Real agents hit edge cases — out-of-stock items, fully booked slots, invalid inputs. Test those paths explicitly.

Single-model testing. What works with one LLM may not work with another. The way you word a description, the way you structure a response — these affect how different models interpret your tools.

Checklist

Where to Go From Here

The Scovant docs cover how agent-readiness testing works and what Scovant checks beyond static validation. The scoring methodology is public — the category weights and per-severity point values are published there — so you know what's being measured and why, and the full check catalog is at scovant.com/rules. Scovant's own MCP server is live at https://scovant.com/mcp with 13 read-only and authenticated tools and a stateless JSON mode, and its discovery file passes the same check we run on yours. If you want to see what a real agent does on your site rather than what a checklist says it should do, that's the place to start.

The agentic web is moving fast. Getting your MCP interface right now means agents can use your site reliably instead of failing silently and routing users somewhere else.

← All posts