SCRIPTMASTERLABS — Provider Trust MCP

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the manifest is 'current' and 'derived from the running service,' which conveys liveness but does not meaningfully go beyond 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.

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

A single sentence that front-loads the action and resource. Every word earns its place, with no redundancy or 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?

This is a parameterless, read-only manifest retrieval tool with strong annotations and no output schema. The description identifies the resource and its source clearly enough for an agent to invoke it, though it could optionally clarify what a capability manifest contains.

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

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

The tool has zero parameters and schema description coverage is 100%, so there is no parameter information the description needs to add. The baseline score for a parameterless tool is 4.

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

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

The description uses a specific verb ('Return') and names the exact resource: 'current SqueezeOS machine capability manifest derived from the running service.' This clearly differentiates the tool from siblings like compare_capabilities or recommend_capability, though it does not explicitly call out those alternatives.

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 gives no guidance on when to use this tool versus discover_capabilities, inspect_capability, compare_capabilities, or recommend_capability. There are no exclusions, conditions, or alternative-selection rules.

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, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context beyond those: it uses live/current metadata and explicitly does not fabricate a composite score. No contradiction with annotations.

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

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

A single focused sentence that front-loads the action and bounds, then appends the key caveat. There is no filler or redundant restating of the schema.

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

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

The description is enough to understand the core operation, but with no output schema it does not clarify what a comparison returns or how `probe` affects the result. It is adequate but not fully complete for an agent invoking it blind.

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 0% schema description coverage, the description must carry parameter meaning. It clarifies that sml_ids represents the two-to-five capabilities being compared, but it never explains the probe boolean or the expected string format. Partial compensation, with a clear gap around probe.

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

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

The description names a specific verb ('Compare'), a clear resource ('capabilities'), and a numerical scope ('two to five'), then adds an explicit constraint ('without fabricating a composite score'). This makes it easy to distinguish from sibling tools like inspect_capability or recommend_capability.

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

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

The description implies the tool is for comparing multiple live capabilities, but it does not state when to prefer it over siblings or provide exclusion criteria. There is no explicit when-to-use or when-not-to-use guidance, so the context must be inferred.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds 'live' inventory context and explicitly excludes transaction-like behaviors, which is useful but not extensive. 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.

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

Two focused sentences with zero filler. The primary action is front-loaded, and the second sentence efficiently clarifies boundaries. Every word 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 a read-only search tool with rich annotations, the description is mostly adequate. However, with no output schema and no explanation of mode or limit, an agent may not know how results vary across modes or how to control result volume. It is sufficient for basic selection but lacks detail for optimal invocation.

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

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

Schema description coverage is 0%, so the description must compensate for the three parameters (query, mode, limit). It only implies 'query' via 'Search' and says nothing about mode's enum semantics or the limit constraint, leaving agents to infer parameter meaning from names alone.

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?

Describes a specific verb ('Search') and resource ('live SCRIPTMASTERLABS SqueezeOS capability inventory'), clearly distinguishing it from sibling tools that compare, inspect, or recommend capabilities. The explicit negation of purchase/sign/settle/execute further sharpens its scope.

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?

States what the tool does not do (purchase, sign, settle, execute paid capabilities), giving a clear when-not-to-use signal. However, it does not explicitly name alternative tools for those paid operations or for other capability-related queries, so it stops short of full routing guidance.

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 establish read-only, idempotent, non-destructive behavior. The description adds useful context by emphasizing 'live' and by disclosing that the result includes current metadata and optional liveness evidence, which goes beyond the annotation hints without contradicting them.

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

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

The description is a single, front-loaded sentence with no filler. It states the action, target, input, and expected output efficiently.

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 simple read-only tool, the core behavior is clear, but the description is incomplete in important areas: it does not define what 'liveness evidence' contains, does not clarify the probe parameter's role, and no output schema exists to fill that gap. It is adequate but leaves the agent to infer details.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It names sml_id as the identifier, but it does not explicitly explain the probe parameter, its default value of true, or how it controls the 'optional liveness evidence' mentioned in the description. That phrase is ambiguous about whether optionality refers to the parameter or the output.

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

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

The description uses a specific verb ('Inspect'), a specific resource ('one live SqueezeOS capability'), and a precise lookup key ('by sml_id'). It also states what is returned, which clearly separates it from sibling tools like discover_capabilities and compare_capabilities.

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 intended usage is implied: use this tool when you have an sml_id and need current metadata or liveness evidence for a single capability. However, it does not explicitly state when to prefer this tool over siblings such as capability_manifest or verify_provider_trust, nor does it provide 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?

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context by stating the operation includes current metadata and, importantly, does not authorize spend. 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.

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

A single, front-loaded sentence that packs the core action, scope, and a critical safety qualifier without fluff. Every phrase 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?

The tool has only two parameters, and the description covers the main behavioral guardrail and return contents. Since there is no output schema, the mention of endpoint and payment metadata helps fill that gap. It could be richer on response shape or alternative routing, but for this tool's complexity it is reasonably complete.

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

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

Schema description coverage is 0%, so the description carries the burden for parameter meaning. It only hints that 'query' is a natural-language need; it does not explain 'limit', its default, or its range. This is minimal compensation for the schema gap.

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: it returns the best matching live SqueezeOS capabilities for a natural-language need. It also adds scope by mentioning endpoint and payment metadata and explicitly says no spend is authorized. It does not explicitly differentiate from siblings like discover_capabilities, but the recommendation framing is distinct enough.

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 conveys when to use it: for a natural-language need where you want matching capabilities without spend authorization. However, it does not explicitly compare against sibling tools such as discover_capabilities or inspect_capability, nor does it state when not to use it.

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, openWorldHint, idempotentHint, and non-destructive behavior, so the description's burden is lower. It adds value by emphasizing that the endpoint is 'live' and by cautioning that the tool does not synthesize health claims, which is useful behavioral context beyond the structured hints.

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

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

