SITEBORNE Utility Network

Server Details

Machine-native utility network: verified evidence services for autonomous agents.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 55.5% over 41 days
Last Tested: 2026-09-27 20:34
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.3/5.0

Scored 2026-09-24 22:40 across 10 tools

Disambiguation1/5

Four of the ten tools are exact duplicate pairs: each evidence service has a base version and a _v3_candidate version with identical descriptions and no stated functional difference. An agent cannot reliably distinguish between them, so multiple tools appear to do the same thing.

Naming Consistency4/5

All tool names follow a consistent siteborne_<verb>_<object> snake_case pattern, which is predictable and readable. The _v3_candidate suffix is a minor deviation that introduces version confusion, but the overall naming convention is consistent.

Tool Count3/5

Ten tools is not inherently excessive, but four are redundant duplicates, leaving only six distinct functions. The count feels inflated by the duplicate v3_candidate tools rather than genuinely well-scoped.

Completeness4/5

The tool set covers the apparent domain well: company evidence graphing, web context retrieval, document extraction, agent output verification, quoting, and service health. It lacks tools for inspecting persisted job or audit state, but this is a minor gap rather than a critical dead end.

Available Tools

10 tools

siteborne_build_company_evidence_graphBuild company evidence graphA

Idempotent

Inspect

Build a proof-carrying graph of public company identity, SEC filings, website observations, regulatory mentions, and repository signals. Use when: the request needs entity-level evidence synthesized across sources. Do not use when: one URL is the subject (use siteborne_retrieve_verified_web_context), one document is the subject (use siteborne_extract_document_evidence_json), or an existing agent output needs evaluation (use siteborne_verify_agent_output). Parameters: authoritative identifiers (cik, lei, isin, cusip, figi) resolve entities more reliably than company_name, ticker or domain alone, and combining them reduces ambiguity; requested_field_groups narrows provider work; maximum_authorized_price only constrains payment and never widens scope. Behavior: open-world: a paid request queries public data providers over the network and persists governed payment, audit, job and Workflow state; an unpaid request returns payment_required; a repeated identical request with the same payment is replay-protected and is not charged twice. This service is currently production-disabled and rejects execution. Economics: exact price of $0.0312 USD per request; the payment challenge requires that amount and the charge settles at exactly that amount. Failure: input that fails schema validation is rejected before any payment challenge; provider or service unavailability returns a structured MCP error. Returns: a company evidence graph with provenance, completeness, verification, and PCC context—not a raw webpage or document extraction.

ParametersJSON Schema

Name	Required	Description
`domain`	No	Primary website hostname only, without a URL path; links first-party web evidence to the company identity.
`ticker`	No	One-to-five uppercase exchange ticker symbols; narrows public-company resolution but is not globally unique without other signals.
`buyer_urls`	No	Up to twenty public supplemental evidence URLs supplied by the buyer; these are additional sources, not replacements for entity resolution.
`identifiers`	No	Known authoritative entity identifiers; supplying precise identifiers reduces ambiguous name, ticker, or domain matching.
`company_name`	No	Legal or commonly used company name; supplies an entity-resolution signal when authoritative identifiers are unavailable.
`freshness_seconds`	No	Maximum acceptable source age in seconds, from 0 through 2,592,000; lower values demand fresher evidence.
`jurisdiction_hints`	No	Up to five two-letter uppercase jurisdiction codes used to focus regulatory context; hints do not assert incorporation.
`minimum_completeness`	No	Required completeness ratio from 0 through 1; results below this threshold fail the requested acceptance condition.
`requested_field_groups`	No	Unique evidence categories to collect; omitted values use the schema default, while a smaller list limits provider work and result scope.
`maximum_authorized_price`	No	Buyer’s decimal-safe maximum authorized price; constrains the payment requirement and never expands provider scope.
`minimum_verification_score`	No	Required PCC verification ratio from 0 through 1; raising it makes result acceptance stricter.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes	Output schema for company_evidence_graph.v1 service. Must be a valid PCC 1.0.0 document with required net.siteborne.company-evidence.v1 extension.

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes significantly beyond the annotations. It explains the open-world behavior (paid vs unpaid requests), replay protection, exact pricing, production-disabled status, and failure modes. These are critical operational details that the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) do not cover, and they are all disclosed clearly without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-structured with clear sections (when to use, parameters, behavior, economics, failure, returns). Every sentence adds value, covering usage, constraints, and operational details without fluff. Information is front-loaded with purpose and usage, and the structure aids readability despite the length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (11 parameters, nested objects, payment requirements, multiple sources) and the fact that annotations and schema provide rich context, the description covers all necessary aspects: usage scenarios, parameter guidance, behavior, pricing, failure modes, and return type. The output schema handles return details, and the description mentions returns enough to set expectations. Nothing critical is missing for an agent to decide and call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 all 11 parameters thoroughly. The description adds guidance on identifier reliability and the role of maximum_authorized_price, but most parameter meaning is already in the schema. The description provides some extra value by explaining how identifiers interact and clarifying that maximum_authorized_price only constrains payment, which justifies a baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it builds a proof-carrying graph of company identity and evidence from multiple sources, using a specific verb ('Build') and resource ('company evidence graph'). It explicitly distinguishes itself from sibling tools by naming the alternatives and their conditions, so an agent can select it correctly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use ('entity-level evidence synthesized across sources') and when-not-to-use conditions, naming each alternative tool (e.g., one URL -> siteborne_retrieve_verified_web_context). It also gives guidance on parameter selection (prefer identifiers over name/ticker/domain) and clarifies scope constraints (maximum_authorized_price never widens scope).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

siteborne_build_company_evidence_graph_v3_candidateBuild company evidence graph (v3 candidate)A

Idempotent

Inspect

ParametersJSON Schema

Name	Required	Description
`domain`	No	Primary website hostname only, without a URL path; links first-party web evidence to the company identity.
`ticker`	No	One-to-five uppercase exchange ticker symbols; narrows public-company resolution but is not globally unique without other signals.
`buyer_urls`	No	Up to twenty public supplemental evidence URLs supplied by the buyer; these are additional sources, not replacements for entity resolution.
`identifiers`	No	Known authoritative entity identifiers; supplying precise identifiers reduces ambiguous name, ticker, or domain matching.
`company_name`	No	Legal or commonly used company name; supplies an entity-resolution signal when authoritative identifiers are unavailable.
`freshness_seconds`	No	Maximum acceptable source age in seconds, from 0 through 2,592,000; lower values demand fresher evidence.
`jurisdiction_hints`	No	Up to five two-letter uppercase jurisdiction codes used to focus regulatory context; hints do not assert incorporation.
`minimum_completeness`	No	Required completeness ratio from 0 through 1; results below this threshold fail the requested acceptance condition.
`requested_field_groups`	No	Unique evidence categories to collect; omitted values use the schema default, while a smaller list limits provider work and result scope.
`maximum_authorized_price`	No	Buyer’s decimal-safe maximum authorized price; constrains the payment requirement and never expands provider scope.
`minimum_verification_score`	No	Required PCC verification ratio from 0 through 1; raising it makes result acceptance stricter.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes	Output schema for company_evidence_graph.v1 service. Must be a valid PCC 1.0.0 document with required net.siteborne.company-evidence.v1 extension. Governed candidate output for Service Contract 3.0.0 / PCC 2.0.0.

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare openWorldHint=true, idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds critical context: it describes payment behavior (paid vs unpaid, payment_required response), replay protection (not charged twice), production-disabled state (rejects execution), and failure modes (schema validation, provider unavailability). It also clarifies scope (never widens scope with price constraint) and return type (graph with provenance, not raw extraction). This far exceeds annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately structured with clear sections for usage, behavior, economics, and failure, front-loading the purpose and routing. Every sentence provides actionable information; there is no fluff or repetition. It is detailed but efficiently organized, earning its length given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 11 parameters, no required params, 100% schema coverage, a nested objects, and an output schema. The description covers all critical aspects: purpose, when to use, payment economics, production status, failure modes, and return type. It references the output schema's context (provenance, completeness, verification, PCC) without over-explaining returns. Given the tool's complexity, nothing essential is missing for an agent to decide and invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds meaningful value: it explains that authoritative identifiers (cik, lei, isin, cusip, figi) resolve entities more reliably than company_name/ticker/domain, and that combining identifiers reduces ambiguity. It also clarifies that requested_field_groups narrows provider work and maximum_authorized_price only constrains payment. This goes beyond the schema's individual field descriptions to explain inter-parameter relationships and strategic usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool builds a 'proof-carrying graph of public company identity, SEC filings, website observations, regulatory mentions, and repository signals'—a specific verb, resource, and scope. It explicitly differentiates from siblings by naming exact alternatives for single-URL, single-document, and agent-output scenarios, so an agent can distinguish it without inspecting other schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit 'Use when' and 'Do not use when' sections, naming specific sibling tools (siteborne_retrieve_verified_web_context, siteborne_extract_document_evidence_json, siteborne_verify_agent_output) and the conditions that route to them. It also clarifies that authoritative identifiers are more reliable than company_name/ticker/domain, and that maximum_authorized_price only constrains payment—no ambiguity left.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

