SCRIPTMASTERLABS — Provider Trust + CANON

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

Goes well beyond the annotations by disclosing the paid model ($0.01 USDC via x402 on Base), the required PAYMENT-SIGNATURE header, the exact 402 challenge behavior (amount 10000, payTo), and that settlement happens on the canonical endpoint with no funds ever held by this MCP. These are non-obvious operational traits the annotations cannot convey.

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

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

Front-loads the core action and value, then the payment mechanics in a logical order, with no filler sentences. It is somewhat dense and long for a single-parameter tool, but every clause (pricing, header, 402 behavior, settlement) carries operational weight.

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

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

For a paid, open-world tool with a nested item array and no output schema, the description covers the invocation prerequisites and safety posture thoroughly. It does not sketch the shape of the returned freshness/conflict records, which the agent would need to interpret results, so it falls just short of complete.

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

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

Schema description coverage is 100%, so the nested item fields (id, type, held_version, held_integrity, publisher_domain) are already fully documented. The description adds only the batch ceiling ('up to 100') and the freshness/conflict framing, which is modest value over the schema, so baseline 3 applies.

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

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

States a specific verb ('Resolve') and resource ('artifact freshness records') plus the scope (up to 100 in one call against live registries and verified publisher manifests), and names the concrete findings (stale mirrors, superseded artifacts, publisher/registry conflicts). An agent can tell this apart from siblings like verify_provider or check_status 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.

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

The description makes the usage context clear: this is the bulk path (up to 100 items) against live registries, and it explicitly explains the required payment flow and the 402 fallback. It stops short of naming when to prefer a single-item/sibling tool or when not to use it, so it is clear context without explicit exclusions.

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

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

The annotations already establish that this is a read-only, idempotent, open-world, non-destructive operation. The description adds a useful semantic caveat that traffic volume is context only and must not be interpreted as buyers, trust, or reputation, but it does not describe the returned history format or other behavioral details.

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

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

The description is two tight sentences with no wasted language, and the core purpose is front-loaded. The caveat sentence is also meaningful rather than filler.

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

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

For a tool with no output schema and an undocumented hours parameter, the description is incomplete. It gives purpose and a traffic-volume caveat, but it does not explain what history is returned, the default 720-hour window, or how results should be interpreted beyond the traffic warning.

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

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

The single optional parameter, hours, is not mentioned at all in the description, and schema description coverage is 0%. The schema provides type, default, and min/max values, but the description adds no meaning about what the time window controls or how it affects results.

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

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

The description states a clear verb and resource: checking recent evidence-backed provider history. It is understandable on its own, but it does not differentiate this tool from siblings such as check_status, verify_provider, or check_identity.

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

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

There is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The traffic-volume caveat is about interpretation, not usage selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description's only added signal is the word 'live', hinting at a real-time external lookup, but it says nothing about what evidence is returned, whether failures are surfaced as errors or empty results, or any latency/rate considerations.

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

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

One short sentence with no filler and the key notion ('live identity evidence') up front, so nothing is wasted. However, the brevity comes at the cost of under-specification rather than from disciplined editing.

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

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

With no output schema and no explanation of what 'evidence' comprises, the agent cannot anticipate the return shape or interpret results. Combined with the total absence of routing guidance among six similar siblings, the definition is not complete enough to invoke confidently.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The schema and annotations fully define the call surface.

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

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

The description essentially restates the tool name: 'Check live provider identity evidence' adds only the qualifiers 'live' and 'evidence' beyond 'check_identity'. It never says what 'identity evidence' concretely is (credentials? registration status? contact data?) or how this differs from verify_provider, check_status, or check_payment.

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

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

There is no when-to-use guidance at all, despite six sibling tools that all sound plausibly related (verify_provider, compare_providers, check_status, check_history, check_payment, canon_registry_bulk_lookup). The agent is left to guess which check to call and under what conditions.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description contributes only the nuance that the check is "live" and reports "real settlement evidence," hinting that it performs an actual network verification rather than reading a cache, but says nothing about latency, failures, or what evidence is returned.

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

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

One front-loaded sentence with no filler or repetition. It is tight, though the terseness leaves the key noun phrase ("x402", "settlement evidence") unexplained rather than earning clarity.

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

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

With no output schema and no parameters, the description is the only place to explain what a "readiness" verdict or "settlement evidence" actually contains, and it does not. Annotations cover the safety profile, but an agent still cannot predict the response shape before calling.

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

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

