Kerne Honesty Index

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

With no annotations provided, the description carries the transparency burden. It explains the computation source (ERC-4626 share-price growth over 30 days), the protocol's self-listing rule, and the special meaning of null gaps. This goes beyond a bare name and gives the agent important interpretive context.

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

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

The description is dense but every sentence earns its place: the first defines the content, the second explains the self-listing rule, and the third clarifies null semantics. It is appropriately sized for a no-parameter tool and front-loads the core meaning.

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

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

The description covers the main return components (advertised vs realized, board summary, provenance) and the null handling. Without an output schema, it gives a solid mental model, though it does not describe the exact column layout or ordering beyond the protocol's own row being first.

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 schema is trivially complete. Per the rubric, a no-parameter tool earns a baseline of 4; the description adds no parameter-specific detail 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 specifies exactly what is returned: the full Kerne Honesty Index, including advertised vs realized values, board summary, and provenance. It clearly distinguishes from siblings like get_row and list_rows by emphasizing the 'whole board' and additional summary/provenance content.

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

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

Usage is implied rather than explicit: 'The full Kerne Honesty Index' indicates this is for retrieving the complete board, but there is no direct statement of when to use this instead of list_rows or get_row. No alternatives or exclusions are mentioned.

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 and does well by stating the append-only property: 'entries are never edited or removed.' It also documents the content fields (old value, new one, date, rule), giving the agent a clear behavioral model beyond a simple getter.

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, with two sentences. The first sentence is slightly convoluted but packs necessary detail; the second sentence is clear and direct. Overall it is efficient and front-loaded with the main 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 no-parameter getter with no output schema, the description adequately explains the nature of the data (corrections log with specific fields) and the immutable behavior. It does not explicitly state the return format (e.g., a list of entries), but that is reasonably inferred from the description.

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 per the rubric the baseline is 4. The description adds context about what the log contains, which is relevant even though there are no parameters to document.

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 a corrections log containing entries for every change to statements about a named company or method rules, with old/new values, date, and the preventing rule. This distinguishes it from sibling tools like get_board or get_right_of_reply, though it lacks an explicit verb like 'returns' or 'lists' to state the tool's action.

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 explicit guidance on when to use this tool versus alternatives such as get_board or get_methodology. The intended use is only implied by the resource description; there are no exclusions or comparisons to sibling tools.

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?

Without annotations, the description carries responsibility for behavioral disclosure. It does reveal content boundaries ('what this board deliberately does not cover') and a commitment about reproducing rows, which is useful context. However, it does not state whether the operation is read-only, idempotent, or any error 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 a single comma-separated list of five items, which is concise but reads as a fragment rather than a complete sentence. It front-loads the most important aspects but lacks a clear structured introduction.

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

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

For a zero-parameter getter with no output schema, the description gives a good overview of content but does not specify the return format (e.g., text, structured object) or any usage context. This is a notable gap for an agent deciding whether and how to use 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?

With zero parameters, the baseline is 4. The description adds no parameter-specific meaning, but none is needed since the schema has no properties.

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 indicates the tool provides methodology information, listing specific topics like measurement, comparability rules, and limitations. However, it lacks an explicit verb+resource statement like 'Returns the methodology document,' relying on the tool name and title for clarity.

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 siblings like get_row or list_rows. The description does not mention alternatives, exclusions, or specific conditions that would prompt its use.

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 of disclosing behavior. It mentions characteristics of the reply slot ('free, permanent, unedited') and a rule about unpublished items, but does not state that this is a read-only operation, what the return format is, or any side effects. Behavioral transparency is minimal.

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 long, run-on sentence that packs multiple ideas ('reply slot', 'terms', 'three things', 'every reply') without clear structure. It is not front-loaded with a verb and would benefit from being split into a clear, concise statement. Overly verbose for the content conveyed.

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

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

The description is cryptic and context-dependent. Terms like 'measured protocol', 'its own row', and 'the only three things that will not be published' are unexplained. Without an output schema or annotations, the agent cannot understand what the tool returns or how to interpret the results. The description leaves too many open questions.

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 schema already fully covers parameter semantics. The description does not need to explain parameters, and it does not attempt to. This matches the baseline of 4 for parameterless tools.

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 describes the content of the right of reply resource ('reply slot', 'terms', 'three things not published', 'every reply received so far') but lacks an explicit verb like 'get' or 'return'. It is not a tautology, but the purpose is only implied by the tool name and 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?

The description provides no guidance on when to use this tool versus siblings like get_row or list_rows. It does not mention alternatives, prerequisites, or exclusions. The agent is given no context to choose this tool appropriately.

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 for behavioral disclosure. It details the content returned, but does not state that the operation is read-only, mention error behavior, prerequisites, or side effects. The name 'get' implies read-only, but the description does not explicitly confirm this or disclose 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 one long run-on sentence with a colon and a list. It is informative but not polished; it could be broken into clearer components. However, it is front-loaded with 'One row' and is not excessively long, so it is acceptable but not exemplary.

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 compensates by listing the row's complete contents, which is helpful. However, it omits operational context such as the need to call list_rows first (only in schema), read-only assurance, and potential error scenarios. For a simple single-param retrieval tool, it is adequate but not fully complete.

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

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

The input schema fully describes the single 'row' parameter with an enum and a note 'from list_rows' (100% coverage). The description does not add parameter-specific details, but it does clarify what the retrieved row will contain, which indirectly helps the agent understand the parameter's purpose. This matches the baseline for schema-heavy definitions.

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 conveys that this tool returns a single row with comprehensive detail, distinguishing it from list_rows which presumably provides an overview. The noun-phrase style is less direct than a verb+resource, but the title 'Get one row in full' reinforces intent. Specific contents are enumerated, making the purpose unmistakable.

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 explicit when-to-use or when-not-to-use guidance is provided. The schema hints at using list_rows to obtain the row key, but the description itself does not clarify when to choose this tool over alternatives like get_right_of_reply, especially since the row includes right-of-reply data. The description lacks any comparative context.

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 that the operation is cheap and enumerates the returned fields, but does not mention pagination, output volume, or other operational constraints. This is adequate for a simple read-only list but not rich in behavioral context.

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

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

The description is remarkably concise: one sentence states the resource and its contents, a second notes the cost, and a third gives usage direction. Every word earns its place, and the key 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 tool with no parameters, no output schema, and no annotations, the description covers the essential aspects: what it lists, the included fields, and its role in the workflow with get_row. The only minor omission is explicit mention of the output format (e.g., an array) or any response size expectations, but these are not critical for this simple listing operation.

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, making the empty input schema complete. The description adds no parameter details simply because there are none to describe; this aligns with the baseline score of 4 for param-less tools.

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 that the tool returns the complete roster of vaults (rows) on the Honesty Index, listing specific fields (key, protocol, symbol, chain, contract address). It explicitly positions itself as the list-all counterpart to get_row, making its purpose unmistakable.

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 instruction 'Call this first to find the key for get_row' provides explicit when-to-use guidance and names the subsequent tool. The word 'Cheap' additionally signals that it is a low-cost operation, encouraging use before more specific lookups.

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