siteborne_extract_document_evidence_jsonExtract document evidence JSONA

Idempotent

Inspect

Extract and verify structured evidence from exactly one authorized artifact, prior SITEBORNE upload, or public document URL. Use when: the source of truth is a PDF or supported image and the desired result is evidence JSON. Do not use when: a webpage alone is sufficient (use siteborne_retrieve_verified_web_context), company-wide public evidence is needed (use siteborne_build_company_evidence_graph), or an existing agent response needs evaluation (use siteborne_verify_agent_output). Parameters: provide exactly one reference mode: artifact_reference (an authorized stored artifact), upload_reference (a prior SITEBORNE upload handle, not document bytes) or document_url (a public URL, no credentials). ocr_permission must be true before image-based content is read by OCR, and OCR pages bill at the OCR tier; extraction_request.extract_tables and table_extraction_request request table extraction, and pages with tables bill at the table tier; declared_page_count and page_range are bounded by the page limit below; maximum_authorized_price only constrains payment. Behavior: open-world: a paid request may read governed artifact storage or fetch a public document URL, calls the document provider, and persists payment, audit, job and Workflow state; an unpaid request returns payment_required; a repeated identical request with the same payment is replay-protected and is not charged twice. This service is currently production-disabled and rejects execution. Economics: upto pricing: the payment challenge authorizes a maximum of $0.19 USD per job; the actual charge is measured per processed page (native-text $0.0098, OCR $0.0156, table $0.0238 per page, the highest applicable tier per page) and never exceeds the authorization. The authorization is a ceiling, not the charge. Documents are limited to 10 pages per job. Failure: schema-invalid input is rejected before any payment challenge; a document over the page limit, an unreadable or encrypted document, or an unavailable provider returns a structured MCP error. Returns: extracted document evidence, integrity/provenance findings, and PCC verification—not an uploaded file.

ParametersJSON Schema

Name	Required	Description	Default
`page_range`	No	Optional one-indexed inclusive page range to process; both bounds are limited to pages 1 through 10.
`document_url`	No	Public document URL for reference mode 3; use exactly one reference mode and never put credentials in this URL.
`language_hints`	No	Up to five BCP 47 language hints used by OCR and extraction; hints do not translate the document.
`ocr_permission`	No	Explicit permission to use OCR for image-based content; false prevents OCR even when text is not embedded.
`upload_reference`	No	Previously issued SITEBORNE upload handle and declared file metadata for reference mode 2; it does not upload document bytes.
`artifact_reference`	No	Authorized stored-artifact descriptor for reference mode 1; use exactly one of artifact_reference, upload_reference, or document_url.
`extraction_request`	No	Selects text, table, key-value, and buyer-schema extraction outputs; omitted switches retain their documented defaults.
`declared_page_count`	No	Optional declared page count from 1 through 10; enables early scope validation but does not override the observed document.
`retention_preference`	No	Requested retention class—none, temporary, or permanent—subject to server policy; it cannot override mandatory retention limits.	temporary
`maximum_authorized_price`	No	Buyer’s decimal-safe maximum authorized price; constrains the payment requirement and not retention or extraction policy.
`table_extraction_request`	No	Explicit top-level request for table extraction; false leaves tables unrequested.
`minimum_verification_score`	No	Required PCC verification ratio from 0 through 1; raising it makes extracted-evidence acceptance stricter.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes	Output schema for document_evidence_json.v1 service. Must be a valid PCC 1.0.0 document with required net.siteborne.document-evidence.v1 extension.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations (openWorldHint, idempotentHint, readOnlyHint=false) are corroborated and richly extended: the description details the open-world state persistence (payment, audit, job, Workflow), replay protection and no-double-charge semantics, the production-disabled rejection behavior, and the full payment-required flow. It adds the payment ceiling-vs-charge distinction and page-tier billing, going well beyond what annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Long but information-dense and well-structured with clear labeled sections (Parameters, Behavior, Economics, Failure, Returns). Every sentence carries operational meaning for a complex paid service; the purpose and usage guidance are front-loaded, and there is no filler or repetition of schema text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter paid service with nested objects and an output schema, the description is exceptionally complete: it covers purpose, alternatives, reference-mode constraints, side effects, replay/idempotency, production-disabled status, pricing mechanics, page limits, failure modes, and the return shape. Since an output schema exists, the return summary is appropriately brief.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds genuine value beyond the schema: it emphasizes the 'exactly one reference mode' constraint, clarifies upload_reference carries a handle 'not document bytes,' and couples parameters to billing tiers (ocr_permission → OCR tier, extract_tables → table tier). The tier-billing coupling is not present in the schema and is materially useful for an agent deciding parameter choices.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ('Extract and verify structured evidence') and a precise scope ('exactly one authorized artifact, prior SITEBORNE upload, or public document URL'). It explicitly names three sibling tools and the conditions that route to each, so an agent can disambiguate without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit 'Use when' and 'Do not use when' guidance naming the exact alternatives (siteborne_retrieve_verified_web_context, siteborne_build_company_evidence_graph, siteborne_verify_agent_output) and the selection conditions. Nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

siteborne_extract_document_evidence_json_v3_candidateExtract document evidence JSON (v3 candidate)A

Idempotent

Inspect

ParametersJSON Schema

Name	Required	Description	Default
`page_range`	No	Optional one-indexed inclusive page range to process; both bounds are limited to pages 1 through 10.
`document_url`	No	Public document URL for reference mode 3; use exactly one reference mode and never put credentials in this URL.
`language_hints`	No	Up to five BCP 47 language hints used by OCR and extraction; hints do not translate the document.
`ocr_permission`	No	Explicit permission to use OCR for image-based content; false prevents OCR even when text is not embedded.
`upload_reference`	No	Previously issued SITEBORNE upload handle and declared file metadata for reference mode 2; it does not upload document bytes.
`artifact_reference`	No	Authorized stored-artifact descriptor for reference mode 1; use exactly one of artifact_reference, upload_reference, or document_url.
`extraction_request`	No	Selects text, table, key-value, and buyer-schema extraction outputs; omitted switches retain their documented defaults.
`declared_page_count`	No	Optional declared page count from 1 through 10; enables early scope validation but does not override the observed document.
`retention_preference`	No	Requested retention class—none, temporary, or permanent—subject to server policy; it cannot override mandatory retention limits.	temporary
`maximum_authorized_price`	No	Buyer’s decimal-safe maximum authorized price; constrains the payment requirement and not retention or extraction policy.
`table_extraction_request`	No	Explicit top-level request for table extraction; false leaves tables unrequested.
`minimum_verification_score`	No	Required PCC verification ratio from 0 through 1; raising it makes extracted-evidence acceptance stricter.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes	Output schema for document_evidence_json.v1 service. Must be a valid PCC 1.0.0 document with required net.siteborne.document-evidence.v1 extension. Governed candidate output for Service Contract 3.0.0 / PCC 2.0.0.

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses significant behavior: open-world side effects (may read governed storage/fetch URLs, persists payment/audit/job/Workflow state), unpaid request returning payment_required, replay protection for identical paid requests, the production-disabled execution state, and structured failure modes. These details are not in the annotations and materially help the agent predict consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured into labeled sections (use, parameters, behavior, economics, failure, returns), with the core purpose and usage guidance front-loaded. Some pricing and failure detail is dense and could be trimmed, but each section earns its place given the payment and side-effect complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high-complexity schema, payment model, open-world side effects, and explicit alternatives, the description covers everything an agent needs: reference-mode selection, use/when-not, economic authorization and per-page charges, page limits, production status, failure behavior, and return shape. The presence of an output schema also lets the description avoid recapitulating return fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema already covers all 12 parameters at 100% coverage, the description adds relational meaning: exactly one reference mode must be chosen, OCR requires explicit permission, table extraction affects billing tier, declared_page_count/page_range are bounded, and maximum_authorized_price only caps payment. It does not re-explain every parameter but clarifies the cross-parameter constraints that the schema alone does not make salient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Extract and verify structured evidence from exactly one authorized artifact, prior SITEBORNE upload, or public document URL.' It also names sibling tools in the usage guidance, so an agent can distinguish this extraction service from retrieval, graph-building, and verification tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Use when' and 'Do not use when' sections are explicit: use for PDF/supported-image sources producing evidence JSON, and do not use for webpage-only context, company-wide evidence, or agent-output evaluation, with named alternatives for each. This leaves no ambiguity about when to invoke this tool versus its siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

