Direct answer: implement WebMCP or site tools when the website contains a recurring task with structured inputs and outputs, proven application logic, and a measurable result. Start with reading and preparation—finding a service, retrieving evidence, comparing eligible options, or drafting a brief. Do not begin by submitting a form, accepting terms, booking a meeting, or making a commitment for the person. The first version should remove steps without removing context, permission, confirmation, or the human interface.
For a CMO, the question is not whether the site “has AI.” It is which job a visitor already needs to complete, where an agent can help, and which decision still belongs to the person. SEO and GEO help a site get discovered and cited. WebMCP lets the page describe structured actions to an agent using that page. A remote MCP server works independently of the page; an API serves integrations; visual automation tries to operate the interface. These are different investments.
Use the Agent-Ready Site Action Ladder
- Read — retrieve a public page, service, policy, availability fact, or other existing information. This is the lowest-risk starting point.
- Match — compare a stated need with eligible services, content, or options and return reasons and limitations.
- Qualify — organize the goal, systems, region, readiness, and constraints without creating a lead or changing CRM.
- Prepare — draft a brief, indicative estimate, or completed form for review; nothing is submitted.
- Confirm — display exactly what will be sent, to whom, and with which consequence; the person decides in the interface.
- Transact — submit, purchase, book, sign, or change records. Advance only when authentication, authorization, validation, confirmation, idempotency, and support already work without the agent.
ChatGPT documentation says site tools operate in the same live page and session. Chrome documents declarative and imperative APIs and emphasizes human-in-the-loop local workflows. The Community Group draft published November 2, 2026 is not a W3C Standard. Build progressive enhancement: unsupported browsers and people who prefer the regular interface must be able to complete the same work.
Write the Site Tool Contract
- Job — the user goal the tool supports and the decision it will not make.
- Input — minimum fields, types, limits, language, market, and allowed values; constrain free text.
- Identity and permission — what is public, what requires sign-in, which roles may act, and which data never enters.
- Effect — read, preparation, reversible change, or consequential action; describe the real effect rather than an aspirational name.
- Output — concise, verifiable, linked to the correct page or record, with uncertainty and next step.
- Failure and fallback — readable errors, no silent partial execution, and a route back to the human interface.
- Confirmation — content, recipient, price, or commitment shown before execution.
- Metric and owner — discovery, execution, success, abandonment, fallback, error, mature conversion, and the person reviewing it.
- Version — schema, logic, sources, permissions, and date; tools drift when the website changes.
Read-only, untrusted-content, and consequential annotations help an agent interpret a tool. They are hints, not security controls. The server still validates authorization, fields, rate limits, idempotency, and state. Chrome's guidance warns about prompt injection; a well-written tool description does not make a broad endpoint safe.
What MAKINAI's telemetry shows—and does not show
For the 30 days ending November 3, 2026, MAKINAI's aggregate telemetry recorded 808 WebMCP sessions and 133 tool calls. Two journeys reached match, qualification, and value stages; none reached drafted brief, contact opening, or submission. This is not a market benchmark or a causal test. It is one-site observation under limited current support and low commercial volume.
The useful operating lesson is that tool discovery is not intent, value, or a lead. Instrument every stage and preserve zero as zero. Do not multiply calls by an assumed conversion rate. The evidence architecture in https://makinai.co/insights/en/measure-ai-search-visibility-pipeline-geo keeps presence, visit, qualification, and pipeline separate.
First scope: three tools and no autonomous submission
- find_service — accepts business need, language, and region; returns up to three services with a reason, limitation, and URL.
- find_evidence — accepts a question and market; returns relevant articles or pages with date, source, and concise answer.
- prepare_consultation — organizes the goal, success measure, systems, constraints, region, and timing; returns a reviewable brief and contact link.
These tools map to work already visible on the website and can reuse existing search, catalog, and validation logic. The third stops before submission. If the person proceeds, the interface shows the fields and asks for confirmation. The agent action contract at https://makinai.co/insights/en/ai-agent-crm-action-contract-permissions covers permission design when the workflow crosses CRM or other systems.
Run a six-week pilot
- Week 1 — choose one observable task; baseline steps, abandonment, and outcome; exclude high-impact actions.
- Week 2 — map the interface, existing logic, authentication, data, errors, consent, events, and fallback.
- Week 3 — implement two read-only tools and one preparation tool with narrow schemas and verifiable responses.
- Week 4 — test normal tasks, ambiguity, malicious input, permissions, duplicates, language, mobile, and unsupported browsers.
- Week 5 — release to a small cohort; monitor execution, human review, and where the agent returns control.
- Week 6 — compare task success, time, error, fallback, qualified contact, and cost; keep, repair, expand, or retire.
Deliverables include a task inventory, risk ladder, versioned contracts, schemas, test suite, events, dashboard, runbook, fallback, confirmation policy, owner, and investment decision. A browser demo is not an operated capability.
Cost, architecture, and trade-offs
Cost rises with the number of tools, authentication states, connected systems, languages, markets, personal data, consequential actions, traffic, observability, security testing, support, and the pace of website change. Annotating a simple form may be inexpensive. Exposing recommendations, estimates, or scheduling requires logic, data, and error handling that should already exist.
WebMCP reduces navigation ambiguity but creates another versioned surface. An API or remote MCP server may be better for work that does not need an open page. The regular interface remains essential for accessibility, review, and fallback. Marketing owns the job and proposition; product and UX own confirmation; engineering implements; security and privacy test boundaries; analytics measures; sales and service validate the handoff.
Measure completed jobs—not calls
Measure tools discovered, calls started, invalid schemas, technical success, output usefulness, review, fallback, time, repetition, errors, incidents, and cost. For marketing, connect the visit, prepared brief, confirmed contact, qualification, opportunity, and revenue only afterward, keeping every stage as separate evidence.
The site may need better discovery through https://makinai.co/insights/en/company-search-absent-ai-answers-geo-plan or conversion through https://makinai.co/insights/en/ai-improve-website-conversion-without-replatforming before it needs agent tools. If a recurring task is clear, bring MAKINAI at https://makinai.co/services/en/data-content-intelligence-systems the current page, backend logic, volume, and the action that cannot happen without confirmation. We can scope the smallest pilot that makes the site useful to agents without creating an autonomous lead-submission channel.
The sources document current capabilities, an evolving draft, and recommended controls. They do not prove broad adoption, universal compatibility, or lead lift. The Ladder, Contract, three-tool scope, pilot, and economics are MAKINAI editorial recommendations for validation on the actual site.