Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Regen Network MCP Server find the latest carbon credit sell orders and their prices"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server providing programmatic access to the Regen Network blockchain - enabling AI agents and developers to interact with ecological credit markets.
This MCP server enables seamless interaction with Regen Network, a blockchain platform designed for ecological asset verification and trading. Through a standardized interface, you can:
š Query ecological credit types, classes, and batches
š° Analyze marketplace dynamics and sell orders
š Perform portfolio impact analysis
š Compare methodology frameworks
āļø Access blockchain data (bank, governance, distribution modules)
š¤ Enable AI agents to participate in environmental markets
Regen Network is a specialized blockchain infrastructure for ecological credits, supporting diverse asset types:
Carbon Credits (CO2e sequestration and reduction)
Biodiversity Credits (habitat preservation and restoration)
Regenerative Agriculture Metrics (soil health, grazing management)
The network provides transparent, verifiable tracking of ecological projects with on-chain provenance.
The Model Context Protocol is a standardized interface for connecting AI systems to external data sources and tools. This server implements MCP to make Regen Network accessible to AI agents like Claude, ChatGPT, and custom applications.
Related MCP server: Bink MCP Server
Bank Module (11 tools): Account balances, token supplies, denomination metadata
Distribution Module (9 tools): Validator rewards, delegator information, community pool
Governance Module (8 tools): Proposals, votes, deposits, tally results
Marketplace Module (5 tools): Sell orders, pricing, allowed denominations
Ecocredits Module (4 tools): Credit types, classes, projects, batches
Baskets Module (5 tools): Basket operations, balances, fees
Analytics Module (3 tools): Portfolio impact, market trends, methodology comparison
Guided workflows for common tasks:
Chain exploration and getting started
Ecocredit query workshop
Marketplace investigation
Project discovery
Credit batch analysis
Query builder assistance
Configuration setup
Full capabilities reference
Multiple endpoint failover for reliability
Configurable caching layer
Type-safe Pydantic models
Async/await for performance
Comprehensive error handling with retryability signals
Health monitoring and metrics
The client includes hardened retry/backoff logic:
Transient errors (5xx, 429, timeouts) are automatically retried with exponential backoff + jitter
Client errors (4xx except 429) fail immediately without wasting retry attempts
All errors include retryable and retry_after_ms fields for downstream clients
fetch_all_pages() helper eliminates agent-side pagination loops
Credit class names are now resolved directly from on-chain anchored metadata IRIs:
Authoritative names: schema:name from https://api.regen.network/data/v2/metadata-graph/{iri}
Source registry: Extracts regen:sourceRegistry (e.g., "City Forest Credits" for C02)
Caching: 1-hour TTL for resolved metadata, 5-minute TTL for failures
No guessing: Class names like C01="Verified Carbon Standard" come from the chain, not hardcoded mappings
The /ecocredits/batches endpoint supports aggregation:
# Get summary by credit type instead of paginating through all batches
curl "https://regen.gaiaai.xyz/regen-api/ecocredits/batches?summary=true&fetch_all=true"Returns totals for issued/tradable/retired credits by type, reducing common multi-page loops.
Python 3.10 or higher
pip package manager
# Clone the repository
git clone https://github.com/your-org/regen-python-mcp.git
cd regen-python-mcp
# Install dependencies
pip install -r requirements.txt
# Run the server
python main.pyThe server uses environment variables for configuration. Create a .env file:
# Optional: Override default RPC endpoints
REGEN_RPC_ENDPOINTS=https://regen-rpc.polkachu.com,https://rpc.cosmos.directory/regen
# Optional: Override default REST endpoints
REGEN_REST_ENDPOINTS=https://regen-api.polkachu.com,https://rest.cosmos.directory/regen
# Optional: Configure caching
REGEN_MCP_ENABLE_CACHE=true
REGEN_MCP_CACHE_TTL_SECONDS=60
# Optional: Logging level
REGEN_MCP_LOG_LEVEL=INFOSee src/mcp_server/config/settings.py for all configuration options.
The repository includes pre-configured MCP setup files. See MCP_SETUP.md for complete instructions.
Quick Start:
Files are already configured:
.mcp.json - Server connection config
.claude/settings.json - Enable MCP servers
Install dependencies: pip install -r requirements.txt
Restart Claude Code
Manual Configuration:
Add to your Claude Desktop or Claude Code configuration:
{
"mcpServers": {
"regen-network": {
"command": "/path/to/uv",
"args": ["run", "--directory", "/path/to/regen-python-mcp", "python", "main.py"],
"env": {
"PYTHONPATH": "/path/to/regen-python-mcp/src"
}
}
}
}from mcp.client import ClientSession, StdioServerParameters
import asyncio
async def main():
server_params = StdioServerParameters(
command="python",
args=["main.py"]
)
async with ClientSession(server_params) as session:
# List available tools
tools = await session.list_tools()
print(f"Available tools: {len(tools)}")
# List credit types
result = await session.call_tool("list_credit_types", {})
print(result)
asyncio.run(main())# Get all ecological credit types
await client.call_tool("list_credit_types", {})
# List credit classes with pagination
await client.call_tool("list_classes", {"limit": 10, "offset": 0})
# Get marketplace sell orders
await client.call_tool("list_sell_orders", {"page": 1, "limit": 20})
# Analyze portfolio impact
await client.call_tool("analyze_portfolio_impact", {
"address": "regen1...",
"analysis_type": "full"
})
# Compare methodologies
await client.call_tool("compare_credit_methodologies", {
"class_ids": ["C01", "C02", "C03"]
})OpenAI Custom GPT Actions enforce a maximum of 30 operations per OpenAPI spec, and Action sets cannot include duplicate domains. This repo supports a two-Action setup:
Ledger Action (on-chain): upload openapi-gpt-ledger.json with server https://regen.gaiaai.xyz (25 ops, /regen-api/* only)
KOI Action (knowledge): upload openapi-gpt-koi.json with server https://registry.regen.gaiaai.xyz (4 ops, /api/koi/* only)
To regenerate the GPT/Full + split Action specs deterministically:
python3 scripts/generate_openapi_schemas.py
python3 scripts/validate_openapi_gpt.py --strictRecommended instruction text for the GPT lives in:
gpt-instructions.md
gpt-knowledge.md
regen-python-mcp/
āāā main.py # Entry point
āāā requirements.txt # Python dependencies
āāā docs/ # Documentation
ā āāā regen_mcp_thesis.md # Vision and use cases
ā āāā regen_network_exploration_report.md
āāā tests/ # Test suite
āāā archive/ # Archived exploratory code
āāā src/
āāā mcp_server/
āāā server.py # Main MCP server (45 tools, 8 prompts)
āāā client/ # Regen Network API client
āāā config/ # Configuration management
āāā models/ # Pydantic data models
āāā tools/ # Tool implementations by module
āāā prompts/ # Interactive prompt guides
āāā resources/ # Dynamic resource handlers
āāā cache/ # Caching layer
āāā monitoring/ # Health and metrics
āāā scrapers/ # Data collection utilitiesModular Organization: Tools grouped by blockchain module for maintainability
Type Safety: Pydantic models throughout for runtime validation
Async-First: All I/O operations use async/await patterns
Graceful Degradation: Optional modules with fallback behavior
Configuration-Driven: Environment variables for deployment flexibility
list_accounts, get_account, get_balance, get_all_balances
get_spendable_balances, get_total_supply, get_supply_of
get_bank_params, get_denoms_metadata, get_denom_metadata, get_denom_owners
get_distribution_params, get_validator_outstanding_rewards
get_validator_commission, get_validator_slashes
get_delegation_rewards, get_delegation_total_rewards
get_delegator_validators, get_delegator_withdraw_address, get_community_pool
get_governance_proposal, list_governance_proposals
get_governance_vote, list_governance_votes
list_governance_deposits, get_governance_params
get_governance_deposit, get_governance_tally_result
get_sell_order, list_sell_orders
list_sell_orders_by_batch, list_sell_orders_by_seller, list_allowed_denoms
list_credit_types, list_classes, list_projects, list_credit_batches
list_baskets, get_basket, list_basket_balances
get_basket_balance, get_basket_fee
analyze_portfolio_impact, analyze_market_trends, compare_credit_methodologies
# Create virtual environment
python -m venv venv
source venv/bin/activate # On Windows: venv\Scripts\activate
# Install in editable mode
pip install -e .
# Install development dependencies
pip install pytest black mypy ruff# Run all tests
pytest tests/
# Run with coverage
pytest --cov=src/mcp_server tests/
# Run specific test file
pytest tests/test_prompts.py -v# Format code
black src/
# Type checking
mypy src/
# Linting
ruff check src/Prompts Guide: Complete guide to interactive prompts
Thesis Document: Vision, use cases, and impact potential
Exploration Report: Technical deep-dive
Configuration: All configuration options
Autonomous environmental market analysis
Automated portfolio optimization
Real-time credit price discovery
Methodology comparison and selection
Building eco-finance applications
Integrating Regen data into dashboards
Creating custom analytics tools
Prototyping new market mechanisms
Environmental credit market analysis
Methodology effectiveness studies
Market liquidity and pricing research
Impact verification and tracking
Contributions welcome! Please:
Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request
This project is licensed under the MIT License - see the LICENSE file for details.
Regen Network - For building the ecological credit infrastructure
Anthropic - For the Model Context Protocol specification
The open source community
Built with š± for a regenerative future
Analyze market trends across credit types with historical data analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| time_period | No | 30d | |
| credit_types | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'analyze' but does not disclose behavioral traits such as whether it has side effects, authorization requirements, rate limits, or if it triggers long computations. The description is insufficient to inform an agent about operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, which is efficient and front-loaded. It avoids unnecessary details, but given the lack of parameter and usage information, the conciseness comes at the cost of completeness. Still, it earns a 4 for being well-structured and appropriately sized for the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (reducing need to describe return values), the description does not explain what 'trends' entails or how the optional parameters affect results. It misses key contextual details like default behavior (e.g., credit_types=null means all) and output format, making it incomplete for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no parameter descriptions. The tool description does not mention the parameters 'time_period' or 'credit_types' at all, failing to add context about valid values, defaults, or behavior. This is a critical gap for correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes market trends across credit types using historical data. It uses a specific verb ('analyze') and resource ('market trends'), and distinguishes from sibling tools like 'analyze_portfolio_impact' which focuses on portfolio, and 'compare_credit_methodologies' which is comparison. However, it could be more precise about the output (e.g., what kind of analysis is produced).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, complementary tools, or when not to use it. With multiple analysis tools available (e.g., analyze_portfolio_impact), the lack of usage context reduces its utility for agent selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advanced portfolio ecological impact analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| analysis_type | No | full |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits but only states 'advanced portfolio ecological impact analysis'. It does not indicate whether the tool is read-only, requires authentication, modifies state, or has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one brief sentence), but it is under-specified for the tool's apparent complexity. While concise, it sacrifices essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not clarify what the analysis returns or how to interpret results. For a tool with 2 parameters and no annotations, the description fails to provide sufficient context to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add parameter meaning. However, it provides no explanation of the 'address' or 'analysis_type' parameters, leaving the AI agent without context on their roles or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs advanced portfolio ecological impact analysis, distinguishing it from siblings like analyze_market_trends by specifying the resource (portfolio ecological impact). However, it could be more specific about what the analysis entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives such as analyze_market_trends or compare_credit_methodologies. The description lacks context on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare different credit class methodologies for impact efficiency analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| class_ids | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the tool 'compare[s]' and hints at a read-only analysis, but does not confirm read-only nature, side effects, or other behavioral traits like performance or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence of 10 words that front-loads the core action and purpose. It earns its place but could benefit from additional detail without exceeding conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's analytical nature and lack of annotations, the description is insufficient. It does not explain the output format, how the comparison is structured, or what 'impact efficiency analysis' entails. The presence of an output schema reduces the need for return value documentation, but the brevity leaves many uncertainties.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context to the single required parameter 'class_ids' by indicating they refer to 'different credit class methodologies' for comparison, which is beyond the schema's bare 'array of strings' definition. However, it does not specify format, constraints, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Compare' and specifies the resource 'credit class methodologies' for 'impact efficiency analysis'. It distinguishes itself from sibling tools like 'analyze_market_trends' and 'analyze_portfolio_impact' which are broader analysis tools, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or context for the comparison. It does not mention any limitations or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed account information.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent and description does not disclose any behavioral traits (e.g., read-only, authentication needs). The one-sentence description provides no insight beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence, very concise. However, it is too short to provide value, borderline under-specified rather than efficiently worded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists and parameter count is low, the description fails to contextualize the tool among many siblings (e.g., get_balance, get_all_balances). Agent cannot distinguish when to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond the schema. The address parameter is not explained regarding format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get detailed account information', using a verb and resource. It distinguishes from sibling tools like get_balance or get_spendable_balances, though 'detailed' is vague but acceptable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_balance, get_all_balances, or get_spendable_balances. Agent receives no selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all token balances for account.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| page | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It fails to disclose pagination behavior, data scope, or any side effects. The single sentence offers no behavioral insight beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is too sparing. It lacks necessary detail, making it under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has required parameters and an output schema, the description is incomplete. It fails to clarify pagination, which tokens are included, or how results are ordered. The agent needs more context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on any parameters. 'address' is required but its meaning is assumed; 'page' and 'limit' are not explained. The description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), resource ('all token balances'), and context ('for account'). This distinguishes it from siblings like 'get_balance' (single balance) and 'get_spendable_balances' (spendable subset).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs. alternatives such as 'get_balance' or 'get_spendable_balances'. The agent is left without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get specific token balance for account.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| denom | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits like read-only nature, caching, permissions, or error conditions. The tool is likely read-only but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core action. It is front-loaded and efficient, though very minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the availability of an output schema and the simplicity of the tool, the description is minimally adequate. However, it lacks context about when to use this tool over similar ones and does not mention the return format or any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning or format of the 'address' and 'denom' parameters. It adds no value beyond what the parameter names imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and resource 'specific token balance for account,' but does not differentiate from sibling tools like get_all_balances or get_spendable_balances, which also retrieve balances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_all_balances or get_spendable_balances. The description offers no exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get bank module parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation via 'Get', but without annotations, no additional behavioral traits (e.g., safety, idempotency) are disclosed. For a simple parameter retrieval, this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter input and presence of an output schema, the description is mostly complete. It could mention that no parameters are required, but the input schema already indicates this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema description coverage is 100% (trivially). Per guidelines, baseline score 4 applies when no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get bank module parameters' clearly identifies the verb and resource, but it does not differentiate from sibling tools like 'get_distribution_params' or 'get_governance_params' that also retrieve module parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling 'get_*' tools, the description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get specific basket information.
| Name | Required | Description | Default |
|---|---|---|---|
| basket_denom | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not indicate whether this is a read-only operation, required permissions, or what happens when the basket does not exist. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, just one sentence. While brief, it lacks sufficient detail to be fully effective. It is not overly verbose, but could be improved with more information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, explanation of return values is not required. However, the tool has one parameter and many siblings; the description does not provide enough context for an agent to correctly invoke this tool over others. It is minimally adequate but incomplete for a complex ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description does not explain the basket_denom parameter. The schema's title 'Basket Denom' provides some meaning, but the description adds no value beyond that, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and resource (specific basket information), and it distinguishes from siblings like get_basket_balance and list_baskets by specifying 'specific' rather than listing or balance. However, 'information' is vague and could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_basket_balance or list_baskets. The description does not mention any preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get specific batch balance in basket.
| Name | Required | Description | Default |
|---|---|---|---|
| basket_denom | Yes | ||
| batch_denom | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden but fails to disclose behavioral traits. It does not state that the operation is read-only, discuss authentication needs, error cases, or the return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, but it is under-specified. While concise, it sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and sibling tools, the description is too brief. It lacks context about the return value, prerequisites, or relationship to other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds no meaning beyond the parameter names; no hints on format or valid values for 'basket_denom' and 'batch_denom'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get specific batch balance in basket,' indicating the tool retrieves a single balance for a batch in a basket. However, it does not differentiate from the sibling 'list_basket_balances' tool, missing an opportunity to clarify singularity vs plurality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not mention when to use this tool over alternatives like 'list_basket_balances' or other getter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get basket creation fee.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool gets a fee, implying a read operation, but does not disclose whether the fee is constant or dynamic, if authentication is required, or if any side effects exist. The behavioral profile 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no superfluous words. It is front-loaded and efficient, fitting the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description covers the basic action. However, it does not mention what the output represents (e.g., numeric value, coin) or any constraints, leaving the agent without full context. It is adequate but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%. The description adds no parameter details but is not required to. The absence of parameters is clear from the schema, so the description does not need to compensate. A higher score would require additional context about the fee's variability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'basket creation fee', indicating the tool retrieves a fee. However, it does not explain what the fee is for or how it is determined, which could be ambiguous. It vaguely distinguishes from siblings like get_basket (which gets basket details) 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_basket or list_baskets. There is no mention of prerequisites, context, or limitations, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get community pool balance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states the tool 'gets balance' without disclosing read-only behavior, rate limits, or authentication needs. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with no parameters and an output schema. Description is minimal but adequate for a straightforward read operation. However, it does not mention any prerequisites or potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters, and schema coverage is 100%. The description adds no extra meaning beyond the schema, which is sufficient (baseline 3).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Get community pool balance' clearly states the action (get) and resource (community pool balance), distinguishing it from sibling tools that retrieve other types of data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_account, get_balance, or list_* tools. The description lacks context about its usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get delegation rewards for specific delegator-validator pair.
| Name | Required | Description | Default |
|---|---|---|---|
| delegator_address | Yes | ||
| validator_address | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only states it is a read operation. It does not mention authentication, error handling, or what happens if the pair does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, clear and concise. No unnecessary words. Efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks guidance on when to use, behavioral details, and parameter semantics, making it incomplete for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description only vaguely refers to 'specific delegator-validator pair' without explaining address format or constraints. Minimal added meaning beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses a specific verb and resource ('Get delegation rewards') and identifies the pair, distinguishing it from siblings like get_delegation_total_rewards or get_validator_outstanding_rewards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_delegation_total_rewards or get_validator_outstanding_rewards. No context on prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get total delegation rewards for a delegator.
| Name | Required | Description | Default |
|---|---|---|---|
| delegator_address | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the action, no information on side effects, permissions, or return behavior. The existence of an output schema is not leveraged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It is efficient but lacks structure like bullet points or sections, which would improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 required param, output schema exists), the description is too minimal. It does not mention the return value format or any conditions, leaving the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the single parameter 'delegator_address' beyond its name and type in the schema. Schema description coverage is 0%, and the description fails to explain what the parameter expects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'total delegation rewards' for a delegator. It is specific enough to indicate the function, but does not differentiate from the similar sibling 'get_delegation_rewards', which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_delegation_rewards' or 'get_delegator_validators'. Does not specify prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get validators that a delegator is bonded to.
| Name | Required | Description | Default |
|---|---|---|---|
| delegator_address | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It only says 'Get' which implies read-only but does not disclose performance, auth needs, rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence lacking structure. While short, it omits necessary context and is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one required param) and presence of an output schema, the description should at least hint at what the output contains. It does not, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the parameter name 'delegator_address'. Schema description coverage is 0%, and the description fails to elaborate on the parameter's format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('validators that a delegator is bonded to'). It differentiates from sibling tools like get_delegation_rewards or get_validator_commission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention any preconditions or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get withdraw address for a delegator.
| Name | Required | Description | Default |
|---|---|---|---|
| delegator_address | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the basic function. It does not indicate whether the operation is read-only, if it has side effects, authorization requirements, or what happens on error.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is under-specified. It fails to front-load important details, such as what the output contains or any constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema present, the description lacks context about delegation withdrawal addresses and their relevance. The tool is simple, but the description still feels incomplete for an agent unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'delegator_address' has 0% schema description coverage, and the tool description adds no meaning beyond the parameter name. The agent is left without guidance on the address format or context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'withdraw address for a delegator', which is specific and distinct from sibling tools that focus on other entities like account, balances, rewards, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites or situations where this tool is preferred, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata for specific token.
| Name | Required | Description | Default |
|---|---|---|---|
| denom | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose behavioral traits such as whether it is read-only, what happens if the denom is not found, or any rate limits. The burden is on the description, which 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single sentence, but it sacrifices necessary information for brevity. It is not wasteful but could be structured to include more context without significant length increase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too brief for a tool with one parameter and an output schema. It does not explain what metadata is returned (even though an output schema exists) and lacks context on how it fits into a workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 0% coverage for the parameter, and the description only adds 'specific token' which weakly implies that denom identifies a token. More detail about the denom format or expected values would be needed to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets metadata for a specific token, matching the tool name. However, it does not differentiate itself from the sibling tool 'get_denoms_metadata' which likely retrieves metadata for multiple tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_denoms_metadata'. The description does not indicate prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all holders of a token.
| Name | Required | Description | Default |
|---|---|---|---|
| denom | Yes | ||
| page | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description says 'get all holders' but input schema shows pagination (page, limit), implying results are paginated and not all at once. This inconsistency is misleading. No disclosure of ordering, rate limits, or behavior for zero holders.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but lacks necessary details about pagination and parameters. Efficiency is good, but at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits key context about pagination behavior and response format. For a paginated list tool, essential information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description does not explain denom, page, or limit. While parameter names are somewhat intuitive, the description fails to clarify that page and limit control pagination, which is crucial for usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves holders for a token (denom). The name and description align, and it distinguishes from sibling getters like get_balance or get_account. However, 'token' could be ambiguous without context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternative list tools or other getters. Does not provide conditions for use or mention pagination behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata for all tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only says 'Get metadata for all tokens' but does not disclose that the tool supports pagination via page and limit parameters, or any behavioral traits like rate limits or data freshness. The agent cannot infer pagination behavior from the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. It is front-loaded and wastes no words. However, it could be slightly improved by mentioning pagination without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing, the description is too minimal. It fails to mention that the tool returns a paginated list, how to control pagination, or what constitutes a 'token' metadata. For a tool with two optional parameters, the description should provide at least basic context about its usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must explain parameter meanings. It does not mention page or limit parameters, leaving the agent to infer their purpose from names alone. While 'page' and 'limit' are somewhat self-explanatory, the description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get metadata for all tokens,' which distinguishes it from sibling 'get_denom_metadata' that gets metadata for a single token. The verb 'Get' and resource 'metadata for all tokens' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention that pagination parameters exist or when to prefer this over get_denom_metadata or other list tools. The description merely states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get distribution module parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only says 'Get,' implying read-only. It fails to disclose potential side effects, permissions, or behavior in error cases, which 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence. While concise, it could be slightly expanded to add context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema, the description is adequate but minimal. It lacks explanation of the module's purpose or what the parameters represent, which contextually weakens completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description adds no parameter info, but this is acceptable since there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'distribution module parameters,' specifying the verb and resource. However, it doesn't elaborate on what these parameters entail, limiting full clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over siblings like get_bank_params or get_governance_params. The agent must infer context 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.
Get specific deposit for a proposal.
| Name | Required | Description | Default |
|---|---|---|---|
| proposal_id | Yes | ||
| depositor | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states a read operation but does not disclose behavior like what happens if the deposit is not found, if the response is always the same shape, or any potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no superfluous words. It could be slightly more informative without losing conciseness, but it is efficiently short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters and no schema descriptions, the description is insufficient. It does not explain how to identify the deposit or what the output contains, though an output schema exists. The description does not leverage the context signal of zero coverage to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter names (proposal_id, depositor) are informative, but with 0% schema description coverage, the description should add context. It does not mention that both are required to uniquely identify a deposit, leaving agents to infer from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get specific deposit for a proposal' uses a clear verb-resource combination and implies a single deposit, which helps differentiate from listing. However, it does not explicitly state that it retrieves a unique deposit by proposal_id and depositor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_governance_deposits or get_governance_proposal. The description lacks any when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get governance parameters.
| Name | Required | Description | Default |
|---|---|---|---|
| params_type | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only states 'Get', implying a read-only operation, but lacks details on required permissions, error cases, or constraints on the required parameter. The behavior is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly briefājust three words. While concise, it omits essential information about the parameter and usage, making it under-specified rather than efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and a single required parameter, the description should provide context on what parameters are available and how to use them. It does not, leaving the tool incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema. The single required parameter 'params_type' is not explained regarding valid values or format. With 0% schema description coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get governance parameters' specifies a verb and resource, but is vague. It does not distinguish this tool from siblings like get_governance_deposit or get_governance_tally_result, which are also related to governance. The purpose is unclear whether it retrieves general parameters (e.g., voting period) or something else.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions. The agent must infer usage from the name alone, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get specific governance proposal.
| Name | Required | Description | Default |
|---|---|---|---|
| proposal_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only says 'Get', which implies read-only. It does not mention idempotency, auth requirements, rate limits, or whether errors (e.g., proposal not found) can occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous information. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, return values are not needed. However, the description lacks context on error handling and preconditions. For a simple getter, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, but the single parameter 'proposal_id' is self-documenting (the ID of the proposal). The description adds no further meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a specific governance proposal, using the verb 'Get' and resource 'specific governance proposal'. This distinguishes it from sibling tools like list_governance_proposals (list) and other governance getters (deposit, vote, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use versus alternatives like list_governance_proposals or other specific governance getters. Usage is only implied by the word 'specific', but no when-not or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get vote tally for a proposal.
| Name | Required | Description | Default |
|---|---|---|---|
| proposal_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the basic function. It omits details like error handling (e.g., if proposal doesn't exist), output format, or whether the tally is final or partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, which is concise but lacks necessary detail. It is front-loaded but at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and 0% schema coverage, the description is incomplete. It does not mention output schema, error conditions, or when to use, leaving the agent to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description should compensate. It only implicitly explains that proposal_id identifies the proposal, but adds no constraints, format, or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool gets a vote tally for a proposal, using a specific verb and resource. However, it does not differentiate from sibling tools like get_governance_vote, which also fetch vote-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_governance_vote or list_governance_votes. The description lacks context about prerequisites or proper invocation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get specific vote on a proposal.
| Name | Required | Description | Default |
|---|---|---|---|
| proposal_id | Yes | ||
| voter | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose any behavioral traits such as read-only nature, required permissions, or side effects. It lacks transparency about what the response contains, despite an output schema existing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
At five words, the description is overly terse. While concise, it sacrifices essential information, making it inadequate for effective tool selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, output schema exists), the description is incomplete. It fails to explain what constitutes a vote or how parameters refine the search, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the two required parameters (proposal_id, voter). It adds no meaning beyond the schema itself, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get specific vote on a proposal,' identifying the verb 'get' and resource 'vote on proposal.' It differentiates from sibling tools like list_governance_votes (list vs. get) and get_governance_proposal (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list_governance_votes or get_governance_proposal. No mention of prerequisites or context where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get specific marketplace sell order.
| Name | Required | Description | Default |
|---|---|---|---|
| sell_order_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavior disclosure. It only states 'Get' which implies a read operation, but it does not mention side effects, rate limits, authorization requirements, or what happens if the order is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, consisting of a single phrase. While this is concise, it sacrifices completeness and clarity; a few more words to explain the parameter or context would improve it without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description does not need to detail return values. However, it lacks any context about when to use this tool versus listing tools, error handling, or prerequisites. For a simple get-by-ID tool, it is adequate but minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not reference the sole parameter sell_order_id at all, despite schema description coverage being 0%. It fails to explain what the ID represents or how to obtain it, leaving the agent without necessary context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a specific marketplace sell order. The verb 'Get' and resource 'specific marketplace sell order' precisely communicate its function, and it distinguishes well from sibling list tools like list_sell_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives such as list_sell_orders. The description does not mention prerequisites or indicate that it requires a sell_order_id to identify the specific order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get spendable balances for account.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| page | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose pagination behavior or any side effects of reading balances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and resource; efficient but could benefit from more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, description lacks pagination info and differentiation from numerous sibling tools; insufficient for reliable tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; description does not explain the meaning of address, page, or limit parameters, nor their defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it gets spendable balances for an account, but does not explain what 'spendable' means nor differentiate from sibling tools like get_balance or get_all_balances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_balance or get_all_balances; no exclusion criteria given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get total supply of specific token.
| Name | Required | Description | Default |
|---|---|---|---|
| denom | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the brief description does not disclose behavior beyond the basic purpose; e.g., does not state read-only nature, return type, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one sentence) but lacks structure; front-loaded though does not earn its place due to missing details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter and an output schema, the description is too minimal; with no annotations, it fails to provide adequate context for agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for the 'denom' parameter, and the description adds no extra meaning (e.g., format, examples). The agent gets no help on how to specify the token.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and the resource (total supply of specific token), differentiating it from sibling like get_total_supply which likely returns aggregate supply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like get_total_supply or get_balance; the agent is left to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get total supply of all tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It does not mention pagination (page/limit parameters) or whether results are aggregated or per-token. With no annotations, this is a major gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise but lacks critical information. It is not verbose, but valuable space is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and two parameters, the description should cover paging behavior and return format. It only states the basic purpose, leaving the agent uninformed about how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (page, limit) with defaults but no descriptions. The description does not explain these parameters at all, leaving the agent unaware of pagination support.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get total supply of all tokens,' indicating it retrieves the aggregate supply across all tokens. It distinguishes from siblings like 'get_supply_of' by implying scope, but does not explicitly contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_supply_of or list_* tools. No context about prerequisites or filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get commission for a validator.
| Name | Required | Description | Default |
|---|---|---|---|
| validator_address | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It fails to indicate whether the operation is read-only, requires authentication, or has any permissions, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, achieving brevity. However, it lacks structure or additional clarifying elements that would enhance scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one required parameter) and the presence of an output schema, the description should at least hint at the return value (e.g., a numeric commission rate). It omits any context about what the agent can expect to receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, yet the description adds no detail about the single parameter 'validator_address', such as format or expected value. The parameter name is self-explanatory, but the description should 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('commission') along with the subject ('validator'), clearly defining the tool's purpose. It distinguishes itself from siblings like 'get_validator_outstanding_rewards' and 'get_validator_slashes' by targeting a different data attribute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent without comparative direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get outstanding rewards for a validator.
| Name | Required | Description | Default |
|---|---|---|---|
| validator_address | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only states the action. It does not clarify whether the operation is read-only, if authentication is required, or what comprises 'outstanding rewards', thus providing insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of a single sentence that directly states the tool's purpose. It is appropriately sized for a simple tool, though it could be slightly expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description need not explain return values. However, the description is minimal for a tool with many siblings; it lacks details like what 'outstanding rewards' entails, making it just adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description adds no details about the validator_address parameter. Although the parameter name is self-explanatory, the description fails to compensate for the lack of schema documentation or provide additional context about its format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource 'outstanding rewards for a validator', making the purpose clear. However, it does not differentiate from sibling tools like get_delegation_rewards or get_validator_commission, which could cause confusion for an AI agent selecting the correct tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or situations where this tool is preferred, leaving the AI 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.
Get slashing events for a validator.
| Name | Required | Description | Default |
|---|---|---|---|
| validator_address | Yes | ||
| starting_height | No | ||
| ending_height | No | ||
| page | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral details such as pagination, sorting, or any side effects. It only states the basic function. The tool likely returns a list with pagination (given page/limit params), but that is not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is under-specified for a tool with 5 parameters and pagination. It could front-load more information without becoming overly long. The structure is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and likely returns a paginated list of slashing events, the description is too brief. It does not cover parameter semantics, pagination, or output format, though an output schema exists. The brevity leaves significant gaps for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. The schema has 5 parameters (validator_address, starting_height, ending_height, page, limit) with defaults and types, but the description adds no meaning. For example, it doesn't clarify that starting_height and ending_height are optional filters or how pagination works.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves slashing events for a validator. The verb 'Get' and resource 'slashing events' are specific, and the scope 'for a validator' is clear. Among sibling tools, this stands out as validator-specific, though it doesn't differentiate from other validator-related tools like get_validator_commission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not indicate prerequisites, when not to use, or mention other tools like list_validator_slashes if they exist. The description provides no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all accounts on Regen Network.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose that this is a read-only operation, potential authorization needs, or that results are paginated via 'page' and 'limit' parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but lacks critical details; it is not verbose but is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, but with no explanation of return values or pagination, the description is insufficient for an agent to fully understand the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the 'page' and 'limit' parameters or their default values, despite 0% schema coverage, leaving the agent without clarity on how to control pagination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all accounts') and the system ('Regen Network'), distinguishing it from specific account tools like 'get_account'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_account' or other listing tools; no mentions of pagination or performance implications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List allowed payment tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the core function; it does not mention whether the tool is read-only, if there are rate limits, pagination behavior, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), which is efficient, but it lacks structure and fails to front-load key information. It could be improved without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and two parameters, the description is insufficient. It does not explain what 'allowed denoms' are, what the output contains, or how pagination works, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions in schema). The description adds nothing about the parameters 'page' and 'limit', leaving the agent to guess their purpose and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('allowed payment tokens'), but does not differentiate from many sibling list tools (e.g., list_accounts, list_baskets). The resource 'allowed denoms' is ambiguous without further context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List credit batches in basket.
| Name | Required | Description | Default |
|---|---|---|---|
| basket_denom | Yes | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 only states the action without mentioning read-only nature, pagination behavior, or any side effects. The description 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it sacrifices necessary detail. It could be slightly more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (including one required) and an output schema exists, the description is too brief to provide a complete understanding. It does not describe return values or pagination details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not clarify the meaning of parameters beyond the schema. It mentions 'in basket' but does not explain the required 'basket_denom' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List credit batches in basket' clearly specifies the verb 'list' and the resource 'credit batches in basket', distinguishing it from sibling tools like 'list_baskets' (lists baskets) and 'list_credit_batches' (lists all credit batches).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools exist for similar functionality but no exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all ecocredit baskets.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks behavioral details such as pagination, ordering, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise but at the cost of omitting important information about parameters and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and sibling tools, the description is too sparse; it should mention pagination and possibly default values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (limit, offset) with zero description coverage, and the tool description does not explain their meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'ecocredit baskets', distinguishing it from sibling tools like 'get_basket' and 'list_basket_balances'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, but the name implies a general list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all credit classes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only says 'list' but omits details like pagination, side effects, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, which is concise but too brief given the complexity and lack of annotations. It could be improved without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return format is covered, but the description is insufficient for a list tool with pagination and sibling tools. Lacks context on ordering and filtering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the limit/offset parameters or pagination, relying solely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all credit classes, matching the name and specifying the resource. However, it does not differentiate from sibling list tools like list_credit_batches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information on when to use this tool versus alternatives. With many list tools, guidance is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all credit batches.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like read-only nature or pagination behavior. It only states 'list all', which is vague and does not clarify potential large result sets or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (single sentence). While there is no wasted content, it lacks structure and fails to include important details, making it under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description provides no context about the data returned or how credit batches are defined. The overall completeness is low, leaving agents uninformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage for parameter descriptions. The description does not mention limit or offset parameters, leaving the agent to infer pagination without any explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource 'credit batches', distinguishing it from other list tools like list_accounts. However, it could be more specific about the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines on when to use this tool versus other list tools or alternatives. The description provides no context on typical use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all enabled credit types.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It does not state that the operation is read-only, nor does it mention any constraints like pagination or data freshness. The description is insufficient 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that immediately communicates the purpose. No filler or redundant words. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description can skip return value details. However, for a list operation, it could clarify what 'credit types' means or whether the list is exhaustive. It is minimally complete but lacks context on the nature of the data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no need for description beyond indicating what is listed. The phrase 'enabled credit types' adds minimal semantic value, but the baseline for no parameters is 4, and the description meets that expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb-resource pairing: 'List all enabled credit types.' It unambiguously states the action and target. However, it does not differentiate from sibling list tools like list_credit_batches, which could cause confusion for an AI agent deciding which to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention context, prerequisites, or scenarios where this tool is appropriate, 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.
List deposits for a specific proposal.
| Name | Required | Description | Default |
|---|---|---|---|
| proposal_id | Yes | ||
| page | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description provides no behavioral details such as pagination behavior, error handling for missing proposal_id, or order of results. The one-sentence description is insufficient for understanding the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (single sentence), but it sacrifices necessary detail. While front-loaded, it lacks structure and fails to earn its place by being too minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, output schema exists), the description should explain pagination, defaults, and what constitutes a 'deposit.' It does none of this, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters with 0% description coverage in the schema. The description adds no meaning beyond the schema: it does not explain `proposal_id`'s format, nor the effect of `page` and `limit`. The tool's purpose is vaguely stated, forcing reliance on the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List deposits for a specific proposal,' which clearly identifies the action (list) and resource (deposits filtered by proposal). It distinguishes from the sibling tool 'get_governance_deposit' by implying bulk retrieval, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_governance_deposit' (retrieval of a single deposit) or other list tools. The description lacks context on required parameters or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List governance proposals with optional filters.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| proposal_status | No | ||
| voter | No | ||
| depositor | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only states 'list' without noting whether it is read-only, paginated, or has rate limits. The minimal phrase does not reveal any behavioral traits beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly concise to the point of being under-informative. It consists of a single generic phrase that fails to justify its brevity with meaningful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the five optional parameters and the presence of many sibling tools, the description is incomplete. It does not explain the return structure (despite having an output schema) or how filters interact. The tool is underspecified for effective agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no details about the five parameters (page, limit, proposal_status, voter, depositor). It only says 'with optional filters', which is too vague to help an agent understand parameter meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists governance proposals with optional filters, distinguishing it from sibling tools like list_governance_deposits and list_governance_votes. However, it does not specify the scope of proposals (e.g., active or all) or enumerate the filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_governance_proposal or other list tools. The description provides no context about prerequisites, expected usage scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List votes for a specific proposal.
| Name | Required | Description | Default |
|---|---|---|---|
| proposal_id | Yes | ||
| page | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like pagination (despite parameters 'page' and 'limit'), result ordering, or whether votes are summarized. The output schema exists but is not referenced to mitigate this gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) with no wasted words. However, it is overly terse and could include critical details like pagination or the requirement of a proposal ID without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and the presence of an output schema, the description should provide more context about filtering, pagination, and the relationship to sibling tools. It is minimally complete and leaves many practical questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only implicitly explains 'proposal_id' (the proposal to get votes for) but does not mention 'page' or 'limit', which are self-evident from their names and defaults. The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and the resource (votes for a specific proposal), distinguishing it from siblings like 'get_governance_vote' (single vote) and 'list_governance_proposals'. However, it does not specify the scope (e.g., all votes or just active ones), 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as 'get_governance_vote' for a single vote or 'list_governance_proposals' for proposals. There is no mention of prerequisites 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.
List all registered projects.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose key behaviors. It does not mention pagination (limit/offset), sorting, filtering, or potential empty results. The agent cannot infer the tool's complete behavior from this terse description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks structure and omits critical details. Every word is earned, but the description is too brief to be fully informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and presence of an output schema, the description could be more complete. It fails to mention the paginated nature of results (implied by input schema) and does not integrate with sibling tools or usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain the purpose or effect of 'limit' and 'offset' parameters. The agent receives no semantic help beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all registered projects with a specific verb and resource. However, it does not differentiate from sibling list tools like list_accounts, though the uniqueness of the resource (projects) makes it unambiguous. Lacks detail on what 'registered' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Agents have no context on whether there are more specific project listing tools or if this is the only option. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active sell orders.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description is minimal. It does not disclose pagination behavior, result ordering, or any side effects. For a tool with no annotations, the description carries full burden but fails to provide sufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficient in length, but lacks necessary details. Not a model of conciseness when key information is omitted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of output schema, description is too sparse. It fails to mention pagination, filtering (only active orders), or result structure, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must explain parameters. However, it does not mention pagination or explain the meaning of page and limit beyond the schema defaults. No added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it lists active sell orders, using a specific verb and resource. It clearly differentiates from sibling tools like get_sell_order (singular) and list_sell_orders_by_batch/seller (scoped).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list_sell_orders_by_batch or list_sell_orders_by_seller. No explicit context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List sell orders for specific batch.
| Name | Required | Description | Default |
|---|---|---|---|
| batch_denom | Yes | ||
| page | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like idempotency or read-only nature. It only states the action, omitting details such as pagination behavior or whether it modifies state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with no filler words, but it may be overly terse at the expense of critical information. It is front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and three parameters, the description is too brief. It does not mention the output schema or pagination, leaving the agent without sufficient context for proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only hints at batch_denom via 'specific batch', but provides no explanations for page and limit parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action (list) and the specific resource (sell orders for a specific batch), clearly distinguishing it from sibling tools like 'list_sell_orders' and 'list_sell_orders_by_seller'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a batch_denom is available, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List sell orders by seller.
| Name | Required | Description | Default |
|---|---|---|---|
| seller | Yes | ||
| page | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states a simple listing operation without discussing read-only behavior, authentication needs, rate limits, or pagination details beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded. However, it may be too terse for a tool with three parameters and no schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 params, 1 required) and presence of an output schema, the description should provide context on what the tool returns (list of sell orders) and any default behavior. It only states 'list sell orders by seller,' leaving gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It adds minimal value: 'by seller' indicates seller as a filter, but does not explain the meaning of seller, page, or limit beyond their names. No format or allowed values noted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List sell orders by seller' clearly states a verb and resource. It distinguishes from siblings like list_sell_orders and list_sell_orders_by_batch by specifying the filtering criteria, but the differentiation is minimal as the tool name itself conveys the same.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., list_sell_orders, list_sell_orders_by_batch). The description lacks context for usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0analyze_market_trendsanalyze_portfolio_impactcompare_credit_methodologiesget_accountget_all_balancesget_balanceget_bank_paramsget_basketget_basket_balanceget_basket_feeget_community_poolget_delegation_rewardsget_delegation_total_rewardsget_delegator_validatorsget_delegator_withdraw_addressget_denom_metadataget_denom_ownersget_denoms_metadataget_distribution_paramsget_governance_depositget_governance_paramsget_governance_proposalget_governance_tally_resultget_governance_voteget_sell_orderget_spendable_balancesget_supply_ofget_total_supplyget_validator_commissionget_validator_outstanding_rewardsget_validator_slasheslist_accountslist_allowed_denomslist_basket_balanceslist_basketslist_classeslist_credit_batcheslist_credit_typeslist_governance_depositslist_governance_proposalslist_governance_voteslist_projectslist_sell_orderslist_sell_orders_by_batchlist_sell_orders_by_sellerMost tools have distinct purposes (e.g., get_balance vs get_all_balances vs get_spendable_balances), and descriptions clarify differences. A few similar prefixes might cause minor confusion, but overall agents can differentiate.
Tool names follow a consistent pattern: get_ for queries, list_ for enumerations, and a few action verbs (analyze, compare). All use snake_case with clear resource references.
At 45 tools, the count exceeds the 25+ threshold for 'too many'. While the domain is broad, many tools could be consolidated (e.g., get_denom_metadata and get_denoms_metadata) reducing the surface.
The tool set is entirely read-only, missing essential write operations like creating sell orders, sending transactions, or modifying credit batches. This is a significant gap for a blockchain server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Crypto yield data for AI agents: lending, savings, staking, borrowing & stablecoin rates. 18 tools.
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
45 AI data tools for agents ā crypto, DeFi risk, audits, equities, energy, and more.
Agentic Finance: 500+ tools for AI agents over x402 or MPP, free via PoW, or prepaid card credits
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gaiaaiagent/regen-python-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