siteborne_get_quoteGet SITEBORNE quoteA

Read-onlyIdempotent

Inspect

Build a canonical x402 payment quote for one SITEBORNE service and exact request input. Use when: an agent needs the governed price, payee, network, asset, resource, expiry, and payment requirement before deciding whether to invoke a paid service. Do not use when: evidence work is required now (use the matching siteborne_build_company_evidence_graph, siteborne_retrieve_verified_web_context, siteborne_extract_document_evidence_json, or siteborne_verify_agent_output tool), or only availability is needed (use siteborne_get_service_health). Parameters: scheme must be the one scheme the service is offered under (company_evidence_graph.v2 exact, web_context_verified.v2 exact, document_evidence_json.v2 upto, verify_agent_output.v2 exact, company_evidence_graph.v3 exact, web_context_verified.v3 exact, document_evidence_json.v3 upto, verify_agent_output.v3 exact); any other scheme is rejected with scheme_not_offered. input is hashed, so the quote binds only that exact request. Behavior: quote-only and read-only; it hashes the proposed input, and does not execute the underlying paid service, verify payment, call a provider, create a Workflow, or settle. Economics: free of charge. The returned amount is the exact price, or for upto an authorized maximum whose actual_amount is null because the real charge is measured at settlement and never exceeds it. Failure: a mode that has a governed price but is unavailable returns retrieval_mode_unavailable or verification_mode_unavailable and no quote; a quote expires at expires_at. Returns: an expiring input-bound quote with its x402 payment requirement and the canonical economics block.

ParametersJSON Schema

Name	Required	Description
`input`	Yes	Complete proposed input for the selected service; its canonical hash binds the quote and later payment requirement to this exact request content.
`scheme`	Yes	Pricing mode: exact fixes the required amount, while upto authorizes a maximum whose eventual charge cannot exceed the returned amount.
`service_id`	Yes	Canonical SITEBORNE service and major version to price; selects that service’s governed pricing key, contract release, and production resource URL.

Output Schema

ParametersJSON Schema

Name	Required	Description
`asset`	Yes	Token contract address on the network that the amount is denominated in.
`payee`	Yes	Public payTo address that receives the payment.
`amount`	Yes	Amount in the asset atomic units (6 decimals for USDC): the exact price when amount_kind is exact, or the authorized maximum when it is authorized_maximum.
`scheme`	Yes	x402 scheme: exact requires the amount; upto authorizes it as a maximum.
`network`	Yes	CAIP-2 network the payment must be made on (for example eip155:8453).
`quote_id`	Yes	Deterministic identifier of this quote.
`economics`	Yes	The canonical economic contract for the quoted service (pricing model, tiers, authorization maximum, settlement model, modes and their availability, limits, production state, pricing_source_version, and network/asset/pay_to); identical on every SITEBORNE discovery surface.
`issued_at`	Yes	UTC time the quote was issued.
`expires_at`	Yes	UTC time after which the quote is no longer valid.
`input_hash`	Yes	Canonical hash of the exact request input this quote binds.
`service_id`	Yes	Canonical service id and major version that was quoted.
`amount_kind`	Yes	exact: the charge equals amount. authorized_maximum: the charge is measured at settlement and never exceeds amount.
`pricing_key`	Yes	Governed pricing key the amount was resolved from (governance pricing authority).
`resource_id`	Yes	Canonical URL of the paid resource this quote is bound to.
`binding_hash`	Yes	Hash binding the quote to the exact service, input hash, price, scheme, network, asset, and payee; a payment for a different binding is not accepted.
`actual_amount`	Yes	Always null in a quote: the actual charge exists only after measured settlement.
`requirement_id`	Yes	Identifier of the x402 payment requirement embedded in payment_requirements.
`service_version`	Yes	Service contract major version.
`contract_release`	Yes	Contract release the quoted service belongs to.
`payment_required`	Yes	Always true: executing the quoted service requires payment.
`production_enabled`	Yes	Quote-level flag, always false: a quote never authorizes execution. The service runtime state is economics.production_enabled.
`payment_requirements`	Yes	The x402 payment requirement to satisfy, including payTo, network, asset and amount.
`pricing_source_version`	Yes	Version of the governed pricing document that produced the amount; a repricing changes this value.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly/idempotent/non-destructive behavior, and the description adds substantial specifics: it hashes input, does not execute the paid service, verify payment, call a provider, create a Workflow, or settle; it is free; failures return mode-unavailable errors and no quote; quotes expire at expires_at. There is no contradiction with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Despite being long, the description is organized into labeled blocks and every sentence adds a distinct decision-relevant fact: purpose, routing, parameter constraints, non-execution behavior, economics, failure, and return shape. There is no filler or tautology.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given three required parameters, enums, an output schema, and a complex sibling set, the description covers selection criteria, parameter constraints, behavior, failure modes, and return shape. An agent has enough to invoke correctly and interpret a non-error result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, the baseline is 3, but the description adds the cross-parameter invariant that scheme must be the scheme the selected service is offered under, enumerates the service-to-scheme mapping, and warns of scheme_not_offered rejection. It also explains that input is hashed so the quote binds exact content. This lifts it above baseline, though the mapping omits the v1 service_id variants that exist in the schema enum.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Build a canonical x402 payment quote for one SITEBORNE service and exact request input.' It also ties the purpose to deciding whether to invoke a paid service, which distinguishes this quote-only tool from the evidence-building siblings by intent, not just name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'Use when' and 'Do not use when' sections name the exact sibling tools for evidence work and health checks, plus the condition that selects the quote tool. This is the clearest possible routing guidance; nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

siteborne_get_service_healthGet SITEBORNE service healthA

Read-onlyIdempotent

Inspect

Report MCP server readiness and production-enable status for each SITEBORNE service. Use when: an agent must check protocol availability, tool count, or whether a service is currently production-enabled before selecting a paid tool. Do not use when: a quote is needed (use siteborne_get_quote) or company, web, document, or agent-output evidence work is required (use the corresponding SITEBORNE service tool). Behavior: read-only and credential-independent; it does not perform paid evidence work, create quotes, verify payment, call providers, write service state, create Workflows, or settle. Economics: free of charge; it never issues a payment challenge. Failure: it depends on no provider, so it does not fail because a provider is unavailable. Returns: the server and protocol versions plus truthful local, production, and external-publication status for all four evidence services.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`tools`	Yes
`status`	Yes
`services`	Yes
`server_name`	Yes
`server_version`	Yes
`production_ready`	Yes
`protocol_version`	Yes
`production_enabled`	Yes
`external_publication`	Yes

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the annotations by detailing that the tool is credential-independent, free of charge, never issues payment challenges, and does not fail due to provider unavailability. It also clarifies it performs no paid evidence work or mutations, which is richer than the basic readOnlyHint and idempotentHint annotations. No contradiction exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is comprehensive but structured with clear segments (Use when, Do not use when, Behavior, Economics, Failure, Returns), though it is longer than strictly necessary. It front-loads the core purpose and usage guidance effectively, but the behavioral and economic details could be slightly more condensed without losing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (parameterless, read-only status check), the description is fully complete. It covers what it returns, when to use, what it doesn't do, and its failure characteristics. The presence of an output schema covers return format details, so the description provides all necessary context for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters, there is nothing for the description to explain about parameter usage. The high schema coverage (100%) and empty schema mean the description correctly focuses on the tool's behavior and return values, which is more relevant for a parameterless tool. The description adds value by explaining what the tool returns and its constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool's purpose: reporting MCP server readiness and production-enable status for each SITEBORNE service. It clearly distinguishes this tool from siblings by naming specific alternatives like siteborne_get_quote and service tools for evidence work, making it unmistakable what this tool is for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit 'Use when' and 'Do not use when' conditions, naming the exact sibling tools for alternatives. This gives clear guidance on when to select this tool versus others, ensuring the agent can make the correct choice without ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

