Basis Protocol

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

With no annotations, the description carries the full burden and does so well: it discloses grounding behavior (cites attestation hashes), refusal semantics for ungroundable queries, a hard behavioral boundary (no recommendations/forecasts), the auth mechanism (x-api-key header or ?apikey=), and multi-turn session handling. This is unusually rich behavioral context for an unannotated tool.

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

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

Front-loads the purpose, then behavior, then auth/session mechanics, then parameters. Every sentence carries information; the only mild inefficiency is restating parameters in prose the schema already names, though it adds limits not present in the schema.

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

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

For a 2-param tool with no annotations, no output schema, and 0% schema coverage, the description covers purpose, behavioral boundaries, auth, session semantics, and param constraints. It could say more about what an 'envelope' contains or the shape of returned answers, but it is largely complete 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 and largely does: it documents the 4000-char limit on query and explains session_id as the Session UUID from a previous envelope for multi-turn use. It adds real meaning the bare schema (just types) does not provide.

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

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

States a specific verb+resource: ask the Basis Agent a question about attested risk state. It is clearly distinguishable from data-retrieval siblings like basis_data or score_history by its Q&A framing. However, it never names an alternative tool or explicitly contrasts itself with the sibling set.

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?

Gives clear operating context: answers must be grounded in attestations, ungroundable queries are refused, and it never recommends positions or forecasts, which tells the agent when NOT to route forecasting/advice requests here. It stops short of naming which sibling to use instead for raw data retrieval.

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

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

With no annotations, the description carries the full behavioral burden and does disclose two useful traits: responses are capped near 12 KB and an unknown kind returns the kind list. It says nothing about auth, freshness, or read-only nature, so it is partial but not empty.

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 purpose is front-loaded in one sentence, followed by a compact per-kind list where every entry carries its own entity/window/limit semantics. It is dense but no line is redundant, given the 0% schema coverage.

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 17-mode dispatcher with no output schema and no parameter documentation, the description supplies the kind vocabulary, per-kind arguments, defaults, and the response-size cap. Return shapes per kind are not described, but the cap notice plus no output schema make that an acceptable omission.

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

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

Schema coverage is 0% and the kind parameter has no enum, so the description compensates heavily: it lists all 17 valid kinds, marks which need entity vs optional entity, states window defaults (90, 24) and limit defaults (20), and gives severity values (notable|alert|critical). Only detail's non-peg behavior is left implicit.

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 (market, governance and risk data) and enumerates the 17 kinds it returns, so an agent knows exactly what it fetches. It does not, however, distinguish this tool from siblings like basis_answer or entity_read, leaving overlap unexplained.

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 tells the agent to 'pick a kind' and annotates each kind with its expected entity window/limit, which implies when each is appropriate. But there is no explicit when-to-use vs basis_answer/entity_read guidance or any exclusion criteria, so routing among siblings is left to inference.

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

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 discloses the return shape ({entity_type, id, score, grade, confidence, receipt_hash, links}) and, crucially, that a miss returns {match: null, did_you_mean: [...]} rather than an error. This is a valuable behavioral trait for an agent to know. It stops short of stating auth needs or rate limits, hence a 4 rather than 5.

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

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

Front-loaded with the core action, then the return shape and the miss behavior. Two tight sentences, though the line-broken formatting of the return object is slightly clunky for a prose description. No filler.

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

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

With no output schema, the description must describe returns, and it does for both the success and miss paths, including the did_you_mean fallback. For a single-param lookup with no annotations, this is close to complete. It could go further on auth/permissions, but nothing essential 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 coverage is 0% for the single 'query' parameter, so the description must compensate, and it does: it enumerates the identifier forms accepted (symbol, slug, contract/wallet address, operator, vault name). That is substantive meaning beyond the bare schema. One param with no enum keeps it at 4 rather than 5.

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

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

States a specific verb (look up) and resource (any entity) and enumerates accepted identifier types (symbol, slug, contract/wallet address, operator, vault name). This clearly distinguishes it from siblings like basis_answer and get_stablecoin_scores, which are analytical rather than lookup tools.

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

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

The description implies this is a general-purpose resolution tool for any identifier, and the enumeration of identifier types signals when it applies. However, it does not explicitly state when to prefer basis_answer, basis_data, or other siblings, leaving the agent to infer the boundary.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the payload difference between modes and warns that full mode is "large", which is useful behavioral context, but it says nothing about read-only safety, caching, or any cost/auth implications.

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 compact sentences with the resource named first and the mode semantics front-loaded; every clause carries information. The fragmentary phrasing ("The Basis methodology.") is efficient but not fully polished, keeping it below 5.

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

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

