catalog-provenance

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

The annotations already establish a safe, idempotent, non-destructive read profile. The description adds meaningful context beyond that: delivery is protected and requires an authenticated subject with an existing purchase entitlement. It does not explain response shape, but the output schema covers that.

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 definition is short and front-loads the protected-interface framing before stating the entitlement constraint. The second sentence is somewhat convoluted, but there is little wasted text.

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 output schema and annotations reduce the burden, but the description still leaves core agent questions unanswered: what exactly is delivered, how approval is determined, and how this tool relates to license lookup or authenticity verification. For a delivery tool with an entitlement gate, that is a significant omission.

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

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

The schema has one parameter, asset_id, with 0% description coverage, and the description never mentions it. There is no added meaning about the identifier format, expected value, or source, so the description fails to compensate 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 calls itself a 'Protected delivery interface,' which gestures at delivering an approved asset but never states the action plainly or names the resource explicitly. It is not a tautology, but it also does not distinguish this tool from siblings like verify_asset_authenticity or lookup_license.

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?

No when-to-use guidance is provided. The entitlement condition reads as a precondition rather than a routing rule, and the description never mentions alternatives or when another sibling should be used instead.

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, non-destructive behavior, so the safety profile is well covered. The description adds the meaningful constraint that protected files are not delivered, which is real behavioral context. However it says nothing about pagination behavior despite a cursor parameter, result limits beyond the schema max, or what a discovery result contains.

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

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

A single tight sentence with no wasted words, front-loading the core action and the key exclusion. It is appropriately sized, though the extreme brevity is also the source of the missing guidance.

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?

An output schema exists, so return-value explanation is not required. But for a paged discovery tool with three parameters (one a cursor) at 0% schema description coverage, and multiple similarly-named search siblings, the description leaves the agent without enough to choose or call it 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?

Schema description coverage is 0%, and the schema only provides types/bounds (query 1–120 chars, limit 1–25 default 10, cursor regex) with no explanation of what query matches (names? text? concepts?) or what cursor points to. The description provides no parameter meaning at all, so it fails to compensate for the coverage 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?

It names a verb+resource (discover assets) and adds a distinguishing scope — policy-filtered approved assets, and explicitly not delivering protected files, which separates it from deliver_approved_asset. But 'discover' is vague about what is actually returned (metadata? listings? previews?) and doesn't tell the agent how results relate to the other search/catalog 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?

It implicitly contrasts with delivery ('without delivering protected files') but gives no positive when-to-use guidance, no statement of when to prefer this over search_catalog or search_concepts, and no prerequisites (e.g., auth/licensing requirements).

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=false, so safety is covered. The description adds one genuinely new trait, 'policy-filtered', signaling results may be withheld or redacted by policy, but it doesn't say what happens on a policy-blocked or nonexistent slug (error vs empty result).

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 sentence, front-loaded with the verb and resource, with no redundant or filler text. Every clause ('policy-filtered', 'by slug') carries meaning.

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?

An output schema exists, so return shape needn't be described, and annotations fully cover the read-only/idempotent profile. The only meaningful omission is the behavior of 'policy-filtered' (redaction, error, or empty result), which is a minor gap for a simple keyed getter.

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 parameter has 0% schema description coverage, but the schema itself supplies a strict pattern and maxLength for the slug. The description identifies the parameter's role as the record key but adds no formatting, casing, or normalization guidance beyond what the schema already enforces, so it does not compensate for the coverage 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 specific verb ('Get') and resource ('concept record') and gives the lookup key ('by slug'), which distinguishes it from the sibling search_concepts by implying a single-record fetch rather than a query. However, it never names search_concepts as the alternative, so the differentiation is implicit rather than explicit.

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

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

Usage is implied by 'by slug' — an agent should call this when it already has an exact slug rather than search terms — but the description never states when to prefer this over search_concepts or what to do when the slug is unknown. No conditions or exclusions are 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 readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the non-obvious semantic boundary that a successful lookup confers no rights, which is useful context not present in structured fields, though it says nothing about failure modes or what 'verified' entails.

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; both clauses earn their place by stating the action and its key limitation.

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?