siteborne_retrieve_verified_web_contextRetrieve verified web contextA

Idempotent

Inspect

Retrieve and verify evidence from one public web URL using direct HTTP retrieval. Use when: the request is specifically about the content and provenance of a URL. Do not use when: evidence must be synthesized for a company (use siteborne_build_company_evidence_graph), extracted from an authorized document (use siteborne_extract_document_evidence_json), checked against an existing output contract (use siteborne_verify_agent_output), or the page requires JavaScript rendering (rendered retrieval is not available). Parameters: retrieval_mode must be direct; rendered is defined but unavailable and is rejected before any payment challenge, never substituted with direct retrieval. output_mode structured needs buyer_schema and field_selectors to be meaningful; redirect_policy and max_redirects bound redirect following; max_content_size bounds returned bytes; maximum_authorized_price only constrains payment and never changes retrieval scope. Behavior: open-world: a paid request performs bounded outbound HTTP retrieval of the target URL through a safe-egress boundary (private and loopback destinations are refused) and persists governed payment, audit, job and Workflow state; an unpaid request returns payment_required; a repeated identical request with the same payment is replay-protected and is not charged twice. Retrieval admission follows the governed runtime rate policy; no fixed public per-origin rate is promised. This service is currently production-disabled and rejects execution. Economics: exact price of $0.008 USD per request in direct mode; the payment challenge requires that amount and the charge settles at exactly that amount. rendered mode has a governed price of $0.029 USD but is not available: it is rejected before any payment challenge and never substituted. Failure: schema-invalid input and unavailable modes are rejected before any payment challenge; target-site errors, timeouts and unavailable retrieval return a structured MCP error and are never answered with a substitute result. Returns: normalized, source-attributed web context with verification and PCC evidence.

ParametersJSON Schema

Name	Required	Description	Default
`target_url`	Yes	Public HTTP or HTTPS URL to retrieve and verify; private, loopback, and otherwise unsafe network destinations are rejected.
`locale_hint`	No	Optional BCP 47 language or language-region hint used for HTTP content negotiation; it does not translate content.
`output_mode`	No	Result representation: clean_text normalizes prose, markdown preserves document structure, and structured validates selected fields against buyer_schema.	clean_text
`buyer_schema`	No	Optional JSON Schema governing structured output; meaningful only with output_mode structured and bounded to fifty properties and depth five.
`max_redirects`	No	Maximum redirect hops from 0 through 10 when the selected redirect policy follows redirects.
`retrieval_mode`	Yes	Retrieval mode. Only direct (plain HTTP retrieval, no JavaScript execution) is available. rendered has a governed price but is not available: it is rejected with retrieval_mode_unavailable before any payment challenge and is never substituted with direct retrieval.
`field_selectors`	No	Up to thirty requested field names for structured extraction; narrows the structured result rather than changing the fetched URL.
`redirect_policy`	No	Redirect handling: follow permits the bounded chain, follow_first permits only the first hop, and manual returns redirect evidence without following.	follow
`max_content_size`	No	Maximum returned content size in bytes, from 1,024 through 10,485,760; smaller limits truncate or reject oversized content sooner.
`freshness_seconds`	No	Maximum acceptable cached-content age in seconds, from 0 through 2,592,000; zero requests uncached content.
`maximum_authorized_price`	No	Buyer’s decimal-safe maximum authorized price; constrains the payment requirement and never changes retrieval scope.
`minimum_verification_score`	No	Required PCC verification ratio from 0 through 1; raising it makes evidence acceptance stricter.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes	Output schema for web_context_verified.v1 service. Must be a valid PCC 1.0.0 document with required net.siteborne.web-context.v1 extension.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes far beyond the annotations, disclosing exact pricing ($0.008 USD), payment challenge behavior, replay protection, safe-egress boundaries, refusal of private/loopback destinations, production-disabled status, and the guarantee that rendered mode is rejected before payment and never substituted. These are material behavioral traits an agent needs to know, and none contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but densely organized into purpose, usage, parameters, behavior, economics, failure, and returns sections, which earns its length given the tool's complexity. However, the point that rendered mode is unavailable and never substituted is repeated three times, which is slightly redundant and could be tightened without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter, payment-gated, production-disabled tool, the description covers every area an agent needs: when to use it, how parameters interact, exact costs, failure semantics, and return shape. The presence of an output schema means detailed return documentation is unnecessary, so nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100%, the description adds crucial meaning beyond the schema: it clarifies that retrieval_mode must be direct, that structured output requires buyer_schema and field_selectors, that maximum_authorized_price only constrains payment and never changes retrieval scope, and that max_content_size bounds returned bytes. This resolves ambiguities that the raw schema leaves open.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Retrieve and verify evidence from one public web URL using direct HTTP retrieval.' It clearly distinguishes this tool from siblings by naming alternative tools and the conditions under which they should be used instead, leaving no ambiguity about what this tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'Use when' and 'Do not use when' guidance names three sibling tools with the exact scenarios that should route to them, and also excludes JavaScript-rendered pages. This gives an agent concrete decision criteria rather than leaving usage to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

siteborne_retrieve_verified_web_context_v3_candidateRetrieve verified web context (v3 candidate)A

Idempotent

Inspect

ParametersJSON Schema

Name	Required	Description	Default
`target_url`	Yes	Public HTTP or HTTPS URL to retrieve and verify; private, loopback, and otherwise unsafe network destinations are rejected.
`locale_hint`	No	Optional BCP 47 language or language-region hint used for HTTP content negotiation; it does not translate content.
`output_mode`	No	Result representation: clean_text normalizes prose, markdown preserves document structure, and structured validates selected fields against buyer_schema.	clean_text
`buyer_schema`	No	Optional JSON Schema governing structured output; meaningful only with output_mode structured and bounded to fifty properties and depth five.
`max_redirects`	No	Maximum redirect hops from 0 through 10 when the selected redirect policy follows redirects.
`retrieval_mode`	Yes	Retrieval mode. Only direct (plain HTTP retrieval, no JavaScript execution) is available. rendered has a governed price but is not available: it is rejected with retrieval_mode_unavailable before any payment challenge and is never substituted with direct retrieval.
`field_selectors`	No	Up to thirty requested field names for structured extraction; narrows the structured result rather than changing the fetched URL.
`redirect_policy`	No	Redirect handling: follow permits the bounded chain, follow_first permits only the first hop, and manual returns redirect evidence without following.	follow
`max_content_size`	No	Maximum returned content size in bytes, from 1,024 through 10,485,760; smaller limits truncate or reject oversized content sooner.
`freshness_seconds`	No	Maximum acceptable cached-content age in seconds, from 0 through 2,592,000; zero requests uncached content.
`maximum_authorized_price`	No	Buyer’s decimal-safe maximum authorized price; constrains the payment requirement and never changes retrieval scope.
`minimum_verification_score`	No	Required PCC verification ratio from 0 through 1; raising it makes evidence acceptance stricter.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes	Output schema for web_context_verified.v1 service. Must be a valid PCC 1.0.0 document with required net.siteborne.web-context.v1 extension. Governed candidate output for Service Contract 3.0.0 / PCC 2.0.0.

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses far more than the annotations: payment and replay protection, safe-egress boundaries, rate policy uncertainty, production-disabled status, and precise failure modes (e.g., 'never answered with a substitute result'). Nothing contradicts the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is organized into logical sections (purpose, usage, parameters, behavior, economics, failure, returns) and front-loaded with the most important purpose and usage info. It is lengthy, but every sentence delivers critical operational detail. Minor redundancy exists about rendered mode being unavailable and never substituted, but it does not detract from the overall effectiveness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with open-world behavior, payment, availability constraints, and complex failure modes, the description covers all necessary context: how to invoke, what happens when unpaid, exact pricing, production-disabled status, and what is returned. The output schema exists so return values are not overly detailed, yet the high-level result type is stated. Nothing an agent needs to make a correct call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds operational meaning beyond the schema: retrieval_mode 'rendered' is defined but unavailable and rejected pre-payment, structured output_mode requires buyer_schema and field_selectors to be meaningful, and maximum_authorized_price never changes retrieval scope. These clarifications are valuable and concise.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Retrieve and verify evidence from one public web URL using direct HTTP retrieval,' which gives a specific verb, resource, and method. It also differentiates itself from siblings by naming alternatives for cases where the request fits another tool (e.g., company evidence graph, document extraction, verify output contract).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes explicit 'Use when' and 'Do not use when' sections, naming the specific sibling tools for each excluded case and adding a clear warning about JavaScript rendering being unavailable. This leaves no ambiguity about when to select this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