The description is a single sentence with no wasted words. It front-loads the verb and resource, and the clarifying negation earns its place by preventing a likely misuse.

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 parameterless, read-only, idempotent tool with rich annotations and no output schema, the description tells the agent everything needed to decide when to call it. The sibling context shows no overlapping tool, so the description is fully adequate.

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

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

The tool has zero parameters, so the description cannot add parameter-level meaning. Per the baseline for tools with no parameters, a score of 4 is appropriate: there is nothing missing and the description correctly focuses on the operation itself.

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

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

The description names a specific verb ('Read') and resource ('live SqueezeOS status endpoint'), making the tool's function immediately clear. The added clause 'without synthesizing health claims' sharpens the purpose by stating what the tool does not do, which helps distinguish it from potential diagnosis or recommendation tools among the siblings.

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

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

The description implies the tool should be used when raw, live SqueezeOS status is needed, and the 'without synthesizing health claims' phrase signals that it is not for drawing health conclusions. It does not explicitly name alternative tools or exclusion conditions, but the sibling list (capability, x402, compare) makes the intended scope clear enough.

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 declare readOnly/openWorld/idempotent/destructive hints, and the description adds meaningful behavioral guarantees: it never forwards credentials, signs, spends, settles, or executes the provider capability. It also clarifies it observes live evidence, going well beyond the annotation metadata.

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 front-loaded sentences deliver the core action, scope, evidence types, and safety guarantees with no filler. Every clause earns its place and the most decision-relevant information appears first.

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 read-only tool with strong annotations and a clear description, the definition is nearly complete. The only minor gap is that no output schema exists and the return value/format is not described, but the tool's purpose is simple enough that an agent can still use it effectively.

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

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

Schema coverage is 100% and the schema already describes the target parameter as a public HTTPS provider, A2A, MCP, or API URL. The description repeats similar context but does not add significant new parameter-level meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description names a specific action ('Run the free read-only SML Universal Trust Passport') and a specific resource ('a public HTTPS provider URL'), then lists exactly what evidence is observed. This is far more specific than the tool name alone and distinguishes it from related discovery/comparison tools.

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 clearly states the intended use case: verify a public HTTPS provider URL in a read-only manner. It does not explicitly name sibling alternatives or state when not to use the tool, but it provides enough context for an agent to select it for trust verification tasks.

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 convey readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds meaningful domain-specific disclosure by clarifying that the tool 'only reports payment terms' and explicitly denies signing, submitting, or settling payments, which is valuable context beyond the generic read-only annotation.

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 concise sentences: the first states the action and target, the second preempts misuse by stating what the tool does not do. Every word earns its place; no filler or redundancy.

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

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

For a zero-parameter, read-only tool with rich annotations and no output schema, the description is sufficient. It identifies what will be reported ('payment terms') and rules out side effects. An agent has everything needed to call this tool correctly.

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

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

The tool has zero parameters, so the 100% schema coverage is trivially complete. The description adds no parameter-specific information, but none is needed. Per the rubric, 0 params warrants a baseline of 4.

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 ('Read') and a specific resource ('public SqueezeOS x402 discovery contract'), and clarifies that it 'reports payment terms.' This clearly distinguishes it from sibling tools like x402_evidence or x402_readiness by naming the contract as the object of inspection.

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?

Clearly indicates when to use it: to read the SqueezeOS x402 discovery contract and obtain payment terms. It also states what it never does ('never signs, submits, or settles a payment'), effectively telling an agent when not to use it. However, it does not explicitly name alternative tools or conditions for choosing them.

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?

Beyond the annotations (readOnlyHint, openWorldHint, etc.), the description adds the behavioral detail that challenges or signatures are not treated as settlement proof, which is useful extra context.

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 concise sentences with no redundant words. It is well-structured and directly states the tool's purpose.

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

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

The description does not specify what the return value or output format will be. Since there is no output schema, more detail on what constitutes 'evidence' or what the response contains would improve completeness.

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

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

There are no parameters, so the description has nothing to add. The baseline for 0 parameters is high, and the description does not introduce any confusion.

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

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

The description clearly states the verb 'Read' and the resource 'public settlement evidence', and adds a clarifying statement about what does not count as proof. This distinguishes it from other tools like x402_contract or x402_readiness.

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 does not explicitly indicate when to use this tool versus alternatives. It merely describes what it does without providing selection criteria or 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds 'live' and the explicit guarantee that no payment is initiated, but these are minor beyond what annotations provide.

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

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

Two short sentences, front-loaded with the action and resource, with no wasted words.

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 parameter schema, the description does not explain what the 'readiness surface' returns or how to interpret it. For a zero-parameter read-only tool this is a moderate gap, though the core invocation is clear.

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

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

The input schema defines zero parameters, so there are no parameter semantics to clarify. The description adds no parameter information, but none is needed, matching the baseline for a zero-parameter tool.

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 ('Read') and resource ('live SqueezeOS x402 readiness surface'), clearly distinguishing this from payment-execution tools. The phrase 'No payment is initiated' reinforces that this is a non-transactional status check.

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

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

The description implies the tool is for checking readiness before any payment, and the 'No payment is initiated' note signals safe use. However, it does not explicitly state when to use this tool over sibling tools like x402_contract, x402_evidence, or system_status.

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