iota-agent-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes with clear boundaries, such as iota_object for fetching object data versus iota_objects_by_owner for listing owner objects. However, there is some overlap between iota_wallet_approve and iota_wallet_reject, which both handle pending signing requests but with opposite actions, which could cause minor confusion in selection. The iota_cli tool is a catch-all for uncovered operations, which might overlap with other tools if not used carefully.
Naming Consistency5/5
The tool names follow a highly consistent pattern with a clear prefix 'iota_' and descriptive verb_noun combinations, such as iota_move_build, iota_wallet_balance, and iota_epoch_info. All tools use snake_case uniformly, and the naming conventions are predictable across the set, making it easy to understand the purpose and domain of each tool.
Tool Count4/5
With 18 tools, the count is slightly high but reasonable for a comprehensive IOTA agent server covering CLI operations, Move development, object queries, and wallet management. It provides a broad scope without being overwhelming, though it might benefit from slight consolidation in areas like wallet request handling to reduce complexity.
Completeness5/5
The tool set offers complete coverage for the IOTA agent domain, including CLI execution, Move package building and publishing, on-chain data queries (objects, transactions, epochs), and full wallet lifecycle management (accounts, balances, signing, network switching). There are no obvious gaps; agents can perform all essential operations from development to deployment and interaction with the blockchain.
Average 3.2/5 across 18 of 18 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 14 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s] coin objects' (implying a read operation) and mentions utility, but doesn't cover critical aspects like error handling, rate limits, authentication needs, or what 'coin objects' entail (e.g., format, pagination). This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is front-loaded with the core purpose ('Get coin objects for an address') and adds useful context without redundancy, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a blockchain query tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., response format, errors), doesn't fully guide usage, and relies on the schema for parameters. For a tool in this context, more comprehensive information is needed to assist the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('address' and 'coin_type') with descriptions. The description adds no additional parameter semantics beyond what's in the schema, such as examples or constraints, but it implies the tool is for querying coins, which aligns with the parameters. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get coin objects for an address' with a specific verb ('Get') and resource ('coin objects'), and it adds context about utility ('useful for gas estimation and token queries'). However, it doesn't explicitly differentiate from sibling tools like 'iota_wallet_balance' or 'iota_objects_by_owner', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions general utility ('gas estimation and token queries') but doesn't specify prerequisites, exclusions, or compare it to sibling tools like 'iota_wallet_balance' or 'iota_objects_by_owner', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool builds and reports results but doesn't mention whether this is a read-only operation, if it modifies files, what happens on compilation errors, or any performance/rate limit considerations. This leaves significant gaps for a tool that presumably performs compilation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the tool's purpose. Every word earns its place, and it's front-loaded with the core functionality. No unnecessary elaboration or redundancy is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a compilation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'compilation results' include, how errors are handled, or the tool's safety profile. For a build operation that could have side effects, this leaves too many unanswered questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what's already in the schema (which has 100% coverage). It doesn't explain what 'Move package directory' means, provide examples, or clarify the default behavior. Since schema coverage is high, the baseline is 3, but no additional value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Build') and target ('Move package') with the outcome ('report compilation results'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'iota_move_publish_unsigned' or 'iota_move_test_coverage' that also operate on Move packages, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when compilation is needed, or how this differs from other Move-related tools like 'iota_move_publish_unsigned' or 'iota_move_test_coverage' in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a list operation, implying read-only behavior, but doesn't mention pagination, rate limits, authentication requirements, error conditions, or what 'objects' specifically refers to (tokens, NFTs, contracts). This leaves significant behavioral gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core functionality. There's no wasted verbiage or unnecessary elaboration - every word serves the purpose of stating what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'objects' means in this context, what format results will be in, whether there are pagination considerations, or any error handling. The agent would need to guess about important operational aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'by an address' which aligns with the 'address' parameter, but adds no semantic context beyond what the schema already provides (100% coverage). The schema fully describes both parameters, so the description meets the baseline without adding meaningful parameter insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('objects owned by an address'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential siblings like 'iota_object' or 'iota_coins' that might also retrieve object information, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'iota_object' (singular) and 'iota_coins' (specific type), there's no indication whether this tool is for general object listing, filtered queries, or other use cases. The lack of context leaves the agent guessing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Approve') but doesn't mention critical aspects like whether this requires authentication, what happens after approval (e.g., transaction execution), potential side effects, or error conditions. For a security-sensitive wallet operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a single-parameter tool and front-loads the essential action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a wallet approval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'approve' entails (e.g., cryptographic signing, authorization), what happens after approval, potential security implications, or how to obtain request IDs. The context signals show moderate complexity that warrants more explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'request_id' well-documented in the schema. The description doesn't add any parameter semantics beyond what the schema already provides (e.g., where to find request IDs, format examples, or relationship to 'iota_wallet_pending' output). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Approve') and the target resource ('a pending signing request'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from its sibling 'iota_wallet_reject' (which presumably rejects rather than approves requests) or 'iota_wallet_sign_execute' (which might involve signing without explicit approval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing pending requests), when-not-to-use scenarios, or explicit references to sibling tools like 'iota_wallet_reject' for rejection or 'iota_wallet_pending' to list pending requests first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('reject') but doesn't explain what rejection entails (e.g., irreversible cancellation, permission requirements, or effects on the request). This leaves significant gaps in understanding the tool's behavior and implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and target, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficient for a mutation tool like 'reject'. It doesn't cover behavioral aspects (e.g., what happens after rejection), error conditions, or return values, leaving the agent with incomplete context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter details beyond what's in the schema, which has 100% coverage for the single parameter 'request_id'. The schema already describes it as 'ID of the pending request to reject', so the description provides no additional semantic value, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('reject') and the target ('pending signing request'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'iota_wallet_approve' which likely handles approval of similar requests, leaving room for improvement in sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'iota_wallet_approve' or 'iota_wallet_sign_execute'. It doesn't mention prerequisites (e.g., needing a pending request) or context for rejection, offering minimal usage direction beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('switch') but doesn't mention critical details like whether this requires authentication, if it's destructive (e.g., resets wallet state), or any rate limits. This is a significant gap for a tool that likely changes network settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely modifies wallet state. It doesn't explain what happens after switching networks (e.g., balance updates, transaction history changes) or potential side effects, which are important for an agent to understand the tool's impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'network' parameter clearly documented as 'Target network' and an enum of values. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('switch') and the target resources ('mainnet, testnet, and devnet'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'iota_wallet_balance' or 'iota_wallet_accounts', which are related but serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as whether it's for testing, development, or production scenarios. It lacks context about prerequisites or exclusions, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'Returns test results and coverage summary,' which gives some output context, but doesn't cover critical aspects like execution time, side effects, error handling, or permissions required. For a tool that runs tests, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that efficiently state the tool's action and output. It is front-loaded with the core purpose and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (running tests with coverage), lack of annotations, and no output schema, the description is minimally adequate. It covers what the tool does and the output type, but doesn't explain return values in detail or address behavioral nuances. This meets the minimum viable threshold but leaves clear gaps for an agent to understand full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter definitions for 'path' and 'filter.' The description adds no additional parameter semantics beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline is 3 even without param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run Move tests with coverage analysis.' It specifies the verb ('Run') and resource ('Move tests'), and mentions the additional feature ('coverage analysis'). However, it doesn't explicitly differentiate from potential siblings like 'iota_move_build' or other testing tools, which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when-not scenarios, or compare to other tools in the sibling list (e.g., 'iota_move_build' for building). Usage is implied by the purpose but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'fetches' data (implying a read-only operation) and lists return fields (owner, type, version, content), but doesn't cover critical aspects like error handling (e.g., invalid IDs), performance (e.g., latency or rate limits), or side effects (e.g., network calls). This leaves gaps for a tool interacting with on-chain data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: two sentences that efficiently state the action ('Fetch on-chain object data by ID') and return values ('Returns owner, type, version, and content'). Every word earns its place, with no redundancy or unnecessary elaboration, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (fetching on-chain data), no annotations, and no output schema, the description is partially complete. It covers the basic purpose and return fields but lacks details on behavior (e.g., error cases, network dependencies) and output structure. This is adequate for a simple read operation but has clear gaps for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'object_id' documented as 'IOTA object ID (0x...)'. The description adds no additional parameter semantics beyond this, as it doesn't explain format details (e.g., hex encoding requirements) or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Fetch on-chain object data by ID' specifies the action (fetch), resource (on-chain object data), and key identifier (ID). It distinguishes from siblings like 'iota_objects_by_owner' (which fetches by owner) and 'iota_transaction' (which handles transactions). However, it doesn't explicitly differentiate from all siblings, such as 'iota_coins' or 'iota_move_build', which might involve different data types or operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid object ID), exclusions (e.g., not for fetching multiple objects), or direct comparisons to siblings like 'iota_objects_by_owner' for owner-based queries. Usage is implied by the action but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'fetch,' implying a read-only operation, but doesn't cover aspects like error handling, rate limits, authentication needs, or what 'details' include (e.g., status, timestamps). For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste: 'Fetch transaction details by digest.' It is front-loaded and appropriately sized for the tool's purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and 100% schema coverage, the description is minimally adequate. However, with no output schema and no annotations, it lacks details on return values and behavioral traits. It meets the basic requirement but could be more complete for a tool in a server with many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'digest' fully documented in the schema as 'Transaction digest.' The description adds no additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to heavily.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch transaction details by digest' clearly states the action (fetch) and target resource (transaction details), with the method specified (by digest). It distinguishes this from siblings like iota_object or iota_objects_by_owner by focusing on transactions rather than general objects. However, it doesn't explicitly differentiate from all siblings, such as those involving wallet operations, which slightly limits specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as whether it's for historical vs. pending transactions or how it compares to siblings like iota_wallet_pending. This leaves the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Get') and method ('via GraphQL'), but lacks details on permissions, rate limits, error handling, or what the output looks like (e.g., format, data structure). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information ('Get current epoch, checkpoint, and network statistics') and includes the method ('via GraphQL') without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with 0 parameters) and lack of annotations and output schema, the description is minimally adequate. It covers the basic purpose and method but doesn't provide details on output format or behavioral traits. For a tool with no structured data beyond the schema, it meets the minimum viable threshold but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate given the lack of parameters. A baseline score of 4 is assigned as it doesn't need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and identifies the resources ('current epoch, checkpoint, and network statistics') and method ('via GraphQL'). It distinguishes itself from siblings by focusing on network statistics rather than wallet operations or transaction handling, though it doesn't explicitly contrast with similar tools like 'iota_cli' or 'iota_object'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for retrieving network statistics, or differentiate it from other tools that might provide overlapping data, such as 'iota_cli' or 'iota_wallet_switch_network'. Usage is implied by the purpose but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states a read operation ('List') but doesn't cover aspects like pagination, rate limits, authentication needs, or what 'derived' means in practice. This leaves significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple tool, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is adequate but incomplete. It lacks behavioral details like return format or error handling, which are important even for a read-only tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, but that's appropriate here, warranting a baseline score above 3 due to the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('all derived wallet accounts'), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'iota_wallet_balance' or 'iota_wallet_address', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as whether a wallet must be initialized, and doesn't mention any exclusions or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a 'Get' operation, implying read-only behavior, but doesn't disclose any behavioral traits such as authentication requirements, rate limits, or what 'active' means in context (e.g., default, currently selected).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for a simple tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is minimally adequate. However, it lacks context about what 'active' means and doesn't explain the return value, leaving gaps for an AI agent to understand the full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics, but with no parameters, the baseline is 4 as it's complete in this aspect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the active wallet address' clearly states the action (Get) and resource (active wallet address). It's specific but doesn't differentiate from sibling tools like 'iota_wallet_accounts' or 'iota_wallet_balance' that might also retrieve wallet information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With sibling tools like 'iota_wallet_accounts' (plural) and 'iota_wallet_balance', the description doesn't clarify if this retrieves a single default address versus multiple addresses or balance information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool checks balance but doesn't clarify if this is a read-only operation, requires authentication, has rate limits, or returns specific data formats. This leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema, no annotations), the description is minimally adequate but lacks depth. It doesn't explain what 'active wallet' means or what the balance check entails (e.g., real-time vs. cached), leaving room for ambiguity in a wallet context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, but that's acceptable here, earning a baseline high score for simplicity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check') and resource ('IOTA balance for the active wallet'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'iota_wallet_accounts' or 'iota_wallet_address', which might also provide balance-related information, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active wallet), exclusions, or compare to siblings like 'iota_wallet_accounts' for broader account info, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves and decompiles, implying a read-only operation, but lacks details on permissions, rate limits, or potential side effects. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the action and resource, and the second specifies the output. It is front-loaded and appropriately sized, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (decompilation), lack of annotations, and no output schema, the description is incomplete. It explains the output format but omits behavioral details like error handling or performance considerations. However, it covers the core purpose adequately, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('package_id' and 'module_name'). The description does not add any additional meaning or context beyond what the schema provides, such as format examples or usage tips, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieve and decompile') and resource ('a deployed Move module'), and distinguishes it from siblings by specifying the unique output ('Returns the module's ABI (structs, functions, type params)'), which no other tool mentions. This makes the purpose explicit and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing a deployed module, or compare it to siblings like 'iota_move_build' or 'iota_move_publish_unsigned', leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool runs CLI commands but doesn't disclose critical traits like whether it's read-only or destructive, what permissions or authentication are needed, potential rate limits, or error handling. This leaves significant gaps for an agent to understand the tool's behavior safely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of two sentences that directly address purpose and usage without any wasted words. Every sentence earns its place by providing essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (running arbitrary CLI commands), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, potential side effects, or safety considerations, which are crucial for an agent to use it correctly in context with its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'command' parameter well-documented in the schema. The description adds minimal value beyond the schema, as it doesn't provide additional syntax, format details, or examples. According to the rules, with high schema coverage, the baseline is 3 even without extra param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run an arbitrary IOTA CLI command.' It specifies the verb ('Run') and resource ('IOTA CLI command'), making the action clear. However, it doesn't explicitly differentiate from siblings beyond mentioning 'operations not covered by other tools,' which is somewhat vague about what those specific operations are.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'Use for operations not covered by other tools.' This implies when to use this tool versus alternatives, as it suggests using specialized sibling tools for covered operations. However, it doesn't explicitly list exclusions or name specific alternatives, which keeps it from being a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the transaction is 'unsigned' and for 'agent wallet signing', but lacks details on behavioral traits like error conditions, side effects (e.g., if it validates the package), or typical output format. This is inadequate for a tool that generates transactions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place, with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., transaction bytes, metadata), error behaviors, or dependencies (e.g., requires a built package). For a transaction-generation tool, this leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no additional meaning beyond what's in the schema (e.g., no clarification on path format or gas budget implications). Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Generate an unsigned publish transaction') and resource ('for a Move package'), with additional context about its purpose ('for agent wallet signing'). It distinguishes from siblings like iota_move_build (which likely compiles) or iota_wallet_sign_execute (which likely signs/executes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when preparing a Move package for signing by an agent wallet, but lacks explicit guidance on when to use this vs. alternatives like iota_move_build (for compilation) or iota_transaction (for other transaction types). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists pending requests, implying a read-only operation, but does not disclose other traits such as permissions required, rate limits, or what happens if no pending requests exist. This leaves gaps in understanding the tool's behavior beyond its basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information ('List pending signing requests awaiting approval') with zero waste. It is appropriately sized for a tool with no parameters and a straightforward purpose, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is complete enough for basic understanding. However, it lacks details on behavioral aspects like error handling or response format, which could be useful for an agent. It meets minimum viability but has clear gaps in contextual richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description does not add parameter details, which is appropriate. A baseline of 4 is applied as it compensates adequately for the lack of parameters by focusing on the tool's purpose without unnecessary elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List') and resource ('pending signing requests awaiting approval'), distinguishing it from siblings like iota_wallet_approve, iota_wallet_reject, and iota_wallet_sign_execute which handle approval actions rather than listing. It precisely defines what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to view pending requests, but does not explicitly state when to use this tool versus alternatives like iota_wallet_approve or iota_wallet_reject for handling those requests. No exclusions or prerequisites are mentioned, leaving usage context partially inferred rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it's a mutation tool (sign and execute), requires human approval, and operates via the agent wallet. However, it does not cover aspects like error handling, rate limits, or what happens on execution failure, leaving some gaps in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Sign and execute a transaction') and includes essential context ('via the agent wallet' and 'human-in-the-loop approval required') without any wasted words. Every part of the sentence contributes directly to understanding the tool's purpose and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation requiring human approval), no annotations, and no output schema, the description is reasonably complete. It covers the action, resource, and key constraint, but could improve by mentioning potential outcomes or error cases. It adequately supports agent selection but leaves some behavioral aspects unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter 'tx_bytes' as 'Base64-encoded transaction bytes'. The description does not add any additional meaning or context about this parameter beyond what the schema provides, such as format details or usage examples, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Sign and execute a transaction') and the resource ('via the agent wallet'), distinguishing it from siblings like iota_wallet_approve or iota_wallet_reject which handle approval/rejection rather than signing and execution. It specifies the exact operation with a specific constraint (human-in-the-loop approval required).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating 'human-in-the-loop approval required', indicating when this tool is appropriate (when manual approval is needed). However, it does not explicitly mention when not to use it or name alternatives like iota_wallet_approve for approval-only actions, so it lacks full exclusion or comparison details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![iota-agent-mcp MCP server](https://glama.ai/mcp/servers/Scottcjn/iota-agent-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Scottcjn/iota-agent-mcp)

Score Badge

Copy to your README.md:

[![iota-agent-mcp MCP server](https://glama.ai/mcp/servers/Scottcjn/iota-agent-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Scottcjn/iota-agent-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Scottcjn/iota-agent-mcp'

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