siteborne_verify_agent_outputVerify agent outputA

Idempotent

Inspect

Evaluate a supplied agent output against explicit claims, deterministic requirements, a required JSON Schema, and optional evidence. Use when: the caller already has an output and needs a governed verification verdict. Do not use when: evidence must first be gathered from a company (use siteborne_build_company_evidence_graph), URL (use siteborne_retrieve_verified_web_context), or document (use siteborne_extract_document_evidence_json), or independent reproduction of the output is required (not available). Parameters: verification_mode must be standard; independent_reproduction is defined but unavailable and is rejected before any payment challenge, never downgraded to standard. required_schema must fit SITEBORNE JSON Schema Profile 1 or the request is rejected before payment; minimum_score sets the acceptance threshold; maximum_authorized_price only constrains payment and never relaxes verification policy. Behavior: closed-world: standard mode evaluates only the supplied claims, requirements, output and evidence with no outbound retrieval, and persists governed payment, audit, job and Workflow state; an unpaid request returns payment_required; a repeated identical request with the same payment is replay-protected and is not charged twice. The verification policy and verdict rules do not depend on price or maximum_authorized_price. This service is currently production-disabled and rejects execution. Economics: exact price of $0.017 USD per request in standard mode; the payment challenge requires that amount and the charge settles at exactly that amount. independent_reproduction mode has a governed price of $0.049 USD but is not available: it is rejected before any payment challenge and never substituted. Failure: an unsupported or oversized required_schema, schema-invalid input and unavailable modes are rejected before any payment challenge; a failed verification is a normal fail or conditional verdict, not an error. Returns: claim-level and deterministic-check results, an overall verification verdict, and PCC evidence—not newly gathered source content.

ParametersJSON Schema

Name	Required	Description
`minimum_score`	No	Minimum overall verification score from 0 through 1; raising it makes the final acceptance verdict stricter.
`required_schema`	Yes	JSON Schema the candidate output must satisfy; it constrains validation and cannot change SITEBORNE verifier policy.
`candidate_output`	Yes	Agent-produced JSON object to evaluate, bounded to 200 properties and depth 10; it is evidence under test, not trusted policy.
`supplied_evidence`	No	Up to twenty evidence objects supplied with the candidate output and bound to integrity hashes.
`verification_mode`	Yes	Verification mode. Only standard (deterministic checks of the supplied material, no outbound retrieval) is available. independent_reproduction has a governed price but is not available: it is rejected with verification_mode_unavailable before any payment challenge and is never downgraded to standard.
`verification_contract`	Yes	Complete set of claims and deterministic checks against which the supplied candidate output is evaluated.
`freshness_requirements`	No	Optional maximum-age limits for evidence and schemas, each expressed in seconds.
`allowed_evidence_sources`	No	Up to ten permitted evidence source URIs; evidence outside this allowlist cannot satisfy source restrictions.
`maximum_authorized_price`	No	Buyer’s decimal-safe maximum authorized price; constrains the payment requirement and never relaxes verification policy.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes	Output schema for verify_agent_output.v1 service. Must be a valid PCC 1.0.0 document with required net.siteborne.agent-verification.v1 extension.

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds substantial behavioral context beyond annotations: closed-world no-outbound evaluation, persisted payment/audit/job/Workflow state, payment_required for unpaid requests, replay protection, production-disabled execution, exact pricing, and the fact that failed verification is a normal verdict rather than an error. These are exactly the non-obvious behaviors 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well structured with labeled sections (Use when, Parameters, Behavior, Economics, Failure, Returns) and front-loaded with the core purpose. It would earn a 5 if not for some repetition of the independent_reproduction unavailability and 'rejected before payment challenge' across multiple sections, though this repetition may be intentional given payment sensitivity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, paid, stateful verification service, the description is remarkably complete: it covers when to use it, when not to, payment behavior, replay protection, production-disablement, schema-profile constraints, failure semantics, and return contents. The output schema exists, so detailed return-value documentation is not the description's job.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuinely useful semantics beyond the schema: required_schema must fit SITEBORNE JSON Schema Profile 1, verification_mode must be standard while independent_reproduction is rejected, minimum_score sets the acceptance threshold, and maximum_authorized_price only constrains payment and never relaxes verification policy. Not every parameter is addressed in prose, but the schema already covers them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Evaluate a supplied agent output against explicit claims, deterministic requirements, a required JSON Schema, and optional evidence.' It clearly distinguishes this verification tool from sibling evidence-gathering tools by naming what it is not for, so an agent can select it without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit use conditions ('Use when: the caller already has an output and needs a governed verification verdict') and explicit exclusions that name the correct sibling tools for evidence gathering from company, URL, or document. It also states that independent reproduction is not available, preventing a likely mis-selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

siteborne_verify_agent_output_v3_candidateVerify agent output (v3 candidate)A

Idempotent

Inspect

ParametersJSON Schema

Name	Required	Description
`minimum_score`	No	Minimum overall verification score from 0 through 1; raising it makes the final acceptance verdict stricter.
`required_schema`	Yes	JSON Schema the candidate output must satisfy; it constrains validation and cannot change SITEBORNE verifier policy.
`candidate_output`	Yes	Agent-produced JSON object to evaluate, bounded to 200 properties and depth 10; it is evidence under test, not trusted policy.
`supplied_evidence`	No	Up to twenty evidence objects supplied with the candidate output and bound to integrity hashes.
`verification_mode`	Yes	Verification mode. Only standard (deterministic checks of the supplied material, no outbound retrieval) is available. independent_reproduction has a governed price but is not available: it is rejected with verification_mode_unavailable before any payment challenge and is never downgraded to standard.
`verification_contract`	Yes	Complete set of claims and deterministic checks against which the supplied candidate output is evaluated.
`freshness_requirements`	No	Optional maximum-age limits for evidence and schemas, each expressed in seconds.
`allowed_evidence_sources`	No	Up to ten permitted evidence source URIs; evidence outside this allowlist cannot satisfy source restrictions.
`maximum_authorized_price`	No	Buyer’s decimal-safe maximum authorized price; constrains the payment requirement and never relaxes verification policy.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes	Output schema for verify_agent_output.v1 service. Must be a valid PCC 1.0.0 document with required net.siteborne.agent-verification.v1 extension. Governed candidate output for Service Contract 3.0.0 / PCC 2.0.0.

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the annotations: it discloses closed-world behavior, persistence of payment/audit/job/Workflow state, replay protection, production-disabled status, exact pricing, and the rule that price never relaxes verification policy. All of this is consistent with readOnlyHint=false, openWorldHint=false, idempotentHint=true, and destructiveHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with labeled sections and front-loaded purpose, but it is long and repeats key facts (independent_reproduction unavailability, price independence) in multiple sections. The redundancy is tolerable for a complex paid service, but not every sentence is strictly necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, paid, production-disabled verification service with 9 parameters and an output schema, the description covers selection, parameter constraints, behavior, failure modes, economics, and return value shape. Nothing an agent needs to decide whether and how to call it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds meaningful constraints not in the schema, such as required_schema needing to fit SITEBORNE JSON Schema Profile 1 and unsupported/oversized schemas being rejected before payment. It also clarifies that verification_mode must be standard and independent_reproduction is never downgraded, though some of this repeats schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource—'Evaluate a supplied agent output against explicit claims, deterministic requirements, a required JSON Schema, and optional evidence'—and immediately distinguishes this verification service from sibling evidence-gathering tools by naming them. The scope is unambiguous even without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit 'Use when' and 'Do not use when' guidance, names the exact sibling tools for evidence gathering, and states that independent reproduction is unavailable. This gives an agent a clear decision procedure for selecting this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesSep 24, 2026

Addedsiteborne_build_company_evidence_graph_v3_candidate
Addedsiteborne_extract_document_evidence_json_v3_candidate

Changedsiteborne_get_quote3 fields changed

changedInput schema / properties / service_id / enum

Previous value: -[
-  "company_evidence_graph.v1",
-  "web_context_verified.v1",
-  "document_evidence_json.v1",
-  "verify_agent_output.v1",
-  "company_evidence_graph.v2",
-  "web_context_verified.v2",
-  "document_evidence_json.v2",
-  "verify_agent_output.v2"
-]New value: +[
+  "company_evidence_graph.v1",
+  "web_context_verified.v1",
+  "document_evidence_json.v1",
+  "verify_agent_output.v1",
+  "company_evidence_graph.v2",
+  "web_context_verified.v2",
+  "document_evidence_json.v2",
+  "verify_agent_output.v2",
+  "company_evidence_graph.v3",
+  "web_context_verified.v3",
+  "document_evidence_json.v3",
+  "verify_agent_output.v3"
+]