The tool takes zero parameters and schema coverage is 100%, so there is nothing to disambiguate. Per the zero-parameter baseline, the description is not required to add parameter meaning.

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

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

The verb+resource pair ("check ... payment readiness") is identifiable, but the object is jargon-heavy: "x402" and "real settlement evidence" are not explained, and the description never distinguishes this from siblings like check_status or check_history. An agent can guess it validates payment state, but not precisely what is being checked.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of when to prefer this over check_status, check_history, or verify_provider. The agent must infer the calling condition entirely from the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so safety and repeatability are covered without description help. The description contributes the useful scoping detail that it checks backend liveness rather than data correctness, but says nothing about latency, failure modes, or what a negative result means.

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

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

A single front-loaded sentence with no filler or redundancy. Every word carries meaning and the key qualifier ('backend is live') is not buried.

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

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

For a no-param liveness probe with rich annotations, the description covers what is being checked. Since no output schema exists, it could say more about the return value (boolean vs. status payload), which is the only real gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No misleading parameter hints are present.

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

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

States a specific verb (check) and resource (Provider Trust backend liveness), which is clearly distinct from data-oriented siblings like check_identity or check_payment. It doesn't explicitly name those siblings, but 'backend is live' is specific enough that an agent won't confuse it with a data lookup.

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

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

Usage is only implied: an agent can infer this is a health/liveness probe to run before or when other calls fail, but the description never says when to call it, when not to, or that it is the fallback diagnostic for the other check_* tools. No alternative routing is given.

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

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

Annotations already declare readOnly, idempotent, open-world, non-destructive, so the safety profile is covered. The description adds real value by saying it draws on live evidence and explicitly does not fabricate a score or winner, which sets expectations for the output. It does not say anything about latency, cost, coverage limits, or what the evidence looks like.

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

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

Two short sentences, front-loaded with the verb and arity, with no filler. Every clause earns its place.

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

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

For an open-world comparison tool with no output schema, the definition leaves too much unresolved: target format, what 'live evidence' is returned, and expected latency. Annotations cover safety but not the information an agent needs to prepare inputs or interpret results.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It explains the 2-5 count (matching minItems/maxItems), but never says what a 'target' string actually is — provider name, ID, or URL — despite a minLength that suggests a structured identifier. That gap is the main thing an agent needs clarified.

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

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

States a specific verb (compare) and resource (providers) with an explicit 2-5 arity bound, so the agent can tell it is a multi-provider comparison rather than a single-provider check like verify_provider. It does not explicitly name the sibling it displaces, so it stops short of a 5.

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

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

The arity '2-5 providers' implies the shape of a valid call, but there is no statement of when to choose this over verify_provider, check_identity, or check_payment, and no exclusions or prerequisites. The agent must infer the routing decision from sibling names alone.

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

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

Adds substantial context the annotations cannot: the $0.001 USDC cost on Base, the required PAYMENT-SIGNATURE header on the /mcp request, and the exact failure mode (HTTP 402 challenge with amount 1000 and payTo). It also discloses custody semantics ("never holds funds and never pays on your behalf") and the conservative result policy, so an agent knows both the cost gate and the outcome shape before calling.

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

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

Cost and payment mechanics are front-loaded, which is the highest-value information here, and the sentences are dense but purposeful. The payment/settlement explanation runs slightly long and repeats the x402 framing, but nothing is filler.

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

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

For a single-parameter, no-output-schema tool, the description covers the missing pieces an agent needs: price, payment handshake, error behavior, and the evidence-only result contract. It stops short of describing what the evidence payload contains or how large it is, which would matter for a verification call whose value is in the returned proof.

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

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

With one parameter at 100% schema description coverage, the schema already defines target as a public HTTPS provider/source/MCP/A2A/API URL, including length bounds. The description only repeats the notion of a provider or source and adds no format or validation detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource: verify a provider or source so an agent can decide whether to trust it, plus an explicit output contract ("Returns live evidence only; unknown stays unknown"). It does not name or distinguish itself from close siblings such as check_identity or compare_providers, so an agent still has to infer the boundary, which keeps it at 4 rather than 5.

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

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

"Verify a provider or source before an AI agent trusts or uses it" gives a clear triggering condition and timing. There are no exclusions or named alternatives, so an agent choosing between this and check_identity or compare_providers receives no routing help.

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