Public AI web-readiness scanner and machine-facing observability discovery service.
Scored across 9 tools
scan_ai_web_readiness, evaluate_ai_web_readiness, and get_normalized_report all revolve around producing/retrieving readiness evidence reports, and the boundary between the one-call evaluator and a plain scan plus report fetch is subtle. The descriptions do clarify intent (one-call vs. two-step vs. read-existing), and the remaining tools (compare, capabilities, pricing, history, diagnose, request) are clearly distinct.
Nearly all tools follow a consistent snake_case verb_noun pattern (compare_..., diagnose_..., evaluate_..., get_..., request_..., scan_...), with the get_* family especially predictable. Minor awkwardness in names like compare_public_machine_web_evidence, but no convention mixing.
Nine tools is well within the ideal 3-15 range and each maps to a discrete operation (scan, evaluate, report, history, compare, capabilities, pricing, capability request, diagnosis). Nothing appears redundant enough to be padding or missing enough to feel thin.
The public readiness/evidence lifecycle is well covered: scanning, one-call evaluation, persisted report retrieval, history, comparison, capability/pricing discovery, and connection diagnosis. The only gap is that private/connected-site evidence is explicitly excluded throughout, so any authenticated-account workflows are absent.
Compare observable public machine-web readiness and evidence coverage for two to six public domains.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it only hints at read-only behavior via 'observable public'. It does not state whether this is a safe read, whether it triggers scanning, auth requirements, or runtime/rate considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the action and scope front-loaded and no filler. It says what it needs to say efficiently, though at the cost of omitting details covered elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations exist, so the description should explain what the comparison returns, yet it only describes the input scope. For a comparison tool whose value is the comparison result, this leaves a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single 'domains' parameter, so the description must compensate. It usefully restates the 2-6 item cardinality ('two to six public domains'), but gives no format guidance (URL vs bare domain) or ordering semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (Compare) and resource (observable public machine-web readiness and evidence coverage), and the 'two to six public domains' scope signals batch comparison rather than the single-target scan_ai_web_readiness or evaluate_ai_web_readiness. It is clear, though it never explicitly names a sibling to rule it out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance and no alternative tool is named. The 'two to six public domains' constraint implies a multi-domain comparison use case, but an agent must infer when to pick this over scan_ai_web_readiness or evaluate_ai_web_readiness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE: read-only MCP/A2A compatibility guidance for version negotiation, legacy/modern header errors, invalid params and unavailable A2A task methods. Never send raw headers, IPs or secrets.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| surface | Yes | ||
| operation | No | ||
| http_status | No | ||
| method_header | No | ||
| accept_profile | No | ||
| session_header | No | ||
| protocol_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose that the call is FREE and read-only and adds a real safety constraint ('Never send raw headers, IPs or secrets'). It stops short of saying whether auth is required, what the response looks like, or how the guidance is produced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the value proposition ('FREE: read-only') before the scope and the privacy caveat. No filler, though it is dense enough that the safety note could be separated for emphasis.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter diagnostic tool with 0% schema coverage, no annotations, and no output schema, the description leaves the agent guessing about input semantics and about what guidance is returned. The privacy warning is welcome but does not fill the parameter or behavior gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 8 parameters, so the description must compensate and largely does not: it never explains surface (the only required field), how reason should be selected, or what operation/http_status/envelope fields represent. The listed error categories loosely echo a few reason enum values, which is marginal help at best.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('diagnose agent connection') and narrows the domain to MCP/A2A compatibility guidance (version negotiation, header errors, invalid params, A2A task methods). It is clearly separable from the scan/readiness siblings, though it never names an alternative to route against.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The error scenarios listed (version negotiation, legacy/modern header mismatch, invalid params, unavailable A2A task methods) imply when the tool is relevant, so usage is inferable. There is no explicit when-not-to-use guidance and no routing to or from the eight sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE ONE-CALL EVALUATION: run the existing bounded public readiness scan, retrieve the matching persisted normalized evidence report, verify scan ID + hostname, then return observed findings and next actions in this one response. Unknown evidence is not a successful observation. Never charges or changes a website.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden and does so well: it declares the call is free, never charges or mutates a website, retrieves persisted (idempotent-style) evidence, and validates scan ID + hostname. It stops short of stating auth requirements, latency, or rate limits, but the safety/side-effect profile is unusually well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core benefit ('FREE ONE-CALL EVALUATION') followed by the pipeline steps and a constraint. It is dense but each clause adds meaning; no filler phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description explains the return at a meaningful level ('observed findings and next actions') and states the operation's side-effect safety. The main gap is the unexplained 'domain' parameter, which prevents a full 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'domain' parameter has 0% schema description coverage, so the description must compensate for the format, validity rules, and hostname relationship. It mentions 'hostname' verification but never explains what 'domain' should contain, leaving the parameter meaning entirely to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear composite verb sequence: run the bounded readiness scan, retrieve the matching persisted normalized evidence report, verify scan ID + hostname, and return findings. The 'ONE-CALL EVALUATION' framing makes it distinguishable from the sibling scan_ai_web_readiness + get_normalized_report two-step, though the siblings are not named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'FREE ONE-CALL EVALUATION' and 'Never charges or changes a website' imply it is the convenience alternative to multi-call flows, and 'Unknown evidence is not a successful observation' sets an interpretation rule. However, there is no explicit when-to-use vs when-not guidance or pointer to the sibling tools it wraps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current public capability contract served at /api/capabilities, including active protocol, evidence, and security boundaries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and it does meaningful work: it discloses that the data is public, current, and served from a specific endpoint, and it names the included sections. The word 'Return' implies a read-only operation, though it does not explicitly address side effects, rate limits, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that names the action, resource, endpoint, and contents without wasted words. Every phrase adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema read tool, the description is nearly complete: endpoint, scope, and content categories are all present. It does not specify the exact response format or error cases, but the low complexity makes those omissions minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so parameter documentation is not needed; the schema already covers everything (100% coverage). The description adds no parameter semantics, but none are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and identifies a precise resource: the public capability contract served at /api/capabilities. It also enumerates the main content areas (active protocol, evidence, security boundaries), which clearly separates it from pricing and readiness-scan siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: call this when you need the current public capability contract. The description does not explicitly state when not to use it or compare it to get_machine_pricing or scan_ai_web_readiness, but the endpoint and content scope make the intended context reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the same public plan catalog served at /api/machine-pricing. Provider configuration identifiers and payment credentials are excluded.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the response mirrors the public endpoint and explicitly excludes provider configuration identifiers and payment credentials, which is valuable context about what the tool will and will not return.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence followed by a precise exclusion note. Every word earns its place; there is no redundant phrasing or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, public-catalog lookup, the description covers the purpose and the key exclusion. It does not spell out output format or authentication, but the simplicity of the tool and the 'public' qualifier make those omissions acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this with an empty object. The description adds no parameter-specific detail, but none is needed; the baseline for a zero-parameter tool is appropriately high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') plus a clear resource ('public plan catalog') and even ties it to an endpoint. It is distinct from the sibling tools, which target capabilities and AI web readiness, so an agent can immediately tell this is the pricing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for retrieving public pricing data but does not explicitly state when to use it over the siblings. There is no direct mention of alternatives or exclusions, though the tool name and endpoint reference make the intent reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read an existing or boundedly refreshed public AI web-readiness evidence report for a public domain. Unknown evidence remains unknown.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'boundedly refreshed' hints that a read may trigger some update and 'Unknown evidence remains unknown' hints at missing-data semantics, but neither auth requirements, refresh limits, nor failure behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, verb+resource front-loaded, so it is tight. But 'boundedly refreshed' and 'Unknown evidence remains unknown' are vague jargon that costs clarity without adding actionable detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should explain what the report contains, what 'unknown' evidence means, and whether calling it can mutate state via refresh. None of that is present, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and only one parameter exists. The description adds that the domain is 'public' and that evidence is scoped to it, but provides no format, validation, or expected-domain syntax to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb (read) and resource (public AI web-readiness evidence report) scoped to a public domain. However, it does not distinguish itself from siblings like scan_ai_web_readiness or evaluate_ai_web_readiness, and 'normalized' in the name is never explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Read an existing ... report' weakly implies you must already have a report, hinting at a contrast with scan_ai_web_readiness, but no when-to-use, when-not, or alternative tool is named. The agent must infer routing entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve public, exact-target scan history and observed changes for a domain; excludes private connected-site evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the read scope: public-only data, exact-target matching, and exclusion of private connected-site evidence. It says nothing about ordering, pagination, time coverage of the history, or whether repeated scans overwrite anything, which leaves meaningful behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the scope constraint front-loaded; nothing is wasted and the key differentiator appears before any incidental detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read tool with no output schema and no annotations, the description covers purpose and scope adequately but omits what 'history' returns structurally and what 'limit' controls. It is callable but not fully specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only implies the 'domain' parameter ('for a domain') and says nothing about 'limit' (max 100) or the domain string format/length constraints. The description adds minimal meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('Retrieve') and resource ('public, exact-target scan history and observed changes for a domain'), and the scope qualifier ('public, exact-target') distinguishes it from the private-evidence sibling family. It does not name which sibling to use instead, so it falls short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the agent can infer it is for looking up past scans of a given domain, and the clause 'excludes private connected-site evidence' acts as a partial when-not constraint. There is no explicit guidance on when to prefer this over compare_public_machine_web_evidence or scan_ai_web_readiness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Declare a missing capability by bounded technical slug and category. This records aggregate research evidence only; it will not execute, charge, provision, queue or promise future delivery.
| Name | Required | Description | Default |
|---|---|---|---|
| horizon | No | ||
| category | Yes | ||
| requested_capability | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that this only 'records aggregate research evidence' and enumerates five side effects it does not perform (execute, charge, provision, queue, promise). It does not mention authentication requirements or what the call returns, but the non-effect disclosure is the highest-value behavioral fact here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the core purpose is front-loaded ahead of the scoping caveat. Every clause carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-annotation, no-output-schema tool with three parameters at 0% schema coverage, the definition covers non-effects well but leaves real gaps: horizon is undocumented, the slug format is only hinted at, and there is no guidance on how this relates to get_machine_capabilities. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. 'Bounded technical slug' gestures at the requested_capability pattern constraint and 'category' maps to the enum parameter, but the third parameter, horizon (now/later/unspecified), is never mentioned and no format or example is given for the slug. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb (declare) and resource (a missing capability) qualified by 'bounded technical slug and category', which is far more precise than the title's vague 'Request ... for a Future Release'. It implicitly separates itself from the read-side sibling get_machine_capabilities by framing this as recording a gap, but it never names that sibling, so differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second clause is unusually clear negative guidance: this tool 'will not execute, charge, provision, queue or promise future delivery', which tells the agent exactly what this call is not for. What's missing is positive routing — nothing says to check get_machine_capabilities first before declaring a capability missing, or when a request is appropriate versus redundant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE EVALUATION FIRST: run a bounded public website readiness scan and get an explicit next-tool recommendation for a normalized evidence report. Read-only; no account or charge. Private/local network targets are rejected; observations may be saved to public scan history.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Public hostname or HTTP(S) URL to inspect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: read-only, no account or charge, private/local targets rejected, scan is bounded, and a genuine side effect is disclosed ('observations may be saved to public scan history'). It omits rate limits, timeouts, or what 'bounded' concretely means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and front-loaded with the 'FREE EVALUATION FIRST' qualifier, and every clause carries information (cost, safety, side effect, routing). Slightly jargon-dense in the 'normalized evidence report' phrase, but no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only scan with no output schema and no annotations, the description covers cost, safety, target restrictions, side effects, and next steps. Return-shape detail is not needed absent an output schema, though what the report actually contains is only loosely implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there is only one parameter, so the schema already documents 'domain' fully. The description adds no syntax, normalization, or format guidance beyond what the schema provides; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('run a bounded public website readiness scan') and names its output artifact ('normalized evidence report'), which maps to the sibling get_normalized_report. It does not explicitly differentiate itself from the close sibling evaluate_ai_web_readiness, so the distinction must be inferred.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'FREE EVALUATION FIRST' positions this as the entry-point scan and it promises an 'explicit next-tool recommendation,' giving clear ordering guidance. It stops short of stating when NOT to use it or naming the alternative for private/authenticated targets beyond rejection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
diagnose_agent_connectionevaluate_ai_web_readinessrequest_machine_capabilitycompare_public_machine_web_evidenceget_normalized_reportget_scan_historyget_machine_capabilitiesget_machine_pricingscan_ai_web_readinessScan any public site for AI-agent visibility; get scored findings, a machine-readable fix pack, and
Scan any public website and see how ready it is for AI agents and AI search, explained plainly.
Scan a public website for AI agent readiness: 60 checks, a score, and the evidence for each.
Public website health scan, AI-crawler and structured-data readiness, and a local presence score.
Add one secure layer between your agents and this server.