changedOutput schema / properties / contract_release / enum

Previous value: -[
-  "1.0.0",
-  "2.0.0"
-]New value: +[
+  "1.0.0",
+  "2.0.0",
+  "3.0.0"
+]

changedOutput schema / properties / service_version / enum

Previous value: -[
-  "v1",
-  "v2"
-]New value: +[
+  "v1",
+  "v2",
+  "v3"
+]

Changedsiteborne_get_service_health1 field changed
- changedOutput schema / properties / tools / const
```
Previous value: -6New value: +10
```
Addedsiteborne_retrieve_verified_web_context_v3_candidate
Addedsiteborne_verify_agent_output_v3_candidate

6 tool updatesSep 21, 2026
- Addedsiteborne_build_company_evidence_graph
- Removedsiteborne_company_evidence_graph
- Removedsiteborne_document_evidence_json
- Addedsiteborne_extract_document_evidence_json
- Addedsiteborne_retrieve_verified_web_context
- Removedsiteborne_web_context_verified

3 tool updatesSep 20, 2026

Changedsiteborne_get_quote24 fields changed

addedOutput schema / properties / actual_amount / description

Added value: +"Always null in a quote: the actual charge exists only after measured settlement."

addedOutput schema / properties / amount / description

Added value: +"Amount in the asset atomic units (6 decimals for USDC): the exact price when amount_kind is exact, or the authorized maximum when it is authorized_maximum."

addedOutput schema / properties / amount_kind / description

Added value: +"exact: the charge equals amount. authorized_maximum: the charge is measured at settlement and never exceeds amount."

addedOutput schema / properties / asset / description

Added value: +"Token contract address on the network that the amount is denominated in."

addedOutput schema / properties / binding_hash / description

Added value: +"Hash binding the quote to the exact service, input hash, price, scheme, network, asset, and payee; a payment for a different binding is not accepted."

addedOutput schema / properties / contract_release / description

Added value: +"Contract release the quoted service belongs to."

addedOutput schema / properties / economics

