Agent Invocation Sitemap Generator

Sitemaps as we know them were built for 2004's problem: crawlers discovering pages.

Agents in 2026 have a different problem: discovering callable actions. "Does this site let me book an appointment? Can I get a quote without filling out a form? Is there a way to verify a service area programmatically?"

An agent asking those questions can't find answers in sitemap.xml — that file only lists pages to render. The sitemap an agent actually needs lists actions: name, endpoint, auth, method, expected input.

That file doesn't have a settled standard name yet. Three conventions are emerging in parallel:

schema.org PotentialAction — embedded in the homepage JSON-LD. Stable, widely supported.
/.well-known/mcp.json — Anthropic-defined Model Context Protocol tools manifest. Broadly adopted by agent frameworks.
/.well-known/agent-actions.json — a nascent parallel convention that extends the sitemap paradigm directly.

Publishing all three hedges across agent frameworks while each finds its standardization path.

What the Agent Invocation Sitemap Generator does

You describe your business + declared callable actions (book, quote, verify, order, contact, search, subscribe). Per action you specify:

Name (snake-case identifier)
schema.org action type (ReserveAction, QuoteAction, ContactAction, etc.)
Endpoint URL + HTTP method
Authentication requirement (none / API-key / OAuth / basic)
Rate limit per minute per agent
Short description for agents

The tool emits three parallel outputs:

A JSON-LD block to paste into your homepage <head> with potentialAction entries
An MCP tools manifest to host at /.well-known/mcp.json
An agent-actions.json sitemap to host at /.well-known/agent-actions.json

The first-mover window

Only a tiny fraction of SMBs have any of these published. In 2026-2027, major agent-framework clients (Claude Desktop, ChatGPT agents, Gemini copilots, LangChain/LlamaIndex agents) are increasingly trying these well-known paths to determine whether a site supports programmatic invocation.

Sites that publish get:

Preferred treatment in agent-initiated workflows (e.g., ChatGPT user asks "book a roofer" and the agent sees your bookable endpoint)
Higher trust in AI-generated recommendations (agents with no visible action surface are treated as "unclear whether bookable")
Potential revenue routing through the agent layer directly, bypassing competitor-heavy search results

Sites that don't publish get:

Treated as read-only sources by agents
Skipped for action-intent queries
Eventually lose action-intent traffic to competitors who did publish

What actions to declare

Start with public, read-only actions. Lowest risk, fastest to deploy:

VerifyAction — "Do you service ZIP X?" endpoint returns yes/no. Safe because it doesn't expose customer data or pricing.
SearchAction — "Find a [product/service] matching [criteria]" endpoint. Catalog exposure.
ContactAction — "Send an inquiry" endpoint. Functionally equivalent to a contact form but machine-callable.

Next tier — actions that require auth but are low-risk:

QuoteAction — "Request a written quote" endpoint. Usually fine with an API key for rate-limiting.
ReserveAction — "Book an appointment / consultation" endpoint. Needs at minimum API-key + rate limit.

Highest tier — actions that affect money or data:

OrderAction / PurchaseAction — full transaction handling. Should require OAuth + payment-layer integration + rigorous rate limiting.

Don't declare the highest tier until the lower tiers are running smoothly for a month. Agents that hit broken endpoints deprioritize your site in future invocations; credibility takes weeks to rebuild.

The authentication decision

Three legitimate options:

None. Public endpoint. Use for read-only verify/search/contact. Rate-limit aggressively at the origin.
API-key. Simple shared secret. Agent embeds the key in requests. Good balance for SMB scale.
OAuth2. Full user-authorization. Required for user-data or payment-involved actions.

Don't use basic auth for agent invocation — it's brittle and many agent-framework clients don't support it cleanly.

The rate-limit discipline

Every declared action should carry a rate_limit field. Honest agents respect it. It's also your first line of defense against abuse — if rate limits are well-publicized, malicious actors have to work around them rather than casually hammering your endpoints.

Start with conservative limits: 30 requests/min per agent for write actions, 60-120/min for read actions. Raise after you have a month of actual usage data.

Fact-check notes and sources

schema.org PotentialAction: schema.org/potentialAction
Model Context Protocol: modelcontextprotocol.io
Well-known URI registry: iana.org/assignments/well-known-uris

This post is informational, not engineering consulting advice. Mentions of Anthropic, OpenAI, Google, schema.org, LangChain, LlamaIndex, Model Context Protocol are nominative fair use. No affiliation is implied.

Why Your Site Needs A Sitemap For Actions, Not Just Pages