An output schema exists so return values need not be explained, and the tool is simple with one parameter. However, the description supplies no guidance on identifier format or when to reach for this tool over siblings, leaving the definition minimally viable for its context.

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 required parameter license_id has 0% schema description coverage and the description says nothing about it — not its format, source, or the distinction between the regex pattern constraint and a real license identifier. This is a clear gap for a tool whose only input is the identifier.

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 (Report) and resource (license status), and the clause 'this tool never grants rights' distinguishes it from siblings like deliver_approved_asset that do confer entitlements. It is clear but does not name any sibling, so it falls 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?

There is no guidance on when to call this versus verify_asset_authenticity or the other sibling tools, no prerequisites, and no exclusions. Usage must be inferred entirely from the tool 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, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds only that the catalog is 'current approved', but says nothing about pagination behavior even though a cursor parameter exists, nor about result ordering or limits.

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 with no waste and the resource stated up front, which is good structure. However, it is under-specified for a three-parameter, paginated search tool, so brevity here reads as omission rather than efficiency.

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?

An output schema exists so return values need not be described, but the definition still leaves pagination (cursor), result sizing (limit), and the choice against sibling retrieval tools unexplained. For a search endpoint with three undocumented parameters, this is inadequate.

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

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

Schema description coverage is 0% for all three parameters, so the description carries the full burden and fails: 'query' semantics, the meaning/numbering scheme of the opaque 'cursor', and the 1-25 range of 'limit' are left entirely to the schema's type constraints.

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

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

States a clear verb+resource (Search ... catalog) and adds a scoping qualifier ('current approved ... commercial'), so the agent knows what corpus is being searched. It does not, however, distinguish itself from siblings like search_concepts or discover_assets, leaving the agent to infer which retrieval tool fits.

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 when-to-use guidance, no prerequisites, and never names an alternative such as search_concepts or discover_assets. The agent must guess whether catalog search or concept search is the right entry point for a given query.

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=false, so safety is covered. The description adds the 'approved public' scope constraint, which is genuinely useful, but says nothing about pagination behavior via cursor or result caps.

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 waste. It is appropriately sized but arguably leaves too much unsaid rather than being over-long.

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?

An output schema exists, so return values need not be described, but the tool has three entirely undocumented parameters including a pagination cursor. For a search tool with no param semantics in either schema or description, the definition is under-specified.

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

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

Schema description coverage is 0% with three parameters (query, limit, cursor), so the description carries the full burden and provides none of it. It does not explain that limit caps at 25, that cursor is a numeric pagination token, or any query syntax.

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 (search) and resource (AgentiScript concept summaries) with a qualifier scoping it to approved public content. It is reasonably distinguishable from search_catalog and get_concept, though it does not explicitly contrast itself with them.

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?

No guidance on when to use this over search_catalog or get_concept, and no mention of prerequisites or exclusions. The agent must infer the routing from the name 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?

Annotations already establish the full safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description usefully adds that verification is against a 'signed canonical catalog' (i.e., cryptographic/authoritative rather than best-effort), but says nothing about what a failed verification yields or whether network/auth is involved.

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

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

A single tight sentence with the verb and resource front-loaded and zero filler. Nothing could be removed without losing meaning.

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 an output schema present, return values need not be explained, and the annotations cover safety. For a two-parameter, single-purpose verification tool the description is nearly sufficient; the only real gap is the lack of routing guidance versus the sibling discovery/search tools.

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 the semantic load. It does map both inputs conceptually ("asset identifier or content hash"), clarifying that either asset_id or content_sha256 can be supplied, but the 'or' relationship and the format constraints (the regex patterns) are only inferable from the schema.

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

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

The description names a specific verb ("Verify") and a specific resource ("an AgentiScript asset identifier or content hash") plus the authority it checks against ("the signed canonical catalog"). This clearly distinguishes it from read/list siblings like discover_assets or search_catalog, though it names no sibling explicitly.

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

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

There is no when-to-use or when-not-to-use guidance and no alternative is referenced, despite six siblings that also touch assets. The agent must infer that this is the validation step to run before trusting an asset discovered via discover_assets or search_catalog.

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