Added value: +{
+  "additionalProperties": {},
+  "description": "The canonical economic contract for the quoted service (pricing model, tiers, authorization maximum, settlement model, modes and their availability, limits, production state, pricing_source_version, and network/asset/pay_to); identical on every SITEBORNE discovery surface.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

addedOutput schema / properties / expires_at / description

Added value: +"UTC time after which the quote is no longer valid."

addedOutput schema / properties / input_hash / description

Added value: +"Canonical hash of the exact request input this quote binds."

addedOutput schema / properties / issued_at / description
```
Added value: +"UTC time the quote was issued."
```

addedOutput schema / properties / network / description

Added value: +"CAIP-2 network the payment must be made on (for example eip155:8453)."

addedOutput schema / properties / payee / description

Added value: +"Public payTo address that receives the payment."

addedOutput schema / properties / payment_required / description

Added value: +"Always true: executing the quoted service requires payment."

addedOutput schema / properties / payment_requirements / description

Added value: +"The x402 payment requirement to satisfy, including payTo, network, asset and amount."

addedOutput schema / properties / pricing_key / description

Added value: +"Governed pricing key the amount was resolved from (governance pricing authority)."

addedOutput schema / properties / pricing_source_version / description

Added value: +"Version of the governed pricing document that produced the amount; a repricing changes this value."

addedOutput schema / properties / production_enabled / description

Added value: +"Quote-level flag, always false: a quote never authorizes execution. The service runtime state is economics.production_enabled."

addedOutput schema / properties / quote_id / description

Added value: +"Deterministic identifier of this quote."

addedOutput schema / properties / requirement_id / description

Added value: +"Identifier of the x402 payment requirement embedded in payment_requirements."

addedOutput schema / properties / resource_id / description

Added value: +"Canonical URL of the paid resource this quote is bound to."

addedOutput schema / properties / scheme / description

Added value: +"x402 scheme: exact requires the amount; upto authorizes it as a maximum."

addedOutput schema / properties / service_id / description

Added value: +"Canonical service id and major version that was quoted."

addedOutput schema / properties / service_version / description
```
Added value: +"Service contract major version."
```

changedOutput schema / required

Previous value: -[
-  "quote_id",
-  "binding_hash",
-  "service_id",
-  "service_version",
-  "contract_release",
-  "input_hash",
-  "pricing_key",
-  "pricing_source_version",
-  "scheme",
-  "network",
-  "asset",
-  "amount",
-  "amount_kind",
-  "actual_amount",
-  "resource_id",
-  "requirement_id",
-  "payment_requirements",
-  "payee",
-  "issued_at",
-  "expires_at",
-  "production_enabled",
-  "payment_required"
-]New value: +[
+  "quote_id",
+  "binding_hash",
+  "service_id",
+  "service_version",
+  "contract_release",
+  "input_hash",
+  "pricing_key",
+  "pricing_source_version",
+  "scheme",
+  "network",
+  "asset",
+  "amount",
+  "amount_kind",
+  "actual_amount",
+  "resource_id",
+  "requirement_id",
+  "payment_requirements",
+  "payee",
+  "issued_at",
+  "expires_at",
+  "production_enabled",
+  "payment_required",
+  "economics"
+]

Changedsiteborne_verify_agent_output1 field changed

changedInput schema / properties / verification_mode / description

Previous value: -"standard checks supplied material; independent_reproduction additionally attempts independently derived verification where implemented."New value: +"Verification mode. Only standard (deterministic checks of the supplied material, no outbound retrieval) is available. independent_reproduction has a governed price but is not available: it is rejected with verification_mode_unavailable before any payment challenge and is never downgraded to standard."

Changedsiteborne_web_context_verified2 fields changed

changedInput schema / examples

Previous value: -[
-  {
-    "freshness_seconds": 3600,
-    "maximum_authorized_price": {
-      "amount": "0.029",
-      "currency": "USD"
-    },
-    "output_mode": "markdown",
-    "retrieval_mode": "rendered",
-    "target_url": "https://acme.example.com/about"
-  }
-]New value: +[
+  {
+    "freshness_seconds": 3600,
+    "maximum_authorized_price": {
+      "amount": "0.029",
+      "currency": "USD"
+    },
+    "output_mode": "markdown",
+    "retrieval_mode": "direct",
+    "target_url": "https://acme.example.com/about"
+  }
+]

changedInput schema / properties / retrieval_mode / description

Previous value: -"direct fetches the origin response without browser rendering; rendered permits browser-backed retrieval for client-rendered pages and may cost more."New value: +"Retrieval mode. Only direct (plain HTTP retrieval, no JavaScript execution) is available. rendered has a governed price but is not available: it is rejected with retrieval_mode_unavailable before any payment challenge and is never substituted with direct retrieval."

5 tool updatesSep 12, 2026

Changedsiteborne_company_evidence_graph18 fields changed

changedInput schema / properties / buyer_urls / description

Previous value: -"Buyer-provided public URLs for supplemental evidence."New value: +"Up to twenty public supplemental evidence URLs supplied by the buyer; these are additional sources, not replacements for entity resolution."

changedInput schema / properties / company_name / description

Previous value: -"Company legal or common name."New value: +"Legal or commonly used company name; supplies an entity-resolution signal when authoritative identifiers are unavailable."

changedInput schema / properties / domain / description

Previous value: -"Primary website domain."New value: +"Primary website hostname only, without a URL path; links first-party web evidence to the company identity."

changedInput schema / properties / freshness_seconds / description

Previous value: -"Maximum acceptable age of data in seconds."New value: +"Maximum acceptable source age in seconds, from 0 through 2,592,000; lower values demand fresher evidence."

changedInput schema / properties / identifiers / description

Previous value: -"Authoritative identifiers when known."New value: +"Known authoritative entity identifiers; supplying precise identifiers reduces ambiguous name, ticker, or domain matching."

changedInput schema / properties / identifiers / properties / cik / description

Previous value: -"SEC CIK"New value: +"Exactly ten decimal digits identifying the company in SEC EDGAR."

changedInput schema / properties / identifiers / properties / cusip / description

Previous value: -"CUSIP"New value: +"Nine-character CUSIP security identifier."

changedInput schema / properties / identifiers / properties / exchange / description

Previous value: -"Primary exchange"New value: +"Primary listing exchange name or code, up to sixteen characters; disambiguates reused ticker symbols."

changedInput schema / properties / identifiers / properties / figi / description

Previous value: -"OpenFIGI"New value: +"Twelve-character OpenFIGI identifier beginning with BBG."

changedInput schema / properties / identifiers / properties / isin / description

Previous value: -"ISIN"New value: +"Twelve-character International Securities Identification Number."

changedInput schema / properties / identifiers / properties / lei / description

Previous value: -"Legal Entity Identifier"New value: +"Exactly twenty uppercase alphanumeric characters for the Legal Entity Identifier."

changedInput schema / properties / identifiers / properties / ticker_symbol / description

Previous value: -"Primary ticker"New value: +"One-to-five uppercase characters for the primary listed ticker when it differs from ticker."

changedInput schema / properties / jurisdiction_hints / description

Previous value: -"Optional jurisdiction hints for regulatory context."New value: +"Up to five two-letter uppercase jurisdiction codes used to focus regulatory context; hints do not assert incorporation."

changedInput schema / properties / maximum_authorized_price / description

Previous value: -"Maximum price authorized for this request."New value: +"Buyer’s decimal-safe maximum authorized price; constrains the payment requirement and never expands provider scope."

changedInput schema / properties / minimum_completeness / description

Previous value: -"Minimum completeness score required [0, 1]."New value: +"Required completeness ratio from 0 through 1; results below this threshold fail the requested acceptance condition."

changedInput schema / properties / minimum_verification_score / description

Previous value: -"Minimum PCC verification score [0, 1]."New value: +"Required PCC verification ratio from 0 through 1; raising it makes result acceptance stricter."

changedInput schema / properties / requested_field_groups / description

Previous value: -"Field groups to include in the result."New value: +"Unique evidence categories to collect; omitted values use the schema default, while a smaller list limits provider work and result scope."

changedInput schema / properties / ticker / description

Previous value: -"Stock ticker symbol."New value: +"One-to-five uppercase exchange ticker symbols; narrows public-company resolution but is not globally unique without other signals."

Changedsiteborne_document_evidence_json22 fields changed

changedInput schema / properties / artifact_reference / description

Previous value: -"Authorized artifact reference (mode 1)."New value: +"Authorized stored-artifact descriptor for reference mode 1; use exactly one of artifact_reference, upload_reference, or document_url."

changedInput schema / properties / declared_page_count / description

Previous value: -"Declared page count when known."New value: +"Optional declared page count from 1 through 10; enables early scope validation but does not override the observed document."

changedInput schema / properties / document_url / description

Previous value: -"Public document URL (mode 3)."New value: +"Public document URL for reference mode 3; use exactly one reference mode and never put credentials in this URL."

changedInput schema / properties / extraction_request / description

Previous value: -"Extraction configuration."New value: +"Selects text, table, key-value, and buyer-schema extraction outputs; omitted switches retain their documented defaults."

addedInput schema / properties / extraction_request / properties / buyer_schema / description

Added value: +"Optional JSON Schema, bounded to fifty properties and depth five, used to validate buyer-shaped extracted data."

addedInput schema / properties / extraction_request / properties / extract_key_values / description
```
Added value: +"Whether key-value extraction is requested; defaults to false."
```

addedInput schema / properties / extraction_request / properties / extract_tables / description

Added value: +"Whether bounded table extraction is requested; defaults to false and may increase processing work."

addedInput schema / properties / extraction_request / properties / extract_text / description
```
Added value: +"Whether normalized text extraction is requested; defaults to true."
```

changedInput schema / properties / language_hints / description

Previous value: -"Language hints for OCR/extraction (BCP 47)."New value: +"Up to five BCP 47 language hints used by OCR and extraction; hints do not translate the document."

changedInput schema / properties / maximum_authorized_price / description

Previous value: -"Canonical decimal-safe money representation. No binary floating-point. Amount is a canonical decimal string."New value: +"Buyer’s decimal-safe maximum authorized price; constrains the payment requirement and not retention or extraction policy."

addedInput schema / properties / minimum_verification_score / description

Added value: +"Required PCC verification ratio from 0 through 1; raising it makes extracted-evidence acceptance stricter."

changedInput schema / properties / ocr_permission / description

Previous value: -"Whether OCR is permitted for image-based content."New value: +"Explicit permission to use OCR for image-based content; false prevents OCR even when text is not embedded."

changedInput schema / properties / page_range / description

Previous value: -"Page range to process (1-indexed, inclusive)."New value: +"Optional one-indexed inclusive page range to process; both bounds are limited to pages 1 through 10."

addedInput schema / properties / page_range / properties / end / description

Added value: +"Last one-indexed page to process, inclusive and not before start."

addedInput schema / properties / page_range / properties / start / description
```
Added value: +"First one-indexed page to process, inclusive."
```

changedInput schema / properties / retention_preference / description

Previous value: -"Retention preference within policy limits."New value: +"Requested retention class—none, temporary, or permanent—subject to server policy; it cannot override mandatory retention limits."

changedInput schema / properties / table_extraction_request / description

Previous value: -"Whether table extraction is requested."New value: +"Explicit top-level request for table extraction; false leaves tables unrequested."

changedInput schema / properties / upload_reference / description

Previous value: -"Authorized upload reference (mode 2)."New value: +"Previously issued SITEBORNE upload handle and declared file metadata for reference mode 2; it does not upload document bytes."

addedInput schema / properties / upload_reference / properties / content_hash / description

Added value: +"Optional lowercase SHA-256 integrity identifier in sha256:<64 hex> form; when supplied it must match the artifact."

addedInput schema / properties / upload_reference / properties / media_type / description

Added value: +"Declared parser media type: PDF, PNG, or JPEG; it must match the stored artifact."

addedInput schema / properties / upload_reference / properties / size_bytes / description

Added value: +"Declared artifact size in bytes, from 1 through 10,485,760; it is checked against stored metadata."

addedInput schema / properties / upload_reference / properties / upload_id / description

Added value: +"Opaque SITEBORNE upload identifier, up to 512 characters, that selects the already admitted artifact."

Changedsiteborne_get_quote3 fields changed

addedInput schema / properties / input / description

Added value: +"Complete proposed input for the selected service; its canonical hash binds the quote and later payment requirement to this exact request content."

addedInput schema / properties / scheme / description

Added value: +"Pricing mode: exact fixes the required amount, while upto authorizes a maximum whose eventual charge cannot exceed the returned amount."

addedInput schema / properties / service_id / description

Added value: +"Canonical SITEBORNE service and major version to price; selects that service’s governed pricing key, contract release, and production resource URL."

Changedsiteborne_verify_agent_output26 fields changed

changedInput schema / properties / allowed_evidence_sources / description

Previous value: -"Allowed evidence source domains/URIs."New value: +"Up to ten permitted evidence source URIs; evidence outside this allowlist cannot satisfy source restrictions."

changedInput schema / properties / candidate_output / description

Previous value: -"The agent output to verify. Cannot modify verifier policy."New value: +"Agent-produced JSON object to evaluate, bounded to 200 properties and depth 10; it is evidence under test, not trusted policy."

addedInput schema / properties / freshness_requirements / description

Added value: +"Optional maximum-age limits for evidence and schemas, each expressed in seconds."

addedInput schema / properties / freshness_requirements / properties / evidence_max_age_seconds / description

Added value: +"Maximum evidence age in seconds from 0 through 2,592,000; older evidence fails freshness requirements."

addedInput schema / properties / freshness_requirements / properties / schema_max_age_seconds / description

Added value: +"Maximum schema age in seconds from 0 through 2,592,000; older schemas fail freshness requirements."

changedInput schema / properties / maximum_authorized_price / description

Previous value: -"Canonical decimal-safe money representation. No binary floating-point. Amount is a canonical decimal string."New value: +"Buyer’s decimal-safe maximum authorized price; constrains the payment requirement and never relaxes verification policy."

changedInput schema / properties / minimum_score / description

Previous value: -"Minimum verification score [0, 1]."New value: +"Minimum overall verification score from 0 through 1; raising it makes the final acceptance verdict stricter."

changedInput schema / properties / required_schema / description

Previous value: -"Required output schema (JSON Schema) that candidate must conform to."New value: +"JSON Schema the candidate output must satisfy; it constrains validation and cannot change SITEBORNE verifier policy."

changedInput schema / properties / supplied_evidence / description

Previous value: -"Evidence items supplied with the candidate output."New value: +"Up to twenty evidence objects supplied with the candidate output and bound to integrity hashes."

addedInput schema / properties / supplied_evidence / items / properties / content / description

Added value: +"JSON evidence content whose integrity must agree with content_hash; it is treated as untrusted input."

addedInput schema / properties / supplied_evidence / items / properties / content_hash / description

Added value: +"Lowercase SHA-256 integrity identifier in sha256:<64 hex> form for the supplied content."

addedInput schema / properties / supplied_evidence / items / properties / evidence_id / description

Added value: +"Caller-stable evidence identifier up to 64 characters, used to connect claims to this evidence item."

addedInput schema / properties / supplied_evidence / items / properties / retrieved_at / description

Added value: +"Optional UTC retrieval timestamp in the schema’s RFC 3339 form, used by freshness checks."

addedInput schema / properties / supplied_evidence / items / properties / source_uri / description

Added value: +"Optional public source URI, up to 2,048 characters, identifying where the evidence was obtained."

changedInput schema / properties / verification_contract / description

Previous value: -"Contract specifying what to verify."New value: +"Complete set of claims and deterministic checks against which the supplied candidate output is evaluated."

addedInput schema / properties / verification_contract / properties / claims / description

Added value: +"Up to fifty expected claims; each binds a stable claim identifier to a predicate, expected value, and optional tolerance/materiality."

addedInput schema / properties / verification_contract / properties / claims / items / properties / claim_id / description
```
Added value: +"Caller-stable claim identifier up to 64 characters, used to correlate the verdict for this claim."
```
addedInput schema / properties / verification_contract / properties / claims / items / properties / expected_value / description
```
Added value: +"Expected JSON value interpreted by the selected predicate; its shape should match the claim being tested."
```

addedInput schema / properties / verification_contract / properties / claims / items / properties / materiality / description

Added value: +"Claim importance—material, supporting, or contextual—which affects how the verdict weighs a failed claim."

addedInput schema / properties / verification_contract / properties / claims / items / properties / predicate / description

Added value: +"Comparison operation applied to the candidate value: equality, containment, pattern, ordering, existence, or nonexistence."

addedInput schema / properties / verification_contract / properties / claims / items / properties / tolerance / description
```
Added value: +"Optional nonnegative numeric tolerance for comparisons where bounded deviation is acceptable."
```

addedInput schema / properties / verification_contract / properties / deterministic_requirements / description

Added value: +"Up to thirty deterministic checks for schema, hashes, signatures, evidence resolution, PII, or secrets."

addedInput schema / properties / verification_contract / properties / deterministic_requirements / items / properties / check / description
```
Added value: +"Closed deterministic check to run: schema, hash, signature, evidence resolution, PII absence, or secret absence."
```
addedInput schema / properties / verification_contract / properties / deterministic_requirements / items / properties / parameters / description
```
Added value: +"Check-specific configuration interpreted only by the selected deterministic check; it cannot modify verifier policy."
```
addedInput schema / properties / verification_contract / properties / deterministic_requirements / items / properties / requirement_id / description
```
Added value: +"Caller-stable requirement identifier up to 64 characters, used to correlate the deterministic check result."
```

changedInput schema / properties / verification_mode / description

Previous value: -"Verification mode."New value: +"standard checks supplied material; independent_reproduction additionally attempts independently derived verification where implemented."

Changedsiteborne_web_context_verified12 fields changed

changedInput schema / properties / buyer_schema / description

Previous value: -"Optional buyer-provided JSON Schema for structured output validation."New value: +"Optional JSON Schema governing structured output; meaningful only with output_mode structured and bounded to fifty properties and depth five."

changedInput schema / properties / field_selectors / description

Previous value: -"Requested field selectors for structured output."New value: +"Up to thirty requested field names for structured extraction; narrows the structured result rather than changing the fetched URL."

changedInput schema / properties / freshness_seconds / description

Previous value: -"Maximum acceptable age of cached content in seconds."New value: +"Maximum acceptable cached-content age in seconds, from 0 through 2,592,000; zero requests uncached content."

changedInput schema / properties / locale_hint / description

Previous value: -"Locale hint for content negotiation (BCP 47)."New value: +"Optional BCP 47 language or language-region hint used for HTTP content negotiation; it does not translate content."

changedInput schema / properties / max_content_size / description

Previous value: -"Maximum content size in bytes to return."New value: +"Maximum returned content size in bytes, from 1,024 through 10,485,760; smaller limits truncate or reject oversized content sooner."

changedInput schema / properties / max_redirects / description

Previous value: -"Maximum number of redirects to follow."New value: +"Maximum redirect hops from 0 through 10 when the selected redirect policy follows redirects."

changedInput schema / properties / maximum_authorized_price / description

Previous value: -"Canonical decimal-safe money representation. No binary floating-point. Amount is a canonical decimal string."New value: +"Buyer’s decimal-safe maximum authorized price; constrains the payment requirement and never changes retrieval scope."

changedInput schema / properties / minimum_verification_score / description

Previous value: -"Minimum PCC verification score [0, 1]."New value: +"Required PCC verification ratio from 0 through 1; raising it makes evidence acceptance stricter."

changedInput schema / properties / output_mode / description

Previous value: -"Desired output format."New value: +"Result representation: clean_text normalizes prose, markdown preserves document structure, and structured validates selected fields against buyer_schema."

changedInput schema / properties / redirect_policy / description

Previous value: -"Redirect handling policy."New value: +"Redirect handling: follow permits the bounded chain, follow_first permits only the first hop, and manual returns redirect evidence without following."

changedInput schema / properties / retrieval_mode / description

Previous value: -"Retrieval mode."New value: +"direct fetches the origin response without browser rendering; rendered permits browser-backed retrieval for client-rendered pages and may cost more."

changedInput schema / properties / target_url / description

Previous value: -"Target URL to retrieve. Public HTTP/HTTPS only."New value: +"Public HTTP or HTTPS URL to retrieve and verify; private, loopback, and otherwise unsafe network destinations are rejected."

6 tool updatesSep 11, 2026
- First observedsiteborne_company_evidence_graph
- First observedsiteborne_document_evidence_json
- First observedsiteborne_get_quote
- First observedsiteborne_get_service_health
- First observedsiteborne_verify_agent_output
- First observedsiteborne_web_context_verified

Related MCP Connectors

LedgerProof LAIN — Verified Evidence for Agents A
io.ledgerproofhq
Cryptographically anchored evidence for agents: verified run receipts, proof-gated settlement.
Blockchain Cryptocurrency Security
2
stillos-notary-mcp A
io.github.stillmarcus24
Attestation infrastructure for the agentic economy: signed, independently verifiable verdicts.
Blockchain Security
511
Knox Anchor A
com.bonissystems
Bitcoin-anchored, tamper-evident audit-permanence layer for AI agents, FRE 902(13)/(14)-shaped.
Blockchain Legal & Compliance
72
Rose Bounty
org.agttglobal
AI-agent trust infrastructure for discovery, authority, execution, verification, and receipts.
1

Related MCP Servers

LedgerProof LAIN
Security Web3 & Decentralized Tech Autonomous Agents
vsdawkins-creator
F
license
Not graded
quality
C
maintenance
Cryptographically anchored, tamper-evident evidence receipts for AI agents — verified run receipts, existence-at-time proofs, and cited answers from an anchored public record. Remote MCP with proof-gated settlement; attests existence and integrity, never truth.
Updated 2 months ago (2026-07-22 18:42 UTC)
-
evermint-mcpofficial
Security Blockchain Autonomous Agents
EverMint-app
A
license
Not graded
quality
C
maintenance
Tamper-evident receipts for AI agent actions. The notary layer for agent-to-agent transactions.
Updated 5 months ago (2026-05-07 01:33 UTC)
23 npm
1
MIT
maiat-protocol
Blockchain Agent Orchestration Finance
JhiNResH
A
license
A
quality
D
maintenance
Trust infrastructure for the agent economy.
Updated 3 months ago (2026-06-27 02:17 UTC)
10
3
MIT
viridis-agent-fleet
Autonomous Agents Blockchain Payments & Billing
jdhart81
A
license
C
quality
B
maintenance
MCP services for agent security preflight, source scanning, injection screening, proof-of-work policy rehearsal, carbon accounting, climate disclosure and regulatory monitoring. Use each hosted endpoint in the README. Inspect a free quote before buyer-authorized x402/USDC payment. Includes free trust and settlement tools. Maxwell rehearsal does not activate runtime protection.
Updated 2 days ago (2026-09-26 02:03 UTC)
220
Apache 2.0