Website intelligence audits for AI agents: free preview plus x402-paid Agent Readiness scoring
Scored across 7 tools
Each tool has a clearly distinct purpose: auditing agent readiness, previewing a website audit, extracting markdown, extracting structured data, parsing feeds, mapping links, and summarizing pages. Even the two audit tools are cleanly separated by target (agent-facing vs general website quality), and the two extract tools are separated by output format.
Several tools follow a clear verb_noun pattern (audit_agent_readiness, audit_website_preview, extract_page_markdown, extract_structured_data), but feed_parse uses noun_verb order, link_map is noun_noun, and summarize is a bare verb. The mixed conventions are still readable but not fully predictable.
Seven tools is a well-scoped set for a web analysis and auditing server. Each tool covers a distinct single-page or feed capability without unnecessary redundancy or bloat.
The server covers many single-page analysis operations well, including content extraction, structured data extraction, summarization, link mapping, and feed parsing. However, despite the 'site-audit' name, it lacks a true multi-page crawling or full production audit tool in the MCP surface—only a one-page preview audit is exposed, with the real audit requiring a raw HTTP call.
PAID CAPABILITY ($0.075 USDC per successful audit via x402 v2). Passively assesses how well a public website or service can be discovered, understood, invoked, and—where explicitly applicable—paid by agents. This MCP call validates the target and returns the canonical x402 HTTP handoff; payment and the versioned result are exchanged at GET https://api.santosautomation.com/api/agent-readiness?url=...&depth=quick. No account or API key is required.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A publicly reachable HTTP or HTTPS target. | |
| depth | No | quick |
| Name | Required | Description |
|---|---|---|
| url | Yes | Exact URL to request, then pay for and retry. |
| method | Yes | HTTP method to use for the paid request. |
| network | Yes | CAIP-2 chain id, eip155:8453 (Base mainnet). |
| settles | No | When funds move. |
| protocol | Yes | x402-v2 |
| price_usdc | Yes | Price in USDC for one successful call. |
| payment_required | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses the $0.075 USDC cost, the fact that the MCP call only validates and returns an x402 handoff while actual payment and result exchange happen at an external GET URL, and that no account or API key is required. This adds significant behavioral context not available from annotations alone.
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 dense but efficient: cost, purpose, MCP behavior, external handoff URL, and authentication requirement each earn their place. The paid capability is front-loaded, and the rest flows logically.
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 the 2-param schema, annotations, and output schema provided, the description conveys the essential call flow, including the paid external handoff and the no-auth requirement. It does not address sibling selection or rate limits, but those are not necessary for making a correct first call.
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 schema documents url reasonably well, but depth has no description beyond an enum and default. The tool description only shows 'depth=quick' in the handoff URL and does not explain what depth controls. With schema coverage at 50% and no compensating explanation in the description, agents receive little semantic help for the depth parameter.
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 clearly identifies the tool's purpose: it assesses how well a public website or service can be discovered, understood, invoked, and paid by agents, and it explicitly states that this MCP call validates the target and returns the canonical x402 handoff. It does not explicitly differentiate itself from siblings like audit_website_preview or link_map, but the specific object of assessment—agent readiness—makes the purpose clear.
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 when the tool is relevant by describing the agent-readiness assessment scope, the paid capability, and the lack of required account/API key. However, it never explicitly states when to choose this tool over siblings such as audit_website_preview or extract_page_markdown, nor does it give any when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE PREVIEW (1 audit per day per caller IP) of Santos Website Intelligence. Runs a fast Quick Intelligence Audit of one public page: fetch timing, page weight, SEO, basic HTML accessibility, security headers, Website Intelligence dimensions, pass/fail checks, and remediation guidance. It audits one page only—no crawling, JavaScript rendering, Core Web Vitals, WCAG certification, or vulnerability scanning. Note for hosted agents: the quota is keyed on the calling IP, so all users of one platform share a single daily preview. Treat it as a sample of the output, not as capacity. For real use, call the machine-payable production endpoint: GET https://api.santosautomation.com/api/audit?url=... — $0.015 USDC per successful audit on Base mainnet (eip155:8453) via x402 v2; no account or API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A publicly reachable HTTP or HTTPS page. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| checks | No | Individual pass/fail checks with detail. |
| issues | Yes | |
| scores | Yes | performance, seo, accessibility, security (0-100 each). |
| timing_ms | No | |
| audited_by | No | |
| fetched_at | No | |
| http_status | No | |
| overall_score | Yes | |
| schema_version | Yes | |
| website_intelligence | No | Discoverable, Understandable, Callable, Trustworthy. |
| website_intelligence_score | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses critical behavioral traits: the one-per-day quota keyed to caller IP, the shared quota across hosted agent users, the non-crawling/non-rendering limitation, and the paid production alternative. This is substantial transparency about rate limits and operational constraints.
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 dense but every sentence earns its place: quota, scope, exclusions, hosted-agent warning, and production alternative. Key limitations are front-loaded, and the text remains structured and readable despite covering a lot of constraint 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 single-parameter tool with a rich output schema and annotations, the description covers all essential context: what the tool examines, what it explicitly does not do, quota behavior, and how to transition to the production endpoint. Nothing an agent needs to decide whether to invoke it is missing.
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 for the single `url` parameter is 100%, so the schema already documents it as a publicly reachable HTTP or HTTPS page. The description's phrase 'one public page' reinforces the parameter but adds little new semantic meaning beyond what the schema provides, so the baseline of 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?
The description states a specific verb and resource: it 'Runs a fast Quick Intelligence Audit of one public page' and enumerates exactly what it checks (fetch timing, page weight, SEO, security headers, etc.). It also clearly distinguishes itself from a production audit and from sibling tools by saying it is a single-page preview with no crawling or JavaScript rendering.
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 explicitly says when to use this tool—for a free daily sample audit—and when not to use it: 'For real use, call the machine-payable production endpoint.' It also states the quota model and that it audits only one page, giving the agent clear conditions for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID CAPABILITY ($0.005 USDC per successful extraction via x402 v2). Fetches one public page and returns its main content as clean Markdown plus title, description, outbound links, and word count. Single page only — no crawling or JavaScript rendering. This MCP call validates the target and returns the canonical x402 HTTP handoff; payment and the result are exchanged at GET https://api.santosautomation.com/v1/extract?url=... (or POST {"url": "…"}). No account or API key is required.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A publicly reachable HTTP or HTTPS page. |
| Name | Required | Description |
|---|---|---|
| url | Yes | Exact URL to request, then pay for and retry. |
| method | Yes | HTTP method to use for the paid request. |
| network | Yes | CAIP-2 chain id, eip155:8453 (Base mainnet). |
| settles | No | When funds move. |
| protocol | Yes | x402-v2 |
| price_usdc | Yes | Price in USDC for one successful call. |
| payment_required | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it is a paid capability with a specific cost, it validates the target and returns a canonical x402 handoff, and the actual payment/result exchange happens at a separate endpoint. This goes beyond what annotations provide.
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 compact and front-loaded with the most critical information (paid capability, cost, and what it does). Every sentence adds value, though the x402 handoff explanation is somewhat dense and could be clearer for an agent unfamiliar with the protocol.
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?
The description covers the tool's purpose, scope, payment model, and handoff flow. The output schema exists, so return values don't need to be explained. The only minor gap is that it doesn't explicitly state when to prefer this over extract_structured_data or link_map, but the single-page Markdown scope is clear enough.
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 100%, so the schema already documents the url parameter as 'A publicly reachable HTTP or HTTPS page.' The description adds the requirement that the page be public and single, but doesn't add much beyond the schema. 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?
The description states a specific verb ('Fetches'), a resource ('one public page'), and the output ('main content as clean Markdown plus title, description, outbound links, and word count'). It also explicitly distinguishes itself from crawling and JavaScript rendering, which helps differentiate it from sibling tools like link_map and extract_structured_data.
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 explicitly says 'Single page only — no crawling or JavaScript rendering' and explains the x402 HTTP handoff flow. It also notes that no account or API key is required, which helps an agent decide when to use it. It doesn't name sibling alternatives explicitly, but the single-page scope and payment model provide clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID CAPABILITY ($0.08 USDC per successful schema-conforming extraction via x402 v2). Fetches one public page and returns JSON fields extracted by an LLM against your own JSON Schema, re-validated against that schema before return; non-conforming output returns 422 and never settles. Single page only — no crawling or JavaScript rendering; page content is truncated to 8000 characters. This MCP call validates the target and returns the canonical x402 HTTP handoff; payment and the result are exchanged at POST https://api.santosautomation.com/v1/extract/structured with {"url": "…", "schema": {...}} — POST only, because a JSON Schema does not fit in a query string. No account or API key is required.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A publicly reachable HTTP or HTTPS page. | |
| schema | No | Optional here — the handoff is returned either way. Required on the paid POST: a self-contained JSON Schema (type: object, no $ref) describing the fields to extract. Max 4000 characters. |
| Name | Required | Description |
|---|---|---|
| url | Yes | Exact URL to request, then pay for and retry. |
| method | Yes | HTTP method to use for the paid request. |
| network | Yes | CAIP-2 chain id, eip155:8453 (Base mainnet). |
| settles | No | When funds move. |
| protocol | Yes | x402-v2 |
| price_usdc | Yes | Price in USDC for one successful call. |
| payment_required | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond annotations: the paid capability and exact price, the 8000-character truncation, the re-validation against the schema, the 422 non-conforming output behavior, and the fact that the MCP call only validates and returns a handoff while payment/result happen at the POST endpoint. This is rich, non-obvious behavior that an agent needs to know.
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 dense but every sentence earns its place: pricing, behavior, constraints, handoff details, and auth requirements are all packed into a compact block. It is front-loaded with the most critical fact (paid capability) and ends with the auth note. It could arguably be split into clearer sections, but it is not bloated.
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?
Given the tool's complexity (paid x402 flow, schema validation, handoff vs. actual extraction), the description is remarkably complete. It covers the payment model, the exact POST endpoint and payload shape, the validation behavior, the truncation limit, the single-page constraint, and the auth requirement. The output schema exists, so return values need not be spelled out. Nothing an agent needs to decide whether to call this tool and how to invoke it correctly is missing.
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 100%, so the schema already documents both parameters. The description adds meaning by explaining that 'schema' is optional on the MCP call but required on the paid POST, and by adding constraints (self-contained, type: object, no $ref, max 4000 characters) that go beyond the schema's own description. It also clarifies that 'url' must be publicly reachable. This is above the baseline 3.
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 states a specific verb ('Fetches one public page and returns JSON fields extracted by an LLM against your own JSON Schema'), names the resource (a public page + user-provided JSON Schema), and clearly distinguishes itself from siblings by noting it is single-page only, with no crawling or JavaScript rendering. It also names the paid POST endpoint, which differentiates it from free sibling tools like extract_page_markdown or summarize.
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 explicitly says when to use it (when you need schema-conforming structured extraction from a single public page) and what it is not for ('no crawling or JavaScript rendering', 'Single page only'). It also gives the exact HTTP handoff and POST-only constraint, and notes no account/API key is required. This is strong routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID CAPABILITY ($0.003 USDC per successful parse via x402 v2). Parses one public feed URL (RSS 2.0, Atom, or JSON Feed) into normalized JSON with feed metadata and up to 50 items; non-feed targets return 422 and never settle. This MCP call validates the target and returns the canonical x402 HTTP handoff; payment and the result are exchanged at GET https://api.santosautomation.com/v1/feed?url=... (or POST {"url": "…"}). No account or API key is required.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A publicly reachable HTTP or HTTPS feed URL. |
| Name | Required | Description |
|---|---|---|
| url | Yes | Exact URL to request, then pay for and retry. |
| method | Yes | HTTP method to use for the paid request. |
| network | Yes | CAIP-2 chain id, eip155:8453 (Base mainnet). |
| settles | No | When funds move. |
| protocol | Yes | x402-v2 |
| price_usdc | Yes | Price in USDC for one successful call. |
| payment_required | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, which the description confirms. Beyond that, it discloses substantial behavior: the paid capability ($0.003 USDC via x402 v2), the never-settling behavior on non-feed targets, the two-phase handoff with explicit GET/POST endpoints, the 50-item limit, and the no-auth requirement. This adds rich context without contradicting annotations.
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?
Four sentences, each with a distinct job: price warning, parse behavior, error/never-settle behavior plus handoff mechanics, and auth requirement. The cost is front-loaded as the most critical fact, and no sentence is redundant. Dense but efficient, with every word earning its place.
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?
The description covers cost, input scope, output size, feed type validation, error behavior (422 and never settle), the exact payment/result exchange mechanics, and auth. Since an output schema is present to document the return shape, nothing an agent needs to select and invoke this tool correctly is missing.
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 the url parameter is documented with format uri, so the baseline is 3. The description adds value beyond the schema by restricting valid targets to feed types, emphasizing public reachability, clarifying single-URL usage ('one public feed URL'), and showing how the URL is passed in the handoff. This meaningfully strengthens the agent's understanding of acceptable values.
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 states a specific verb ('Parses'), a specific resource ('one public feed URL (RSS 2.0, Atom, or JSON Feed)'), and a concrete outcome ('normalized JSON with feed metadata and up to 50 items'). This clearly differentiates it from siblings like extract_page_markdown and extract_structured_data, which target arbitrary pages rather than feed formats.
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 defines the tool's scope precisely—only RSS 2.0, Atom, or JSON Feed URLs—and warns that 'non-feed targets return 422 and never settle', setting agent expectations. It does not explicitly name sibling alternatives or state when-not-to-use conditions, but the feed-only constraint is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID CAPABILITY ($0.003 USDC per successful link map via x402 v2). Maps one public HTML page's links into a categorized link map — kind internal/external plus topic tags (docs, pricing, api, careers, social, feed) with per-category counts, up to 200 links. This MCP call validates the target and returns the canonical x402 HTTP handoff; payment and the result are exchanged at GET https://api.santosautomation.com/v1/links?url=... (or POST {"url": "…"}). No account or API key is required.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A publicly reachable HTTP or HTTPS page. |
| Name | Required | Description |
|---|---|---|
| url | Yes | Exact URL to request, then pay for and retry. |
| method | Yes | HTTP method to use for the paid request. |
| network | Yes | CAIP-2 chain id, eip155:8453 (Base mainnet). |
| settles | No | When funds move. |
| protocol | Yes | x402-v2 |
| price_usdc | Yes | Price in USDC for one successful call. |
| payment_required | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite readOnly/idempotent annotations, the description reveals critical extra behavior: this is a PAID capability with per-use cost, the MCP call only validates and returns an x402 handoff, and the actual payment/result exchange happens at a separate GET/POST endpoint. This two-stage flow is exactly the kind of behavior an agent needs and the annotations don't convey.
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 dense but well-organized: capability and cost first, then operational flow, then auth prerequisite. Slightly long, but every clause carries worthwhile information (categories, limit, handoff, endpoint, no key).
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 tool with a full output schema and safety annotations, the description covers the paid workflow, the endpoint, the validation step, and the conditions of use. Nothing an agent needs to call it correctly is missing.
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 input schema already gives 100% coverage for the url parameter ('A publicly reachable HTTP or HTTPS page'). The description reinforces the need for a public HTML page and clarifies the one-page scope, but it doesn't add materially different parameter-level information.
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?
Description states a specific action ('Maps one public HTML page's links into a categorized link map'), gives output details (internal/external, topic tags, per-category counts, 200-link limit), and thereby distinguishes from siblings like extract_page_markdown or summarize.
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?
It clearly signals when to use: for a single public HTML page requiring categorized link extraction, and states the no-API-key prerequisite. It doesn't name an alternative tool or explicitly say when not to use it, but the context is clear enough for a single-purpose utility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID CAPABILITY ($0.033 USDC per successful summary via x402 v2). Summarizes one public HTML page into a Claude-generated structured summary (title, summary, key_facts, entities, word_count) with an optional focus steering prompt; non-HTML targets return 422 and never settle. This MCP call validates the target and returns the canonical x402 HTTP handoff; payment and the result are exchanged at POST https://api.santosautomation.com/v1/summarize with {"url": "…"} (or GET ?url=&focus=). No account or API key is required.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A publicly reachable HTTP or HTTPS page. | |
| focus | No | Optional steering prompt for the summary, e.g. "pricing plans". |
| Name | Required | Description |
|---|---|---|
| url | Yes | Exact URL to request, then pay for and retry. |
| method | Yes | HTTP method to use for the paid request. |
| network | Yes | CAIP-2 chain id, eip155:8453 (Base mainnet). |
| settles | No | When funds move. |
| protocol | Yes | x402-v2 |
| price_usdc | Yes | Price in USDC for one successful call. |
| payment_required | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds substantial behavioral context beyond those: the payment requirement, the 422 error for non-HTML targets, the canonical x402 HTTP handoff, and the exact endpoint for payment and result exchange. It also notes that no API key is required. No contradictions with annotations.
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 dense but every sentence earns its place: cost, functionality, output fields, focus capability, error behavior, handoff details, endpoint, and requirement of no account. It is front-loaded with the most important usage determinant (paid capability) and structured logically from what it does to how to call it.
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?
The tool has an output schema, so return values are documented. The description covers input requirements, error handling, payment flow, endpoint, and lack of authentication. Nothing an agent needs to correctly invoke the tool is missing; the information is complete and actionable.
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 schema already describes both parameters (url is a publicly reachable HTTP/HTTPS page, focus is an optional steering prompt), so coverage is 100%. The description adds value by explaining the output structure (title, summary, key_facts, entities, word_count) and clarifies that focus steers the summary, slightly enriching semantics beyond the schema. No enums or nested objects require extra explanation.
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 states a specific verb ('summarizes'), a specific resource ('one public HTML page'), and the exact output structure ('title, summary, key_facts, entities, word_count'). This clearly distinguishes it from sibling extraction tools like extract_page_markdown or extract_structured_data, which have different purposes.
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 clarifies when the tool applies ('public HTML page') and when it fails ('non-HTML targets return 422'), and it explicitly notes the cost ('PAID CAPABILITY') as a usage consideration. However, it does not explicitly enumerate alternatives or say 'use this when you need a summary, not raw extraction', leaving some comparison to inference from the sibling list.
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.
audit_agent_readiness1 field changedOutput schema / properties / free_preview_urlRemoved value: -{
- "description": "Free alternative, where one exists.",
- "format": "uri",
- "type": "string"
-}audit_website_preview1 field changedInput schema / properties / tokenRemoved value: -{
- "description": "Optional verified-email token. Without it the daily free quota is keyed on the caller IP, which every caller behind that address shares — hosted agents should pass a token so each user gets their own allowance. Obtain one via POST /api/leads/verify/request then /confirm; valid 30 days.",
- "type": "string"
-}extract_page_markdown20 fields changedInput schema / properties / tokenRemoved value: -{
- "description": "Optional verified-email token. Without it the daily free quota is keyed on the caller IP, which every caller behind that address shares — hosted agents should pass a token so each user gets their own allowance. Obtain one via POST /api/leads/verify/request then /confirm; valid 30 days.",
- "type": "string"
-}Output schema / properties / bylineRemoved value: -{
- "type": [
- "string",
- "null"
- ]
-}Output schema / properties / canonical_urlRemoved value: -{
- "type": [
- "string",
- "null"
- ]
-}Output schema / properties / descriptionRemoved value: -{
- "type": [
- "string",
- "null"
- ]
-}Output schema / properties / fetched_atRemoved value: -{
- "format": "date-time",
- "type": "string"
-}Output schema / properties / final_urlRemoved value: -{
- "format": "uri",
- "type": "string"
-}Output schema / properties / http_statusRemoved value: -{
- "type": "integer"
-}Output schema / properties / linksRemoved value: -{
- "items": {
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / markdownRemoved value: -{
- "description": "Readability-isolated main content.",
- "type": "string"
-}Output schema / properties / methodAdded value: +{
+ "description": "HTTP method to use for the paid request.",
+ "type": "string"
+}Output schema / properties / networkAdded value: +{
+ "description": "CAIP-2 chain id, eip155:8453 (Base mainnet).",
+ "type": "string"
+}Output schema / properties / payment_requiredAdded value: +{
+ "const": true,
+ "type": "boolean"
+}Output schema / properties / price_usdcAdded value: +{
+ "description": "Price in USDC for one successful call.",
+ "type": "string"
+}Output schema / properties / protocolAdded value: +{
+ "description": "x402-v2",
+ "type": "string"
+}Output schema / properties / schema_versionRemoved value: -{
- "type": "string"
-}Output schema / properties / settlesAdded value: +{
+ "description": "When funds move.",
+ "type": "string"
+}Output schema / properties / titleRemoved value: -{
- "type": [
- "string",
- "null"
- ]
-}Output schema / properties / url / descriptionAdded value: +"Exact URL to request, then pay for and retry."Output schema / properties / word_countRemoved value: -{
- "type": "integer"
-}Output schema / requiredPrevious value: -[
- "schema_version",
- "url",
- "markdown",
- "word_count"
-]New value: +[
+ "payment_required",
+ "protocol",
+ "method",
+ "url",
+ "price_usdc",
+ "network"
+]extract_structured_data15 fields changedInput schema / properties / schema / descriptionPrevious value: -"Self-contained JSON Schema (type: object, no $ref) describing the fields to extract. Max 4000 characters."New value: +"Optional here — the handoff is returned either way. Required on the paid POST: a self-contained JSON Schema (type: object, no $ref) describing the fields to extract. Max 4000 characters."Input schema / properties / tokenRemoved value: -{
- "description": "Optional verified-email token. Without it the daily free quota is keyed on the caller IP, which every caller behind that address shares — hosted agents should pass a token so each user gets their own allowance. Obtain one via POST /api/leads/verify/request then /confirm; valid 30 days.",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "url",
- "schema"
-]New value: +[
+ "url"
+]Output schema / properties / dataRemoved value: -{
- "description": "Fields extracted against the caller's own JSON Schema, re-validated before return.",
- "type": "object"
-}Output schema / properties / methodAdded value: +{
+ "description": "HTTP method to use for the paid request.",
+ "type": "string"
+}Output schema / properties / modelRemoved value: -{
- "type": "string"
-}Output schema / properties / networkAdded value: +{
+ "description": "CAIP-2 chain id, eip155:8453 (Base mainnet).",
+ "type": "string"
+}Output schema / properties / payment_requiredAdded value: +{
+ "const": true,
+ "type": "boolean"
+}Output schema / properties / price_usdcAdded value: +{
+ "description": "Price in USDC for one successful call.",
+ "type": "string"
+}Output schema / properties / protocolAdded value: +{
+ "description": "x402-v2",
+ "type": "string"
+}Output schema / properties / schema_versionRemoved value: -{
- "type": "string"
-}Output schema / properties / settlesAdded value: +{
+ "description": "When funds move.",
+ "type": "string"
+}Output schema / properties / url / descriptionAdded value: +"Exact URL to request, then pay for and retry."Output schema / properties / word_countRemoved value: -{
- "type": "integer"
-}Output schema / requiredPrevious value: -[
- "data"
-]New value: +[
+ "payment_required",
+ "protocol",
+ "method",
+ "url",
+ "price_usdc",
+ "network"
+]feed_parse1 field changedOutput schema / properties / free_preview_urlRemoved value: -{
- "description": "Free alternative, where one exists.",
- "format": "uri",
- "type": "string"
-}link_map1 field changedOutput schema / properties / free_preview_urlRemoved value: -{
- "description": "Free alternative, where one exists.",
- "format": "uri",
- "type": "string"
-}summarize1 field changedOutput schema / properties / free_preview_urlRemoved value: -{
- "description": "Free alternative, where one exists.",
- "format": "uri",
- "type": "string"
-}audit_agent_readiness29 fields changedOutput schema / $idRemoved value: -"https://api.santosautomation.com/schemas/agent-readiness-result-1.0.0.json"Output schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Output schema / properties / applicabilityRemoved value: -{
- "additionalProperties": {
- "enum": [
- "tested",
- "not_applicable",
- "unknown"
- ],
- "type": "string"
- },
- "type": "object"
-}Output schema / properties / confidenceRemoved value: -{
- "maximum": 1,
- "minimum": 0,
- "type": "number"
-}Output schema / properties / fetch_budgetRemoved value: -{
- "type": "object"
-}Output schema / properties / findingsRemoved value: -{
- "items": {
- "properties": {
- "category": {
- "type": "string"
- },
- "confidence": {
- "enum": [
- "low",
- "medium",
- "high"
- ],
- "type": "string"
- },
- "evidence": {
- "type": "object"
- },
- "id": {
- "type": "string"
- },
- "recommendation": {
- "type": "string"
- },
- "severity": {
- "enum": [
- "info",
- "low",
- "moderate",
- "high"
- ],
- "type": "string"
- },
- "status": {
- "enum": [
- "pass",
- "fail",
- "unknown",
- "not_applicable"
- ],
- "type": "string"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "category",
- "severity",
- "confidence",
- "status",
- "title",
- "recommendation"
- ],
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / free_preview_urlAdded value: +{
+ "description": "Free alternative, where one exists.",
+ "format": "uri",
+ "type": "string"
+}Output schema / properties / gradeRemoved value: -{
- "enum": [
- "A",
- "B",
- "C",
- "D",
- "F"
- ],
- "type": "string"
-}Output schema / properties / interfacesRemoved value: -{
- "type": "object"
-}Output schema / properties / limitationsRemoved value: -{
- "items": {
- "type": "string"
- },
- "type": "array"
-}Output schema / properties / methodAdded value: +{
+ "description": "HTTP method to use for the paid request.",
+ "type": "string"
+}Output schema / properties / networkAdded value: +{
+ "description": "CAIP-2 chain id, eip155:8453 (Base mainnet).",
+ "type": "string"
+}Output schema / properties / payment_requiredAdded value: +{
+ "const": true,
+ "type": "boolean"
+}Output schema / properties / price_usdcAdded value: +{
+ "description": "Price in USDC for one successful call.",
+ "type": "string"
+}Output schema / properties / profileRemoved value: -{
- "enum": [
- "general_website",
- "documentation_site",
- "api_provider",
- "mcp_provider",
- "agent_commerce_provider"
- ],
- "type": "string"
-}Output schema / properties / protocolAdded value: +{
+ "description": "x402-v2",
+ "type": "string"
+}Output schema / properties / readiness_levelRemoved value: -{
- "additionalProperties": false,
- "properties": {
- "level": {
- "maximum": 4,
- "minimum": 0,
- "type": "integer"
- },
- "name": {
- "type": "string"
- }
- },
- "required": [
- "level",
- "name"
- ],
- "type": "object"
-}Output schema / properties / recommended_actionsRemoved value: -{
- "items": {
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / schema_versionRemoved value: -{
- "const": "1.0.0",
- "type": "string"
-}Output schema / properties / scoreRemoved value: -{
- "maximum": 100,
- "minimum": 0,
- "type": "integer"
-}Output schema / properties / settlesAdded value: +{
+ "description": "When funds move.",
+ "type": "string"
+}Output schema / properties / subscoresRemoved value: -{
- "additionalProperties": {
- "maximum": 100,
- "minimum": 0,
- "type": "integer"
- },
- "type": "object"
-}Output schema / properties / targetRemoved value: -{
- "additionalProperties": false,
- "properties": {
- "canonical_origin": {
- "format": "uri",
- "type": "string"
- },
- "final_url": {
- "format": "uri",
- "type": "string"
- },
- "requested_url": {
- "type": "string"
- }
- },
- "required": [
- "requested_url",
- "canonical_origin",
- "final_url"
- ],
- "type": "object"
-}Output schema / properties / tested_coverage_percentRemoved value: -{
- "maximum": 100,
- "minimum": 0,
- "type": "integer"
-}Output schema / properties / urlAdded value: +{
+ "description": "Exact URL to request, then pay for and retry.",
+ "format": "uri",
+ "type": "string"
+}Output schema / properties / website_intelligenceRemoved value: -{
- "description": "Additive AI Website Intelligence presentation with four dimensions, coverage, confidence, and prioritized fixes.",
- "properties": {
- "dimensions": {
- "properties": {
- "callable": {
- "maximum": 100,
- "minimum": 0,
- "type": [
- "integer",
- "null"
- ]
- },
- "discoverable": {
- "maximum": 100,
- "minimum": 0,
- "type": [
- "integer",
- "null"
- ]
- },
- "trustworthy": {
- "maximum": 100,
- "minimum": 0,
- "type": [
- "integer",
- "null"
- ]
- },
- "understandable": {
- "maximum": 100,
- "minimum": 0,
- "type": [
- "integer",
- "null"
- ]
- }
- },
- "type": "object"
- },
- "schema_version": {
- "const": "1.0.0",
- "type": "string"
- },
- "score": {
- "maximum": 100,
- "minimum": 0,
- "type": [
- "integer",
- "null"
- ]
- }
- },
- "type": "object"
-}Output schema / properties / website_intelligence_scoreRemoved value: -{
- "maximum": 100,
- "minimum": 0,
- "type": [
- "integer",
- "null"
- ]
-}Output schema / requiredPrevious value: -[
- "schema_version",
- "target",
- "profile",
- "readiness_level",
- "score",
- "grade",
- "confidence",
- "tested_coverage_percent",
- "applicability",
- "subscores",
- "interfaces",
- "findings",
- "recommended_actions",
- "limitations"
-]New value: +[
+ "payment_required",
+ "protocol",
+ "method",
+ "url",
+ "price_usdc",
+ "network"
+]Output schema / titleRemoved value: -"AgentReadinessResult"audit_website_preview1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "audited_by": {
+ "type": "string"
+ },
+ "checks": {
+ "description": "Individual pass/fail checks with detail.",
+ "type": "object"
+ },
+ "fetched_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "http_status": {
+ "type": "integer"
+ },
+ "issues": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "overall_score": {
+ "maximum": 100,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "schema_version": {
+ "type": "string"
+ },
+ "scores": {
+ "description": "performance, seo, accessibility, security (0-100 each).",
+ "type": "object"
+ },
+ "timing_ms": {
+ "type": "object"
+ },
+ "url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "website_intelligence": {
+ "description": "Discoverable, Understandable, Callable, Trustworthy.",
+ "type": "object"
+ },
+ "website_intelligence_score": {
+ "maximum": 100,
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "schema_version",
+ "url",
+ "overall_score",
+ "scores",
+ "website_intelligence_score",
+ "issues"
+ ],
+ "type": "object"
+}extract_page_markdown1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "byline": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "canonical_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fetched_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "final_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "http_status": {
+ "type": "integer"
+ },
+ "links": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "markdown": {
+ "description": "Readability-isolated main content.",
+ "type": "string"
+ },
+ "schema_version": {
+ "type": "string"
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "word_count": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "schema_version",
+ "url",
+ "markdown",
+ "word_count"
+ ],
+ "type": "object"
+}extract_structured_data1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "description": "Fields extracted against the caller's own JSON Schema, re-validated before return.",
+ "type": "object"
+ },
+ "model": {
+ "type": "string"
+ },
+ "schema_version": {
+ "type": "string"
+ },
+ "url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "word_count": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "data"
+ ],
+ "type": "object"
+}feed_parse1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "free_preview_url": {
+ "description": "Free alternative, where one exists.",
+ "format": "uri",
+ "type": "string"
+ },
+ "method": {
+ "description": "HTTP method to use for the paid request.",
+ "type": "string"
+ },
+ "network": {
+ "description": "CAIP-2 chain id, eip155:8453 (Base mainnet).",
+ "type": "string"
+ },
+ "payment_required": {
+ "const": true,
+ "type": "boolean"
+ },
+ "price_usdc": {
+ "description": "Price in USDC for one successful call.",
+ "type": "string"
+ },
+ "protocol": {
+ "description": "x402-v2",
+ "type": "string"
+ },
+ "settles": {
+ "description": "When funds move.",
+ "type": "string"
+ },
+ "url": {
+ "description": "Exact URL to request, then pay for and retry.",
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "payment_required",
+ "protocol",
+ "method",
+ "url",
+ "price_usdc",
+ "network"
+ ],
+ "type": "object"
+}link_map1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "free_preview_url": {
+ "description": "Free alternative, where one exists.",
+ "format": "uri",
+ "type": "string"
+ },
+ "method": {
+ "description": "HTTP method to use for the paid request.",
+ "type": "string"
+ },
+ "network": {
+ "description": "CAIP-2 chain id, eip155:8453 (Base mainnet).",
+ "type": "string"
+ },
+ "payment_required": {
+ "const": true,
+ "type": "boolean"
+ },
+ "price_usdc": {
+ "description": "Price in USDC for one successful call.",
+ "type": "string"
+ },
+ "protocol": {
+ "description": "x402-v2",
+ "type": "string"
+ },
+ "settles": {
+ "description": "When funds move.",
+ "type": "string"
+ },
+ "url": {
+ "description": "Exact URL to request, then pay for and retry.",
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "payment_required",
+ "protocol",
+ "method",
+ "url",
+ "price_usdc",
+ "network"
+ ],
+ "type": "object"
+}summarize1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "free_preview_url": {
+ "description": "Free alternative, where one exists.",
+ "format": "uri",
+ "type": "string"
+ },
+ "method": {
+ "description": "HTTP method to use for the paid request.",
+ "type": "string"
+ },
+ "network": {
+ "description": "CAIP-2 chain id, eip155:8453 (Base mainnet).",
+ "type": "string"
+ },
+ "payment_required": {
+ "const": true,
+ "type": "boolean"
+ },
+ "price_usdc": {
+ "description": "Price in USDC for one successful call.",
+ "type": "string"
+ },
+ "protocol": {
+ "description": "x402-v2",
+ "type": "string"
+ },
+ "settles": {
+ "description": "When funds move.",
+ "type": "string"
+ },
+ "url": {
+ "description": "Exact URL to request, then pay for and retry.",
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "payment_required",
+ "protocol",
+ "method",
+ "url",
+ "price_usdc",
+ "network"
+ ],
+ "type": "object"
+}audit_website_preview1 field changedInput schema / properties / tokenAdded value: +{
+ "description": "Optional verified-email token. Without it the daily free quota is keyed on the caller IP, which every caller behind that address shares — hosted agents should pass a token so each user gets their own allowance. Obtain one via POST /api/leads/verify/request then /confirm; valid 30 days.",
+ "type": "string"
+}extract_page_markdown1 field changedInput schema / properties / tokenAdded value: +{
+ "description": "Optional verified-email token. Without it the daily free quota is keyed on the caller IP, which every caller behind that address shares — hosted agents should pass a token so each user gets their own allowance. Obtain one via POST /api/leads/verify/request then /confirm; valid 30 days.",
+ "type": "string"
+}extract_structured_data1 field changedInput schema / properties / tokenAdded value: +{
+ "description": "Optional verified-email token. Without it the daily free quota is keyed on the caller IP, which every caller behind that address shares — hosted agents should pass a token so each user gets their own allowance. Obtain one via POST /api/leads/verify/request then /confirm; valid 30 days.",
+ "type": "string"
+}feed_parselink_mapsummarizeextract_structured_dataaudit_agent_readiness5 fields changedOutput schema / $defsRemoved value: -{
- "finding": {
- "properties": {
- "category": {
- "type": "string"
- },
- "confidence": {
- "enum": [
- "low",
- "medium",
- "high"
- ],
- "type": "string"
- },
- "evidence": {
- "type": "object"
- },
- "id": {
- "type": "string"
- },
- "recommendation": {
- "type": "string"
- },
- "severity": {
- "enum": [
- "info",
- "low",
- "moderate",
- "high"
- ],
- "type": "string"
- },
- "status": {
- "enum": [
- "pass",
- "fail",
- "unknown",
- "not_applicable"
- ],
- "type": "string"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "category",
- "severity",
- "confidence",
- "status",
- "title",
- "recommendation"
- ],
- "type": "object"
- }
-}Output schema / properties / findings / items / $refRemoved value: -"#/$defs/finding"Output schema / properties / findings / items / propertiesAdded value: +{
+ "category": {
+ "type": "string"
+ },
+ "confidence": {
+ "enum": [
+ "low",
+ "medium",
+ "high"
+ ],
+ "type": "string"
+ },
+ "evidence": {
+ "type": "object"
+ },
+ "id": {
+ "type": "string"
+ },
+ "recommendation": {
+ "type": "string"
+ },
+ "severity": {
+ "enum": [
+ "info",
+ "low",
+ "moderate",
+ "high"
+ ],
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "pass",
+ "fail",
+ "unknown",
+ "not_applicable"
+ ],
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+}Output schema / properties / findings / items / requiredAdded value: +[
+ "id",
+ "category",
+ "severity",
+ "confidence",
+ "status",
+ "title",
+ "recommendation"
+]Output schema / properties / findings / items / typeAdded value: +"object"extract_page_markdownaudit_agent_readinessaudit_website_previewScan any website's AI readiness: AI search visibility and AI agent usability. Free, no auth.
Score any website's AI-agent readiness. Open Agent Registry scanner + platform tools.
Is a website ready for AI shopping agents? Readiness score (0-100) + agent shopping simulation.
Free preflight and exact-price discovery for paid website and AI-agent audits.
Add one secure layer between your agents and this server.
