CuNi exactness, Chamber two-key JSON, Agent-Rider. Lab signup, agent keys, x402 catalog.
Scored across 42 tools
The many `_get`/`_search` pairs across 14 obscure domains are nearly identical in description, making it hard for an agent to know which domain is relevant or what distinguishes 'get' from 'search.' The retired aware_* aliases alongside pcc_* add further confusion.
There are two clear naming conventions: `domain_get`/`domain_search` pairs for the catalog and an `spl_` prefix for the utility tools. Each group is internally consistent, but mixing suffix and prefix patterns, plus the odd `cuni_bank`, creates an inconsistent overall system.
42 tools is too many for a server that essentially provides catalog lookups and a handful of utilities. Many `_get`/`_search` pairs are templated variations of the same concept, making the set feel bloated rather than well-scoped.
The catalog is covered with lookups for each domain, and the spl_ suite includes paired operations (compress/decompress, zip/unzip, warrant issue/receipt/verify). Minor gaps exist, such as no account management beyond signup and no clear way to browse domains beyond searching, but overall the main workflows are supported.
PCC (AWARE is a retired alias) — one entry with notes, price, and links.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It does disclose the return contents (notes, price, links) and that it returns a single entry, which is useful. However, it says nothing about read-only guarantees, error behavior, authentication, or other potentially relevant behavioral traits.
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 short and front-loaded, but its brevity verges on under-specification. The alias note and the fields list could be valuable, yet the absence of action and parameter guidance makes it concise more due to scarcity than intentional 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?
With no output schema, no annotations, and only a single undocumented required parameter, the description fails to provide the minimal context needed. It briefly explains what came out of the entry but does not cover the required `id`, optional return details, or API behavior, so it is not complete for a real agent 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?
The schema has one required parameter, `id`, with no description (0% coverage), and the tool description never mentions it. An agent cannot infer what the ID represents, its format, or how to obtain it, which is a critical 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 identifies the resource (PCC) and indicates it returns a single entry with notes, price, and links, which distinguishes it from search siblings. However, it never states an explicit verb like 'get' or 'retrieve' and 'PCC' plus the retired alias note make the purpose vague and reliant on the tool's name.
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 the many sibling tools. The singular 'one entry' only implies a get-instead-of-search use case, but no alternative or exclusion is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PCC (AWARE is a retired alias) — what it is, what you get, what you pay. Free text or code.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It indicates the query type and roughly what the result covers, but it does not state whether this is a read-only search, how results are returned, or whether there are any limits or prerequisites.
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 brief and mostly front-loaded with the subject, but it reads as fragmented sentence fragments rather than a clear explanatory statement. It is concise without being fully informative.
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 search tool with no annotations and no output schema, the description should at least clarify return behavior and how q maps to results. It provides superficial context but leaves essential operational details unspecified.
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 bare 'q' string property. 'Free text or code' adds some meaning, but it does not explain requiredness, query format, examples, or edge cases like an empty query.
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 identifies PCC as the subject and hints at the scope ('what it is, what you get, what you pay'), but it lacks an explicit verb like 'search' or 'find'. The tool name supplies the missing action, so the purpose is inferable rather than clearly stated.
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 use this tool instead of the many sibling search tools, such as pcc_search or aware_get. The alias note ('AWARE is a retired alias') is context, not a usage directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Try — one entry with notes, price, and links.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It adds only a hint that the result is a single entry with notes, price, and links, but it does not state that this is a read-only fetch, how errors behave, or what the ID parameter does. This is insufficient behavioral transparency for a tool with zero 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but 'Try — one entry...' is an unclear fragment rather than a disciplined, front-loaded explanation. It omits essential context while including an ambiguous 'Try' preamble that does not earn 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 tool with one required parameter and no output schema, the description should at least connect the id to the returned entry and clarify the operation. It mentions output fields but never says 'get a box by ID,' leaving the agent to rely on the tool name and schema. This is not complete enough for confident 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?
There is exactly one required parameter, id, with 0% schema description coverage. The description never mentions id, how it is used, or how it relates to the returned entry, so it fails to compensate for the missing schema documentation.
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 says 'one entry with notes, price, and links,' which conveys singular retrieval and some expected output fields, but it uses the vague verb 'Try' and never explicitly names the resource as a 'box' or says 'get by ID.' It is not a clear, specific verb-plus-resource statement, so it stays at the vague-purpose level.
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 about when to use this tool instead of alternatives such as box_search. The phrase 'one entry' weakly implies a single-record lookup, but the description never explains the distinction between get and search or indicates that an ID is the selection mechanism.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Try — what it is, what you get, what you pay. Free text or code.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided and the description discloses no behavioral traits. It does not say whether this is a read-only operation, what inputs are accepted beyond a vague 'free text or code,' what output to expect, or any side effects or limitations.
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 short, but brevity is not the issue—it is under-specification. The opening phrase 'Try — what it is, what you get, what you pay' is promotional filler that earns no place in a tool definition. Nothing useful is communicated.
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?
Despite having only one parameter and no output schema, the description is still completely inadequate. An agent cannot determine the operation's purpose, result, or relationship to the many sibling tools. This is a minimal-viability failure.
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 q has zero schema description coverage. The only hint is 'Free text or code,' which could suggest that q accepts free text or code strings, but it is ambiguous and does not clarify format, constraints, or semantics. This falls far short of compensating for the complete lack of schema documentation.
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 'Try — what it is, what you get, what you pay. Free text or code.' contains no verb or resource. It reads as a marketing tagline, not a functional tool description. The tool name box_search implies a search operation, but the description never states what is searched, what is returned, or how it differs from sibling search 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?
There is no guidance about when to use box_search versus alternatives such as chamber_search, docs_search, or any of the other sibling *_search tools. The description does not mention any conditions, exclusions, or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Chamber — one entry with notes, price, and links.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only hints at returned data fields and does not clarify whether this is a read-only operation, what happens for an unknown ID, or any other behavioral characteristics.
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 very short and front-loaded, with no filler or redundant wording. It loses points only because its brevity sacrifices necessary semantic content.
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?
Although the tool is simple, the description does not provide enough context for correct invocation. It omits how the ID relates to the resource, when to use this tool instead of chamber_search, and what the response actually contains beyond vague field names.
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 description does not mention the 'id' parameter at all. The parameter name alone suggests an identifier, but the description adds no meaning about ID format, source, or how it selects the chamber entry.
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 identifies the resource as 'Chamber' and suggests a single entry, but it lacks an explicit verb such as 'retrieves' or 'gets by ID.' It only weakly differentiates itself from chamber_search.
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 is given about when to call chamber_get versus chamber_search or any other sibling. The 'one entry' phrasing implies a single-record lookup, but this is not stated as an explicit usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Chamber — what it is, what you get, what you pay. Free text or code.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden, but it states nothing about side effects, safety, permissions, rate limits, or what a successful search actually returns. The phrase 'what you pay' is the only behavioral hint and it is ambiguous.
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 short and front-loaded, but brevity here comes from under-specification rather than efficient delivery of useful information. It is a slogan, not a structured tool description.
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?
Despite a simple one-parameter schema, the description is not complete: it omits the tool's actual purpose, return behavior, and relationship to chamber_get and sibling search tools, and there is no output schema to compensate.
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 only documents q as an optional string, and schema description coverage is 0%. The description's 'Free text or code' adds minimal meaning to q, but it is too vague to tell an agent what kinds of queries are valid or how to format them.
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 'Chamber — what it is, what you get, what you pay' gestures at an informational search tool but never names a verb, a resource, or a clear operation. It does not distinguish chamber_search from chamber_get or any sibling.
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 about when to use this tool instead of chamber_get or the other *_search tools. 'Free text or code' hints at input format, not a selection criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CuNi Bank: paste N, get X. Ingest → emit → prove, or refuse. v1 from Python. Args: source, from (py|cuni), to (catalog id, e.g. js). POSTs to cuni-studio /api/bank.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | catalog id: py, go, js, ts, … | |
| from | No | py | cuni | |
| source | Yes | Source program (Python v1 subset or .cuni) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does add real context not in the schema: the operation POSTs to a remote endpoint (cuni-studio /api/bank) and may 'refuse', implying validation. However, it omits auth requirements, side effects, and reversibility.
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 text is short but the front-loaded metaphor ('paste N, get X', 'Ingest → emit → prove, or refuse') consumes space without conveying usable meaning, so it is not well-structured or front-loaded with the actual 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?
There is no output schema and no annotations, so the description must explain inputs and outputs. It never describes the result of the transform, what 'prove' returns, or failure modes, leaving the agent without enough to call it 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?
Schema description coverage is 100%, so the baseline is 3. The description repeats the arg names with brief glosses (py|cuni, catalog id e.g. js) that roughly match the schema, adding no syntax or format detail beyond it.
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 tagline 'paste N, get X' and 'Ingest → emit → prove, or refuse' are cryptic metaphors that never state plainly what the tool converts or produces. The args hint at a Python-to-catalog-language transform, but the agent must infer that, and the tool is not distinguished from siblings like cuni_get/cuni_search.
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 statement of when to use this tool versus cuni_get, cuni_search, or any other sibling. 'v1 from Python' implies a version/scope but no explicit 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.
CuNi — one entry with notes, price, and links.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that an entry includes notes, price, and links, which hints at the return payload, but it says nothing about read-only guarantees, error behavior, missing IDs, authentication, or response shape. The 'get' in the tool name implies a safe read, but that is not from the description.
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 extremely short with no filler words, and the em-dash structure front-loads the resource name. However, it is a sentence fragment rather than a complete instruction, and the brevity sacrifices essential information, making it more under-specified than genuinely concise.
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 get-by-id tool with no output schema and no annotations, the description should at least state that it fetches the entry matching the `id` and describe the returned structure. It only says 'one entry with notes, price, and links', which is incomplete: no mention of the ID parameter's role, not-found behavior, or usage 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?
Schema description coverage is 0%, so the description must compensate for the undocumented `id` parameter. It never explicitly connects `id` to the 'one entry' concept, nor does it state that `id` selects which entry to retrieve. The only parameter is effectively undocumented.
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 identifies the resource (a CuNi entry) and mentions its content fields (notes, price, links), and the 'one entry' phrasing implies single-record retrieval. However, it lacks an explicit verb like 'get' or 'fetch', and does not clearly distinguish itself from cuni_search beyond implying a single entry rather than a search result.
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 provides no guidance on when to use this tool versus cuni_search or any other sibling. It does not mention that an ID is needed to fetch a specific entry, nor does it indicate when to prefer the search alternative. The only hint is the required `id` parameter in the schema, which is outside the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CuNi — what it is, what you get, what you pay. Free text or code.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it reveals almost nothing about behavior: no return format, no scope of results, no cost implications despite mentioning 'what you pay,' and no read/write indication. The only behavioral hint is that input can be free text or code.
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 short, but brevity comes at the cost of substance. The first sentence is a vague tagline that earns no functional value, and the second is a sparse hint. It is under-specified rather than efficiently concise.
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?
Although the tool has only one optional parameter and no output schema, the description still fails to explain what cuni_search searches, what domain it covers, or what the results look like. With 0% schema coverage and no annotations, this is far from a complete callable contract.
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 lone parameter 'q' is only documented as a string. The description adds minimal meaning by saying 'Free text or code,' suggesting q accepts natural language or code snippets, but it does not explain what kinds of queries are valid or what the parameter represents beyond that.
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 the topic (CuNi) and implies a search, but never states a clear verb+resource relationship like 'search CuNi information.' The phrasing 'what it is, what you get, what you pay' is promotional rather than functional, and it does not distinguish cuni_search from the many sibling _search 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 phrase 'Free text or code' gives a hint that the query can be natural language or code, but there is no guidance on when to use cuni_search versus cuni_get or any other sibling. No exclusions, alternatives, or preconditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Docs — one entry with notes, price, and links.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral disclosure burden. It implies a read operation only through the tool name and describes output fields, but it does not explicitly state that the tool returns an entry by id, what happens when the id is not found, or any other runtime behavior.
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 very short, front-loaded, and free of filler. It sacrifices completeness for brevity, but every word earns its place in conveying the resource and basic return shape.
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 one-parameter getter, the description combined with the id schema is minimally usable. However, the missing explicit retrieval statement, usage guidance, and id semantics leave meaningful gaps, especially given that no annotations or output schema are present.
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 description does not mention the id parameter at all beyond associating the tool with a single entry. The id's meaning, source, and format are left entirely to the agent's inference from the parameter name.
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 identifies the resource ('Docs') and indicates singular scope ('one entry'), which makes the get-vs-search distinction inferable from the sibling docs_search. However, it is a noun phrase rather than an explicit verb statement, so it stops short of the clarity of a full retrieval description.
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 docs_search or the other getter tools. It also does not mention how to obtain the required id, such as searching first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Docs — what it is, what you get, what you pay. Free text or code.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not indicate that the tool is a read-only search, what kind of results it returns, whether it returns snippets or links, or any limitations. The only behavioral hint is that the query can be free text or code.
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 very short and scannable, with no filler. The first phrase introduces the domain, and the second gives the key input clue. It is concise, though the brevity comes at the cost of 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?
For a tool with no output schema, no annotations, and an undocumented parameter, the description is too incomplete. It does not explain what results the agent should expect, how the docs are scoped, or how this search differs from docs_get and other sibling searches. The agent would likely need to invoke it speculatively to learn its behavior.
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 provides zero description for the single 'q' parameter, and the description only adds 'Free text or code.' This gives a general sense that q accepts natural language or code, but it does not explain format, examples, optionality, or any constraints. With 0% schema coverage, the description should compensate much more.
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 reads as a tagline ('Docs — what it is, what you get, what you pay') rather than a statement of what the tool does. It never explicitly says 'search' or 'retrieve', and it does not distinguish docs_search from the sibling docs_get. The resource is named, but the action is only implied by the tool name.
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 use this tool versus alternatives. The sibling set includes many search tools and docs_get, but the description does not mention any of them or give conditions for choosing this one. 'Free text or code' only hints at input format, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
License — one entry with notes, price, and links.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It only says what a license contains and that one entry is returned; it does not state that the tool performs a read by id, what happens for a missing id, or any other behavioral traits.
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 short and front-loaded, but its opening word 'License' repeats the tool name and the fragment omits the action. It is concise to the point of being telegraphic rather than appropriately structured.
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 one-parameter get tool with no output schema and no annotations, the description is too thin. It does not explain how to use the id, what the returned entry represents, or what state transitions or errors might occur, leaving an agent to guess.
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 description does not mention the required id parameter or explain its meaning. It adds no value over the bare schema field 'id' and 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?
The description identifies the resource as a license and notes it returns one entry with notes, price, and links, but it never states an action verb such as 'get' or 'retrieve.' This makes the purpose inferable from the tool name and singular phrasing rather than clearly specified, and it only weakly distinguishes from license_search.
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 about when to use license_get versus license_search or other sibling tools. The singular 'one entry' implies a lookup by id, but no explicit condition, alternative, or exclusion is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
License — what it is, what you get, what you pay. Free text or code.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure burden, but it only loosely mentions what the user 'gets' and 'pays.' It does not clarify whether this is a read-only lookup, whether it returns a list or a single item, or whether there are any side effects, rate limits, or dependencies.
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 short and front-loaded, which is good, but it reads more like a marketing tagline than a functional tool description. The dashes and fragmented phrasing are concise but sacrifice clarity and completeness.
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 annotations, no output schema, and only a vague description, important context is missing: return format, pagination, error behavior, pricing implications, and when to choose the search variant over the get variant. The description is minimally adequate for a single-parameter tool but leaves significant gaps.
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 provides only a bare 'q' string with 0% description coverage, so the description must compensate. 'Free text or code' adds basic meaning to the q parameter, but it lacks examples, format hints, or clarification of what kinds of codes are accepted.
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 identifies the resource (License) and suggests a free-text/code query mode, but it never states an explicit action verb like 'search' and relies heavily on the tool name for meaning. The phrase 'what it is, what you get, what you pay' hints at output content but is vague about what the tool actually does.
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 license_search versus license_get or any other sibling tool. 'Free text or code' implies an unstructured query use case, but no comparative context or exclusion is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How pulsar compares — one entry with notes, price, and links.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only hints at output content (notes, price, links) and does not state whether the operation is read-only, requires authentication, or has side effects. For a get tool this is a meaningful omission.
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 very short, but it is under-specified rather than concise. It lacks a sentence structure that conveys a complete thought about what the tool does, sacrificing clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no parameter descriptions, the description needs to explain what 'one entry' means, what 'pulsar' refers to, and how 'id' relates to the result. It only lists three fields, leaving key context missing for a tool with a single required parameter.
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 required 'id' parameter with no description and 0% schema description coverage. The description never mentions the parameter or explains what kind of ID is expected or how it selects the entry. It adds no semantic value for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'How pulsar compares — one entry with notes, price, and links' does not clearly state a verb or action. It reads as a subtitle about content rather than an explanation that this tool retrieves a measure by ID. The tool name suggests 'get', but the description fails to establish that.
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 is provided about when to use this tool versus alternatives like measure_search or pulsar_get. There is no mention of use cases, prerequisites, or exclusions, leaving selection entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How pulsar compares — what it is, what you get, what you pay. Free text or code.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses what the results are about ('what it is, what you get, what you pay') and input style ('Free text or code'), but it does not describe output format, scope, limitations, or whether this is strictly a read/search operation.
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 concise and easy to scan, using one short sentence plus a brief input hint. It avoids filler and clearly front-loads the core value proposition, though the phrasing is more promotional than operational.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter search tool with no output schema and no annotations, the description gives some context about content areas but omits essential selection cues. It does not explain what a typical result looks like, how to distinguish it from sibling tools, or what 'code' input entails, leaving an agent under-informed.
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 provides only a string parameter 'q' with no description, and schema description coverage is 0%. The description adds some meaning by saying 'Free text or code,' which tells the agent that q accepts natural language or code snippets, but it stops short of providing examples, constraints, or expected format.
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 conveys the topic ('How pulsar compares — what it is, what you get, what you pay') and indicates input flexibility ('Free text or code'), but it lacks a clear verb and resource. It does not explicitly state that this tool searches or returns comparison information, and the 'pulsar' focus could be confused with sibling tools like pulsar_search.
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 is given about when to use measure_search versus alternatives such as measure_get or pulsar_search. The only implied context is 'pulsar compares,' which is too indirect to help an agent choose among the many sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
npm / public packages — one entry with notes, price, and links.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It does disclose the return contents ('notes, price, and links'), which is useful, but it does not mention behavior around missing IDs, errors, authentication, or response format beyond those fields.
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 fragment with no wasted words. It communicates the resource and the core output in a compact and scannable way.
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?
There are no annotations and no output schema, so the description is the main source of context. It omits important details about what 'id' means, how to construct a valid request, and what the full response looks like, making it incomplete for confident 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%, and the description does not explain what the required 'id' parameter represents or in what format it should be provided. The tool name and resource hint that 'id' identifies a package, but this is inferred rather than stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as 'npm / public packages' and indicates this is a retrieval of a single entry ('one entry'), which distinguishes it from the search siblings. However, it does not explicitly state that it retrieves by ID or contrast itself with npm_search.
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 is given about when to use this tool versus npm_search or the other search tools. The sibling naming pattern implies a get/search split, but the description itself does not state when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
npm / public packages — what it is, what you get, what you pay. Free text or code.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It offers only the tagline 'what it is, what you get, what you pay' and 'free text or code,' which vaguely suggests a result list, but does not explain search semantics, return shape, read-only behavior, or any limitations. This is minimal behavioral information.
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 very short and front-loaded with the resource name. However, brevity crosses into under-specification: the tagline 'what it is, what you get, what you pay' is catchy but not informative enough to replace structured 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?
For a simple one-parameter search tool, the description is nearly complete on input but not on output or selection context. It lacks return-value semantics, how results relate to npm_get, and any search behavior details. Given the sibling get/search pattern, more context is needed for correct tool selection.
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 has a single undocumented 'q' parameter with 0% description coverage, so the description's 'Free text or code' is the only clue to query semantics. It adds some meaning beyond the bare schema, but it omits examples, accepted formats, and whether q is a package name, keyword, or code fragment.
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 identifies the resource as 'npm / public packages' and hints that the query is 'free text or code,' which conveys the package-search domain. However, it never states an explicit verb such as 'search' or 'find,' and it does not differentiate this tool from the sibling npm_get. The purpose is inferable from the name but not clearly specified.
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 use npm_search instead of npm_get or the many other *_search siblings. The description does not mention whether to use this tool for discovery before fetching details, nor any exclusion or alternative. An agent must infer usage from naming conventions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PCC — one entry with notes, price, and links. Prefer this. aware_get is a retired alias.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It mentions the returned fields but does not say whether the operation is read-only, what the response format is, whether errors can occur, or how the id is used. This is a minimal description that reveals output content but almost no behavior.
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 very short, front-loaded with the core meaning, and contains no filler. The alias note is relevant for tool selection)Skip. Every sentence serves a 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?
For a single-parameter getter with no output schema and no annotations, the description is serviceable but not complete. It gives the main return fields and a routing hint, but it omits what PCC means, what id refers to, and any behavioral or error expectations. An agent could probably call it correctly, but only with reasonable inference rather than explicit guidance.
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 description does not mention the id parameter at all. The schema only says id is a required string, so the agent must infer that id identifies the PCC entry. 'One entry' hints at a lookup-by-id operation, but the description adds no real semantic value beyond 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 states that the tool returns 'one entry with notes, price, and links,' which conveys the resource and result shape. It does not use an explicit verb like 'get' or 'fetch,' but the tool name pcc_get plus the contrast with aware_get make the purpose reasonably clear. It also distinguishes itself from the search siblings by emphasizing a single entry.
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 tells the agent to 'Prefer this' and notes that aware_get is a retired alias, which is useful routing guidance. However, it does not explain when to choose pcc_get over pcc_search or other getters. The guidance is implied by the name and sibling patterns but not stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PCC — what it is, what you get, what you pay. Free text or code. Prefer this. aware_search is a retired alias.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It hints at output ('what you get, what you pay') and input flexibility ('Free text or code'), but never states whether this is read-only, whether auth is required, what the response format is, or any other side effects or limitations.
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 very short, but its core phrase is cryptic rather than clear and lacks a proper sentence structure. It is under-specified more than efficiently concise, and the fragment format adds confusion rather than 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?
For a one-parameter tool with no output schema and no annotations, the description should clarify return values and usage context. It only offers vague allusions to what PCC is and what you get, leaving the actual output format, scope, and relationship to pcc_get or other search tools unexplained.
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 only defines q as a string with no description, so schema coverage is 0%. The description adds meaningful semantics by stating 'Free text or code', indicating the q parameter accepts natural language or code input. However, it does not provide examples or clarify expected query format beyond that.
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 is a slogan-like fragment — 'PCC — what it is, what you get, what you pay' — with no explicit verb or defined resource. It does not clearly state that this tool searches PCC-related information, and it only distinguishes itself from the retired aware_search, not from active siblings like pcc_get.
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?
'Prefer this' and 'aware_search is a retired alias' give a clear migration directive and imply this is the preferred alias. However, it does not explain when to use this tool versus alternative search tools or pcc_get, and provides no exclusionary conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pulsar — one entry with notes, price, and links.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals the returned entry contains notes, price, and links, but it does not state that the operation is read-only, what happens when the id is not found, or any other behavioral traits. This is a partial but minimal disclosure.
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 very short and contains no filler, but it is a fragment ('pulsar — ...') rather than a complete instruction. It conveys some detail about the response content but omits crucial information such as the id parameter, making it under-specified rather than effectively concise.
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 get tool with one parameter and no output schema, the description is not complete enough. It fails to explain the input, the action, or how pulsar_get differs from pulsar_search, leaving an agent to infer the tool's purpose from its name and sibling 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 schema has one required string parameter 'id' with 0% description coverage, and the description never mentions this parameter or how to identify the entry. 'One entry' is too vague to tell an agent that an id must be supplied or what it represents.
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 the resource ('pulsar') and hints at a singular result ('one entry with notes, price, and links'), but it never uses an explicit verb like 'get' or 'retrieve.' The tool name supplies the action, yet the description does not clearly distinguish this from the sibling pulsar_search.
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 is provided about when to use pulsar_get versus pulsar_search or any other sibling. The description does not state that this is the right tool when an id is known, nor does it mention that search is available for querying.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pulsar — what it is, what you get, what you pay. Free text or code.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the input can be free text or code and hints at result content, but it does not explain how results are returned, whether there are limits, how matching works, or what 'what you get' actually 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?
The description is very short and has no wasted verbiage, but it is cryptic and under-specified. It reads more like a tagline than a structured tool description for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should explain what the search returns and how to use q effectively. It does neither clearly, leaving an agent to guess at the response shape, query interpretation, and relationship to the many sibling 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?
The schema only defines q as a string with no description, so coverage is 0%. The description adds some meaning by saying the query accepts free text or code, which goes beyond an empty schema. However, it does not clarify format, behavior with no q, or result semantics.
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 identifies the resource ('pulsar') and suggests the content it covers ('what it is, what you get, what you pay'), which gives a vague sense of purpose. However, it never explicitly states the search behavior, and it does not distinguish this tool from siblings like pulsar_get or other *_search 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?
'Free text or code' gives a minimal hint that the query can be natural language or code, but there is no guidance about when to use pulsar_search versus pulsar_get or other searches. No exclusions, alternatives, or contexts are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How to pay — one entry with notes, price, and links.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining behavior. It hints that the result has notes, price, and links, but it does not describe read-only semantics, potential errors, authentication needs, or any other behavioral traits.
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 very short, but it is under-specified rather than effectively concise. 'How to pay' is not a clear tool-oriented phrase, and the single sentence omits critical structural information about what the tool does.
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 one required parameter, no output schema, and no annotations, the description needed to explain the tool's purpose, the meaning of id, and what a successful response looks like. It provides almost none of this, making it inadequate for correct tool selection and 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?
The schema has one required parameter 'id' with 0% description coverage, and the tool description never mentions id or what it represents. The description provides no guidance about how to supply or obtain the id, which is essential for calling the tool correctly.
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 says only 'How to pay — one entry with notes, price, and links.' It does not state a clear verb and resource such as 'retrieve a rail entry by ID.' The content is vague and does not distinguish this tool from rail_search or the many other X_get 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?
There is no explanation of when to use rail_get versus rail_search or any alternative. The phrase 'one entry' weakly implies retrieval of a single item, but no explicit when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How to pay — what it is, what you get, what you pay. Free text or code.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether the tool reads data, mutates anything, returns matches, or how it behaves. It is effectively content-free on behavior.
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 text is short, but brevity here is under-specification rather than conciseness. The opening phrase is a confusing headline, and the fragment 'Free text or code' does little to structure or clarify 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?
Even for a simple one-parameter search tool, the description omits the core information needed to invoke it correctly: what is being searched, what input is expected, and what result the agent will get. An agent cannot reliably select or use this tool.
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 only says q is a string with 0% coverage. The phrase 'Free text or code' offers minimal guidance on input format, but it does not explain what q should contain, what kind of search is performed, or how the query is interpreted.
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 never states a verb or resource: 'How to pay — what it is, what you get, what you pay' reads as unrelated payment guidance rather than a search tool. It does not mention searching, rail data, or the q parameter, and it is misleading relative to the tool name rail_search.
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 is given for when to use rail_search versus rail_get or any sibling search tool. The lone hint about paying provides no decision criteria, so an agent cannot determine appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Agent-Rider — one entry with notes, price, and links.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contributes useful output context: the result is a single entry and it contains notes, price, and links, which is valuable because there is no output schema. It does not explicitly confirm read-only behavior or describe missing-ID/error behavior, but the `get` name and 'one entry' imply a simple lookup.
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 text is short and has no filler, so it is concise in length. However, it is a sentence fragment with no action verb, and the 'Agent-Rider' prefix mostly restates the tool's domain; a front-loaded sentence like 'Gets one Agent-Rider entry by ID, including notes, price, and links' would be clearer without being longer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with no nested objects, the schema plus description is nearly sufficient: the schema provides the required `id`, and the description indicates that the result is a single entry with notes, price, and links. It is not fully complete because it omits an explicit by-ID lookup statement and any error or return-format expectations, but the low complexity limits the impact.
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 required `id` parameter has 0% schema description coverage, and the tool description never explains that `id` is the identifier of the Agent-Rider entry or what format it should take. The agent is left to infer the parameter meaning from the name alone, and the description does not compensate for the missing schema documentation.
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 identifies the resource (Agent-Rider) and says it concerns 'one entry,' which strongly implies a single-entity retrieval operation, especially with the `_get` tool name. However, it never uses an explicit verb like 'gets' or 'retrieves,' and it does not clearly distinguish itself from sibling `_search` tools beyond the singular wording.
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 about when to use `rider_get` versus `rider_search` or other `_get` tools. The description does not say 'use this when you have an ID' or name alternatives, so the agent must infer usage entirely from naming conventions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Agent-Rider — what it is, what you get, what you pay. Free text or code.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It weakly implies an informational/pricing result and that the input can be text or code, but it does not state whether the tool returns a list, performs lookups, requires authentication, or has any side effects.
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 short and front-loads the product name with no filler, which is good. However, it reads more like a tagline than a tool specification, and the brevity sacrifices the operational clarity an agent needs.
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 annotations, no output schema, and zero schema description coverage, the description is the only context and it is incomplete. It never explains the query scope, return shape, or relationship to rider_get, leaving an agent to guess whether to pass a plan name, a code snippet, or a natural-language question.
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 only exposes a string parameter named 'q' with no description, and schema coverage is 0%. The description adds some meaning by saying the query can be 'free text or code,' but it leaves unclear how the text is matched or what the query should target.
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 identifies a resource ('Agent-Rider') and hints at content ('what it is, what you get, what you pay'), but it never states a clear verb or operation. 'Free text or code' suggests a search/query tool, yet the description does not explicitly say what the tool does or how it differs from rider_get.
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 about when to use rider_search instead of rider_get or other sibling tools. 'Free text or code' is a clue about the query format, not a use-case condition, so the agent receives no selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prices — one entry with notes, price, and links.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only lists output fields (notes, price, links) and cardinality (one entry). It does not state that the operation is read-only, how it behaves on missing IDs, or what other side effects may exist.
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 text is very short, but this is under-specification rather than effective conciseness. It reads like a label, not a structured tool definition, and no context is front-loaded beyond the noun 'Prices.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool the definition is simple, but it is still incomplete: it lacks a verb, does not tie 'id' to the entry being fetched, and does not explain the relationship between the SKU and the returned entry. The description needs at least one complete sentence describing the lookup and return value.
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 description never mentions the required 'id' parameter. With no meaning added beyond the bare string type, the agent gets no help on how to fill the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a resource ('Prices') and says the tool provides a single entry with notes, price, and links, which suggests a get-by-id operation. However, it lacks an explicit verb and does not clearly state that it retrieves the price entry for a given SKU, so it stays at the vague-purpose level.
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 about when to use sku_get versus sku_search or any other sibling tool. 'One entry' loosely implies a singular lookup, but there is no explicit context, prerequisite, or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prices — what it is, what you get, what you pay. Free text or code.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only hints that results surface price-related details such as what the item is and what is included, but it does not state whether the operation is read-only, what fields are returned, how matching behaves, or any limitations.
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 short and front-loaded, with no filler. The first phrase signals domain and scope, and the second phrase gives basic input guidance. However, the cryptic style reduces clarity even though the structure itself is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no usage guidance, this description is too thin to fully support correct tool selection and invocation. It works for a very simple read-only search, but it does not distinguish sku_search from many similar search siblings or explain what the returned price information looks like.
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 only defines q as an optional string with no further explanation. The description adds some meaning by stating that q accepts free text or code, which is useful but still vague; there are no examples, format expectations, or clarification of what kinds of codes are valid.
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 communicates that the tool is about prices and accepts free text or code, but it never explicitly states the action or resource. The verb search is only implied by the tool name, and the tagline-style phrasing leaves room for ambiguity about whether this returns price lists, cost breakdowns, or records.
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 is given about when to use sku_search versus sku_get or the many other sibling search tools. The description does not name alternatives, exclusion conditions, or suggested workflows, so an agent must infer usage context from the tool name and vague price phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mint an agent API key (no password).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It conveys only that an agent API key is created without a password; it does not disclose expiry, return format, privileges, or side effects. This is minimal behavioral disclosure for a credential-minting operation.
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. The essential qualifier '(no password)' earns its place by clarifying the authentication style.
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 parameters and no output schema, there is little to document, making this a minimally viable description. However, it omits any mention of prerequisites or what the caller receives in return, so the overall context is thin.
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 has zero parameters, so the description is not required to explain parameter details. The note '(no password)' usefully reinforces that no credential input is needed, matching the empty 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 uses a specific verb ('Mint') with a clear resource ('agent API key') and adds a clarifying qualifier ('no password'). It does not explicitly name or differentiate from sibling tools like spl_signup or spl_lab_auth, 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?
There is no guidance on when to use this tool versus alternatives such as spl_signup or spl_lab_auth. The parenthetical '(no password)' hints at a use case, but no explicit when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Standing SKUs agents can buy via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the tool's purpose but reveals no behavioral traits: no mention of read-only nature, no side effects, no authentication requirements, no rate limits, or what the output looks like. The description adds no value beyond the bare statement.
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 extremely concise (one short sentence), but this is under-specification rather than effective conciseness. It fails to convey critical usage context. While it is front-loaded with the core purpose, it omits necessary behavioral and usage details, so it does not earn its place as sufficient.
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 parameters, no output schema, and low complexity, the description should at least indicate what the catalog contains and how to interpret it. It only states what 'standing SKUs' are, but does not mention return format, pagination, or any interaction details. This is inadequate for an agent to confidently invoke the tool and process the result.
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 the schema has additionalProperties: true. Per the baseline rule for 0 params, a score of 4 is appropriate because there are no parameters to document. The description doesn't add parameter information, but none is needed. The schema's allowance for additional properties is not addressed but is not a required disclosure.
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 resource (standing SKUs) and an implied action (listing/cataloging for purchase via x402). It distinguishes from siblings like sku_get/sku_search by focusing on the catalog nature rather than retrieval of a single SKU. However, it lacks an explicit verb like 'list' or 'retrieve', so it's not a perfect 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?
No guidance is provided on when to use this tool versus alternatives such as sku_search or sku_get. There is no mention of context, exclusions, or preferred scenarios. The description is purely informational with no directional advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hosted lossless compression. Every dual-licensed pathway on this machine. Args: data_b64.
| Name | Required | Description | Default |
|---|---|---|---|
| data_b64 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It adds the useful traits 'hosted' and 'lossless,' but it does not mention what the tool returns, whether it mutates anything, what permissions are needed, or any side effects. The vague 'Every dual-licensed pathway' sentence does not meaningfully disclose behavior.
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 short, but shortness is not conciseness when key information is missing. 'Every dual-licensed pathway on this machine' does not earn its place, and the description fails to front-load the essential information an agent needs, such as what data_b64 means and what output to expect.
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?
Even though the tool has only one parameter and no output schema, the description is incomplete. An agent cannot tell what to pass in, what the output will be, or how this differs from sibling compression/zipping tools. The description needs at least a sentence clarifying the input-output contract.
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 lack of parameter documentation. It only repeats the parameter name 'data_b64' in 'Args: data_b64' without explaining what data should be supplied, its format, encoding requirements, or how it relates to the compression behavior. This adds no value beyond 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 states the core action ('Hosted lossless compression') and clearly indicates a compression tool. However, the phrase 'Every dual-licensed pathway on this machine' is cryptic domain jargon that does not clarify what the tool operates on, and it does not distinguish this tool from siblings like spl_zip, which may also perform compression.
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 instead of spl_zip, spl_decompress, or other siblings. There are no conditionals, no alternatives named, and no context about the intended use case beyond the word 'compression,' which is implied by the tool name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restore bytes packed by spl_compress. Args: packed_b64.
| Name | Required | Description | Default |
|---|---|---|---|
| packed_b64 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Restore bytes' and does not disclose the output type, whether the operation is reversible, error behavior, or any side effects. The agent is left without behavioral expectations beyond the basic action.
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 appropriately short and front-loads the core purpose. The 'Args: packed_b64' clause is somewhat redundant with the schema, but it is harmless and keeps the essential information visible without unnecessary padding.
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 annotations and no output schema, the description is too sparse. It does not explain what the output looks like, whether it returns a string or binary data, or how errors are surfaced. An agent would need more context to confidently use the tool across varied situations.
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 has 0% description coverage, so the description must explain packed_b64. It merely repeats the parameter name and implies it is 'packed' data from spl_compress, but does not state that it is a base64-encoded string, what format is expected, or how it relates to the output. This is only a minimal improvement over the raw 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 uses a specific verb ('Restore') and a clear resource ('bytes packed by spl_compress'), making the decompression action unambiguous. By naming spl_compress, it actively distinguishes this tool from its sibling and indicates the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly establishes the context: use this tool when dealing with data produced by spl_compress. It does not explicitly list alternatives or exclusion conditions, but the inverse relationship with spl_compress is a clear enough usage signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lead product, cash product, auth, MCP, x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, and it reveals nothing about side effects, output, access requirements, or read/write behavior. The phrase is just a noun list, not a statement of what happens when the tool is invoked.
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 short, but conciseness here is under-specification rather than efficient structure. It is a fragment that does not communicate what an agent needs to decide, so the single sentence does not earn 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?
There are no annotations and no output schema, so the description must fully explain the tool's behavior and return value. It fails to explain what the tool does, returns, or requires, leaving the agent unable to correctly invoke or interpret it.
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 zero properties and 100% schema coverage, so there are no parameters for the description to document. The baseline for a zero-parameter tool is 4, and the description adds no parameter information because none is needed.
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 offers a list of content areas ('Lead product, cash product, auth, MCP, x402') that vaguely suggests what the tool covers, but it never states a verb or what action the tool performs. The tool name implies 'discover', but the description alone does not establish a clear purpose or differentiate it from siblings like spl_catalog or spl_lab_auth.
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 is given on when to call this tool versus alternatives. Sibling tools are not referenced, and no conditions, exclusions, or use-case context are supplied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How to mint a lab account or agent API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It hints at creating or issuing auth material, but does not state side effects, permissions required, whether credentials are returned or stored, or whether this is actual execution or a how-to guide.
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 concise sentence with no filler. It is front-loaded with the core purpose, though the 'How to' phrasing is slightly ambiguous and could be more direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no usage guidance, the description is too thin for confident invocation. It leaves open whether the tool creates credentials, returns instructions, or requires prerequisites, which an agent would need to know.
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 baseline is 4. The description does not need to document parameter behavior, and the schema provides no additional parameter semantics to miss.
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 action ('mint') and resource ('lab account or agent API key'), so an agent can tell what the tool is about. However, it does not differentiate from siblings like spl_agent_key or spl_signup, which likely cover related authentication and account workflows.
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 use this tool versus alternatives such as spl_agent_key or spl_signup. The description implies a workflow for issuing credentials but does not state exclusions or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suite quote. First 2 GB/month free, then 8¢/GB, $1 card minimum. Args: bytes, product, op.
| Name | Required | Description | Default |
|---|---|---|---|
| op | No | compress | decompress | roundtrip | |
| bytes | No | Payload bytes. first 2 GB/month free. | |
| product | No | auto | zrw | blackjack | shard-zip | shard-tsdb | slid-phi | |
| dataClass | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It does add meaningful context by disclosing pricing tiers and the card minimum, but it does not disclose whether the tool only computes an estimate, whether any state changes occur, or what the response 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?
The description is short and front-loads the key pricing detail, but it wastes the opening 'Suite quote' on a near-tautology and uses an 'Args:' list that largely duplicates schema information. It is compact but not optimally informative.
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 four parameters, no annotations, no output schema, and many sibling tools, the description leaves critical gaps: it never states the return value (presumably a quote), how the quote is computed for a product/op, or what dataClass influences. An agent cannot confidently invoke this tool correctly from the description alone.
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 75%, so the schema already documents op, bytes, and product. The description adds the '8¢/GB' rate and '$1 card minimum' to bytes, which is useful, but it repeats parameter names without adding new meaning and leaves dataClass entirely unexplained.
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 communicates that this is a cost/pricing quote, reinforced by pricing details ('First 2 GB/month free, then 8¢/GB'). However, it does not state an explicit verb or what the quote is for, and it does not distinguish itself from sibling tools such as spl_compress or spl_discover.
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 is given about when to call spl_quote versus alternatives. With many spl_* siblings (compress, decompress, zip, unzip, catalog, discover), an agent would have no basis for choosing this tool over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a human lab account (email + password).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It only states the creation intent and credential type, but does not disclose what happens upon success (e.g., auto-login, verification email), any permission requirements, rate limits, or whether the operation is idempotent. For a mutation tool with zero annotation coverage, this is a significant gap.
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 core action, resource, and credential type. No filler words; every part earns its place. It is appropriately sized for the tool's simplicity.
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?
Despite the simple tool surface, an agent lacks critical invocation details: the exact JSON field names for 'email' and 'password', whether both are required, any password validation rules, and the expected response shape (since no output schema exists). The empty input schema with additionalProperties true puts the burden on the description to supply structure, which it only partially does.
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 has no properties and additionalProperties: true, so it provides no parameter meaning. The description compensates by specifying 'email + password' as the relevant datapoints. With 0 parameters, the baseline is 4, and the description adds meaningful semantic value about what the account consists of, though exact field names remain unspecified.
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 ('Create'), a specific resource ('a human lab account'), and the method ('email + password'). This clearly distinguishes it from siblings like spl_agent_key and spl_lab_auth, which likely handle agent credentials or authentication flows.
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 phrase 'human lab account' implies this tool is for human users rather than programmatic agent access, but it does not explicitly state when to use it versus spl_agent_key or spl_lab_auth. The usage context is clear but exclusions and alternative conditions are left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restore files from a .pcc archive. Args: packed_b64. Returns files: [{path, data_b64}].
| Name | Required | Description | Default |
|---|---|---|---|
| packed_b64 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the return shape ('files: [{path, data_b64}]') and does not disclose side effects, error behavior, permissions, idempotency, or whether anything is written to disk versus returned in memory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: one sentence states the purpose, then the argument and return format are given in a terse, scannable structure. 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 simple one-parameter tool, the input and output shapes are minimally sufficient, and the lack of an output schema makes the explicit return format useful. However, with no annotations and no usage guidance, the description leaves notable gaps around when to use it and what behavioral guarantees or limitations exist.
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 lone parameter. It names 'packed_b64' and implies it is the .pcc archive, but it does not explicitly explain that the value must be a base64-encoded string of the archive contents or describe how to construct it. The parameter name carries most of the 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 description clearly states the action ('Restore files from a .pcc archive') and the resource (.pcc archive), so an agent can tell this is an extraction/unzip tool. However, it does not explicitly distinguish itself from sibling tools like spl_zip, spl_compress, or spl_decompress beyond the verb and the tool name.
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 usage context is provided: it does not say when to use this tool versus spl_zip/spl_compress/spl_decompress, nor does it mention any prerequisites, exclusions, or alternatives. The only guidance is implicit in 'Restore files from a .pcc archive.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Issue a Warrant (mandate) for a Rider identity. Pass rider JWT, or demo:true for a 10-minute shape check. Complements Agent-Rider.
| Name | Required | Description | Default |
|---|---|---|---|
| demo | No | ||
| rider | No | X-Agent-Rider JWT | |
| actions | No | ||
| max_usd | No | ||
| max_calls | No | ||
| allow_hosts | No | ||
| ttl_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It says the tool 'issues' a warrant, implying a mutating/side-effect operation, but does not explain consequences, permissions required, persistence, costs, or the shape of the resulting warrant. The demo mode hint ('10-minute shape check') is helpful but insufficient.
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 concise and front-loaded with the core action. The phrase 'Complements Agent-Rider' adds little value and is somewhat cryptic, but the overall length is appropriate and no major redundancy exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, no annotations, and very low schema coverage, the description is not complete enough for reliable invocation. It explains the basic intent and demo path but omits how the warrant constraints work, what the response contains, and how this relates to the warrant receipt and verify siblings.
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 only 14%, so the description must compensate. It adds meaning for 'rider' and 'demo' but leaves five parameters (actions, max_usd, max_calls, allow_hosts, ttl_seconds) completely unexplained. This is a significant gap for an agent trying to call the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Issue a Warrant (mandate) for a Rider identity.' It clearly identifies the tool's action and target, though 'Complements Agent-Rider' is vague and does not meaningfully distinguish it from sibling tools like spl_warrant_receipt or spl_warrant_verify.
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 explicit usage instructions: pass a rider JWT, or use demo:true for a 10-minute shape check. This provides a clear context for when each mode is appropriate, though it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
File a receipt against a Warrant after an action.
| Name | Required | Description | Default |
|---|---|---|---|
| usd | No | ||
| host | No | ||
| note | No | ||
| action | No | ||
| warrant | No | ||
| result_sha256 | No | ||
| request_sha256 | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'File a receipt' implies a mutation but does not disclose side effects, whether the receipt is persisted, whether it updates warrant state, idempotency, or any authorization requirements. This is a significant gap for a tool that appears to write data.
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 single sentence is concise and front-loaded with the key verb and object. However, it is too terse to be genuinely helpful, omitting almost all operational detail. It is under-specified rather than elegantly compact.
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 7 parameters, no annotations, and no output schema, the description is far from complete. It does not clarify what a receipt contains, what inputs are expected, what the result of filing is, or how this interacts with warranty workflow. The tool is likely part of a larger process, but that context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only vaguely maps to 'action' and 'warrant' parameters; the other five parameters (usd, host, note, result_sha256, request_sha256) are entirely unexplained. The description adds minimal meaning beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action ('File a receipt') against a specific resource ('a Warrant') with a temporal context ('after an action'). This distinguishes it somewhat from sibling tools like spl_warrant_issue and spl_warrant_verify, though 'receipt' remains domain-specific and is not further explained.
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 phrase 'after an action' gives an implicit usage context, suggesting this tool should follow some action. However, it does not explicitly explain when to prefer this over spl_warrant_issue or spl_warrant_verify, nor does it state any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a Warrant token. Optional host and action.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | ||
| action | No | ||
| warrant | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Verify' with no detail on what verification entails, what the result looks like, whether it has side effects, or what happens on invalid tokens. This is minimal and insufficient for a security-related verification operation.
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 short and front-loaded with the core action. However, it is so sparse that it sacrifices necessary detail; still, there is no redundant or verbose phrasing.
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 three-parameter tool with no annotations, no output schema, and no parameter documentation. The description provides almost no contextual information about return values, error scenarios, or the meaning of optional parameters, making it incomplete for correct 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. It names 'host' and 'action' as optional but does not explain what they mean or how they affect verification. It also implies 'warrant' is the token to verify, yet the schema marks it as optional, creating ambiguity about whether the parameter is required or not.
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 ('Verify') and a specific resource ('a Warrant token'), which distinguishes it from issuance or receipt tools. However, it does not explicitly contrast with spl_warrant_issue or spl_warrant_receipt, so some differentiation relies on the verb alone.
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 about when to use this tool instead of the related warrant tools or any other sibling. The phrase 'Verifify a Warrant token' implies a use case but offers no context, prerequisites, or exclusions, leaving the agent to guess when this is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pack files into a .pcc archive (our zip). Args: files: [{path, data_b64}]. Returns packed_b64.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does state that the tool returns 'packed_b64', which is useful, but it does not mention any edge cases, size limits, or behavior of the 'dir' flag. It is a simple pack operation, so the level of disclosure is adequate but not rich.
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 deliver the core purpose, input shape, and return value with no filler. The most important information is front-loaded.
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 archive-creation tool, the description gives the essential input and output. However, the unexplained 'dir' boolean in the schema, lack of usage guidance, and absence of any caveats or format details leave the definition only minimally viable for correct 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. It explains the overall shape ('files: [{path, data_b64}]') but omits the 'dir' property entirely and does not clarify which fields are required or how base64 data is expected. The description adds some meaning beyond the raw schema but is incomplete.
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 action ('Pack files') and the resource ('.pcc archive, our zip'), making it easy to understand what the tool does. It also distinguishes it from spl_unzip by framing it as the zip/archive operation, though it does not explicitly contrast it with spl_compress.
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 like spl_compress, spl_decompress, or spl_unzip. The phrase 'our zip' implies it is for creating archives, but the description leaves the choice of tool to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where to use them — one entry with notes, price, and links.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention that this is a read operation, what the response contains beyond a vague list of fields, whether authentication is needed, or how errors are handled. The phrase 'one entry with notes, price, and links' is the only behavioral hint and it is underdeveloped.
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 short, but it is under-specified rather than concise. 'Where to use them' is ungrounded and confusing, and the sentence does not front-load the tool's purpose. It lacks a clear structure that would help an agent quickly understand the operation.
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?
Despite the tool having only one parameter, the description is incomplete for correct invocation. It does not define the resource, the meaning of the ID, or how this tool differs from surface_search. With no output schema and no annotations, the description fails to provide the essential context an agent needs.
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 has only an 'id' property with no description, and schema description coverage is 0%. The description does not explain what the ID identifies, what kind of value should be passed, or how it relates to the entry mentioned in the description. There is no compensation for the missing schema documentation.
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 never states the primary action ('get', 'retrieve', 'lookup') and reads as a fragment: 'Where to use them — one entry with notes, price, and links.' It hints at a single entry but does not clearly explain that this tool fetches a surface by ID, nor does it distinguish it from surface_search.
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 about when to use this tool versus surface_search or any other sibling. No criteria such as 'use when you have an ID' or 'use search when you need to filter' are provided. The name implies ID lookup, but the description itself gives no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where to use them — what it is, what you get, what you pay. Free text or code.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior, but it does not mention what the tool does, how it behaves, what it searches, whether it is read-only, or what the output looks like. The only potentially behavioral phrase, 'Free text or code,' says nothing about tool behavior.
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 extremely short, but that is under-specification rather than effective conciseness. It is not structured around the tool's core purpose and front-loads a vague phrase instead of a clear statement of what the tool does.
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 search tool with one undocumented parameter, no output schema, and a large set of sibling search/get tools, the description is completely inadequate. It leaves the search scope, input semantics, return value, and selection criteria entirely undefined.
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 provides only a property named q with type string and 0% description coverage, so the description must compensate. 'Free text or code' does add minimal meaning by suggesting q accepts natural language or code, but it never explicitly ties that phrase to q and gives no format, examples, or constraints. This is insufficient for an unannotated 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 does not state what surface_search does with a specific verb and resource. Phrases like 'Where to use them' and 'what you pay' read more like a general help header than a tool definition, and nothing indicates that this is a search operation over any particular corpus. It also fails to distinguish surface_search from the many sibling search 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?
There is no guidance on when to use surface_search instead of surface_get or any other sibling. 'Where to use them' is vague and does not name alternatives, conditions, or exclusions. An agent cannot determine when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
spl_quote1 field changedInput schema / properties / bytes / descriptionPrevious value: -"Payload bytes. ≤6.9 GiB unpaid."New value: +"Payload bytes. first 2 GB/month free."cuni_bankpcc_getpcc_searchspl_compressspl_decompressspl_unzipspl_zipspl_warrant_issuespl_warrant_receiptspl_warrant_verifynpm_getnpm_searchspl_quoteaware_getaware_searchbox_getbox_searchchamber_getchamber_searchcuni_getcuni_searchdocs_getdocs_searchlicense_getlicense_searchmeasure_getmeasure_searchpulsar_getpulsar_searchrail_getrail_searchrider_getrider_searchsku_getsku_searchsurface_getsurface_searchspl_agent_keyspl_catalogspl_discoverspl_lab_authspl_signupUniversal Language briefings, FusionGirl context JSONs, service catalog, agent info. x402-enabled.
Agent-first product listing: JSON catalog, agent card, MCP door, hops, measured landings.
Agent supply-chain security, scanner consensus, x402 reliability, and commerce MCP tools.
Read-only discovery for exact-commit Agent Skill validation, x402 payment, and signed receipts.
Add one secure layer between your agents and this server.