With no output schema and no annotations, the description does the necessary work by outlining the returned content for both modes (index list, versions, component counts vs. formula, weights, specifications). It is sufficient for correct invocation, though a note on output format or size handling for full mode would round it out.

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

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

Schema coverage is 0% and the schema does not even declare an enum for mode, but the description compensates fully: it defines both accepted values, states the default, and describes the content returned by each. This is exactly the case where the description must document the parameter, and it does.

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 specific resource (the Basis methodology) and what each mode returns, so an agent can tell it apart from sibling retrieval tools like basis_data or basis_answer. It lacks an explicit verb ("retrieve"/"get"), relying on the tool name to supply the action, which keeps it just 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?

It clearly explains the two modes and marks summary as the default, which is genuine selection guidance for the parameter. However, it gives no guidance on when to call this tool at all versus siblings such as basis_answer or basis_data, and no exclusions or prerequisites.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the bounded result set (max 500) and exposes a 'stale' field hinting at freshness semantics, but says nothing about side effects, permissions, or whether the call is purely read-only.

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?

Purpose is front-loaded in one sentence, parameters are grouped in a compact indented block, and the sibling pointer closes it out. No filler sentences; every line carries information 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?

No output schema exists, but the fields parameter's default list (score, grade, confidence, stale, computed_at) effectively documents the return shape, and all three params are covered. Only auth/permission expectations and the meaning of the SII acronym are left unstated.

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

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

Schema coverage is 0%, so the description must compensate and it does: it documents all three params with defaults, the sort_by enum values, the limit ceiling of 500, and the default field list including the special 'categories' value. This is materially more than the bare schema provides.

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

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

States a specific verb+resource with scope and scale: 'Current SII scores (0-100) for scored stablecoins'. The word 'Current' implicitly separates it from the score_history sibling, and it names entity_read as the per-coin alternative, though it never explicitly contrasts with basis_answer or score_history.

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?

'Use before any decision involving stablecoins' gives a clear trigger condition, and 'One coin's detail: entity_read(query)' routes the agent to the alternative when a single-coin lookup is needed. No explicit when-not is stated, but the usage context is unambiguous.

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

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

With no annotations, the description carries the full burden. It does disclose the core behavior: the hash is resolved against attestation tables and returns either what it attests to or an unknown result, which is meaningful return-semantics disclosure. It says nothing about permissions, whether the lookup is read-only, or any rate/consistency caveats.

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?

Three short sentences, front-loaded with the verb and resource, followed by mechanism and the optional filter. No filler or repetition; the slightly terse phrasing is efficient rather than padded.

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 two-parameter read tool with no output schema and no annotations, the description covers purpose, input origin, and the shape of the result. It omits the permissible values of 'source', hash format expectations, and any behavioral caveats, which leaves meaningful gaps given the absence of structured support.

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 that 'source' optionally restricts which table is searched and that 'hash' comes from an envelope, giving both parameters meaning beyond their bare names. It does not state the accepted source values or hash format, leaving a real gap at 0% coverage.

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?

Specific verb ('Verify') plus resource ('receipt or citation hash') distinguishes this from the read/score siblings. The parenthetical '(basis_answer, entity_read)' identifies the upstream tools that emit the hashes, further pinning down what this tool consumes. It does not name a sibling it is not, so it lands short of a 5.

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

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

The description makes clear this is called on a hash lifted from a basis_answer or entity_read envelope, which is real usage context rather than inference. It offers no explicit when-not or alternative path, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the burden. It discloses the exact return shape and that only {date, score, grade} is returned, which is useful. It says nothing about read-only nature, caching, rate limits, or behavior for unknown coins, leaving gaps for a zero-annotation tool.

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

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

Front-loaded purpose followed by a clean parameter block; no filler sentences. The '{date, score, grade} only' phrasing efficiently signals scope in a few words.

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

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

No output schema exists, but the description supplies the return shape itself, and both parameters are documented despite zero schema coverage. The main unmet need is usage routing against siblings, not call mechanics.

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

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

With 0% schema description coverage, the description must compensate and largely does: coin accepts symbol, slug or contract address (with resolution behavior), and days is a lookback window bounded 1-365 with a default of 30. Only the exact resolution rules are left to the referenced entity_read.

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

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

States a specific resource and scope: daily SII score history for a stablecoin, and even names the exact return shape ({date, score, grade}). This implicitly differentiates it from get_stablecoin_scores, but the description never explicitly says it is the historical counterpart to that 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?

No when-to-use guidance and no routing against siblings like get_stablecoin_scores or basis_answer. The reader must infer that this is for historical lookback rather than current scores. A single 'use X for current scores' clause is missing.

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