koios-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
The tools are grouped by domain and mostly have distinct purposes, but the sheer number of similar resources (e.g., koios_account_updates vs koios_account_update_history, koios_pool_registrations vs koios_pool_updates) creates potential confusion. Descriptions help, but boundaries between some tools are subtle.
Naming Consistency4/5
All tools consistently use the 'koios_' prefix with snake_case, and most follow a resource_qualifier pattern (e.g., koios_epoch_info, koios_block_txs). Minor deviations like koios_ogmios and embedded abbreviations (cli, cbor) prevent a perfect score.
Tool Count2/5
With 92 tools, the server is far beyond the typical well-scoped MCP range. While the Koios API is broad, exposing every endpoint as a separate tool makes the surface unwieldy and overwhelming for agents.
Completeness5/5
The toolset offers comprehensive coverage of the Cardano blockchain, including chain status, epochs, blocks, transactions, addresses, accounts, assets, pools, governance, scripts, and even transaction submission. No significant gaps are apparent.
Average 3.2/5 across 92 of 92 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It implies a read operation via 'Get', but does not disclose pagination behavior, extended data handling, response format, or error conditions. The schema indicates these features, but the description adds no behavioral context beyond a basic read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is under-specification rather than effective conciseness. It omits important usage context that would fit naturally without bloat. It is not a tautology, but it does not earn its place as an adequate summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 a minimal description, the tool is under-specified. The input includes a nested array of asset pairs and several pagination/ordering options, but the description does not explain the return value, how the input should be structured, or what 'detailed information' entails. It is insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: all six parameters have descriptions in the input schema. The description itself adds no parameter semantics, but per the baseline rule for high coverage, the schema sufficiently documents parameters, so no penalty is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb+resource pattern ('Get detailed information about specific assets'), but 'detailed information' is vague and does not specify what data will be returned. With numerous asset-related sibling tools (koios_asset_history, koios_asset_summary, koios_asset_utxos, etc.), it fails to differentiate from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention scenarios, exclusions, or contrasts with sibling tools like koios_asset_list or koios_asset_token_registry. The agent is left without any selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 merely says 'Get information', offering no details about return format, pagination, filtering behavior, or any side effects. This is essentially a bare verb with no added transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified—it is a command-like phrase rather than a complete, informative sentence. It includes no extra context or usage details, making it more of a restatement of the tool name than a helpful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 5 optional parameters and lack of an output schema, the description is severely incomplete. It does not explain what kind of data is returned (e.g., committee member details, status), how filtering works, or any relevant edge cases. This is especially inadequate for an API tool with pagination and filtering options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, including meaning for limit, order, offset, select, and _cc_hot_id. The tool description adds no parameter-specific meaning, but the schema already fully documents the parameters, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (Constitutional Committee member information) with a clear verb ('Get'), and it is distinguishable from sibling tools like koios_committee_votes by focusing on member info rather than votes. However, it does not specify whether the tool returns all members or a specific one, which the schema hints at via the _cc_hot_id parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that it complements committee_votes or any other sibling, nor does it describe the typical scenario (e.g., querying member details by hot key). This leaves the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral transparency. It only states the basic action and does not disclose pagination behavior, ordering, limits, response format, or any constraints. This is a significant gap for a tool with six parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the verb. It is efficient and avoids redundancy. However, given the tool's parameter complexity and the lack of annotations, a slightly more detailed description would be beneficial, making it less minimal than the top tier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is part of a large sibling family with many related transaction/metadata endpoints. The description does not clarify the relationship to these siblings, define what a 'metadata label' is in Koios, or explain return values or edge cases. Without annotations or an output schema, the description is insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all six parameters, so the schema already provides meaning. The description adds no extra context about parameters, such as relationships or usage nuances. Baseline of 3 is appropriate since the schema handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('transactions') with a clear modifier ('by metadata label'), making it distinct from sibling tools like koios_tx_metadata (which gets metadata for transactions) and koios_tx_metalabels (which lists labels). It does not explicitly name alternatives, but the purpose is unambiguous and easy to differentiate from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It does not mention prerequisites, exclusions, or scenarios where koios_tx_metadata or koios_tx_metalabels would be more appropriate. The sibling list is available but the description itself offers no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses only that it fetches a UTxO set, omitting behavior around pagination (limit/offset), ordering, extended data (_extended), and the meaning of 'set.' This minimal disclosure is insufficient for an endpoint with 6 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, but it is under-specified for the tool's complexity. It achieves brevity but sacrifices necessary context, so it is not fully appropriate in size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 6 parameters, lack of annotations, and absence of an output schema, the description is incomplete. It doesn't explain return structure, pagination behavior, or the distinction from similar sibling tools, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so a baseline of 3 applies. The description repeats the _addresses concept ('given addresses') but adds no additional meaning beyond the schema descriptions for limit, offset, order, select, and _extended.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('UTxO set') with scope ('for given addresses'), making the core function clear. However, it doesn't explicitly differentiate among sibling address-related tools like koios_address_outputs or koios_credential_utxos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as koios_address_outputs or koios_utxo_info. It only states the basic action, with no context about prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states what the tool does at a high level but does not explain what 'current' means (e.g., latest epoch), what the response looks like, or how pagination parameters (limit, offset) apply to something seemingly singular. This lack of detail leaves important behavioral traits opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff, which is good. However, it largely restates information already implied by the tool name ('protocol_params', 'cli'), and it misses the opportunity to clarify the return format or pagination behavior. It is not as under-specified as a tautology, but it adds minimal value over the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations and no output schema, the description is insufficient. The presence of pagination parameters on a 'current parameters' endpoint is confusing and not explained. The description does not clarify whether the tool returns a single object or a list, nor does it explain how the pagination parameters interact with the 'current' concept. This leaves significant gaps for an agent trying to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (limit, order, offset, select all have descriptions), so the baseline is 3. The tool description adds no parameter-specific meaning beyond what the schema already provides, but it doesn't need to because the schema is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('current protocol parameters'), and adds a valuable differentiator with 'in cardano-cli compatible format'. However, it does not explicitly differentiate from sibling tools like koios_epoch_params or koios_param_updates, which also deal with protocol parameters, so it loses a point for lack of sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It does not mention that this returns the current active parameters while koios_epoch_params returns historical ones, nor does it note any exclusions (e.g., 'not for historical queries'). The agent is left to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden for behavioral disclosure. It only states what the tool returns, not how it behaves (e.g., pagination, ordering, data range, or response format). The verb 'Get' implies a read operation, but this is weak and not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded, but it is also under-specified and repeats the resource name already in the tool name. It earns only partial credit for being brief without providing additional useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 a description that only restates the tool's purpose, the tool is not adequately contextualized. The schema covers parameters, but there is no explanation of the data scope, return structure, or operational context, making the description insufficient for a meaningful tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all four parameters, so the baseline is 3. The tool description itself adds no parameter-specific meaning beyond what the schema already states, which is sufficient given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and specifies the resource ('reserve withdrawals') and context ('Cardano reserve'). It is unambiguous, though it doesn't differentiate from sibling tools like treasury_withdrawals, which serve a similar conceptual purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. There is no mention of prerequisites, typical use cases, or when to prefer a different endpoint such as treasury_withdrawals. A single declarative sentence is all that is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only uses 'Get' to imply a read operation. It does not disclose rate limits, authentication needs, or any other behavioral traits beyond the basic query nature, so the description fails to carry the full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, achieving maximum conciseness and front-loading the key verb and resource. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, no annotations, and numerous sibling tools, the description is too sparse to provide complete context. It lacks information about return format, differentiation from similar tools, and usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 6 parameters, so the schema already documents the parameters. The description adds no additional semantics beyond what's in the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get reward history for given stake accounts' with a specific verb and resource. However, it does not explicitly differentiate from sibling tools like koios_account_stake_history or koios_account_update_history, so it's clear but lacks direct sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. There is no mention of exclusions or comparisons with similar account-related tools, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 simply says 'Get transaction history' and does not explain pagination behavior, response format, ordering defaults, or any rate limits. This is a minimal description that does not add context beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words. It is efficient and front-loaded, though it is extremely brief and lacks any detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 6-parameter tool with no output schema, yet the description only states the basic purpose. It does not explain what the returned transaction history looks like, how pagination works, or any special behaviors. This is insufficient for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all seven parameters. The description adds no additional parameter context beyond what the schema provides, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Get transaction history for a specific stake account'. This distinguishes it from other account-related tools like account_utxos or account_reward_history, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other similar account or transaction history tools. There are no use-case scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states 'full update history' but does not clarify what constitutes an 'update', whether the result is paginated, or any other behavioral traits such as rate limits or data freshness. This leaves the agent guessing about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single declarative sentence with no extraneous words, making it highly concise and front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, no annotations, and no output schema, yet the description offers only a bare purpose statement. Given the existence of a similarly named sibling ('koios_account_updates'), the description is under-specified and lacks the behavioral and selection context needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all five parameters, including the required '_stake_addresses'. The description's mention of 'given stake accounts' aligns with the schema but adds no additional meaning beyond it. Thus, the parameter semantics baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'full update history' for stake accounts, making the core function clear. However, it does not differentiate from the sibling tool 'koios_account_updates', which likely provides the same or overlapping data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'koios_account_updates' or 'koios_account_info'. The description lacks any context about intended scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states 'Get UTxOs', implying a read operation, but does not disclose pagination behavior, extended data flags, ordering, limit/offset semantics, or the shape of the returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds meaning: 'Get UTxOs', 'stake accounts'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being extremely concise, the tool has 6 parameters and no output schema. The description does not explain pagination, ordering, extended data options, or result structure, leaving significant gaps for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds no additional parameter meaning beyond what the schema already provides for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is clear: it uses the verb 'Get' and specifies the resource 'UTxOs' scoped to 'stake accounts'. It distinguishes itself from siblings like koios_address_utxos and koios_credential_utxos by the stake-account scope, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus related tools such as koios_address_utxos, koios_credential_utxos, or koios_account_txs. The intended context is implied by the name, but no explicit when-to-use or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it merely restates the function. It does not mention pagination behavior (despite limit/offset parameters), whether ADA is included in 'native assets', or any other behavioral traits such as response shape or error conditions. It is not misleading, but it is extremely minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence with clear verb-object structure and no superfluous words. It is front-loaded and concise, though it is arguably too terse to be fully informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, no output schema, and a large set of similar sibling tools, this one-liner is insufficient. It does not explain what 'holdings' means, whether results are aggregated per address, or how pagination works, leaving the agent without enough context to predict the tool's behavior or select it appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters have descriptions. The tool description adds no semantic value beyond what the schema already provides; it only implies that '_addresses' is the key input. Per the baseline rule, this scores a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('native asset holdings'), and the scope ('given addresses'). It is specific enough to convey the tool's core function, but it does not explicitly differentiate this from similar sibling tools like address_utxos or account_assets, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as address_utxos, address_txs, or account_assets. No context, exclusions, or alternative tool references are given, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'Get a list of all native assets' and fails to mention pagination behavior, response format, rate limits, or that the list could be large. This is a minimal disclosure that adds little beyond the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource. Every word contributes meaning, and there is no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool simply lists all native assets, the description lacks important context about pagination (limit/offset are present in schema but not described), potential result size, and what 'all native assets' entails. Without an output schema or annotations, the one-sentence description is insufficient for complete operational understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides comprehensive descriptions for all four parameters, so the description need not add parameter details. However, the description itself adds no extra semantic context about how parameters like 'order' or 'select' affect the list, keeping this at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a list of all native assets on the Cardano blockchain, using a specific verb and resource. It conveys the scope with 'all' but does not explicitly differentiate from sibling tools like policy_asset_list, which could be an alternative for filtering by policy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as policy_asset_list or asset_info. It only states what the tool does, leaving the agent to infer usage from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the tool is read-only, how pagination works, that the asset policy is required, or any other behavioral traits beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant information. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the description is too terse. It does not explain the returned transaction structure, the effect of options like _history or after_block_height, or pagination behavior, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as all 8 parameters have detailed descriptions. The tool description adds no parameter semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get transactions involving a specific asset' clearly states the verb (Get) and resource (transactions) with a specific filter (specific asset). It is clear, but it does not explicitly distinguish from sibling tools like koios_asset_history or koios_asset_utxos, which may also relate to asset activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 koios_asset_history, koios_asset_utxos, or koios_address_txs. The description gives no context about use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It discloses the output format (raw CBOR), but doesn't mention pagination behavior, limits, error handling, or any other behavioral traits that would help an agent understand the tool's runtime characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word serves to identify the tool's purpose, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters and no output schema, this one-liner is insufficiently complete. It lacks information about pagination, ordering, return structure, and when to use this versus related tools, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds no extra parameter semantics; 'specific blocks' is already implied by the _block_hashes parameter description. It doesn't go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it retrieves raw CBOR-encoded transactions for specific blocks, using a specific verb and resource. It is clear, but it doesn't explicitly differentiate from sibling tools like koios_block_txs or koios_tx_cbor, so it misses the full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives, no prerequisites, and no exclusions. It only states the general function without context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states 'Get', implying a read operation, but does not explain what the summary statistics include, whether there are limitations, pagination behavior, or any potential side effects. The lack of detail is a significant gap for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is concise and directly states the tool's purpose, though it may be too brief to convey necessary context; nonetheless, it earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no annotations, and no output schema, placing a heavy burden on the description. The one-line description only states the purpose and gives no information about return values, filtering strategies, or how this tool fits into a workflow, leaving it incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all parameters, including limit, order, offset, select, and _epoch_no. The description itself adds no parameter-specific meaning, but with full schema coverage the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'DRep epoch summary statistics', clearly stating the tool's action. However, it does not differentiate from sibling DRep-related tools like koios_drep_info or koios_drep_voting_power_history, so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 compared to other DRep or epoch tools. No alternatives, prerequisites, or typical use cases are mentioned, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only says 'get detailed information' and reveals nothing about pagination, output structure, or behavior for invalid DRep IDs. This is minimal behavioral disclosure for a tool with 5 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. However, it is extremely terse and could include brief usage context without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema and many sibling DRep tools, the one-sentence description is insufficient. It does not explain what 'detailed information' includes, nor does it mention the required _drep_ids parameter, making it hard for an agent to fully understand the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of the parameters, including clear explanations for _drep_ids, limit, offset, order, and select. The description adds no extra nuance, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get') and resource ('detailed information about specific DReps'). It is understandable but does not differentiate from sibling DRep tools such as koios_drep_metadata or koios_drep_epoch_summary, both of which could be argued to return 'detailed information' about DReps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It does not mention that it specifically targets DRep IDs, nor does it exclude list-based tools like koios_drep_list, leaving the agent without selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mention whether this is a read-only operation, any response format, pagination behavior, or authorization needs. The description essentially restates the tool's name without adding meaningful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is concise and every word contributes to the meaning, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description is the only source for return-value context. It does not describe what metadata is returned, the response structure, or any constraints. While the input schema is well-documented, the absence of output information is a significant gap for a retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with all five parameters documented, including the required _drep_ids array and pagination controls. The description adds no extra semantic meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Get') and resource ('metadata for specific DReps'), which conveys the tool's core function. However, it does not distinguish it from the sibling tool koios_drep_info, which likely serves a very similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like koios_drep_info or koios_drep_list. The description does not mention any prerequisites, exclusions, or context in which this tool is the preferred choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It states a read operation but fails to describe what protocol parameters are returned, whether the output is a single object or a list, how pagination works, or any access restrictions. The description is too minimal to inform the agent beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It conveys the core function efficiently. Every word earns its place, and there is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 annotations, the description should explain what the agent can expect in the response and mention that all parameters are optional or that pagination is available. The description only states 'get protocol parameters' without addressing output format, pagination, or the scope of the result set. This leaves a significant gap for a 5-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter individually described, so the baseline is 3. The description's phrase 'specific epoch' adds minimal extra meaning aligning with the _epoch_no parameter, but does not clarify parameter interactions or format details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get protocol parameters for a specific epoch'. It uses a specific verb ('Get') and identifies the target resource ('protocol parameters') with a scoping qualifier ('for a specific epoch'). This distinguishes it from parameter update tools, though it does not explicitly name alternatives or contrast with sibling tools like koios_cli_protocol_params.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other related tools. It does not mention that this returns historical epoch parameters, whereas koios_cli_protocol_params might be used for current parameters. There is no mention of prerequisites, typical use cases, or exclusions, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It only says 'Get the genesis parameters', which implies a read operation but does not mention pagination behavior, default limits, ordering, or response format. The agent is left without critical context for a safe and correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the core purpose. It is not overly verbose and earns its place, though it lacks any structural breakdown or additional context. The terseness is acceptable given the simplicity of the described action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and a one-sentence description. It does not describe what the response contains, how to paginate results, or why it differs from other parameter-related tools. For a blockchain data tool, this is insufficient to guide correct usage, especially without output schema or behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all four parameters (limit, order, offset, select), with 100% schema description coverage. The tool description adds no parameter-level semantics beyond the schema, but since the schema already does the heavy lifting, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses the verb 'Get' and specifies the resource as 'genesis parameters of the Cardano blockchain', making the purpose evident. It distinguishes from related siblings like koios_param_updates and koios_era_summaries by focusing specifically on genesis parameters, though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 koios_param_updates or koios_cli_protocol_params. The description simply states the action without any context, exclusions, or comparison to similar parameter-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. Saying 'Get' implies a read-only operation, but no information is given about response format, pagination behavior, error handling, rate limits, or any side effects. This is minimal disclosure, similar to the 'update_drive' example where the description doesn't compensate for absent annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of six words, front-loaded with the action 'Get'. It is appropriately short for a simple lookup tool and contains no filler. However, it is almost too terse, omitting any elaboration that could aid understanding, so it stays just below a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the description does not explain what Calidus keys are or what the response contains. Despite being a simple read operation, the lack of context makes it hard for an agent to fully understand the tool's place among many pool-related siblings. With low complexity, the description is incomplete in conveying the full picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (limit, order, offset, select) having a clear description. The tool description itself adds no parameter-specific meaning, but since the schema already documents them, the baseline of 3 is appropriate. The description does not clarify how these parameters interact with the specific Calidus keys resource.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'Calidus keys for stake pools', clearly identifying the tool's function. It distinguishes from siblings by naming a unique resource (Calidus keys) not mentioned in any other tool description. However, it does not explain what Calidus keys are, which could reduce clarity for an unfamiliar agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. There are many pool-related sibling tools (e.g., pool_info, pool_relays, pool_metadata), but no exclusions or comparison are mentioned. The agent is left to infer applicability based solely on the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states that the tool 'gets historical performance data', but does not disclose pagination behavior (though the schema has limit/offset), epoch filtering, or what specific metrics are returned. There is no mention of response format or any caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler or unnecessary words. It is front-loaded with the action and resource, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6-parameter schema and lack of output schema, the description is too sparse. It does not explain what 'historical performance data' entails, whether it returns one row per epoch, or how pagination/filtering works. The schema covers parameters but the tool's behavior and return shape remain ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 6 parameters have descriptions in the schema). The tool description adds no additional parameter meaning, so the baseline score of 3 applies. It does not compensate for any gaps because none exist in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get historical performance data for a specific pool' clearly identifies the action (get) and the resource (historical performance data for a specific pool). It is distinct enough from siblings like koios_pool_info, but does not explicitly mention what 'performance' includes or differentiate itself from similar pool history tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 koios_pool_info, koios_pool_stake_snapshot, or koios_pool_blocks. The description does not mention any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey safety and behavior. It only states it gets information, which implies a read operation, but it does not disclose prerequisites such as valid bech32 pool IDs, pagination behavior, or what fields are returned. This is minimal coverage 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it concise and easily scanned. However, it is also under-specified for a tool with multiple pagination and filtering parameters, so it is not maximally informative despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a data-retrieval tool with no annotations and no output schema, and the description does not explain return structure, pagination defaults, or how 'detailed information' relates to the select/order parameters. It is barely adequate for an agent to invoke reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all five parameters, so the schema carries the parameter semantics. The description adds only the idea that the tool targets 'specific' pools, which aligns with the required _pool_bech32_ids parameter, but provides no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Get detailed information about specific stake pools,' which clearly identifies the verb (get), resource (stake pools), and scope (specific, by ID). It distinguishes from pool_list by emphasizing 'specific' rather than listing all pools, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this tool over the many sibling pool tools such as pool_list, pool_history, or pool_info variants. No context is given beyond the basic action, so an agent has no basis for selecting it among alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, yet it only states the basic function. It does not mention that it relies on off-chain metadata, the absence of metadata for some pools, pagination behavior, or any response details, leaving the agent without important context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It communicates the essential purpose efficiently and is appropriately sized for a straightforward lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the schema thoroughly documents parameters, the description lacks information about the return structure or the nature of pool metadata, especially given there is no output schema. This incompleteness could leave an agent uncertain about what to expect from the tool's response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all parameters, including _pool_bech32_ids, limit, order, offset, and select, achieving 100% coverage. The description adds no additional parameter semantics beyond implying that 'specific stake pools' corresponds to the required pool ID array, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and resource (metadata for specific stake pools), and specifies that it operates on specific pools, which aligns with the required parameter. However, it does not explicitly distinguish from sibling tools like pool_info or pool_list, though 'metadata' suggests a distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 koios_pool_info or koios_pool_list. The description implies usage for specific pool IDs but offers no context, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the basic function and does not disclose behavior around pagination, filtering, or response format. For a read-only query tool, the lack of any safety or behavioral notes 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or repetition. It is concise and front-loaded, clearly stating the tool's purpose without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 6 optional parameters and no output schema, the description is extremely minimal. It does not explain the output structure, how to filter by pool or epoch, or the broader context of voting power history. Given the complexity and many sibling tools, more detail is needed for a complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning each parameter (limit, order, offset, select, _epoch_no, _pool_bech32) is already documented in the schema. The description adds no additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Get' and specifies the resource as 'voting power history for stake pools'. It is specific enough to convey the tool's function, but it does not explicitly differentiate it from sibling tools such as koios_pool_history or koios_drep_voting_power_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It does not mention any context, prerequisites, or exclusions, leaving the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 implies a read-only operation via 'Get' but does not mention pagination behavior, response format, aggregation details, or any special constraints. The description adds no behavioral insight beyond what the schema and name already suggest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded with the key action and object. However, it is somewhat terse and mostly restates the tool name, providing only slightly more detail ('specific governance proposal'). It is concise but not richly informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and annotations, and the description does not clarify what constitutes a 'voting summary' or how it differs from sibling tools like proposal_votes. Given the existence of multiple voting-related tools and the need to select and invoke correctly, this description is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all five parameters adequately. The description adds minimal value by reinforcing that the proposal is specific, but it does not explain how the pagination/filtering parameters relate to the summary output beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get voting summary for a specific governance proposal' uses a specific verb ('get') and identifies the resource ('voting summary') and scope ('specific governance proposal'). It clearly distinguishes from list-oriented siblings like proposal_list and vote_list, though it could be more explicit about what the summary includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 koios_proposal_votes (which likely returns raw votes) or koios_vote_list. No exclusions or alternative recommendations are given, leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mention pagination behavior, ordering, or what 'metadata' specifically includes. The schema hints at pagination via limit/offset, but the description fails to explain any behavioral traits 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the key action and resource, though its brevity leaves out helpful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is insufficiently complete. It does not explain return values, pagination, or how this differs from related metadata tools like koios_tx_metalabels, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters. The description adds no extra semantics beyond implying '_tx_hashes' is the target, which does not exceed the baseline established by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('metadata') for specific transactions, which gives a basic understanding. However, it does not distinguish itself from siblings like koios_tx_info or koios_tx_metalabels, making it clear but not differentiating enough for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 koios_tx_info or koios_tx_metalabels. The description merely states what it does without any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure, but it only states that it lists labels. It does not mention pagination behavior (despite limit/offset parameters in the schema), return format, or whether 'all' implies a single response or paginated results. This is a minimal but incomplete disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately concise for a simple list operation, though it lacks supplementary context that could make it more helpful. Not verbose, but not expansive either.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list endpoint with no output schema, the description should provide more context about what the labels represent, how they relate to transaction metadata, or pagination default behavior. It does not explain the return structure or usage scenario, leaving gaps in completeness for an agent that may be unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters (limit, order, offset, select) are fully described in the schema. The description adds no additional meaning beyond the schema, which is the baseline for full coverage. No special parameter hints are provided, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a list of all transaction metadata labels' uses a specific verb and resource, clearly indicating the action and scope. It is distinct from sibling tools like 'koios_tx_metadata' (which gets metadata for specific transactions) and 'koios_tx_by_metalabel' (which finds transactions by label), but it does not explicitly differentiate itself from these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives, nor does it mention any exclusions or specific use cases. There is no context about querying labels vs metadata or label-based transaction search, leaving the agent without comparative usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 implies a read operation via 'Get', but it does not disclose pagination behavior, response shape, defaults, or other behavioral traits, which is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant content. It is concise and easy to parse, though it provides minimal information beyond the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, a one-sentence description is not complete enough. It does not explain what fields a governance vote contains, how pagination works, or how this differs from similar vote/proposal tools, leaving important context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with descriptions (limit, order, offset, select), giving 100% schema coverage. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the resource ('a list of all governance votes'), making the core purpose clear. However, it does not explicitly distinguish itself from closely related siblings like koios_proposal_votes or koios_voter_proposal_list, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 description only states the basic function and does not mention conditions, exclusions, or related tools such as koios_proposal_list or koios_proposal_votes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only states the resource and action, omitting important details such as whether results are historical, how pagination works, response shape, or any usage caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant words. It immediately states the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives an adequate one-sentence overview for a straightforward query tool, and the schema covers parameter semantics. However, without an output schema or behavioral notes, the description leaves uncertainty about return payload and operational details, keeping it at a minimum viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes all five parameters with individual descriptions, so the description adds little beyond restating that stake addresses are required. Baseline 3 is appropriate because the description does not introduce meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource 'account registration/deregistration updates' scoped to given stake accounts. It clearly distinguishes from many sibling tools, though not from the similarly named 'koios_account_update_history', so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of alternatives such as koios_account_update_history or other account-related queries. The description only states the function without any exclusions or recommended contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only states the basic action. It does not mention that this is a read-only operation, that results are paginated via limit/offset, or what fields are returned. This is particularly insufficient given the lack of an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the tool's purpose. It contains no fluff or repetition, making it an appropriately concise and well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read-only list endpoint with four optional parameters, so the description's brevity is somewhat acceptable. However, the absence of an output schema and the lack of any indication of pagination or relationship to sibling DRep tools means the description is only minimally complete for an agent to fully understand what will be returned and how to choose this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds no additional meaning beyond what the schema already provides for limit, order, offset, and select. While some schema descriptions are thin (e.g., 'Column ordering'), the description itself does not compensate for or enrich these definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with the resource 'list of all registered DReps' and expands the acronym, clearly indicating the action and scope. It distinguishes from DRep-specific tools like koios_drep_info by emphasizing 'all', but it does not explicitly name any sibling alternatives, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as koios_drep_info, koios_drep_updates, or koios_drep_delegators. It also omits any mention of pagination behavior or intended use cases, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention that this is a read-only operation, does not describe pagination behavior or the response structure, and offers no insight into what data fields are returned per pool. The description simply restates the operation without adding transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that earns its place without unnecessary detail. It is concise and front-loaded, but could be marginally improved by adding a brief note about pagination or the nature of the response while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no required parameters, no annotations, no output schema), but the description lacks any indication of what the response looks like or how pagination works. Given the large sibling set, the description does not adequately position the tool's role, making it incomplete for an agent trying to understand the result shape or usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all four parameters (limit, order, offset, select) with descriptions, providing 100% coverage. The tool description adds no additional semantics beyond the schema, so the baseline score of 3 is appropriate because the schema does the heavy lifting and the description does not conflict or add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a list of all registered stake pools' with a specific verb ('Get') and resource ('list of all registered stake pools'). It distinguishes the tool from siblings like koios_pool_info (specific pool) and other pool-related tools by focusing on the list-level operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 over alternatives. With dozens of related pool tools in the sibling list, it fails to mention that this tool is the entry point for browsing all pools or when to prefer it over more targeted queries, leaving the agent without decision-making assistance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 function and does not disclose behavioral traits like pagination, default response size, or that it is a read-only query. Minimal value added beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, front-loaded with the verb and resource. Every word earns its place, with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward query with 5 optional parameters and no output schema, the description is minimal but adequate. It does not explain what fields are returned or any constraints on the query, but the schema covers parameter details. The lack of output schema and any behavioral context leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters. The description adds the meaning that omitting _epoch_no returns all epochs, which is useful, but it does not elaborate on limit, order, offset, or select beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Get' and the resource 'pool retirements', and adds a clear scope ('for a specific epoch or all epochs'). It is specific and avoids tautology, though it does not explicitly distinguish from sibling tools like koios_pool_updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 koios_pool_registrations or koios_pool_updates. The description implies usage for retirements but does not state context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states 'Get', implying a read operation, but does not disclose pagination behavior, default limits, or what constitutes a withdrawal entry. This is minimally informative but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It is appropriately short for a simple read operation, though slightly repetitive with 'treasury' appearing twice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys the core purpose but lacks context such as pagination defaults, response format, or the distinction from reserve withdrawals. Given the four schema-documented parameters and no output schema, more detail would improve selection confidence, yet the essential action is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are already described in the input schema (100% coverage), so the description does not add parameter-level meaning. It correctly implies a paginated query through the schema's limit/offset descriptions, but the description itself contributes nothing beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('treasury withdrawals from the Cardano treasury'). However, it does not distinguish this from the closely related sibling tool `koios_reserve_withdrawals`, so it falls short of full clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives, especially the sibling `koios_reserve_withdrawals`. The description gives no context for selecting between them, and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 fails to clarify that the listed components (inputs, metadata, assets, etc.) are controlled by opt-in boolean flags; the wording 'including' suggests they are always returned. It also doesn't mention pagination, required hashes, or response shape, making it misleading about default behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with an active verb and object. It is efficient, though 'etc.' is vague. Overall, it is concise and structurally sound for a high-level summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, no output schema, and many sibling tools, the description is too brief. It doesn't explain that the components are optional flags, nor does it describe pagination or response structure. It leaves significant gaps for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds little beyond enumerating some parameter groups (inputs, outputs, metadata, assets) and 'etc.', providing no additional semantic detail beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed transaction information, listing key components like inputs, outputs, metadata, and assets. It distinguishes itself from specialized siblings (e.g., koios_tx_metadata, koios_tx_cbor) by signaling a comprehensive scope. However, it doesn't explicitly mention that the input is transaction hashes, though 'specific transactions' implies it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is the primary tool for full transaction details but doesn't mention exclusions or alternatives. Given the many sibling tools (e.g., koios_tx_status, koios_tx_outs_epoch), this is a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as read-only semantics, pagination via limit/offset, or response format. 'Get' implies a read operation but lacks explicit transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that clearly names the action and resource. No unnecessary words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 fails to explain the response structure (e.g., list of assets, quantities, policy IDs) or pagination behavior. For a simple getter, this is a notable gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds minimal semantic value by restating '_stake_addresses' as 'stake accounts', but doesn't go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'native asset holdings' and targets 'stake accounts', clearly distinguishing it from siblings like account_utxos (UTxOs) and address_assets (address-based). The tool name reinforces the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 account_utxos or address_assets. The description merely states the action without any context, exclusions, or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mention pagination behavior (despite limit/offset parameters), return format, or how balances and staking information are structured, which are important for an agent to understand the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. It front-loads the verb and resource, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema, so the description should provide more context about return values, pagination, or typical use cases. It is too brief to fully inform an agent about the tool's capabilities, especially given the large number of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all parameters. The description itself adds no additional parameter semantics beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Get' and specifies the resource 'balance and staking information' scoped to 'given addresses'. This distinguishes it from sibling tools like koios_address_utxos or koios_address_txs which focus on UTXOs or transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description only states what it does without any comparative context or conditions, leaving the agent to infer when it should be selected over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the function. It does not mention pagination, return format, or whether multiple addresses could be returned despite the singular phrasing, which is especially relevant given the limit/offset parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It conveys the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and annotations, and the description provides no information about return values, pagination behavior, or edge cases like not-found scenarios. Despite a well-documented schema, the description is too sparse for a six-parameter tool with pagination options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter coverage with descriptions, so the baseline is 3. The description does not add meaningful syntax or behavioral details beyond the schema; it implies the NFT is identified by policy and optionally name, but _asset_name is not required, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the current address holding a specific NFT, using a specific verb and resource. It distinguishes itself from sibling tools like koios_asset_addresses by focusing on the singular current holder and NFT specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 similar asset-related tools, nor are any alternative tools or exclusions mentioned. The description simply states what the tool does without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It only states the action and data source, omitting details about pagination, rate limits, response format, or any constraints. This is a significant gap for a tool with four pagination parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence that front-loads the action and resource. Every word serves a purpose, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description is under-specified. It does not clarify what 'asset information' entails, how the token registry is structured, or how the limit/offset/select parameters influence the returned data, leaving the agent to infer critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all four parameters, so the baseline is 3. The description adds no extra meaning beyond the schema, which is acceptable given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly identifies the resource as 'asset information from the token registry (off-chain metadata)', distinguishing it from on-chain asset tools like koios_asset_info. The parenthetical qualifier adds precision that differentiates it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The 'off-chain metadata' hint implies a use case but there are no explicit exclusions or comparisons with sibling tools such as koios_asset_info or koios_asset_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 not disclose whether the tool is read-only (though 'Get' implies so), whether it includes spent UTxOs, how pagination works, or any rate-limit implications. There is no mention of output structure or error behavior, leaving the agent without key behavior expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It is concise and front-loaded, immediately conveying the tool's core function. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 6 parameters and no output schema, the description only states the basic function. It does not explain the expected response format, the meaning of 'extended' data, or how the asset list is interpreted. This is insufficient for an agent to invoke the tool correctly, especially with no annotation guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all 6 parameters, achieving 100% coverage. The description's one-liner adds no additional meaning beyond the schema, so the baseline of 3 is appropriate; the schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('UTxOs containing specific assets'), which distinguishes it from sibling tools like asset_addresses or asset_info. The phrasing maps directly to the _asset_list parameter, 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.
Usage Guidelines2/5
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 alternative UTxO lookup tools (e.g., address_utxos, credential_utxos, account_utxos). It lacks context about use cases, prerequisites, or exclusions. The agent is left to guess which tool fits their need.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only states the function, omitting details about pagination, default ordering, required filters, or response structure. This is insufficient for a tool with no structured safety metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler or redundant information. It is front-loaded with the main action and resource, achieving maximum efficiency in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description provides only a minimal function statement. It lacks context about what data is returned, how the votes are structured, or any relationships to other governance objects, making it incomplete for a tool with five parameters and many sibling alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, with each parameter (limit, offset, order, select, _cc_hot_id) already explained. The description adds no extra semantic value, but the schema adequately handles the burden, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and the resource ('Constitutional Committee votes') with a modifier ('on governance proposals'), making it unambiguous. It distinguishes itself from sibling tools like koios_proposal_votes and koios_vote_list by specifying the committee membership.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention exclusions or differentiate from other vote-related tools, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only says 'Get UTxO set' with no mention of pagination, result limits, extended data behavior, or error handling. It does not contradict annotations (none exist), but it omits important behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence with no redundant words. It is appropriately sized for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, this description is incomplete. It does not explain the return format, pagination behavior, or how 'payment credentials' are structured, leaving the agent to infer critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters have schema descriptions giving 100% coverage, so the baseline is 3. The description itself adds no extra parameter semantics beyond what the schema already provides, so it neither improves nor harms understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Get'), the resource ('UTxO set'), and the input type ('given payment credentials'), which distinguishes it from sibling tools like koios_credential_txs or koios_address_utxos. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 koios_address_utxos or koios_account_utxos, nor are any exclusions or prerequisites mentioned. The description simply states what it does without context on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'Get', implying a read-only operation, but does not disclose behavioral details such as pagination behavior, event ordering, or whether the response is a list or a single object. The description adds minimal transparency beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that wastes no words and immediately communicates the core function. It is perfectly sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 should explain what an 'event' contains or what the response looks like. It does not, leaving users to infer the return structure. For a paginated list endpoint with five parameters, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all five parameters. The description adds no extra meaning to the parameters beyond what is already in the schema, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves registration/update events for DReps, using a specific verb and resource. It distinguishes from sibling tools like koios_drep_list and koios_drep_info by focusing on events, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by the description: use this tool when you need DRep registration/update events. However, it provides no explicit guidance on when to prefer this over other DRep-related tools, nor any exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention whether this is a read-only query, pagination behavior, or any caveats about era summaries—it only describes the basic action without revealing side effects or response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose. It is well-structured and front-loaded, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too vague to fully understand what an 'era summary' contains or how results are structured. It fails to specify the return format or any behavioral context, making it insufficient for complete tool understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all four parameters (limit, order, offset, select), giving 100% schema coverage. The description adds no extra parameter context beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('a summary of all eras on the Cardano blockchain'). This distinguishes it from sibling tools that focus on epochs, blocks, or other entities, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives, nor any exclusions. It simply states what the tool does, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 basic function and does not disclose pagination behavior, performance implications, return format, or any side effects. For a potentially large dataset of all Plutus scripts, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core verb and resource. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 optional parameters, no output schema, and no annotations. The description is too terse to fully inform an agent about the response structure, default pagination, or how to use the tool effectively among 100+ siblings. A slightly more detailed description would be warranted given these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (limit, order, offset, select) are already documented in the schema. The description adds no additional parameter semantics but correctly implies the list can be paginated. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a list of all Plutus scripts on the blockchain' uses a specific verb and resource, clearly indicating what the tool returns. It distinguishes from sibling tools like koios_script_info (which targets a specific script) and koios_native_script_list (which lists native scripts rather than Plutus scripts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives, nor does it mention pagination, filtering, or any prerequisites. It is a generic 'get all' statement without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'Get', which implies a read operation, but does not mention required parameters, pagination, result ordering, or any other behavioral traits. The schema covers parameter syntax but not behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently communicates the core purpose. It is front-loaded and contains no wasted words, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, the description is too sparse to provide complete context. It does not explain what owner history entails, how the data is structured, or any other details needed to fully understand the tool's behavior. The schema helps but is insufficient for comprehensive understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with descriptions for every parameter, including the required _pool_bech32_ids and pagination options. The description adds minimal semantic value beyond the schema, only indicating that the query targets 'specific pools'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: fetching owner history for specified pools. The verb 'Get' and resource 'owner history' provide clear intent, and 'specific pools' signals that pool IDs must be provided, distinguishing it from other pool-related tools like pool_info or pool_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need owner history for given pools, but it does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or prerequisites. The context is inferred from the resource name rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions the key filtering behavior (specific epoch or all epochs) but does not disclose pagination, rate limits, default behavior, or that this is a read-only operation beyond the implied 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single succinct sentence that communicates the core functionality without redundancy. It is front-loaded and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 5 optional parameters and no output schema, the description is minimally adequate. It does not explain pagination behavior or return shape, but the name and schema fill some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying that omitting _epoch_no returns registrations for all epochs, which is not explicitly stated in the parameter schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Get pool registrations') and clarifies the epoch scoping. It distinguishes from sibling tools by the resource itself, but does not explicitly address overlapping scope with tools like koios_pool_updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 pool_updates or pool_retirements. The description implies usage for epoch-based lookups but gives no exclusions or comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only says 'Get a list' without indicating pagination behavior, output structure, or any constraints. It implies a read-only action but provides no additional detail about what the response contains or how the list is ordered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. There is no redundant wording or filler, and every word contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should compensate by explaining what the returned list contains, but it does not. It also fails to mention that pagination is supported (though implied by the parameters) or any details about the relay list's scope. The description is minimal and leaves significant ambiguity for a tool with 4 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameters with descriptions, so the schema carries the semantic load. The tool description adds no extra meaning beyond what the schema already provides, which matches the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a specific resource ('registered pool relays'), which clearly distinguishes it from sibling pool-related tools like koios_pool_list or koios_pool_info. The purpose is unambiguous and matches 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.
Usage Guidelines2/5
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, nor are there any exclusions or prerequisites mentioned. The description simply states what it does without contextualizing its use case among the many Koios endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the mark/set/go snapshot types, adding some nuance, but it does not describe the return format, pagination behavior, potential rate limits, or whether the operation is read-only. This is a minimal disclosure for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the essential information without unnecessary words. Every part adds value, and the parenthetical clarification about snapshot types is compact yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain what the tool returns, but it does not describe the response structure or any paging details. Given the tool's specificity and the lack of annotations, the description feels incomplete for an agent needing to understand the full context of the result, especially with multiple snapshot types mentioned but not explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are already described in the schema, so baseline starts at 3. The description does not add any additional meaning to the parameters beyond what the schema provides, such as explaining how _pool_bech32 relates to the snapshot types or how limit/offset interact with the snapshot sets.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('stake snapshot for a specific pool') while adding the distinctive qualifier '(mark, set, go snapshots)'. This distinguishes the tool from other pool-related siblings like pool_delegators or pool_history, making the purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other pool-related tools, nor does it mention any prerequisites or alternative tools. It simply states what the tool does without contextualizing its use case among the many sibling koios pool endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 that votes are fetched, but does not mention pagination behavior, result format, or any other operational details. The schema shows limit/offset, yet the description offers no behavioral context beyond the basic read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It effectively communicates the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is too thin. It does not explain pagination parameters, return value expectations, or any operational nuances, making it incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add meaning beyond what the schema already provides, but it does align with the _proposal_id parameter' s purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: "Get all votes cast on a specific governance proposal." It is specific with a verb and resource, and the scoping to a single proposal distinguishes it from broader vote-listing tools, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description: an agent would use this when needing votes for a specific proposal. However, there is no explicit guidance on when to prefer this over siblings like koios_vote_list or koios_proposal_voting_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey all behavioral context. It only states that it retrieves information; it does not disclose that it is a read-only operation, any pagination behavior, potential large result sets, or what 'information' includes. This is a minimal disclosure that leaves the agent to infer safety and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of nine words, front-loaded with the action and resource. It contains no fluff or redundant details, making it highly efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 is insufficiently complete. It does not specify what script information will be returned (e.g., script type, bytecode, or associated data), nor does it clarify whether both native and Plutus scripts are covered. For a tool with no output schema, the description should carry more context to compensate, but it leaves significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with descriptive parameters like _script_hashes, limit, offset, etc. The description adds no semantic value beyond the schema – it only corroborates that lookup is by hashes. Baseline 3 is appropriate because the schema fully documents parameters and the description does not contribute additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get information about specific scripts by their hashes' uses a clear verb ('Get') and resource ('information about scripts'), with a specific qualifier ('by their hashes') that distinguishes it from list-oriented siblings like koios_native_script_list. It directly states what the tool does in a concise, unambiguous manner.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It implies usage when you have script hashes, but does not explicitly state this or mention any sibling tools (e.g., koios_plutus_script_list for listing scripts). There is no 'use X instead' or 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the basic read operation and does not reveal any details about response structure, pagination behavior, ordering, or any side effects. The schema provides parameter descriptions, but the description adds no behavioral context beyond the title.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly front-loads the verb and resource. It contains no unnecessary words or repetition, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description only provides the bare minimum. It does not explain what the redeemer information contains, how results are returned, or any limitations. This is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the description is not required to explain them. The description itself does not add any parameter semantics beyond what the schema provides, meriting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the specific resource 'redeemer information for a specific script'. This distinguishes it from sibling tools like script_info or datum_info by focusing on redeemers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternative sibling tools. There is no mention of prerequisites, exclusions, or cross-references, so an agent cannot determine if this is the right tool for a given scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior, but it only states the data scope and does not mention return format, default pagination, behavior when _epoch_no is omitted, or any filtering limits. This leaves significant behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that starts with the verb 'Get' and includes only meaningful details. There is no redundancy or filler, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 compensate by describing return structure or typical data shape, but it does not. The tool has 5 optional parameters, yet the description only hints at the epoch context, leaving the overall behavior and response under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%—every parameter (limit, order, offset, select, _epoch_no) has a description in the input schema. The tool description adds no further parameter detail, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and specifies the resource as 'tokenomic statistics' with concrete categories (supply, staking, treasury, reserves) and the scope 'per epoch'. This distinguishes it from sibling tools like koios_epoch_info or koios_genesis by focusing specifically on token metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, and no exclusions or preconditions are mentioned. The description only implies its use via the stated purpose, but there is no explicit 'when to use' or reference to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 claims to return 'all' outputs but does not mention pagination (limit/offset), ordering, or that results may be limited, which is a significant omission. It also does not clarify whether this is a read-only operation or what the response shape 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. Every word contributes to conveying the core function, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, no output schema, and no annotations, the description is too sparse. It does not explain how pagination works, what fields are returned, how 'all' interacts with limit/offset, or any rate-limit or permission context. This is a complex query tool, and the minimal description leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all five parameters have descriptions in the schema itself. The tool description adds no parameter-specific meaning beyond the schema, but it does not need to because the schema is already self-documenting. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('transaction outputs') with a clear scope ('for a specific epoch'), making its purpose unambiguous. It distinguishes itself from sibling tools like koios_tx_info or koios_address_outputs by focusing on all transaction outputs at the epoch level, so the agent can select it appropriately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention exclusions, prerequisites, or comparisons with siblings such as koios_tx_info, koios_address_outputs, or koios_utxo_info. The description implies its use case but offers no explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 that the operation is a read ('Get'), but does not mention pagination, default filtering (e.g., whether empty addresses are excluded), or response shape. This is minimal behavioral disclosure for a tool with multiple filtering parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundant wording. It is front-loaded with the key action and resource, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 only covers the core purpose. It does not mention pagination, the meaning of '_empty' or '_first_only' (though these are in the schema), or how results are returned. For a tool with 7 parameters, this is adequate but has clear gaps in behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 7 parameters described. The description adds no parameter-specific meaning, but the schema already fully documents them, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'payment addresses', and the scope 'associated with given stake accounts'. This distinguishes it from sibling account tools like account_info or account_utxos, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any exclusions or prerequisites. The description simply states what the tool does without contextualizing its appropriate use among the many account-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'get information' and lists some data categories. It does not disclose pagination behavior, default limits, live vs cached data, or any side effects, leaving the agent unaware of important operational characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and includes the key input and output context. Every word earns its place with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide enough context about return shape and operational details. It mentions balance, delegation, and rewards, which is helpful, but it does not describe the output structure, pagination, or distinction from cached alternatives, leaving moderate gaps for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 5 parameters already described in the schema. The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves stake account information, specifying key data categories (balance, delegation, rewards) and the input type (stake addresses). However, it does not differentiate from the closely related sibling koios_account_info_cached, leaving potential ambiguity about which variant to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you need stake account details for given addresses. It does not explicitly mention when to avoid this tool, nor does it reference alternatives like koios_account_info_cached or other account-focused tools, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Get' implying read-only, but does not disclose pagination behavior, response format, or any potential side effects. For a query tool without annotations, more behavioral context would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the key action and resource, zero waste. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys the core purpose but lacks detail on pagination, return value shape, or edge cases. With no output schema and no annotations, the description is minimal but adequate for a simple read query. It doesn't explicitly state that results are paginated despite the schema including limit/offset, so there's a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already describes all parameters. The description adds no additional parameter semantics beyond linking 'stake accounts' to the required parameter. With high schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and resource 'stake history' with detail 'active stake per epoch', which clearly distinguishes it from sibling tools like koios_account_reward_history. It clearly states the scope (for given stake accounts), meeting the criteria for specific verb+resource+scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It doesn't mention exclusions or alternative tools like reward history or account info. The usage is only implied by the description itself, with no explicit when/where guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action ('Get detailed information') and does not disclose anything about response format, error handling, rate limits, or that it is a read-only safe operation. The description is a restatement of purpose rather than a disclosure of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the tool's core purpose. Every word contributes meaning, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally viable: it clearly states the purpose and the schema fully documents parameters. However, there is no output schema, and the description does not indicate what 'detailed information' includes or how to interpret the response. Given the simplicity of the tool and rich schema, this is adequate but leaves gaps in expectations about return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the schema. The description adds minimal extra meaning beyond the main parameter `_block_hashes`, which is also described in the schema. Per the rubric, the baseline of 3 applies here since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get detailed information') and resource ('specific blocks') with the input method ('by their hashes'), distinguishing it from sibling tools like koios_blocks or koios_block_txs. This is a specific verb+resource combination that leaves no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as koios_blocks, koios_block_txs, or koios_block_tx_cbor. There is no mention of exclusion criteria or preferred use cases, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 ordering (latest first) and pagination support, but lacks information about default limits, response shape, whether it returns full block details or summaries, rate limits, or any other side effects. Minimal behavioral disclosure beyond the obvious read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, focused sentence that leads with the main verb and resource, followed by core details. No fluff or repetition of schema information. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list endpoint with fully documented schema parameters, the description covers the core functionality. However, with no output schema, it doesn't mention return value structure or defaults (e.g., block id vs full block). It is adequate but leaves some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The description adds 'latest first' and 'pagination support' which aligns with the order and limit/offset parameters, but doesn't explain parameter interactions or provide syntax examples. It meets the baseline but doesn't enhance meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description has a clear verb (Get), resource (blocks), and distinguishing details (latest first, pagination support). It contrasts with sibling tools like block_info or block_txs, which handle specific blocks or transactions, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention that for a single block you'd use koios_block_info, or that this is the primary list endpoint. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It only says 'Get' without mentioning pagination (despite limit/offset in schema), response format, or that results may be ordered. No information about rate limits or filtering by epoch is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no wasted words. It is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward read query, but with no output schema and no annotations, the description could be more complete. It doesn't mention the historical/epochal aspect or potential large result sets requiring pagination, though the schema provides parameter hints. Overall, it is minimally adequate but leaves room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so based on the rubric the baseline is 3. The description adds no additional parameter context beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('voting power history'), and the target ('specific DRep'). It distinguishes itself from sibling DRep tools like koios_drep_info or koios_drep_epoch_summary by naming the specific data being fetched.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. The description only states what it does, leaving the AI agent without explicit decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description provides no additional behavioral context such as pagination behavior, output format, data scoping, or any side effects. It only restates the essential purpose, leaving the agent without insights into how the endpoint behaves beyond the literal request.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is front-loaded with the action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys the core purpose but lacks additional context given the absence of an output schema and annotations. It would benefit from mentioning typical response fields or clarifying that it returns a list of proposals. However, for a simple, parameterized query endpoint, the minimal description is moderately acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover all four parameters (limit, order, offset, select) with sufficient detail, so the tool description need not explain them. The description adds no parameter-level meaning, but the schema already provides adequate semantics, yielding the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Get') and resource ('protocol parameter update proposals') with a context qualifier ('submitted on-chain'). This distinguishes it from related endpoints like koios_cli_protocol_params, which likely returns current parameters, not proposals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Sibling tools include koios_cli_protocol_params, but the description does not differentiate or recommend when to choose this endpoint. The usage is implied by the purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'Get', implying a read operation, but does not explain what 'invalid delegators' means, what data is returned, or any operational characteristics like pagination or epoch-specific behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It efficiently communicates the essential purpose and required target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple list endpoint with all parameters documented in the schema, but no output schema exists and the description does not clarify the concept of 'invalid delegators' or the return format. This leaves some ambiguity for an agent deciding whether this tool meets its needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters have descriptions in the input schema, covering 100% of parameter semantics. The description itself adds no additional parameter context, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the specific resource ('invalid delegators'), and the target ('for a specific pool'). It distinguishes this tool from sibling tools like koios_pool_delegators by adding the 'invalid' qualifier, which makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives, such as koios_pool_delegators or koios_pool_delegators_history. There is no mention of prerequisites, exclusions, or recommended contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the basic function without explaining whether the response is a list or a single object, how pagination parameters affect results, or what fields are returned. This is a significant gap for a tool with pagination parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It is appropriately sized and front-loaded, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema fully documents all parameters, but the description lacks context about the return shape and the effect of pagination on a 'tip' query. Without an output schema, this omission leaves room for ambiguity, though the core purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the current chain tip (latest block) of the Cardano blockchain. The verb 'Get' and resource 'chain tip' are specific, and the parenthetical explanation distinguishes it from sibling tools that query specific blocks or other chain data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It does not mention whether this is the canonical way to get the latest block, nor does it suggest any other relevant tools for related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'first appearance on the blockchain' which is a useful behavioral detail, but it does not disclose pagination behavior, ordering defaults, or the potentially large result set. The tool's read-only nature is implied but not explicitly stated, and there is no mention of rate limits or response format. This provides minimal transparency beyond the core operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose without any redundant or unnecessary words. It is well-structured and front-loaded with the key information, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four pagination/format parameters, no output schema, and no annotations, the description is insufficiently complete. It does not explain pagination behavior, describe expected response fields, or provide guidance on when to use this tool versus address-specific alternatives. The agent receives only the core purpose but lacks critical context for correct invocation and interpretation of results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% description coverage for all four parameters (limit, order, offset, select), so the baseline is 3. The description does not add any additional meaning or context to these parameters; it merely states the overall purpose. No extra value is provided beyond what the schema already explains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource (list of all addresses) with a distinctive qualifier ('with their first appearance on the blockchain'). This effectively distinguishes it from sibling tools like koios_address_info which target specific addresses, and from other list tools like koios_account_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a comprehensive list of addresses via the phrase 'all addresses', which contrasts with sibling tools for individual address lookups. However, it does not explicitly state when to use this tool versus alternatives, nor provide any exclusion criteria or prerequisites. The usage context is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 basic action and does not disclose behavioral traits such as pagination behavior, that multiple addresses are accepted, or that only hashes are returned without full transaction details. The read-only nature is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words, front-loaded with the action and resource. It is appropriately sized for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters and no output schema, the description is too sparse. It does not explain the response shape, pagination behavior, or how to combine parameters, leaving the agent with gaps in understanding the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 6 parameters, including descriptions for limit, order, offset, select, _addresses, and _after_block_height. The description itself adds no extra parameter information, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('transaction hashes for given addresses'), clearly distinguishing this from sibling tools like koios_address_utxos or koios_address_info. It is unambiguous about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the tool's name and description, but there is no explicit guidance on when to use this versus alternatives such as koios_address_utxos or koios_address_outputs. No exclusions or preferred contexts are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states the basic read operation and reveals nothing about pagination, response structure, error conditions, or other behavioral nuances. This is a clear gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no superfluous content. It is appropriately sized and front-loaded with the key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must provide more context about what the returned history contains (e.g., fields, pagination behavior). The current description is minimal and leaves significant ambiguity about the response format and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description itself adds no parameter-level semantics beyond identifying the target asset, but the schema already handles this adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get mint/burn history of a specific asset' uses a specific verb and resource, clearly distinguishing this tool from sibling asset tools like koios_asset_info and koios_asset_txs. It unambiguously states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching mint/burn history but provides no explicit guidance on when to use this tool versus related asset tools. It lacks any exclusionary or alternative-indicating language.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'Get' implies a read operation, it does not disclose behavioral traits such as pagination limits, rate limits, error behavior, or side effects. The parenthetical lists return content, not operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the actionable verb and resource. The parenthetical adds relevant clarifying information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description provides a partial list of return fields, which is sufficient for basic invocation. It does not describe the full return structure or edge cases, but given the tool's simplicity and the rich schema, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3 applies. The description does not add parameter-level details beyond the schema, but the parenthetical hints at what the asset summary contains, which helps infer the role of policy/name parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('summary of a specific asset'), with a parenthetical enumerating key return fields (total transactions, wallets, mints/burns). This differentiates it from sibling tools like koios_asset_info or koios_asset_list by emphasizing a summary view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives. It does not mention distinguishing scenarios, exclusions, or recommend it for overviews vs detailed history, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mention pagination behavior, default epoch selection if _epoch_no is omitted, or the structure of the returned distribution. The description only states the high-level action without any behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste. It succinctly conveys the tool's purpose without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations. The description is too minimal to be complete. It does not clarify what happens when no epoch is specified, how the results are paginated or formatted, or provide examples. This falls short for an agent needing to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides, but does not need to compensate for missing schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to retrieve block protocol distribution for a specific epoch. The verb 'Get' is specific, the resource 'block protocol distribution' is clearly defined, and the scope 'specific epoch' distinguishes it from other epoch-related tools such as koios_epoch_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when block protocol distribution data for an epoch is needed, but it does not explicitly mention alternatives or when not to use the tool. There is no exclusion criteria or comparison with sibling tools, so it relies on the purpose being self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the action and resource, but doesn't disclose pagination behavior (despite limit/offset parameters), whether all results are returned at once, or any other operational characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler, making it highly concise and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters and no output schema, yet the description offers no information about pagination, response format, or ordering. An agent would need to infer behavior from the schema alone, leaving gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all five parameters, so the description adds no further parameter semantics. The phrase 'under a given policy' maps to _asset_policy but doesn't enrich the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('all assets minted under a given policy'), clearly distinguishing it from sibling tools like koios_asset_list or koios_policy_asset_mints by specifying the policy filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance is provided. The description implies it is the tool to use for retrieving assets by policy, but it does not mention when to prefer it over similar sibling tools (e.g., koios_policy_asset_mints) or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry full disclosure of behavior. It only states the basic function and does not mention pagination (limit/offset), ordering, filtering by epoch, or what fields are returned. There is no information about rate limits, output format, or how the tool handles missing/invalid pool IDs. This is a significant gap for an API endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource. It wastes no words and is easy to scan. It could be considered too terse for behavioral transparency, but as a purpose statement it is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, and the description is minimal. It does not explain that the endpoint is paginated, what a 'block' record looks like, or how the optional filters (epoch, select, order) affect results. The description leaves an agent without enough context to know what to expect in the response or how to construct effective queries beyond the schema field names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with each parameter (limit, order, offset, select, _epoch_no, _pool_bech32) having a description. The tool description adds no extra parameter semantics beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('blocks') and a specific scope ('minted by a specific pool'). It clearly distinguishes this from sibling tools like koios_blocks, which likely returns all blocks or general block information, and from pool-level tools like koios_pool_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by a specific pool' implies this tool is for querying blocks associated with a pool, giving some usage context. However, it does not explicitly state when to use this versus alternatives such as koios_blocks, nor does it mention any prerequisites (e.g., needing a pool ID in bech32 format) or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says to 'get current delegators' and does not disclose pagination behavior, response shape, data freshness, or whether this is a read-only operation beyond the implicit 'get' verb. The word 'current' adds some nuance but not enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Get current delegators for a specific pool.' Every word is substantive and there is no extra verbosity, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations, yet the description provides only a one-line summary. It does not describe return values, pagination behavior, or how this compares to the sibling history/invalid delegators tools, leaving the description incomplete for an agent to understand what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 even with no parameter details in the tool description. The description does not repeat or add to the parameter information beyond naming the pool as the scope, but the schema already documents _pool_bech32, limit, order, offset, and select.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'current delegators' scoped to 'a specific pool.' The adjective 'current' distinguishes this from sibling tools like koios_pool_delegators_history and koios_pool_invalid_delegators, satisfying the requirement for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context of retrieving current delegators is clear, and the word 'current' implies this is not for historical or invalid delegator queries. However, it provides no explicit guidance about when to choose this tool over the closely related koios_pool_delegators_history, koios_pool_invalid_delegators, or koios_drep_delegators.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure burden. It only states the basic action without mentioning pagination behavior (limit/offset), epoch filtering, rate limits, or any side effects. While 'Get' implies a read operation, the description provides minimal behavioral context beyond the literal action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence with no unnecessary words. It front-loads the core purpose clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too sparse to provide adequate context. It does not explain what 'historical' means (e.g., delegators at a specific epoch vs. all historical changes), how pagination works, or how this tool relates to 'koios_pool_delegators'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 6 parameters having descriptions. The description itself adds no parameter-specific information, so it meets the baseline of 3. It does not clarify the meaning of 'historical' in relation to the epoch parameter or how limit/offset interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('historical delegators for a specific pool'). The word 'historical' distinguishes it from the sibling tool 'koios_pool_delegators', which likely returns current delegators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for historical delegator data but does not explicitly state when to use it over alternatives. The sibling tool 'koios_pool_delegators' suggests a current-delegators counterpart, but the description does not mention this distinction or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full burden of behavioral disclosure, but it only provides a high-level noun phrase. It does not mention pagination behavior, handling of the optional _pool_bech32 filter, or what data is returned in each certificate type. This is a significant gap for a tool with optional parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It front-loads the action and resource, keeping the entire content easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations, yet the description is only a one-line summary. It fails to explain the distinction between registration, update, and retirement certificates, or how the optional pool filter behaves. This leaves the agent without enough context to select and invoke correctly in non-trivial cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all 5 parameters, including type constraints and meaning (e.g., 'Pool ID in bech32 format'). Since schema_description_coverage is 100%, the baseline is 3; the description itself adds no additional parameter semantics beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get pool registration/update/retirement certificates' clearly specifies the action (get) and the resource (pool certificates). It distinguishes from sibling tools like koios_pool_registrations and koios_pool_retirements by covering all three certificate types in one endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving pool certificates across registration, update, and retirement, but it does not explicitly mention alternatives or when to choose this over the more specific pool_registrations/pool_retirements endpoints. The scope is clear enough for a user to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states a basic read action and does not mention pagination, extended data options, output format, or potential limitations. The agent receives minimal behavioral context beyond the operation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the action and target format. Every word is essential, and there is no unnecessary detail or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite rich schema coverage, there is no output schema and no annotations. The description is too terse to be fully self-sufficient; it fails to describe return values, pagination behavior, or the optional extended data flag. For a relatively simple tool, it still leaves meaningful gaps in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for all 6 parameters, with each property described. The tool description adds no additional parameter semantics; it merely repeats the format already found in the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'UTxO information', and specifies the exact input format (tx_hash#tx_index). This distinguishes it from sibling UTxO tools that operate by address, credential, or asset, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when UTxO references are available, but it does not explicitly state when to use this tool over alternatives or mention sibling tools like address_utxos or asset_utxos. The context is present but relies on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states that the tool returns governance proposals for a voter, but does not disclose response format, pagination behavior, what happens when _voter_id is omitted, or whether any side effects occur. The word 'Get' implies a read operation, but beyond that the behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant phrases or filler. It is front-loaded with the core action and resource, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, moderate parameter complexity (five params, pagination, filtering), and no annotations, the description leaves key context unstated, such as the response structure, the optionality/behavior of _voter_id, and how pagination works. The brief description is not enough for an agent to fully understand expected inputs and outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter description coverage, including _voter_id's meaning as 'Voter ID (DRep, SPO, or CC member)'. The description adds little beyond restating the voter focus, so it neither enhances nor harms the schema-driven understanding. A baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get governance proposals relevant to a specific voter' clearly states the action (get) and resource (governance proposals) while scoping it to a specific voter, which distinguishes it from sibling tools like koios_proposal_list. This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'relevant to a specific voter' implies the tool should be used when querying voter-governance interactions, but it does not explicitly state when to use this tool over alternatives like koios_proposal_list. No exclusions or alternative tool references are provided, making the guidance primarily implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only states the basic action. It does not reveal that the endpoint is paginated (despite the pagination parameters in the schema), what the response format is, or any rate-limit or data-scope caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is entirely on-topic, with no tautology or filler. It is immediately front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a paginated list endpoint) and the absence of an output schema, the description provides only the core purpose. It omits the response format and pagination details, which are partially inferable from the schema but not explicitly connected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all four parameters (limit, order, offset, select) with thorough descriptions, so the description adds no parameter semantics beyond what is already structured. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get a list' and identifies the resource as 'all stake accounts on the Cardano blockchain', clearly distinguishing it from sibling tools like koios_account_info which target individual accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives like koios_account_info, koios_account_utxos, or koios_account_addresses. Usage is only implied by the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The word 'Get' signals a read-only operation, which is the primary behavioral disclosure. However, with no annotations, the description carries the full burden and does not mention pagination, response format, or any potential side effects. It is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff or redundancy. It concisely captures the tool's essence without being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description communicates the core purpose but lacks detail about the returned data structure, which is relevant given no output schema. It does not mention that results are paginated, although that is inferable from the limit/offset parameters. For a simple read tool, this is acceptable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds no parameter-specific meaning beyond the schema, which already clearly documents each parameter including the required _block_hashes array.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('a list of all transactions included in specific blocks'). It accurately conveys the tool's function and distinguishes it from sibling tools like block_info or block_tx_cbor, which focus on different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It does not mention any prerequisites, exclusions, or situations where another tool might be more appropriate, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden for behavioral context. It only states the basic action and provides no details on authentication, rate limits, error formats, response structure, or whether operations are read-only. This is a significant gap for a generic proxy tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the purpose, resource, and example methods. It contains no wasted words and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a generic proxy to Ogmios, the description provides the core concept but lacks an enumeration of supported methods beyond the 'etc.', expected response behavior, or any restrictions. The absence of an output schema increases the need for such context, making the description minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as both parameters have descriptions. The tool description adds some examples for the 'method' parameter but does not go beyond the schema's 'Ogmios JSON-RPC method name' and 'Optional parameters' text. The baseline of 3 is appropriate since the schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Send a JSON-RPC request' and the resource 'Ogmios endpoint via Koios'. It also gives specific method examples (queryLedgerState, queryNetwork) which distinguishes it from sibling tools that are all dedicated Koios API endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: since this is the only tool mentioning Ogmios, an agent can infer it is for Ogmios methods not covered by other Koios endpoints. However, no explicit when-to-use vs alternatives or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action and resource, with no mention of pagination behavior, response format, or how invalid hashes are handled. The description adds little beyond what the schema already provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words. It is front-loaded and immediately conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple query tool with no output schema, the description is minimally adequate but lacks context about what fields are returned or any behavioral notes. The schema covers parameter details, but the description could be improved by mentioning the UTxO output structure or typical use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds a small amount of context by clarifying that the script hashes are used to find reference script UTxOs, but it does not elaborate on the relationship between parameters or their specific use beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and specific resource 'UTxOs containing reference scripts for given script hashes'. This distinguishes it from sibling tools like address_utxos or utxo_info by specifying the reference script filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you have script hashes and need reference script UTxOs, but it does not explicitly state when to prefer this over alternatives like koios_script_info or koios_utxo_info. No exclusions or alternative guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the core write action but does not disclose side effects (e.g., network submission, possible rejection), required permissions, idempotency, or return value. An agent cannot infer what happens after submission or what error conditions may arise.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that is front-loaded with the action and resource. Every word earns its place; there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single parameter and a clear action, but no output schema and no annotations. The description covers the core operation but omits behavioral context (e.g., what the API returns, failure modes, or whether the transaction is broadcast synchronously). It is minimally adequate but leaves gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter is already documented in the input schema. The description reinforces the parameter meaning ('CBOR-encoded hex string') but adds no extra details like size limits or encoding requirements. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Submit') and identifies the resource ('already serialized transaction (CBOR-encoded hex string)') and target ('Cardano network'), clearly distinguishing it from all read-only sibling tools. It is concise and unambiguous about the action performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case — when you have a serialized transaction to submit — but does not state prerequisites (e.g., transaction must be signed) or exclusions. It also does not explicitly distinguish from potential alternatives like koios_ogmios, though the serialized-transaction framing offers some context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the output type ('raw CBOR-encoded transactions') but omits details about response structure (e.g., keyed by hash), error handling for missing hashes, pagination behavior, or any side effects. This is minimal disclosure for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence: 'Get raw CBOR-encoded transactions by their hashes'. It is front-loaded, specific, and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool, the description conveys the core purpose but does not explain the response format (e.g., how CBOR is returned or keyed) or how the pagination parameters (limit, offset) affect results. Given the absence of an output schema, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all 5 parameters, including the required `_tx_hashes`. The description only reinforces that hashes are transaction hashes, adding little beyond the schema. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('raw CBOR-encoded transactions') filtered by hashes. It distinguishes itself from sibling tools like koios_tx_info and koios_tx_metadata, which provide decoded or metadata information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by their hashes' implies the tool is used when transaction hashes are available and raw CBOR is needed. However, there is no explicit comparison to alternatives or guidance on when not to use this tool, leaving the context solely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the key behavioral trait of using cached data (faster but potentially stale), which is valuable. However, it does not elaborate on the caching mechanism, response format, or explicitly confirm read-only nature (though 'get' implies it). This is moderate disclosure, not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and efficiently appends the trade-off. Every phrase contributes meaning without redundancy or excess length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a cached read tool, the description successfully conveys the core behavior and trade-off. The schema covers all parameters, and the description is sufficient for basic usage. However, the lack of an output schema and explicit cross-reference to the non-cached sibling prevents a perfect completeness score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for 100% of the 5 parameters, meeting the high-coverage baseline of 3. The tool description adds no additional parameter context beyond what the schema already documents, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the resource ('cached stake account information'), making the purpose clear. The 'cached' modifier distinguishes it from the sibling koios_account_info, though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'faster but may be slightly stale' implies when to use this tool (when speed is preferred and slight staleness is acceptable), but it does not explicitly state when not to use it or mention the fresh-data alternative (koios_account_info). The guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'Get datum information' without disclosing any behavioral traits such as pagination, ordering, read-only nature, error handling, or what fields are returned. This is minimal and leaves the agent guessing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no redundant words. It is front-loaded with the action and resource, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too sparse. It doesn't explain what 'datum information' includes, how the hashes affect the response, or any pagination behavior. For a tool with five parameters, this lacks essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it doesn't explain how the hashes are used or the role of pagination parameters. The schema already documents each parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and clearly identifies the resource 'datum information' scoped to 'given datum hashes'. This unambiguously distinguishes it from all sibling tools, none of which target datums.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage: call this tool when you have datum hashes and need information about them. No explicit alternatives or exclusions are given, but the context is clear and there is no overlapping sibling tool to confuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Get' implies read-only, and 'current' provides a temporal scope, but the description does not disclose pagination behavior, response format, or any prerequisites. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. Every word contributes to the meaning, making it exceptionally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema covers parameters thoroughly, the description does not explain what the response contains (e.g., list of stake addresses, fields available via 'select') or that results are paginated via limit/offset. With no output schema, this leaves the agent without critical context about return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters. The description adds no extra meaning or guidance about the parameters, matching the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get), the resource (delegators), and the scope (for a specific DRep). It distinguishes itself from sibling tools like koios_drep_info and koios_drep_list, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: if you need to retrieve delegators for a DRep, this is the tool. However, it provides no explicit guidance on when to use it versus alternatives, nor any exclusions or context such as 'for historical delegators, use X'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It adds context by specifying the included fields (times, block counts, tx counts) and clearly implies a read-only operation. However, it does not disclose default behavior (e.g., which epoch is returned when _epoch_no is omitted) or pagination defaults, which are only implied by the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the action ('Get epoch-specific information') and specific content. Every phrase contributes value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only info tool with a well-described schema, the description is largely sufficient. It lacks an output schema, so mentioning the likely return structure or default epoch selection would improve completeness, but the current text plus schema provide enough to understand basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full descriptions for all 6 parameters, achieving 100% coverage. The tool description adds no additional parameter semantics beyond what the schema already documents, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'epoch-specific information' and enumerates three key data fields (start/end times, block counts, transaction counts). This distinguishes it from sibling epoch-related tools like koios_epoch_params or koios_epoch_block_protocols, which have narrower focus areas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 compared to alternatives such as koios_epoch_params or koios_epoch_info. It does not mention any exclusions, prerequisites, or typical use cases, leaving the agent to infer usage from the tool name and field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses one behavioral trait: 'including spent' outputs, which differentiates it from typical UTxO endpoints. However, it does not mention pagination behavior, output size limits, or any side effects (though this is a GET-like operation). The description is minimal and leaves the agent to infer most behavioral details from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is highly concise with no filler. It efficiently communicates the core function in 8 words. Structure is clean and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations, yet the description only states the basic function without explaining the return format, pagination expectations, or how this endpoint differs from similar address-related siblings. Given the large sibling list, this lack of differentiation may cause selection confusion. However, the schema covers parameters, so the description's brevity is partially acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 6 parameters, so the baseline is 3. The description adds no additional parameter-level information beyond what the schema already provides. It does not explain parameter relationships or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with resource 'transaction outputs' and scope 'given addresses', and the parenthetical 'including spent' adds important scope distinction. This clearly distinguishes it from sibling tools like koios_address_utxos, which would not include spent outputs. Purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 vs alternatives like koios_address_utxos or koios_address_txs. The phrase 'including spent' implies a use case for retrieving both spent and unspent outputs, but there is no direct mention of alternatives or exclusions. This is implied usage at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral transparency. It merely states 'Get all addresses' and does not disclose pagination behavior, ordering, or any caveats about what 'all' includes (e.g., zero-balance addresses). No additional context is provided 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no wasted words. Every word contributes to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple query tool, and the schema covers parameter details. However, it lacks any contextual information about the response shape, pagination behavior, or typical use cases. Given the absence of an output schema and the brevity of the description, it feels minimally complete but with room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description does not add any extra meaning to the parameters beyond what the schema already provides, such as the distinction between _asset_policy and _asset_name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all addresses holding a specific asset' clearly states a specific action (get) and resource (addresses) with a qualifier (holding a specific asset). It distinguishes from sibling tools like koios_asset_utxos (which retrieves UTXOs) and koios_asset_nft_address (which retrieves the address of an NFT).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to retrieve addresses that hold a given asset. It does not mention exclusions or alternative tools, but the context is unambiguous given the sibling list. A score of 4 reflects clear context without explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It only states the purpose; it does not disclose pagination behavior, response format, rate limits, or any caveats. The schema implies pagination via limit/offset, but the description itself adds no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, no redundancy, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple list endpoint, but without annotations or output schema, it doesn't explain return values or pagination behavior, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters with meaningful explanations. The tool description adds no parameter-specific information, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('list of all native scripts'), and explicitly clarifies non-Plutus, distinguishing it from sibling koios_plutus_script_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'non-Plutus' implies this tool is for native scripts versus Plutus scripts, but it does not explicitly name the alternative or provide when-not-to-use guidance. Sibling koios_plutus_script_list exists, so the guidance is clear but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to mention that results are paginated via the limit/offset parameters, despite saying 'all' events. It also doesn't clarify what an 'event' contains, which is a behavioral gap given there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the tool's purpose. There is no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema, the description is minimal. It doesn't explain the shape of returned events (e.g., amounts, tx hashes, timestamps), which is needed for complete understanding. However, the schema-rich input parameters partially compensate, making this a mediocre but not deficient description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds no additional parameter semantics. All parameters (limit, order, offset, select, _asset_policy) are already well documented in the schema, so the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('all mint/burn events for assets under a specific policy'). It distinguishes from siblings like policy_asset_list (which lists assets) and asset_history (which covers individual asset history).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for mint/burn events at the policy level, which implies appropriate use cases. It does not explicitly name alternatives or exclusions, but the policy-level scoping helps differentiate it from similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states 'Get a list' with no mention of pagination behavior, default ordering, response format, rate limits, or required permissions. While the read-only nature is implied, the description lacks meaningful behavioral context beyond the obvious action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clean sentence of 8 words. It is front-loaded with the verb and resource, with no wasted words or redundant phrases. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 optional parameters and no output schema. The description only says it lists proposals, but does not explain the response structure, pagination semantics, or any nuances like whether all proposals are returned in a single call or requires multiple requests. Given the lack of annotations and output schema, the description is minimally adequate but leaves gaps about behavior and return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (limit, order, offset, select) described in the schema. The description adds no additional parameter semantics or examples, so the baseline 3 is appropriate. The description does not compensate or enhance meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a list of all governance proposals' uses a specific verb ('Get') and a clear resource ('list of all governance proposals'). It distinguishes itself from sibling tools like koios_voter_proposal_list (voter-specific) and koios_proposal_votes (votes), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'all governance proposals' implies this is the general list endpoint, contrasting with more specific sibling tools. However, it does not explicitly state when to prefer this tool over alternatives or mention exclusions like voter-specific proposals or voting summaries. It gives clear context but no direct comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the output is transaction hashes rather than full transactions, indicating a read-only operation via 'Get'. However, it doesn't mention pagination behavior, ordering defaults, or error handling, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short, front-loaded sentence: 'Get transaction hashes for given payment credentials.' Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool; the description and schema together cover the essential input (payment credentials array with pagination parameters) and output (transaction hashes). However, it lacks explicit mention of return format or default behavior, and there is no output schema to fill the gap, so a small deduction applies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all six parameters described in the input schema. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb ('Get'), the resource ('transaction hashes'), and the input scope ('for given payment credentials'). This distinguishes it from sibling tools like koios_credential_utxos (which returns UTXOs) and koios_address_txs (which uses addresses instead of credentials).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives such as koios_address_txs or koios_credential_utxos. The usage is implied by the description's focus on payment credentials, but there is no clear context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 disclose the core behavior (returns number of confirmations), but it doesn't mention that it's a read-only operation, nor does it describe pagination, error handling, or response structure beyond the confirmation count. It's transparent about the main action but lacks richer context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 10 words. Every word contributes meaning, and there is no redundancy or filler. It earns a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description adequately covers the main purpose and output. The rich schema handles parameter details, and the description clarifies the essential outcome (confirmation counts). However, it doesn't explain how this tool differs from other transaction-focused siblings, which would enhance completeness, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds minimal value by implying the transaction hashes input via 'given transactions', but it doesn't elaborate on the limit, order, offset, or select parameters, which the schema already documents. No additional semantic meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and clearly identifies the resource as 'status (number of confirmations) of given transactions'. This distinguishes it effectively from sibling transaction tools like koios_tx_info or koios_tx_metadata, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'of given transactions' implies the tool is used when you have transaction hashes and need confirmation counts. However, it doesn't explicitly state when to prefer this over alternatives like koios_tx_info, nor does it mention any exclusions or prerequisites. The guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 accurately indicates a read operation ('Get') but doesn't disclose output format, response structure, or any notable side effects. There is no content to contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource, with a parenthetical clarifier. Every word earns its place, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should hint at return values or response content. It doesn't, though the tool is relatively simple. The 4-parameter schema is well-covered, but the description leaves the actual response format guessable, making it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all parameters (100% coverage), so the baseline is 3. The description adds no parameter-specific detail beyond the tool's context, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a resource, 'pool groups', then clarifies the definition in parentheses ('pools sharing the same owner/reward accounts'). This clearly distinguishes it from sibling tools like pool_info (individual pool details) and pool_list (all pools).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides sufficient context: use this tool when you want pool groups sharing owner/reward accounts. However, it doesn't explicitly state when not to use it or name alternative tools, so it stops short of fully explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![koios-mcp MCP server](https://glama.ai/mcp/servers/michaeljfazio/koios-mcp/badges/card.svg)](https://glama.ai/mcp/servers/michaeljfazio/koios-mcp)

Score Badge

Copy to your README.md:

[![koios-mcp MCP server](https://glama.ai/mcp/servers/michaeljfazio/koios-mcp/badges/score.svg)](https://glama.ai/mcp/servers/michaeljfazio/koios-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/michaeljfazio/koios-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server