Griphook
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation4/5
Tools are well-organized by domain (admin, bridge, cdp, lending, etc.) with clear distinctions within each category. However, some pairs like strato.cdp.mint and strato.cdp.mint-max or strato.lending.borrow and strato.lending.borrow-max have overlapping purposes that could cause confusion, though descriptions clarify the 'max' variants.
Naming Consistency5/5Naming follows a highly consistent pattern: all tools use snake_case with a clear domain prefix (strato.<domain>) and descriptive action names. The structure is uniform across all 67 tools, making them predictable and easy to parse.
Tool Count2/5With 67 tools, the count is excessive for a single server, even for a comprehensive DeFi platform. This many tools will overwhelm agents, increase cognitive load, and likely lead to misselection or inefficiency. A more modular approach with separate servers per domain would be more appropriate.
Completeness5/5The toolset provides extensive coverage across multiple DeFi domains (admin, bridge, CDP, lending, rewards, swap, tokens). Each domain includes full CRUD/lifecycle operations, administrative controls, and user actions, leaving no obvious gaps for the intended functionality.
Average 2.6/5 across 67 of 67 tools scored. Lowest: 1.6/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
This repository is licensed under Mozilla Public License 2.0.
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.jsonto 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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers no behavioral details. It does not disclose whether this is a read or write operation, what permissions are needed, if it's destructive, rate limits, or what happens after requesting auto save. This leaves critical behavioral traits unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it appropriately concise. However, it is under-specified rather than truly concise, as it lacks necessary detail for a tool with two required parameters and no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (bridge transaction operation), lack of annotations, 0% schema coverage, no output schema, and two required parameters, the description is severely incomplete. It does not provide enough context for an agent to understand the tool's purpose, usage, behavior, or parameters effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the parameters 'externalChainId' and 'externalTxHash'. It fails to explain what these parameters represent, their format, or how they relate to the bridge transaction, leaving them completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Request auto save for a bridge transaction' restates the tool name 'Bridge request auto save' with minimal elaboration, making it tautological. It specifies the action ('request auto save') and resource ('bridge transaction') but lacks detail on what 'auto save' entails or how it differs from sibling tools like 'strato.bridge.request-withdrawal'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 prerequisites, context, or exclusions, and it fails to differentiate from sibling tools such as 'strato.bridge.request-withdrawal', leaving usage ambiguous.
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?
No annotations are provided, so the description carries full burden. 'set' implies a write/mutation operation, but the description doesn't disclose critical behavioral traits: whether this requires admin permissions, if changes are irreversible, what happens to existing CDPs using this collateral, or any rate limits/constraints. For a 9-parameter configuration tool with no annotation coverage, this is severely inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Admin: set collateral parameters.') with no wasted words. However, it's overly terse given the tool's complexity—front-loading is good, but it under-specifies rather than being concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high complexity (9 required parameters), 0% schema description coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't explain the tool's purpose in context, parameter meanings, behavioral implications, or output. For a configuration tool in a DeFi/blockchain context, this leaves the agent unable to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 9 parameters have descriptions in the schema. The tool description provides no information about parameters beyond 'collateral parameters', failing to explain what 'asset', 'liquidationRatio', 'stabilityFeeRate', etc., represent or their expected formats. This leaves all parameters semantically undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Admin: set collateral parameters' restates the title ('CDP set collateral config') and name ('set-collateral-config') without adding specificity. It mentions 'collateral parameters' but doesn't clarify what a CDP is or what 'set' entails operationally. Compared to siblings like 'strato.cdp.set-collateral-config-batch', it doesn't distinguish itself as the single-asset version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 like 'strato.cdp.set-collateral-config-batch' for batch operations or 'strato.cdp.set-asset-paused' for pausing. The 'Admin:' prefix implies administrative privileges but doesn't state prerequisites or exclusions. The description lacks any 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers none. 'Cast an administrative vote' implies a write/mutation operation but doesn't specify permissions required, whether votes are reversible, what happens after voting, rate limits, or any side effects. This leaves the agent completely in the dark about behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise - a single four-word phrase. While this represents severe under-specification, it's not wordy or poorly structured. Every word technically serves a purpose, though the purpose is insufficiently elaborated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It doesn't explain what the tool does beyond the obvious, provides no parameter guidance, no behavioral context, and no differentiation from sibling tools. This leaves the agent unable to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 3 required parameters with 0% description coverage, and the tool description provides absolutely no information about what 'target', 'func', or 'args' represent, their expected formats, or their relationships. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Cast an administrative vote' restates the title 'Cast vote' with minimal elaboration, making it tautological. It specifies 'administrative' which provides some context, but doesn't clarify what type of vote, what it affects, or how it differs from the sibling tool 'strato.admin.vote-by-id'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 like 'strato.admin.vote-by-id' or other administrative tools. There's no mention of prerequisites, appropriate contexts, or exclusions for this administrative voting operation.
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 full burden but fails to disclose behavioral traits. It does not indicate if this is a read-only or destructive operation, what permissions or authentication are required, potential side effects (e.g., token transfers, fees), rate limits, or error conditions. This omission is critical for a financial transaction tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence 'Swap within an existing pool.', which is concise but under-specified. It lacks front-loaded critical information (e.g., purpose clarity, usage context) and feels incomplete rather than efficiently structured, as it fails to earn its place with meaningful details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a swap operation (financial transaction with 4 parameters), no annotations, and no output schema, the description is severely incomplete. It does not explain what the tool returns, error handling, security implications, or how it integrates with sibling tools, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional meaning beyond the schema, such as explaining parameter interactions (e.g., how 'isAToB' relates to 'poolAddress') or providing examples. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Swap within an existing pool' is tautological with the title 'Execute swap' and name 'strato.swap.execute', merely restating the action without specifying what 'swap' entails. It lacks a clear verb+resource distinction from siblings like 'strato.swap.add-liquidity' or 'strato.swap.create-pool', making the purpose vague and minimally informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 prerequisites (e.g., needing an existing pool), exclusions, or comparisons to sibling tools like 'strato.swap.create-pool' for pool creation or 'strato.swap.add-liquidity' for liquidity management, leaving usage context entirely implicit.
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?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the action ('claim junior note rewards') without explaining what 'claim' does (e.g., transfers tokens, updates records), whether it requires authentication, has side effects like balance changes, involves transactions or fees, or what happens on success/failure. This is inadequate for a tool likely involving financial operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase ('Claim junior note rewards') that is overly concise to the point of under-specification. It lacks necessary details about behavior or context, making it inefficient rather than appropriately brief. Every word is essential but insufficient, failing to provide a complete understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by the 'strato.cdp' context (likely involving financial or blockchain operations) and the absence of annotations and output schema, the description is severely incomplete. It does not explain what 'junior note' is, what rewards are claimed, the outcome, or any behavioral aspects, leaving critical gaps for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate, but it also doesn't clarify that no inputs are required, though this is implied by the empty schema. A baseline of 4 is given since the schema fully covers the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Claim junior note rewards' restates the tool name 'Claim junior note' with the addition of 'rewards', making it a near-tautology. It specifies the action ('claim') and resource ('junior note rewards'), but lacks detail on what claiming entails or what 'junior note' means in this context, failing to clearly distinguish it from sibling tools like 'strato.cdp.open-junior-note' or 'strato.rewards.claim'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 (e.g., having unclaimed rewards), timing considerations, or comparisons to related tools such as 'strato.rewards.claim' or 'strato.cdp.top-up-junior-note', leaving the agent with no usage context.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Redeem' implies a financial transaction that likely modifies state (e.g., reducing shares), but the description doesn't specify if this is destructive, requires authentication, has rate limits, or what the expected outcome is (e.g., asset transfer, confirmation). It lacks any behavioral details 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence 'Redeem sUSDST shares.' It's front-loaded and wastes no words, though this brevity comes at the cost of clarity and completeness. Every word directly relates to the tool's purpose, even if insufficiently detailed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a financial redemption tool likely involving state changes), lack of annotations, 0% schema description coverage, and no output schema, the description is severely incomplete. It doesn't explain what redemption entails, the parameters, behavioral traits, or expected results, leaving the agent with minimal actionable information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds no information about the two required parameters ('sharesAmount' and 'includeStakedSToken'), such as what units 'sharesAmount' uses (e.g., integer, decimal string) or what 'includeStakedSToken' controls (e.g., whether staked tokens are included in redemption). It fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Redeem sUSDST shares' restates the tool name 'safety-redeem' and title 'Redeem safety' without adding specificity. It doesn't clarify what 'redeem' means in this context (e.g., converting shares to another asset, withdrawing funds) or what 'safety' refers to, making it a tautology. The sibling tool 'strato.lending.safety-redeem-all' suggests this might be for partial redemption, but the description doesn't distinguish between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 doesn't mention prerequisites (e.g., needing shares to redeem), compare it to 'safety-redeem-all' for partial vs. full redemption, or indicate any constraints (e.g., cooldown periods from 'safety-cooldown'). With no usage context, the agent has to infer everything 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.
- Behavior1/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 mentions 'maximum safe' without explaining what that entails—whether it involves calculations, safety checks, permissions, or side effects. This leaves critical behavioral traits like mutability, risk, or operational impact completely unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, 'Mint maximum safe USDST.', which is front-loaded and wastes no words. However, this brevity contributes to underspecification rather than effective communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'maximum safe' in a financial/CDP context, no annotations, 0% schema coverage, and no output schema, the description is severely incomplete. It doesn't address what the tool returns, how 'maximum safe' is determined, or any operational details needed for safe and correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the single parameter 'asset'. It doesn't clarify what 'asset' represents, acceptable values, or its role in minting 'maximum safe USDST'. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mint maximum safe USDST' states a verb ('mint') and resource ('USDST'), but it's vague about what 'maximum safe' means and doesn't distinguish this tool from sibling 'strato.cdp.mint'. It partially restates the name/title without clarifying the specific purpose beyond basic minting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'strato.cdp.mint' or other CDP tools. The description lacks context about prerequisites, constraints, or typical scenarios for invoking this specific minting operation.
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 but offers almost none. 'toggle asset support' vaguely implies a mutation, but it doesn't describe what 'asset support' entails, potential side effects, permission requirements, or system impacts. This is inadequate for a tool that likely modifies system state, leaving the agent with critical gaps in understanding its 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with 'Admin: toggle asset support.'—a single, front-loaded sentence that wastes no words. However, this brevity comes at the cost of clarity and completeness, as it under-specifies critical details. While structurally efficient, it prioritizes conciseness over informativeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by administrative functions and the lack of annotations (0% coverage), output schema, or detailed parameter explanations, the description is severely incomplete. It doesn't address what 'asset support' means, the effects of toggling, error conditions, or return values. For a tool with likely significant system impact, this minimal description is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'asset' and 'supported' implicitly but doesn't explain what these parameters mean, their expected formats, or valid values. For example, it doesn't clarify if 'asset' refers to a token type or identifier, or what 'supported' toggles in practical terms. This leaves both parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Admin: toggle asset support' restates the title 'CDP set asset supported' in slightly different words, making it tautological. It specifies the action ('toggle') and resource ('asset support') but lacks specificity about what 'asset support' means in this context. Compared to siblings like 'strato.cdp.set-asset-paused', it doesn't clearly differentiate the exact administrative function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'Admin:' implying administrative privileges, but doesn't specify when to use this tool versus alternatives. No explicit when/when-not scenarios or sibling comparisons are mentioned, such as how this differs from 'strato.cdp.set-asset-paused' or other CDP tools. The guidance is insufficient for an agent to make informed decisions.
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 full burden but fails to disclose critical behavioral traits. It doesn't indicate that this is a destructive/mutative operation (likely transferring assets), mention authorization needs, rate limits, or potential risks (e.g., liquidation). This omission is severe for a tool involving asset transfers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it appropriately concise. However, it's too brief to be fully helpful, bordering on under-specified rather than optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a financial transaction with asset parameters), lack of annotations, 0% schema coverage, and no output schema, the description is completely inadequate. It misses essential context like behavioral risks, parameter meanings, and usage scenarios, failing to support safe tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter details. It doesn't explain what 'asset' represents (e.g., token symbol, address) or 'amount' (e.g., units, decimals), leaving both parameters undocumented. This is inadequate given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Supply collateral to lending pool' clearly states the action (supply) and target (lending pool), which is better than a tautology. However, it doesn't specify what 'supply' entails (e.g., depositing assets as security) or differentiate it from sibling tools like 'strato.lending.deposit-liquidity' or 'strato.cdp.deposit', leaving the purpose somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 doesn't mention prerequisites (e.g., needing approved tokens), exclusions, or related tools like 'strato.lending.withdraw-collateral' for reversal, making it misleadingly simplistic for a financial operation.
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 'set multiple collateral configs,' implying a write/mutation operation, but fails to detail critical aspects like required permissions, whether changes are reversible, potential side effects, rate limits, or error handling. This leaves significant gaps for a tool with 9 required parameters and administrative implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just one sentence: 'Admin: set multiple collateral configs.' It is front-loaded with the key action and scope, with no wasted words. However, this brevity comes at the cost of underspecification, but as per scoring rules, conciseness is about efficiency, which this achieves perfectly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 required parameters, administrative mutation tool), lack of annotations, 0% schema coverage, and no output schema, the description is severely incomplete. It doesn't explain parameters, behavioral traits, usage context, or return values, making it inadequate for safe and effective tool invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 9 parameters are documented in the schema. The description adds no information about what these parameters mean (e.g., what 'assets' or 'liquidationRatios' represent), their formats, or how arrays should be aligned. This fails to compensate for the complete lack of schema documentation, leaving parameters entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Admin: set multiple collateral configs' clearly indicates an administrative action to configure collateral settings in batch, but it's vague about what 'collateral configs' entail. It distinguishes from the sibling 'strato.cdp.set-collateral-config' by specifying 'batch' in the name, but the description doesn't explicitly highlight this difference, leaving the scope ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like the non-batch version 'strato.cdp.set-collateral-config' or other configuration tools. The 'Admin:' prefix implies administrative privileges, but it doesn't specify prerequisites, exclusions, or contextual triggers for batch operations, offering minimal usage direction.
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 full burden but fails to disclose any behavioral traits. It doesn't mention whether this is a read or write operation, potential side effects (e.g., debt accrual, interest rates), permissions required, or error conditions. This is inadequate for a financial transaction 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, 'Borrow from lending pool.', which is front-loaded and wastes no words. While it may be too brief for completeness, it earns full marks for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a borrowing operation in a DeFi context, with no annotations, no output schema, and minimal parameter documentation, the description is severely incomplete. It doesn't explain what happens after borrowing, return values, or critical details like collateral requirements or risks, making it inadequate for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description adds no semantic information about the 'amount' parameter (e.g., units, format, constraints like minimum/maximum). This leaves the parameter meaning ambiguous, failing to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('borrow') and target ('from lending pool'), which clarifies the basic purpose. However, it lacks specificity about what is being borrowed (USDST is only in the title) and doesn't distinguish it from sibling tools like 'strato.lending.borrow-max', leaving ambiguity about scope differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'borrow-max' or other lending operations like 'repay'. The description offers no context about prerequisites, constraints, or typical use cases, 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Deposit into lending pool' implies a write/mutation operation but provides no information about permissions required, whether the operation is reversible, potential side effects, rate limits, or what happens on success/failure. This is inadequate for a financial transaction 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, with zero wasted language. It's front-loaded with the core action and target. While it's under-specified, it's not verbose or poorly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial transaction tool with 2 undocumented parameters, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool actually does beyond the basic verb, provides no parameter guidance, no behavioral context, and no differentiation from similar tools in the ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for both parameters, the description provides no information about what 'amount' represents (currency, units, format) or what 'stakeMToken' means. The description doesn't compensate for the complete lack of parameter documentation in the schema, leaving both parameters completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deposit') and target ('lending pool'), which is specific enough to understand the basic function. However, it doesn't differentiate from sibling tools like 'strato.lending.supply-collateral' or 'strato.cdp.deposit', which could cause confusion about when to use this specific deposit tool versus others in the same domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. With multiple deposit-related tools in the sibling list (e.g., 'strato.lending.supply-collateral', 'strato.cdp.deposit', 'strato.swap.add-liquidity'), there's no indication of what makes this deposit operation unique or when it's appropriate versus other deposit mechanisms.
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 mentions 'Admin:' which hints at permission requirements, but doesn't disclose critical behavioral traits like whether this is a write operation (implied by 'create'), what happens on success/failure, rate limits, or any side effects. The description is too minimal for a tool that likely creates blockchain tokens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two words and a colon, which is efficient and front-loaded. However, it's arguably under-specified rather than optimally concise, as it lacks necessary details for proper tool usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, 5 required, no schema descriptions, no output schema, no annotations), the description is severely incomplete. It doesn't explain what the tool returns, how parameters interact, or the broader context of token creation in this system. For a likely blockchain token creation tool, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 8 parameters have descriptions in the schema. The tool description provides no information about parameters like 'name', 'symbol', 'initialSupply', etc., leaving their meaning and format completely undocumented. This fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'create a new token' which is a clear verb+resource combination, but it's vague about what kind of token (cryptocurrency, authentication, etc.) and doesn't distinguish from sibling tools like 'strato.tokens.approve' or 'strato.tokens.transfer'. The 'Admin:' prefix adds some context but doesn't fully specify the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Admin:' prefix implies this tool requires administrative privileges, but there's no explicit guidance on when to use it versus alternatives, prerequisites, or constraints. No comparison to sibling tools like 'strato.tokens.set-status' or 'strato.tokens.transfer' is 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. It implies a mutation ('dismiss') but doesn't disclose behavioral traits like permissions needed, whether the action is reversible, side effects, or error conditions. The cryptic 'only proposer only-voter case' adds minimal context but is insufficient for a mutation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) and front-loaded with the core action. However, the cryptic phrase 'only proposer only-voter case' adds confusion without clarity, slightly reducing efficiency. Overall, it's brief but could be more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, this is a mutation tool with high complexity. The description is incomplete—it doesn't explain the governance context, what dismissing entails, or return values. It leaves critical gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'issueId' implicitly via 'issue' but provides no semantics—no explanation of what an issue is, how to obtain issueId, or format constraints. With one undocumented parameter, this adds little value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('dismiss') and resource ('an issue'), but is vague about what 'only proposer only-voter case' means. It distinguishes from some siblings like 'strato.admin.vote' but not clearly from others like 'strato.admin' which might handle issues broadly. The purpose is understandable but lacks 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/5Does 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 phrase 'only proposer only-voter case' hints at a specific scenario but doesn't explain what that is or when other tools (e.g., 'strato.admin.vote') should be used instead. There's no mention of 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'backend search interface,' which implies a read-only operation, but doesn't specify if it's safe, has rate limits, requires authentication, or what the output looks like. For a query tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence: 'Query chain events through the backend search interface.' It's front-loaded and wastes no words, making it efficient. However, it could be more structured by including key details upfront, but it's appropriately concise for its current content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a query tool with 3 parameters), low schema coverage (33%), no annotations, and no output schema, the description is incomplete. It doesn't explain the tool's behavior, parameter usage, or expected results, leaving too much undefined for effective agent use. It should provide more context to bridge these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% (only 'order' has a description), and the description doesn't add any parameter details beyond what's in the schema. It doesn't explain what 'limit' and 'offset' do, their formats, or typical usage, failing to compensate for the low coverage. With 3 parameters and minimal schema help, the description should provide more context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Query chain events through the backend search interface,' which includes a verb ('Query') and resource ('chain events'), making it clear this is a search/query tool. However, it doesn't differentiate from sibling tools like 'strato.events' (if it existed) or other query/search tools in the list, leaving the scope somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention any specific contexts, prerequisites, or exclusions, and with many sibling tools available (e.g., various admin, cdp, lending tools), there's no indication of how this tool fits into the broader workflow or when it should be preferred over others.
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 burden but only states it's an admin action. It doesn't disclose behavioral traits such as whether this is a write operation, permission requirements beyond 'Admin', potential side effects, rate limits, or what happens to existing configurations. The description is minimal and lacks necessary context for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with just two words and a colon, making it front-loaded and efficient. However, it's arguably too brief, bordering on under-specified rather than optimally concise, as it sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 required parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the tool's purpose in detail, parameter meanings, behavioral context, or expected outcomes. For an admin configuration tool with multiple parameters, this level of description is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description mentions 'lending parameters' but doesn't explain any of the 7 required parameters (e.g., what 'ltv', 'liquidationThreshold', or 'perSecondFactorRAY' mean). It fails to compensate for the schema's lack of documentation, leaving parameters semantically unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Admin: set lending parameters' states the action ('set') and target ('lending parameters'), but it's vague about what specific parameters are being configured. It distinguishes from siblings by focusing on asset configuration rather than operations like borrowing or liquidating, but lacks specificity about the asset 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Admin:' which implies administrative privileges, but provides no explicit guidance on when to use this tool versus alternatives like 'strato.lending.set-debt-ceilings' or 'strato.cdp.set-collateral-config'. No context about prerequisites or exclusions is given.
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. 'Repay all debt' implies a write/mutation operation that likely requires sufficient funds or permissions, but it doesn't specify critical behaviors: whether this is irreversible, what happens if insufficient funds exist, if it affects all loan types or just specific ones, or any rate limits. The description adds minimal context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two words, with zero wasted language. It's front-loaded with the core action, though this brevity contributes to underspecification in other dimensions. For a tool with no parameters, this minimalism is structurally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial transaction tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'all debt' entails, the return value or confirmation, error conditions, or system state changes. For a mutation tool in a lending context, this lacks necessary detail about outcomes and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. Baseline is 4 for zero parameters, as the schema fully covers the absence of inputs without requiring description compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Repay all debt' is a tautology that essentially restates the tool name 'Repay all loans' without adding meaningful specificity. It doesn't clarify what type of debt, under what conditions, or how this differs from sibling tools like 'strato.lending.repay' (which likely repays specific loans). The verb 'repay' is clear, but the scope 'all debt' lacks differentiation from similar operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 multiple sibling tools in the lending category (e.g., 'strato.lending.repay' for specific repayments, 'strato.lending.borrow' for borrowing), but the description doesn't indicate when 'repay all' is appropriate versus partial repayments or other debt management tools. No context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 states the action ('claim rewards') but does not describe what 'claim' entails—e.g., whether it's a read-only operation, if it modifies state, requires authentication, has side effects like token transfers, or involves rate limits. For a tool with zero annotation coverage, this is a significant gap in 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence that efficiently conveys the core action without unnecessary words. It is front-loaded with the key information ('Claim rewards for a specific activity'), making it easy to parse. However, it could be more structured by including usage notes or parameter hints, but as-is, it avoids verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by the tool name (involving rewards and activities), the lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It does not address behavioral aspects, parameter meaning, or expected outcomes, leaving the agent with insufficient context to use the tool effectively. This is inadequate for a tool with potential state changes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the parameter 'activityId' is undocumented in the schema. The description does not compensate by explaining what 'activityId' represents, its format, valid ranges beyond the schema's numeric bounds, or how to obtain it. With one required parameter and no semantic details provided, the description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('claim') and resource ('rewards for a specific activity'), which clarifies the basic action. However, it does not differentiate from sibling tools like 'strato.rewards.claim' or 'strato.rewards.claim-all-activities', leaving ambiguity about when to use this specific tool versus those alternatives. The purpose is clear but lacks 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/5Does 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 'strato.rewards.claim' or 'strato.rewards.claim-all-activities'. It does not mention prerequisites, conditions, or exclusions for claiming activity rewards, leaving the agent without context for tool selection. This lack of guidance reduces effectiveness in multi-tool scenarios.
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 burden for behavioral disclosure but provides minimal information. It mentions 'fetch' operations but doesn't specify whether these are read-only, require admin permissions, have rate limits, or what format the results take. For a tool with admin capabilities and no annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that lists all capabilities without unnecessary words. However, it could be better structured by front-loading the primary purpose rather than presenting a bullet-like list of functions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an admin tool with 3 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'fetch' means operationally, what permissions are required, what data formats to expect, or how the multiple functions relate to each other. The user is left guessing about fundamental aspects of tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (2 of 3 parameters have descriptions), providing a baseline. The description mentions 'contract search' and 'config' which align with the 'search' and 'includeConfig' parameters, but doesn't add meaningful context beyond what's in the schema descriptions. It doesn't explain relationships between parameters or provide usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description lists multiple functions ('fetch current user profile, admins, open issues, contract search, and config') but doesn't specify a single clear purpose or verb. It's vague about whether this is a unified query tool or multiple operations, and doesn't distinguish it from sibling tools like 'strato.admin.add-admin' or 'strato.admin.remove-admin' which are clearly different admin operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description doesn't mention prerequisites, appropriate contexts, or when to choose this over other admin tools like 'strato.admin.vote' or 'strato.admin.dismiss-issue'. The user must infer usage from the parameter names 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. 'Revoke' implies a destructive/mutative action, but it doesn't specify whether this requires special permissions, is reversible, affects system state, or has side effects. For a security-sensitive admin tool, this lack of behavioral context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, with zero wasted language. It's front-loaded with the core action and doesn't include any unnecessary information. For such a simple action, this brevity is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive admin tool with no annotations, 0% schema coverage, and no output schema, the description is inadequate. It doesn't cover parameter meaning, behavioral implications, success/failure conditions, or relationships with sibling tools. The agent lacks crucial information to use this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description provides no information about the 'userAddress' parameter. It doesn't explain what format this address should be (e.g., email, wallet address, username), where to find it, or what happens if an invalid address is provided. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Revoke administrator access' clearly states the action (revoke) and resource (administrator access), providing a basic understanding of the tool's function. However, it doesn't specify what system or context this applies to (Strato platform) or differentiate it from sibling tools like 'strato.admin.dismiss-issue' or 'strato.admin.add-admin' beyond the obvious inverse relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention prerequisites (e.g., user must currently be an admin), consequences, or relationships with sibling tools like 'strato.admin.add-admin' for adding admin access. The agent must 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 full burden. 'Mint USDST against collateral' implies a financial transaction that creates tokens, but doesn't disclose critical behavioral traits: whether this requires specific permissions, what happens to the collateral, if there are rate limits or fees, what the expected output is, or potential risks. For a financial operation with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 4 words. Every word earns its place: 'Mint' specifies the action, 'USDST' specifies what's being created, and 'against collateral' provides the mechanism. There's zero wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a financial transaction tool with 2 parameters, 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, what happens on success/failure, or provide enough context for safe usage. The description alone is insufficient for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'collateral' which relates to the 'asset' parameter, and 'mint USDST' which relates to the 'amount' parameter, but provides no specifics about what assets are acceptable, what format the amount should be in (e.g., decimal string, integer), or any constraints. The description adds minimal semantic context beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mint USDST against collateral' clearly states the action (mint) and target (USDST), but it's vague about the specific mechanism. It distinguishes from some siblings like 'strato.cdp.deposit' or 'strato.cdp.repay' by focusing on minting, but doesn't explicitly differentiate from 'strato.cdp.mint-max' which appears to be a related 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/5Does 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 doesn't mention prerequisites (e.g., having collateral deposited), when not to use it, or how it differs from 'strato.cdp.mint-max' which appears to be a sibling tool with similar purpose.
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 mentions 'open a junior note position for bad debt,' implying a financial transaction or creation, but fails to disclose critical behavioral traits such as required permissions, whether it's a read-only or mutative operation, potential risks, or expected outcomes. This is inadequate for a tool likely involving financial operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial tools (implied by sibling tools like 'liquidate' and 'mint'), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks details on behavior, parameters, and usage context, making it insufficient for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It adds no information about the 'asset' or 'amountUSDST' parameters, leaving their meaning, formats, or constraints unexplained. This fails to provide necessary context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Open') and target ('junior note position for bad debt'), providing a basic purpose. However, it's vague about what 'open' entails operationally and doesn't differentiate from sibling tools like 'strato.cdp.claim-junior-note' or 'strato.cdp.top-up-junior-note', which also involve junior notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 lacks context about prerequisites, timing, or how it relates to other CDP tools like 'strato.cdp.deposit' or 'strato.cdp.repay', leaving the agent with no usage framework.
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. 'Repay USDST debt' implies a financial transaction but doesn't specify if it requires authentication, affects user balances, has rate limits, or what happens on success/failure. This is inadequate for a tool that likely involves monetary operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single phrase, 'Repay USDST debt', which is front-loaded and wastes no words. However, this brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial transactions, no annotations, 0% schema coverage, and no output schema, the description is insufficient. It doesn't cover behavioral aspects, parameter details, or expected outcomes, leaving critical gaps for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'USDST debt' but doesn't explain the 'asset' and 'amount' parameters (e.g., what assets are supported, format of amount). This adds minimal value beyond the schema's basic structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Repay USDST debt' states a clear verb ('repay') and resource ('USDST debt'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'strato.cdp.repay-all' or 'strato.lending.repay', leaving ambiguity about when to use this specific tool versus 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/5Does 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 like 'repay-all' or other CDP/lending tools. The description lacks any context about prerequisites, conditions, or distinctions from siblings, offering minimal 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 provided, so the description carries full burden. 'Add USDST to junior note' implies a financial transaction/mutation, but doesn't disclose behavioral traits like: whether this requires specific permissions, if it's reversible, what happens if the note doesn't exist, potential fees, or confirmation requirements. The description is minimal and lacks crucial operational 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words. It's front-loaded with the core action and resource. There's zero wasted language or redundancy. While it may be too brief for completeness, it's structurally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a financial transaction tool with no annotations, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't explain what a 'junior note' is, what 'top up' accomplishes operationally, what happens after execution, or any error conditions. For a tool that presumably moves funds, this leaves too many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'USDST' which relates to the 'amountUSDST' parameter, providing some context about the currency/unit. However, it doesn't explain the parameter's purpose, format (e.g., decimal string, integer), constraints, or typical values. With only 1 parameter, this is a significant gap in documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Add') and target resource ('junior note'), but lacks specificity about what 'top up' means in this context. It distinguishes from some siblings like 'claim-junior-note' or 'open-junior-note' by implying an addition operation, but doesn't clarify how it differs from 'deposit' or other financial operations in the CDP namespace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With multiple CDP operations available (deposit, withdraw, mint, repay, etc.), the description doesn't indicate whether this is for increasing collateral, adding funds to an existing position, or another specific use case. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without disclosing behavioral traits. It doesn't mention permissions required, whether liquidation is irreversible, potential side effects (e.g., collateral seizure), rate limits, or error conditions. This is inadequate for a mutation tool with significant financial implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It's front-loaded and appropriately sized for the tool's name and title, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a liquidation operation, no annotations, low schema coverage, and no output schema, the description is incomplete. It lacks details on behavior, parameters, outcomes, and context, leaving significant gaps for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 25%, with only 'id' documented. The description adds no parameter semantics beyond the schema, failing to explain 'collateralAsset', 'repayAmount', or 'minCollateralOut'—critical for understanding liquidation mechanics. It doesn't compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Liquidate a lending loan' clearly states the action (liquidate) and target (lending loan), but it's vague about what liquidation entails and doesn't differentiate from sibling tools like 'strato.cdp.liquidate' or other lending operations. It provides basic purpose but lacks specificity about scope or mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'strato.cdp.liquidate' or other lending tools such as 'repay' or 'withdraw-collateral'. The description offers no context about prerequisites, timing, or exclusions for liquidation.
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 burden but only states the action without disclosing behavioral traits. It doesn't cover permissions needed, whether the operation is reversible, rate limits, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Repay outstanding debt' is front-loaded and appropriately sized for its purpose, though it may be too brief given the lack of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with financial implications), no annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It should explain more about the operation's effects, return values, or error conditions to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description adds no meaning beyond the schema. It doesn't explain what 'amount' represents (e.g., currency, units, format) or constraints, failing to compensate for the low coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Repay outstanding debt' clearly states the action (repay) and target (debt), but it's vague about scope—it doesn't specify if this is for a specific loan type or context, unlike sibling tools like 'strato.lending.repay-all' which suggests alternatives. It avoids tautology by not just restating the name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'strato.lending.repay-all' or 'strato.cdp.repay', nor does it mention prerequisites like loan existence or authorization. The description implies usage for debt repayment but lacks explicit 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 carries full burden. It mentions 'Stake' which implies a write/mutation operation, but doesn't disclose behavioral traits like permissions required, whether it's reversible, potential risks (e.g., lock-up periods), or effects on user balances. This leaves significant gaps for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action, making it easy to parse quickly, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a financial staking operation with 2 parameters), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It fails to explain key aspects like return values, error conditions, or operational context, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It doesn't explain the 'amount' parameter (e.g., format, units, constraints) or 'stakeSToken' (what it means, implications of true/false). Without this, parameters remain cryptic despite being required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Stake') and target resource ('USDST into safety module'), which is clear but vague. It doesn't specify what 'safety module' means or how this differs from sibling tools like 'strato.lending.safety-redeem' or 'strato.lending.safety-cooldown', leaving the purpose somewhat ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With multiple safety-related tools in the 'strato.lending' namespace (e.g., safety-redeem, safety-cooldown), the description lacks any context about prerequisites, timing, or comparisons, offering no help 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 carries the full burden of behavioral disclosure. It mentions 'Admin:' which hints at permission requirements, but fails to describe key behavioral traits such as whether this is a destructive operation (e.g., permanently moving reserves), what happens to the swept reserves, any rate limits, authentication needs beyond admin status, or the expected outcome. For a tool with no annotations and likely significant impact (given 'sweep' and admin context), this is a substantial 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two words ('Admin: sweep protocol reserves.'), which is front-loaded and wastes no space. Every word contributes meaning (indicating admin role and action), making it efficient. However, this conciseness comes at the cost of completeness, as noted in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'sweep' (likely a significant admin action), no annotations, no output schema, and 0% schema description coverage for the single parameter, the description is incomplete. It lacks details on behavior, parameters, output, and differentiation from siblings. For a tool in a lending context with many alternatives, this minimal description is inadequate to guide an AI agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter ('amount') with 0% schema description coverage, meaning the schema provides no details on what 'amount' represents. The description adds no parameter semantics—it doesn't explain what 'amount' refers to (e.g., a numeric value, token amount, or percentage), its format, or constraints. With low schema coverage, the description fails to compensate, leaving the parameter undocumented and ambiguous for an AI agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is for 'sweep protocol reserves' and identifies it as an admin action, which provides a basic purpose. However, it's vague about what 'sweep' entails (e.g., transferring, collecting, or redistributing reserves) and doesn't clearly differentiate from sibling tools like 'strato.lending.withdraw-liquidity' or 'strato.lending.liquidate', which might involve similar reserve-related operations. The description lacks specificity about the resource being acted upon beyond 'reserves'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Admin:' which implies this tool requires administrative privileges, offering some contextual guidance. However, it provides no explicit guidance on when to use this tool versus alternatives (e.g., compared to other lending tools like 'strato.lending.withdraw-liquidity'), no prerequisites, and no exclusions. The usage context is implied but not elaborated, leaving gaps for an AI agent to determine applicability.
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. 'Withdraw' implies a mutation that reduces collateral position, but the description doesn't mention permission requirements, whether this affects borrowing capacity, potential liquidation risks, transaction costs, or what happens on success/failure. For a financial operation with zero annotation coverage, this leaves critical behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words. It's front-loaded with the core action and resource. There's zero wasted language or redundancy. While it may be too brief for completeness, as a standalone statement it's efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a financial mutation tool with 2 required parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, what side effects occur, parameter formats, or usage context. For a tool that presumably moves assets in a DeFi system, this leaves too many critical questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning neither parameter ('asset', 'amount') has any documentation in the schema. The description provides no information about these parameters - no explanation of what 'asset' represents (token address, symbol, etc.), what format 'amount' should be in (wei, decimal string, etc.), or any constraints. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Withdraw supplied collateral' clearly states the verb ('withdraw') and resource ('collateral'), but it's somewhat vague about what 'supplied collateral' means in this context. It distinguishes from some siblings like 'strato.lending.borrow' or 'strato.lending.supply-collateral', but doesn't explicitly differentiate from similar tools like 'strato.lending.withdraw-liquidity' or 'strato.lending.withdraw-collateral-max'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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's no mention of prerequisites (e.g., having collateral already supplied), differences from 'strato.lending.withdraw-collateral-max', or when to choose this over other withdrawal tools. The agent must infer usage from the tool 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 of behavioral disclosure. 'Withdraw from lending pool' implies a financial transaction that likely involves moving assets, but it doesn't specify if this is irreversible, requires specific permissions, has rate limits, or what happens on success/failure. For a tool with potential monetary impact and no annotations, this is a significant gap in safety and operational 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste: 'Withdraw from lending pool.' It's front-loaded and efficiently conveys the core action without unnecessary words. This is an example of effective brevity, though it sacrifices detail for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a financial withdrawal tool with 2 parameters), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't address behavioral risks, parameter meanings, or expected outcomes. For such a tool, more context is needed to ensure safe and correct usage by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters 'amount' and 'includeStakedMToken' are undocumented in the schema. The description adds no information about these parameters—it doesn't explain what 'amount' represents (e.g., token units, percentage), the format of 'amount' as a string, or what 'includeStakedMToken' does. With low coverage, the description fails to compensate, leaving parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Withdraw from lending pool' clearly states the action (withdraw) and target (lending pool), which is adequate. However, it doesn't differentiate from sibling tools like 'strato.lending.withdraw-liquidity-all' or 'strato.lending.withdraw-collateral', leaving the scope vague. It's not tautological but lacks specificity about what 'liquidity' entails versus other withdrawal types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention prerequisites (e.g., having deposited liquidity first), compare to 'withdraw-liquidity-all' for partial vs. full withdrawals, or indicate scenarios where it's appropriate. Without such context, an agent must infer usage from the tool 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 full burden for behavioral disclosure. 'update token status' implies a mutation operation, but the description doesn't disclose what permissions are required, whether the change is reversible, what side effects might occur, or any rate limits. It mentions 'Admin' which hints at elevated privileges, but this is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words. It's front-loaded with the most important information ('Admin') first. While perhaps too brief, every word serves a purpose with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 2 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what tokens are being updated, what the status changes mean, what permissions are required, or what the tool returns. The context signals show this is a non-trivial tool that needs more complete documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only the 'status' parameter has a description with enum mapping). The tool description adds no parameter information beyond what's in the schema. Since schema coverage is moderate, the baseline is 3 - the description doesn't compensate for the undocumented 'address' parameter but doesn't make things worse either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Admin: update token status' states the action (update) and resource (token status) but is vague about what 'token status' means. It distinguishes from some siblings like 'create' or 'transfer' but not from other admin tools. The purpose is understandable but lacks specificity about what tokens or statuses are involved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 mentions 'Admin' which implies administrative privileges, but doesn't specify prerequisites, when this operation is appropriate, or what other tools might be used for related tasks. No explicit when/when-not statements 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?
No annotations are provided, so the description carries full burden. It states 'Cast a vote' which implies a mutation/write operation, but doesn't disclose behavioral traits like required permissions, whether votes are reversible, rate limits, or what happens after voting. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, 'Cast a vote given an issue ID.', which is front-loaded and wastes no words. Every part of the sentence contributes to the tool's purpose, making it efficient despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with no annotations, 1 parameter at 0% schema coverage, and no output schema), the description is incomplete. It doesn't cover behavioral aspects, usage context, or parameter details, leaving significant gaps for an AI agent to understand 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema, which has 0% description coverage. It mentions 'issue ID' as the parameter, aligning with the schema's 'issueId', but doesn't explain format, constraints, or examples. With one parameter and low schema coverage, the description provides basic context but lacks depth, meeting the baseline for minimal documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Cast a vote given an issue ID' clearly states the action (cast vote) and resource (issue ID), but it's vague about what type of vote or system this involves. It doesn't distinguish from sibling tools like 'strato.admin.vote' (which lacks 'by-id'), leaving ambiguity about when to use one versus the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With sibling tools including 'strato.admin.vote' (without '-by-id'), the description doesn't explain the difference, prerequisites, or context for usage, leaving the agent to guess based on naming 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 of behavioral disclosure. It mentions 'Admin' and 'toggle', implying it's a mutation that requires elevated permissions, but fails to detail critical aspects like what 'global CDP pause' entails (e.g., pausing all CDP operations system-wide), potential side effects, whether the change is reversible, or any rate limits or authentication requirements. The description is too vague for a tool that likely has significant system impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, making it front-loaded and efficient. However, this brevity comes at the cost of clarity and completeness, as it omits necessary details for proper tool usage. While it avoids waste, it may be overly terse for a tool with potential system-wide impact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'global CDP pause' (likely a critical admin function), the lack of annotations, no output schema, and minimal parameter documentation, the description is inadequate. It doesn't explain the tool's effects, return values, or how it integrates with the broader system (e.g., sibling tools like 'strato.cdp.set-asset-paused'), leaving significant gaps for an AI agent to understand and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description provides no information about the 'isPaused' parameter. It doesn't explain what the boolean value represents (e.g., true to pause, false to unpause), default behavior, or any constraints. This leaves the parameter's meaning ambiguous, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('toggle global CDP pause') and identifies it as an admin function. It specifies the resource ('global CDP pause'), making the purpose understandable. However, it doesn't explicitly differentiate from the sibling tool 'strato.cdp.set-asset-paused', which appears to be a similar pause function but for individual assets rather than globally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by labeling it as 'Admin', implying it requires admin privileges. However, it offers no explicit guidance on when to use this tool versus alternatives like 'strato.cdp.set-asset-paused' or other pause-related tools in the sibling list, nor does it mention any prerequisites or exclusions beyond the admin hint.
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 indicates a read operation ('fetch') but doesn't specify authentication requirements, rate limits, pagination behavior, or what happens when parameters are omitted. For a tool with 4 parameters and no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that lists all data types fetched. It's appropriately sized for the tool's scope, though it could be more front-loaded with primary purpose versus secondary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 0 required parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or how optional parameters interact. The agent lacks sufficient context to use this tool effectively without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'userAddress' has a description), and the description doesn't add any parameter-specific information. It mentions 'leaderboard' generally but doesn't explain how 'leaderboardLimit' or 'leaderboardOffset' work, or what 'includeLeaderboard' controls. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches multiple reward-related data points (overview, activities, user rewards, pending balances, leaderboard), providing a specific verb ('fetch') and resources. However, it doesn't explicitly differentiate from sibling tools like 'strato.rewards.claim' or 'strato.rewards.claim-activity', which appear to be write operations versus this read 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/5Does 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 doesn't mention prerequisites (e.g., authentication needs), when to use it over other reward tools, or any context-specific recommendations. The agent must infer usage from the tool name and description alone.
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 full burden but fails to disclose critical behavioral traits. It doesn't mention whether this is a read-only or mutating operation (though 'add' suggests mutation), what permissions are required, potential costs like gas fees, slippage risks, or what happens to the provided token. This leaves the agent with insufficient information to understand 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word contributing to understanding the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of DeFi liquidity operations, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'liquidity' means in this system, what LP tokens are, the implications of staking, or what the tool returns. For a financial transaction tool with 4 parameters, this leaves too many gaps for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing clear documentation for all parameters. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting, but doesn't compensate with extra context like token types or liquidity pool mechanics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Provide liquidity') and the key constraint ('using only one token'), which distinguishes it from the sibling 'strato.swap.add-liquidity' that likely requires multiple tokens. However, it doesn't specify the exact resource or outcome beyond liquidity provision, leaving some ambiguity about what 'liquidity' entails in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used when providing liquidity with a single token, but it offers no explicit guidance on when to choose this over 'strato.swap.add-liquidity' or other alternatives, nor does it mention prerequisites, risks, or typical scenarios for single-sided liquidity provision.
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. 'Grant administrator access' implies a write/mutation operation with security implications, but it doesn't disclose behavioral traits like required permissions, whether the action is reversible (hint: sibling 'remove-admin' exists), rate limits, or what happens on success/failure. This is a significant gap for a security-sensitive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded and gets straight to the point, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (admin permission change) and lack of annotations/output schema, the description is incomplete. It doesn't cover security implications, error conditions, or what 'administrator access' entails. For a mutation tool with no structured support, this leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage. The description adds no information about the 'userAddress' parameter—it doesn't explain what format this address should be (e.g., Ethereum address, email), what user it refers to, or any validation rules. With low schema coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Grant administrator access' clearly states the action (grant) and resource (administrator access), which aligns with the tool name 'Add admin'. It distinguishes from sibling 'remove-admin' by specifying addition rather than removal. However, it doesn't specify what system or context this applies to (e.g., Strato platform), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention prerequisites (e.g., existing admin rights), constraints, or when to choose this over other admin tools like 'vote' or 'dismiss-issue'. The agent must 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 full burden for behavioral disclosure. While 'submit a withdrawal request' implies a write operation, it doesn't disclose critical behavioral traits: whether this requires specific permissions, if it's reversible, what happens after submission (pending state? immediate execution?), rate limits, or error conditions. The description is minimal and lacks operational 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise with a single clear sentence. There's zero wasted language or redundancy. It's appropriately sized for what it communicates, though what it communicates is insufficient for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, bridge operation), no annotations, no output schema, and 0% schema coverage, the description is severely incomplete. It doesn't explain what the tool returns, error conditions, security implications, or how this withdrawal differs from other withdrawal tools in the system. For a financial bridge operation, this level of documentation is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 5 parameters (4 required), the description provides no information about any parameters. It doesn't explain what 'externalChainId', 'stratoToken', 'stratoTokenAmount', 'externalRecipient', or 'targetStratoToken' mean, their formats, or relationships. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Submit a withdrawal request') and target ('to an external chain'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'strato.cdp.withdraw' or 'strato.lending.withdraw-liquidity', which appear to handle different types of withdrawals within the system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention prerequisites, when this tool is appropriate versus other withdrawal tools in the sibling list, or any context about what constitutes an 'external chain' withdrawal versus internal withdrawals.
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. While 'deposit' implies a write/mutation operation, the description doesn't address critical behavioral aspects: whether this requires specific permissions, whether it's reversible, what happens on failure, or what the expected response looks like. For a financial transaction tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words, front-loading the core action and target with zero wasted words. Every element ('deposit', 'collateral', 'into a vault') contributes essential information about the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a financial transaction tool with no annotations, no output schema, and 2 undocumented parameters, the description is insufficiently complete. It doesn't address the mutation nature, potential side effects, error conditions, or return values that would be essential for safe and effective use of this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning neither parameter has any documentation in the schema. The description provides no additional information about what 'asset' and 'amount' represent, their expected formats, units, or constraints. For a 2-parameter tool with zero schema coverage, the description fails to compensate for this documentation gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('deposit') and target ('collateral into a vault'), providing a specific verb+resource combination. It distinguishes from some siblings like 'strato.cdp.withdraw' but doesn't explicitly differentiate from other deposit-related tools like 'strato.lending.deposit-liquidity' or 'strato.lending.supply-collateral'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With multiple CDP and lending-related deposit tools in the sibling list (e.g., 'strato.lending.deposit-liquidity', 'strato.lending.supply-collateral'), there's no indication of when this specific collateral deposit operation is appropriate versus those other options.
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 burden for behavioral disclosure. While 'liquidate' implies a destructive/mutative operation, the description doesn't specify what happens during liquidation (e.g., collateral seizure, debt repayment, penalties), whether this requires special permissions, potential costs or fees, irreversible consequences, or what the expected outcome looks like. For a financial operation with significant implications, this is inadequate behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that gets straight to the point with zero wasted words. It's front-loaded with the core action and target. While it may be too brief for adequate tool understanding, from a pure conciseness perspective, it's maximally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial liquidation tool with 3 undocumented parameters, no annotations, and no output schema, the description is severely incomplete. It doesn't explain the liquidation process, parameter requirements, expected outcomes, error conditions, or relationship to sibling tools. The agent would struggle to use this tool correctly without significant external knowledge about CDP systems and liquidation mechanics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 3 required parameters, the description provides no information about what 'collateralAsset', 'borrower', or 'debtToCover' represent, their expected formats, or how they relate to the liquidation process. The description doesn't mention parameters at all, failing to compensate for the complete lack of schema documentation. This leaves the agent guessing about parameter meaning and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('liquidate') and target ('an unhealthy CDP position'), providing a specific verb+resource combination. It distinguishes from other CDP tools like 'deposit', 'withdraw', or 'repay' by focusing on liquidation. However, it doesn't explicitly differentiate from the sibling 'strato.lending.liquidate' tool, which appears to serve a similar function in a different context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance - it only indicates this tool is for liquidating 'unhealthy' CDP positions. It doesn't explain when to use this versus alternatives like 'strato.lending.liquidate', what constitutes an 'unhealthy' position, prerequisites for liquidation, or any conditions under which liquidation would fail. No explicit when/when-not guidance or alternative tool references 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 provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose whether this is a write operation (implied by 'repay'), what permissions are needed, if it's irreversible, potential side effects (e.g., collateral release), or rate limits. This is inadequate for a financial transaction 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It's appropriately sized for a simple tool, though brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a debt repayment tool in a DeFi context, no annotations, no output schema, and poor parameter documentation, the description is insufficient. It lacks critical context about financial implications, error conditions, return values, and how it integrates with sibling tools, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the single parameter 'asset' is undocumented in the schema. The description adds no semantic information about what 'asset' means (e.g., token symbol, address, or identifier format), acceptable values, or examples, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('repay all debt') and the target resource ('for an asset'), which is specific and unambiguous. It distinguishes from the simpler 'strato.cdp.repay' sibling tool by specifying 'all' debt, though it doesn't explicitly contrast with other CDP tools like 'liquidate' or 'withdraw'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'strato.cdp.repay' (for partial repayment) or 'strato.cdp.liquidate' (for forced closure). The description implies it's for full debt repayment but doesn't specify prerequisites, conditions, or consequences relative to other 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 carries full behavioral disclosure burden. 'toggle pause' implies a state mutation, but it doesn't specify permission requirements, side effects (e.g., impact on existing positions), reversibility, or error conditions. This is inadequate for an administrative mutation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at 6 words with zero wasted language. The structure is front-loaded with the core action ('toggle pause') followed by target and context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an administrative mutation tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks behavioral context, parameter explanations, and output expectations, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter details. It doesn't explain what 'asset' represents (identifier format) or 'isPaused' semantics (true=pause, false=unpause). This leaves both parameters undocumented beyond basic types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('toggle pause') and target ('collateral asset'), with 'Admin' indicating administrative context. It distinguishes from siblings like 'strato.cdp.set-global-paused' by specifying asset-level control, but doesn't explicitly contrast with other pause-related tools like 'strato.lending.pause'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'Admin' hinting at permission requirements, but offers no explicit when-to-use rules, alternatives (e.g., vs. global pause), or prerequisites. It doesn't help an agent decide between this and sibling tools like 'strato.cdp.set-global-paused'.
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. While 'withdraw' implies a write/mutation operation, the description doesn't specify permission requirements, whether this action is reversible, potential side effects, or what happens to the withdrawn collateral. For a financial transaction tool, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the essential action and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial transaction tool with no annotations, no output schema, and completely undocumented parameters, the description is inadequate. It doesn't explain what happens after withdrawal, what the tool returns, error conditions, or important behavioral aspects. The description should do more given the complexity and potential impact of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so both parameters ('asset' and 'amount') are completely undocumented in the schema. The description provides no additional information about what these parameters represent, their expected formats, units, or constraints. This leaves the agent guessing about parameter meaning and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('withdraw') and resource ('collateral from a vault'), making the purpose immediately understandable. It distinguishes from some siblings like 'strato.cdp.deposit' but doesn't explicitly differentiate from 'strato.cdp.withdraw-max' or 'strato.lending.withdraw-collateral', which are closely related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'strato.cdp.withdraw-max' (presumably for maximum withdrawal) or 'strato.lending.withdraw-collateral' (which appears to be a similar operation in a different module). There's no mention of prerequisites, constraints, or typical use cases.
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 burden for behavioral disclosure. It mentions 'maximum safe' which hints at safety constraints, but fails to explain what 'safe' means (e.g., risk limits, collateral ratios), whether this is a destructive operation, permission requirements, or potential side effects. For a financial operation with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single phrase that efficiently conveys the core action. There's no wasted verbiage, and it's front-loaded with the essential information, making it structurally optimal for its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a CDP withdrawal operation, no annotations, no output schema, and poor parameter documentation, the description is incomplete. It lacks crucial details about behavior, parameters, return values, and differentiation from sibling tools, leaving significant gaps for an agent to understand and use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, with one parameter 'asset' completely undocumented. The description adds no parameter semantics—it doesn't explain what 'asset' represents (e.g., token type, identifier format), acceptable values, or how it relates to 'maximum safe collateral'. This fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('withdraw') and resource ('maximum safe collateral'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'strato.cdp.withdraw' or other withdrawal tools in the CDP/lending context, which would require explicit differentiation for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'strato.cdp.withdraw' or 'strato.lending.withdraw-collateral-max'. There's no mention of prerequisites, conditions, or comparative context with sibling tools, leaving the agent with insufficient 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 provided, so the description carries full burden. 'Admin: pause lending' implies a mutation requiring admin privileges, but doesn't disclose behavioral traits like whether pausing is reversible, if it affects all lending operations, what happens to active loans, or any side effects. For a mutation tool with zero annotation coverage, this is a significant gap in 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Admin: pause lending') with no wasted words. It's front-loaded with the key information. However, it borders on under-specification given the tool's likely complexity, but within the bounds of efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's name ('pause lending pool') suggests administrative control over a financial system, the description is incomplete. No annotations, no output schema, and minimal description fail to address critical context like permissions, effects, or error conditions. For a potentially high-impact admin tool, this leaves too much unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate. Baseline is 4 for zero parameters, as the schema fully covers the absence of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Admin: pause lending' states the action (pause) and resource (lending), but is vague about scope. It doesn't specify what 'lending' refers to (pool, protocol, asset) or distinguish from sibling tools like 'strato.lending.unpause' or 'strato.cdp.set-global-paused', which could have overlapping functionality. The purpose is understandable but lacks 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/5Does 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 doesn't mention prerequisites (e.g., admin role), conditions for pausing, or relationships to siblings like 'strato.lending.unpause' or 'strato.cdp.set-asset-paused'. Without this context, an agent must 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 full burden but offers limited behavioral insight. 'Admin:' implies elevated permissions, and 'set' suggests a mutation, but it doesn't disclose critical details like whether changes are irreversible, require multi-signature, have rate limits, or affect system stability. For an admin tool with potential high impact, this is a significant gap in 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, front-loaded sentence ('Admin: set global/per-asset debt ceilings.') that wastes no words. Every part earns its place by conveying action, scope, and context efficiently, making it easy to parse despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (admin mutation with 2 parameters), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It omits essential context such as parameter semantics, behavioral risks, expected outcomes, or error conditions, leaving the agent under-informed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'global/per-asset' but doesn't explain how 'assetUnits' and 'usdValue' parameters relate to this distinction (e.g., which is for global vs. per-asset, expected formats like token symbols or numeric strings). Without this, the agent cannot infer parameter meanings beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('set') and resource ('global/per-asset debt ceilings'), with 'Admin:' indicating administrative context. It distinguishes from siblings like 'strato.lending.borrow' or 'strato.lending.repay' by focusing on configuration rather than user transactions. However, it doesn't explicitly differentiate from other admin tools like 'strato.lending.configure-asset' or 'strato.lending.pause', which slightly reduces 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'Admin:' hinting at administrative privileges, but it lacks explicit when-to-use criteria, prerequisites, or alternatives. No comparison is made to sibling tools (e.g., 'strato.lending.configure-asset' for asset-specific settings), leaving the agent to infer usage context without clear boundaries 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 carries the full burden of behavioral disclosure. While 'approve' implies a write operation that modifies token allowances, the description doesn't cover critical aspects like authorization requirements, whether this is reversible, gas costs, or what happens on success/failure. For a blockchain transaction tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (blockchain token approval operation), lack of annotations, 0% schema coverage, and no output schema, the description is severely incomplete. It doesn't explain what the tool returns, error conditions, or the broader context of token allowances in DeFi systems. This leaves the agent with insufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (address, spender, value) are documented in the schema. The description adds no information about what these parameters mean, their formats (e.g., Ethereum addresses, token amounts), or constraints. This fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('approve allowance') and the target ('for a spender'), which is a specific verb+resource combination. However, it doesn't distinguish this tool from potential sibling tools like 'strato.tokens.transfer' or 'strato.tokens.transfer-from' that might also involve token permissions, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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's no mention of prerequisites (e.g., token ownership), context (e.g., for DeFi interactions), or exclusions. With many sibling tools in the 'strato.tokens' namespace, this lack of differentiation is a significant 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?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'transfer tokens' implies a write/mutation operation, it doesn't disclose critical behavioral traits like required permissions, whether the transfer is irreversible, gas costs, rate limits, or what happens on failure. This is inadequate for a financial transaction 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words, with zero wasted language. It's front-loaded with the core action and doesn't contain any unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a token transfer tool with 3 undocumented parameters, no annotations, and no output schema, the description is severely incomplete. It doesn't address the financial nature of the operation, potential risks, return values, or error conditions that an agent needs to understand.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for all 3 parameters, and the description provides no additional parameter information. It doesn't explain what 'address', 'to', or 'value' represent, their formats, units, or constraints. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('transfer tokens') and the target ('to another address'), which is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'strato.tokens.transfer-from', which appears to be a related transfer operation with different semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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's no mention of prerequisites, context, or comparison to sibling tools like 'strato.tokens.transfer-from', leaving the agent with no usage differentiation.
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 action ('transfer tokens') but fails to describe critical behaviors such as required permissions (e.g., approval from the 'from' address), whether the transfer is irreversible, potential gas costs, or error conditions. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for the tool's complexity and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a token transfer with 4 parameters), lack of annotations, 0% schema description coverage, and no output schema, the description is insufficient. It omits essential details like parameter meanings, behavioral traits, and usage context, making it incomplete for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters are documented in the schema. The description does not explain what 'address,' 'from,' 'to,' or 'value' represent (e.g., 'address' might be the token contract, 'value' in what units), failing to compensate for the schema gap. This leaves parameters ambiguous and hard to use correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('transfer tokens') and specifies it's done 'on behalf of another address,' which adds important context. However, it doesn't explicitly distinguish this from the sibling tool 'strato.tokens.transfer' (which likely transfers from the caller's own address), missing 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/5Does 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 like 'strato.tokens.transfer' or other token-related tools. It lacks any mention of prerequisites, context, or exclusions, leaving the agent to guess based on 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 full burden but only states what data is fetched without behavioral details. It doesn't disclose whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior (implied by limit/offset but not explained), or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured as a single sentence listing four data categories. It's appropriately sized for a multi-purpose fetch tool, though it could be slightly more front-loaded with primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the relationships between parameters (e.g., how chainId interacts with other parameters), doesn't describe the return format, and leaves behavioral aspects undocumented despite the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (3 of 6 parameters have descriptions). The description mentions 'deposit/withdrawal history' which aligns with the txType parameter, and 'withdrawal summary' relates to includeSummary, adding some context. However, it doesn't fully compensate for the undocumented parameters (limit, offset) or provide additional semantics beyond what the schema already describes for chainId and context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches multiple types of bridge-related data (configs, tokens, history, summary), providing specific resources. However, it doesn't explicitly differentiate from sibling tools like 'strato.bridge.request-auto-save' or 'strato.bridge.request-withdrawal', which appear to be action-oriented rather than fetch operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 lists what data can be fetched but doesn't indicate scenarios, prerequisites, or comparisons with other bridge-related tools in the sibling 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('fetch'), but doesn't specify if it requires authentication, has rate limits, returns paginated data, or what happens on errors. For a tool with 3 parameters and no annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that lists what data is fetched. It's appropriately sized and front-loaded with the core purpose. However, it could be slightly more structured by grouping related data points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (CDP data fetching with 3 parameters), no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain return formats, error handling, or provide enough context for the agent to use the tool effectively in this rich sibling tool environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (1 of 3 parameters has a description), so the description should compensate but doesn't. It mentions 'assets' generally but doesn't explain the 'asset' parameter's address format or clarify the boolean flags. The description adds minimal value beyond the sparse schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches specific CDP-related data (vaults, assets, debt metrics, bad debt, and interest/stats), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'strato.cdp.deposit' or 'strato.cdp.liquidate', which are clearly write operations, so it falls short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention prerequisites, timing, or compare it to other tools like 'strato.events' or 'strato.protocol-fees' that might also provide related data. This leaves the agent without contextual usage instructions.
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 fetching data (implying a read operation) but lacks details on permissions, rate limits, response format, or any side effects. This is insufficient for a tool with multiple data types 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence listing the fetched data types without unnecessary words. It's front-loaded with the verb 'Fetch' and directly states the scope, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (fetching multiple data types), no annotations, no output schema, and 0% schema coverage, the description is incomplete. It lacks details on behavior, parameters, and output, making it inadequate for an agent to use effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it doesn't mention parameters at all. The two parameters (includeInterest, includeNearUnhealthy) are undocumented in both schema and description. Baseline is 3 due to low parameter count (2) and no schema coverage, but the description adds no value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches multiple lending-related data types (pools, loans, liquidity, collateral, liquidations, safety module state), which is specific and actionable. However, it doesn't distinguish itself from potential sibling tools like 'strato.events' or 'strato.cdp' that might also provide related data, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 lists what it fetches but doesn't specify scenarios, prerequisites, or comparisons to other tools like 'strato.events' for events or 'strato.cdp' for CDP data, leaving the agent without contextual 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?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It does not disclose effects (e.g., whether it locks funds, requires permissions, has time delays, or impacts other operations), rate limits, or error conditions, leaving significant gaps for a tool that likely involves system state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loaded. It is appropriately sized for a tool with no parameters, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'safety module cooldown' in a lending context, no annotations, no output schema, and 0 parameters, the description is incomplete. It lacks details on what the tool does behaviorally, what it returns, or how it integrates with sibling tools, failing to provide sufficient context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description does not add param details beyond the schema, but this is acceptable as there are no parameters to document, aligning with the baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Begin safety module cooldown' states the action (begin) and target (safety module cooldown), providing a basic purpose. However, it lacks specificity about what 'safety module cooldown' entails or how it differs from sibling tools like 'strato.lending.safety-redeem' or 'strato.lending.safety-stake', making it vague rather than clearly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 prerequisites, timing, or context for initiating a cooldown, leaving the agent without usage instructions. It implies a specific action but offers no exclusionary or comparative 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 provided, the description carries full burden for behavioral disclosure. It states a financial action ('redeem') but doesn't explain what redemption entails (e.g., converting shares to another asset, potential fees, irreversible effects, or required permissions). This is inadequate for a tool likely involving asset transfers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for a no-parameter tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial redemption tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, outcomes, or error conditions, which are crucial for safe invocation in a DeFi context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, earning a baseline score of 4 for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Redeem all sUSDST shares' states a clear verb ('redeem') and resource ('sUSDST shares'), but it's vague about what 'redeem' means in this context and doesn't differentiate from sibling tools like 'strato.lending.safety-redeem' (singular vs. all). It provides basic purpose but lacks specificity about the financial 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/5Does 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 doesn't mention prerequisites, conditions for redemption, or differences from similar tools like 'strato.lending.safety-redeem', leaving the agent with no usage 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 burden. It implies a mutation ('unpause') but doesn't disclose behavioral traits such as required admin permissions, whether the action is reversible, side effects on users, or rate limits. The description adds minimal context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loaded with the key action and context ('Admin'). There is no wasted language, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (an admin action to unpause lending) and lack of annotations and output schema, the description is incomplete. It doesn't explain what 'unpause' entails operationally, potential impacts, or return values, leaving significant gaps for an AI agent to understand the tool's full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate, earning a baseline score of 4 for adequately handling the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Admin: unpause lending' states the action (unpause) and resource (lending), but is vague about what 'lending' specifically refers to (e.g., a lending pool, protocol, or system). It distinguishes from sibling 'strato.lending.pause' by being the opposite action, but lacks specificity about the 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/5Does 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 mentions 'Admin' but doesn't specify prerequisites, conditions for unpausing, or when to choose this over other lending tools like 'strato.lending.configure-asset' or 'strato.lending.set-debt-ceilings' that might affect pool status.
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 burden for behavioral disclosure. It states this is a withdrawal operation (implying a state change) but doesn't mention important behavioral aspects like whether this requires specific permissions, what happens to the withdrawn collateral, potential transaction costs, or how 'maximum available' is calculated (e.g., considering health factors, limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just one sentence with no wasted words. It's front-loaded with the core action and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial transaction tool with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what 'maximum available' means operationally, doesn't mention return values or potential errors, and provides minimal context for a tool that presumably moves significant financial assets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'for an asset' which corresponds to the single 'asset' parameter, giving it some semantic meaning. However, it doesn't specify what format the asset identifier should take (e.g., token address, symbol) or provide examples, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('withdraw maximum available collateral') and resource ('for an asset'), making the purpose understandable. However, it doesn't explicitly differentiate from its sibling 'strato.lending.withdraw-collateral' (which presumably withdraws a specified amount rather than maximum), so it misses full 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'strato.lending.withdraw-collateral' or other lending operations. The description doesn't mention prerequisites, constraints, or typical use cases for withdrawing maximum collateral versus partial amounts.
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 full burden but only states it's an admin action without detailing behavioral traits like permissions required, whether the change is reversible, rate limits, or effects on the system. 'set' implies mutation, but critical context like authorization needs or impact is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single sentence that front-loads key information ('Admin: set oracle price for an asset'). It avoids redundancy, though it could be more structured with separate usage or parameter notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, 50% schema coverage, and no output schema, the description is incomplete. It lacks details on permissions, behavioral effects, parameter meanings, or return values, making it insufficient for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'price' has a description), and the description adds no parameter details beyond what's in the schema. It doesn't explain 'token' or provide additional context for either parameter, so it meets the baseline for moderate schema coverage without compensating for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('set') and resource ('oracle price for an asset'), with 'Admin' indicating administrative privileges. It distinguishes from siblings like 'strato.cdp.set-asset-paused' or 'strato.lending.configure-asset' by focusing specifically on oracle pricing, though it doesn't explicitly contrast with 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'Admin' hinting at administrative context, but lacks explicit when-to-use instructions, prerequisites, or alternatives. It doesn't specify conditions for use or compare to other price-setting tools, leaving usage ambiguous.
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 implies a write operation ('claim') but doesn't specify permissions required, whether it's irreversible, potential side effects, or rate limits. This is inadequate for a tool that likely involves transactions or rewards distribution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and directly states the tool's function, making it highly concise and well-structured for its simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a rewards-claiming tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'rewards' or 'activities' entail, the return format, error conditions, or behavioral traits, leaving significant gaps for an AI agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, but it could hint at implicit context (e.g., user authentication). Baseline is 4 for zero parameters, as the schema fully covers the lack of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Claim all rewards across activities' clearly states the action (claim) and target (rewards across activities), which is better than a tautology. However, it doesn't specify what 'activities' refers to or distinguish this tool from its sibling 'strato.rewards.claim' and 'strato.rewards.claim-activity', leaving the purpose somewhat vague in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'strato.rewards.claim' or 'strato.rewards.claim-activity'. It lacks context about prerequisites, timing, or exclusions, offering only a basic statement of function without 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?
With no annotations provided, the description carries full burden but lacks behavioral details. It states the tool proxies requests but doesn't disclose traits like whether it's read-only or destructive, authentication needs, rate limits, error handling, or response format. This is a significant gap for a tool that likely interacts with blockchain networks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of RPC operations, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral constraints, leaving the agent under-informed for safe and effective use in a blockchain context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the two parameters (chainId and payload). The description adds no additional semantic context beyond implying the payload is JSON-RPC, which the schema already covers. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('proxy') and resource ('JSON-RPC request through the backend RPC router'), providing a specific technical function. However, it doesn't explicitly differentiate from sibling tools like 'strato.bridge' or 'strato.cdp' that might also involve RPC-like operations, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., for generic RPC calls vs. specific operations handled by other tools), or any exclusions, leaving the agent with minimal 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only inspection function ('inspect'), but doesn't clarify if it requires authentication, has rate limits, returns paginated data, or what happens with partial inputs. The mention of 'history' and 'positions' suggests data retrieval, but lacks details on scope or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that lists all key functionalities without redundancy. It's front-loaded with the core action ('inspect') and enumerates resources clearly, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, low schema coverage, no annotations, no output schema), the description is inadequate. It doesn't explain return values, error conditions, or how parameters interact (e.g., mutual exclusivity between 'poolAddress' and token pairs). For a multi-functional inspection tool in a DeFi context, more detail is needed to ensure correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 43% (low), but the description adds minimal parameter semantics beyond the schema. It mentions inspecting pools, tokens, positions, history, and details, which loosely maps to parameters like 'poolAddress', 'includePositions', and 'includeHistory', but doesn't explain relationships (e.g., that 'tokenA' and 'tokenB' are for finding pairable pools) or usage nuances. This partially compensates for the low coverage but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects swap pools, supported tokens, LP positions, history, and pool details, providing a specific verb ('inspect') and resources. However, it doesn't explicitly distinguish from sibling tools like 'strato.swap.execute' (which likely performs swaps) or 'strato.swap.add-liquidity' (which modifies pools), leaving some ambiguity about its read-only nature versus mutation capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention prerequisites, context (e.g., for querying vs. executing swaps), or exclusions, despite having many sibling tools in the 'strato.swap' namespace that handle related operations like adding liquidity or executing swaps.
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 the action ('provide both tokens') but lacks critical details: it doesn't mention that this is a write/mutation operation (implied by 'add'), potential risks (e.g., impermanent loss, slippage), required permissions, or what happens upon success (e.g., LP token minting). For a financial operation with 4 parameters, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Provide both tokens to a pool')—a single sentence with zero wasted words. It's front-loaded with the core action, making it easy to parse quickly. This efficiency is commendable, though it comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a DeFi liquidity operation with 4 parameters), no annotations, and no output schema, the description is incomplete. It misses behavioral traits (e.g., mutation effects, risks), usage context, and output expectations. While the schema covers parameters well, the description fails to compensate for the lack of other structured information, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so parameters are well-documented in the schema itself. The description adds no additional semantic context beyond implying dual-token involvement ('both tokens'), which aligns with parameters like 'tokenBAmount' and 'maxTokenAAmount'. Since the schema does the heavy lifting, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Provide both tokens to a pool' clearly states the action (provide) and resource (tokens to a pool), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'strato.swap.add-liquidity-single' (which likely adds single-sided liquidity) or 'strato.lending.deposit-liquidity' (which might be for lending pools), leaving room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 no mentions of prerequisites (e.g., token approvals), comparisons to sibling tools (like 'add-liquidity-single'), or scenarios where this tool is preferred. This lack of context makes it harder for an agent to choose correctly among 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Create') but doesn't describe what this entails—whether it's a blockchain transaction requiring gas fees, if it requires specific permissions, what happens on failure, or if it returns a pool address. For a creation tool with zero annotation coverage, this leaves critical behavioral aspects 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what a 'swap pool' is in this context, what the creation process involves (e.g., on-chain transaction), what permissions are needed, or what the tool returns (e.g., a pool address). Given the complexity implied by sibling tools in the 'strato.swap' namespace, more context is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters (tokenA, tokenB, isStable) documented in the schema. The description mentions 'between tokenA and tokenB,' aligning with the schema but adding no extra semantic context beyond what's already provided. The baseline score of 3 reflects adequate coverage when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new swap pool between tokenA and tokenB'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'strato.swap.add-liquidity' or 'strato.swap.execute', which also involve swap pool operations but for 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/5Does 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 doesn't mention prerequisites (e.g., token approvals, existing pools), when not to use it (e.g., if a pool already exists), or refer to sibling tools like 'strato.swap.add-liquidity' for adding to existing pools.
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 burden for behavioral disclosure. While 'redeem' implies a transaction that likely involves blockchain interaction and potential fees, the description doesn't specify gas requirements, confirmation times, irreversible nature, or what happens to the redeemed assets. This leaves significant behavioral gaps for a financial 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for the tool's complexity and gets straight to the point with zero wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial transaction tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after redemption (what assets are returned, in what proportions), doesn't mention transaction costs or risks, and provides no information about the return format or potential error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing complete parameter documentation. The description doesn't add any additional semantic context beyond what's already in the schema (pool address, LP token amount, include staked LP tokens). This meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Redeem LP tokens from a pool' clearly states the action (redeem) and resource (LP tokens from a pool), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'strato.swap.add-liquidity' or 'strato.lending.withdraw-liquidity', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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's no mention of prerequisites, timing considerations, or comparison to similar tools in the sibling list, leaving the agent without contextual usage information.
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 implies a read-only operation ('fetch'), but doesn't mention authentication requirements, rate limits, response size considerations (e.g., 'large response' is only noted in the schema), or error conditions. This is inadequate for a tool with 7 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads all key information without any wasted words. It directly lists the four data types that can be fetched, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain how the parameters interact (e.g., combining 'tokenAddress' with other flags), what the response structure looks like, or any behavioral constraints. This leaves significant gaps for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 71%, providing good documentation for most parameters. The description adds no parameter-specific information beyond what's in the schema, but with high coverage, the baseline is 3. It doesn't compensate for the 29% gap (e.g., 'includeStats' lacks a description in both).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('fetch') and resources ('token catalog, user balances, voucher balance, and earning assets'), making it easy to understand what data can be retrieved. However, it doesn't explicitly distinguish this read-only tool from its sibling mutation tools like 'strato.tokens.approve' or 'strato.tokens.transfer', which would require 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/5Does 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 doesn't mention any prerequisites, context-specific recommendations, or exclusions, leaving the agent to infer usage solely from the purpose statement.
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 states the action ('Borrow') but doesn't explain what this entails—e.g., whether it's a transaction that requires user approval, what the financial implications are (like interest or collateral), or what happens on success/failure. This leaves significant gaps for a financial 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial borrowing tool with no annotations and no output schema, the description is inadequate. It lacks details on behavior, risks, returns, or how it differs from siblings. Given the complexity implied by the tool's context (lending/borrowing in a DeFi system), more completeness is needed to guide safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description doesn't add parameter details, which is appropriate here, but it could have mentioned implicit dependencies (e.g., user context or asset availability). Given the zero-param baseline, this is a strong score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Borrow') and the resource ('maximum available USDST'), which is specific and informative. However, it doesn't explicitly differentiate from its sibling 'strato.lending.borrow', which appears to be a similar tool without the 'max' qualifier, leaving some ambiguity about when to use one over the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention the sibling 'strato.lending.borrow' or explain the difference between borrowing a specific amount versus the maximum available, nor does it discuss prerequisites or contexts for usage.
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 full burden but only states the action without behavioral details. It doesn't disclose permissions needed, whether it's irreversible, potential side effects, or transaction outcomes, leaving significant gaps for a financial 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, effectively front-loading the core action. It's appropriately sized for a simple tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial withdrawal tool with no annotations and no output schema, the description is insufficient. It lacks details on return values, error conditions, or behavioral context, making it incomplete for safe agent use despite the simple parameter setup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema coverage, so no parameter documentation is needed. The description doesn't add param info, but this is appropriate given the empty schema, warranting a baseline score above minimum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('withdraw') and resource ('all available liquidity'), making the purpose understandable. However, it doesn't explicitly differentiate from its sibling 'strato.lending.withdraw-liquidity' (which likely allows partial withdrawals), missing full 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/5Does 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 like 'strato.lending.withdraw-liquidity' for partial withdrawals. The description lacks context about prerequisites, timing, or exclusions, offering minimal 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 provided, so the description carries the full burden of behavioral disclosure. It mentions fetching revenue summaries but doesn't specify whether this is a read-only operation, if it requires authentication, rate limits, data freshness, or error conditions. For a data-fetching tool with zero annotation coverage, this is a significant gap in 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('fetch revenue summaries') and includes key details ('aggregated or per-protocol'). There is no wasted verbiage, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 optional parameters, no output schema, no annotations), the description is minimally adequate. It covers what the tool does but lacks behavioral details and usage context. Without annotations or output schema, the agent must rely heavily on the schema and trial-and-error, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description implies that parameters control aggregation level (per-protocol vs. aggregated) and time period, which adds some semantic context beyond the schema's enum values. However, with 100% schema description coverage, the schema already documents both parameters well, so the description only provides marginal additional value, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('fetch') and resource ('revenue summaries'), and distinguishes between aggregated and per-protocol summaries. However, it doesn't explicitly differentiate from sibling tools like 'strato.events' or 'strato.rewards' that might also fetch data, though the focus on revenue is 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/5Does 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 doesn't mention prerequisites, timing, or compare it to other data-fetching tools in the sibling list, leaving the agent to infer usage based on the name and parameters 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 full burden but offers minimal behavioral insight. It implies a write operation ('Claim') but doesn't disclose side effects, permissions required, transaction costs, or what 'pending' means. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and scope, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., idempotency, errors), return values, or how it interacts with the reward system. The agent would struggle to use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description adds no parameter information, which is appropriate here. Baseline is 4 for zero-parameter tools when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Claim') and target ('all pending CATA rewards from RewardsChef'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'strato.rewards.claim-activity' or 'strato.rewards.claim-all-activities', which appear to handle different reward types or scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention prerequisites (e.g., having pending rewards), timing considerations, or differences from sibling reward-claiming tools, leaving the agent to infer usage context.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/strato-net/strato-griphook'
If you have feedback or need assistance with the MCP directory API, please join our Discord server