mcp-ipfs

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools have overlapping purposes that could cause confusion, such as w3_can_blob_add and w3_can_store_add both handling file storage with similar requirements, and w3_key_create and w3_up both generating key pairs. However, descriptions provide some clarity, and many tools target distinct resources like accounts, spaces, and uploads, reducing ambiguity.
Naming Consistency4/5
Most tools follow a consistent w3_ prefix with snake_case and verb_noun patterns like w3_account_ls, w3_space_create, and w3_can_blob_add. Minor deviations exist, such as w3_up being less descriptive and some tools having vague names like w3_ls or w3_open, but overall naming is predictable and readable.
Tool Count2/5
With 35 tools, the count is excessive for the apparent scope of IPFS and account management, making it heavy and potentially overwhelming. A more focused set of 10-20 tools would be more appropriate, as many tools like w3_can_index_add and w3_can_upload_rm are marked as advanced use, suggesting unnecessary complexity.
Completeness4/5
The toolset provides comprehensive coverage for IPFS operations, including account management, file storage, space handling, and advanced features like CAR file management. Minor gaps exist, such as limited error handling tools or missing interactive commands like w3_space_create, but core workflows are well-supported with CRUD-like operations for blobs, stores, and uploads.
Average 2.9/5 across 35 of 35 tools scored. Lowest: 1.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No issues in the last 6 months
- No commit activity data available
- 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description reveals nothing about what the tool actually does behaviorally - whether it's a read operation, creates something, modifies state, requires authentication, has rate limits, or what format the output takes. 'open' could mean anything from displaying content to initiating a session.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just 5 words, this is under-specification rather than effective conciseness. The description fails to communicate essential information about the tool's purpose. Every sentence should earn its place, but this single sentence provides almost no value beyond the tool name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool does, when to use it, what behavior to expect, or what the output might contain. Given the complexity implied by the sibling tools (which include operations for content management, authentication, and storage), this description leaves the agent with insufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (cid and path) clearly documented in the schema. The description adds no additional parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tool for w3_open operation' is a tautology that merely restates the tool name without explaining what the operation does. It provides no specific verb or resource, and doesn't distinguish this from sibling tools like w3_ls or w3_rm. The description fails to convey what 'open' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 sibling tools like w3_ls (list), w3_rm (remove), and w3_up (upload), there's no indication of when 'open' is appropriate versus these other operations. No context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It offers no information on whether the operation is read-only or destructive, what permissions are required, or any side effects (e.g., rate limits, state changes). The vague term 'operation' gives no insight into behavior beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise (one sentence), the description is under-specified rather than efficiently informative. It wastes its limited space on a tautological statement that adds no value, failing to front-load useful information. Conciseness should not come at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is severely incomplete. It does not explain the tool's purpose, behavior, or output, leaving the agent unable to understand or use it effectively. For a tool with one parameter but no other context, this description fails to provide necessary information.
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 'spaceDid' clearly documented in the schema (including pattern and example). The description adds no parameter semantics beyond what the schema provides, but the baseline is 3 since the schema adequately covers the parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tool for w3_space_use operation' is a tautology that merely restates the tool name with minimal added meaning. It lacks a specific verb or resource description, failing to clarify what the tool actually does (e.g., select, activate, or utilize a space). Compared to siblings like 'w3_space_add' or 'w3_space_ls', it provides no differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, nor does it reference sibling tools (e.g., 'w3_space_info' or 'w3_space_ls') that might serve similar purposes. This leaves the agent with no basis for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It adds nothing beyond the tautological name restatement—no indication of whether this is a read/write operation, what permissions are needed, how results are returned, or any side effects. For a tool with zero annotation coverage, this is completely inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Tool for w3_delegation_ls operation.') but this is under-specification rather than effective brevity. It wastes its single sentence on a tautology that provides no value, failing to front-load useful information. A more structured approach would clarify the tool's purpose upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's likely complexity (inferred from sibling tools involving delegations), no annotations, no output schema, and a minimal description, this is highly incomplete. The description doesn't explain what the tool returns, how to interpret results, or any operational context, leaving critical gaps for an agent to use it 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?
The input schema has 1 parameter with 100% description coverage, documenting that 'json' controls output formatting. The description adds no parameter information beyond what the schema provides. With high schema coverage, the baseline is 3, as the schema handles the heavy lifting, but the description doesn't compensate or add any semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tool for w3_delegation_ls operation' is a tautology that merely restates the tool name without explaining what the operation does. It doesn't specify what resource it acts on (delegations) or what 'ls' means (likely 'list'), nor does it differentiate from sibling tools like 'w3_delegation_create' or 'w3_delegation_revoke'. This provides minimal actionable information to an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, and fails to reference related sibling tools (e.g., 'w3_delegation_create' for creating delegations or 'w3_ls' for broader listing). This leaves the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it offers no information about what the tool does (e.g., whether it lists files, spaces, or other resources), what permissions are required, whether it's read-only or destructive, or what the output looks like. This lack of behavioral context makes it inadequate 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, under-specified sentence that fails to convey meaningful information. While concise, it's not appropriately sized for the tool's complexity—it lacks essential details about the tool's purpose and behavior. This isn't efficient brevity but rather insufficient content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and a vague description, the description is incomplete. It doesn't explain what the tool lists, how to interpret results, or any behavioral traits, leaving significant gaps for an agent to understand and use the tool effectively. This is inadequate for a tool in a context with many sibling listing operations.
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 1 parameter with 100% description coverage, documenting that 'json' controls output formatting as newline delimited JSON. The description adds no parameter information beyond this, but since schema coverage is high, the baseline score is 3. The description doesn't compensate for any gaps, but none exist in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tool for w3_ls operation' is a tautology that merely restates the tool name without explaining what the operation does. It doesn't specify what resource is being listed or what 'w3' refers to, making the purpose vague. While sibling tools like 'w3_space_ls' and 'w3_delegation_ls' suggest this might list something, the description fails to clarify what specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 any context, prerequisites, or exclusions, and doesn't differentiate it from sibling tools like 'w3_space_ls' or 'w3_delegation_ls' that also perform listing operations. This leaves the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. It doesn't indicate whether this is a read or write operation, what permissions are required, whether it's destructive, what happens on success/failure, or any rate limits. The single sentence provides zero behavioral context 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with only one sentence, this is a case of under-specification rather than effective conciseness. The single sentence 'Tool for w3_space_add operation' doesn't earn its place by providing any useful information beyond what's already in the tool name, making it inefficient despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a completely inadequate description, this tool definition is severely incomplete. The description fails to explain what the tool does, when to use it, what behavior to expect, or how it differs from sibling space-related tools, leaving the agent with insufficient information to properly invoke it.
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 single parameter 'proof' well-documented in the schema as 'Filesystem path to a CAR encoded UCAN proof, or a base64 identity CID string.' The description adds no additional parameter information beyond what the schema already provides, which meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tool for w3_space_add operation' is a tautology that merely restates the tool name without explaining what the operation does. It doesn't specify what resource is being added to what space or what the verb 'add' actually accomplishes, making the purpose vague and unhelpful for agent selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. Given the sibling tools include 'w3_space_create', 'w3_space_ls', and 'w3_space_info', there's no indication of how this 'add' operation differs from creating or provisioning a space, leaving the agent with no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to describe what the tool does operationally (e.g., lists proofs, retrieves verification data), its effects (e.g., read-only vs. mutative), or any constraints like authentication needs or rate limits. The vague phrasing offers no actionable behavioral insights.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single vague sentence that under-specifies rather than being concise. It wastes space on redundant phrasing ('Tool for...operation') without delivering meaningful content. A truly concise description would front-load purpose or usage, but this fails to do so effectively.
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, no output schema, and a vague description, this tool is inadequately documented. The description doesn't compensate for the lack of structured data, leaving the agent unsure of the tool's function, behavior, or output. For a tool in a complex ecosystem with many siblings, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 100% description coverage, documenting the 'json' boolean for output formatting. The description adds no parameter semantics beyond this, but since schema coverage is high, the baseline score of 3 applies. No additional value is provided over the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tool for w3_proof_ls operation' is a tautology that merely restates the tool name without explaining what it does. It doesn't specify the verb (e.g., list, retrieve) or resource (e.g., proofs, verification data), nor does it differentiate from sibling tools like w3_ls or w3_delegation_ls. This provides minimal useful information to an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. Given sibling tools like w3_ls (general listing) and w3_delegation_ls (specific to delegations), there's no indication of what makes w3_proof_ls distinct or appropriate for certain contexts. This leaves the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It fails to indicate that this is a destructive operation (implied by 'rm' but not stated), doesn't mention permissions or authentication requirements, and provides no information about rate limits, side effects, or what happens to removed content. The description adds almost no behavioral context 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 words) but under-specified rather than efficiently informative. While it doesn't waste words, it fails to provide essential information that would help an agent understand and use the tool effectively. The single sentence doesn't earn its place by adding value.
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 destructive operation with no annotations and no output schema, the description is severely incomplete. It doesn't explain what 'w3_rm' actually does, what resource it operates on, what the consequences are, or what to expect as a result. The combination of a vague description with missing structural information creates significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, both parameters (cid and removeShards) are well-documented in the input schema. The description adds no additional parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tool for w3_rm operation' is a tautology that merely restates the tool name without specifying what the operation does. It doesn't identify the verb (remove/delete) or resource (uploads listing, content), nor does it differentiate from sibling tools like w3_can_upload_rm or w3_can_blob_rm. This provides minimal actionable information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or exclusions. With sibling tools like w3_can_upload_rm and w3_can_blob_rm that also perform removal operations, the lack of differentiation is particularly problematic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the absolute path requirement for file arguments, which is useful operational context. However, it doesn't describe what the tool actually creates (a delegation CAR file), what permissions are needed, whether this is a write operation, or what happens after creation. The description is insufficient for a tool that appears to create security delegations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences. The first sentence is redundant (tautology), but the second provides valuable constraint information. While under-specified, it's not verbose or poorly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that creates security delegations with 6 parameters and no annotations or output schema, the description is inadequate. It doesn't explain what a delegation is, what the CAR file contains, how it should be used, or what the tool returns. The absolute path requirement is helpful but insufficient for understanding this complex operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds the absolute path requirement for the 'output' parameter, which provides additional context beyond the schema's description. However, it doesn't explain the relationship between parameters or the overall delegation creation process.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tool for w3_delegation_create operation' is a tautology that merely restates the tool name. It adds 'Requires ABSOLUTE paths for file arguments' which is a constraint but doesn't explain what the tool actually does. The name suggests it creates a delegation, but the description fails to specify what resource is being delegated or to whom.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like w3_delegation_ls or w3_delegation_revoke. The description mentions a constraint about absolute paths, but this is a technical requirement rather than usage context. There's no indication of prerequisites, typical scenarios, or relationship to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool 'requires ABSOLUTE paths for file arguments', which is a useful constraint. However, it doesn't disclose whether this is a read or write operation, what permissions are needed, what side effects occur, or what the expected output looks like. For a tool with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point with two sentences. The first sentence is redundant, but the second provides critical information about path requirements. There's no unnecessary verbosity, though it could be more informative about the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and a single parameter, the description is incomplete. It fails to explain what 'w3_proof_add' operation does, what a 'proof' is in this context, or what the expected outcome is. The absolute path requirement is helpful but doesn't compensate for the lack of core operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'proofPath' parameter clearly documented as 'ABSOLUTE path to the CAR encoded proof file delegated to this agent'. The description adds the requirement for 'ABSOLUTE paths for file arguments', which reinforces but doesn't significantly expand upon the schema. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tool for w3_proof_add operation' is a tautology that merely restates the tool name. It adds the requirement for 'ABSOLUTE paths for file arguments', which provides some context but doesn't explain what the operation actually does. Compared to sibling tools like 'w3_proof_ls' (likely listing proofs) and 'w3_delegation_create' (creating delegations), the purpose remains vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 the requirement for absolute paths but doesn't specify prerequisites, dependencies, or appropriate contexts. Given sibling tools like 'w3_proof_ls' and 'w3_delegation_create', there's no indication of how this tool relates to them or when it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions login requirements and edge case handling, which adds some context. However, it doesn't describe what information is returned, whether this is a read-only operation, potential error conditions, or any rate limits. For a tool that presumably retrieves space information, the behavioral description is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is poorly structured and not front-loaded. It starts with a tautological statement, then includes important login and edge case information as an afterthought. The sentences are awkwardly constructed, and the note about login status should be more prominent if it's a critical prerequisite. The description could be much more efficiently organized.
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 should provide more complete context about what this tool does and returns. While it mentions login requirements and edge cases, it doesn't explain what 'space info' actually includes, what format the information comes in, or how to interpret the results. For a tool with 2 parameters and presumably returning space information, this is inadequate.
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 (json and spaceDid) with clear descriptions. The description doesn't add any meaningful parameter semantics beyond what's in the schema. It mentions space-related concepts but doesn't clarify parameter usage, interactions, or provide examples. The baseline of 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Tool for w3_space_info operation' which is essentially a tautology that restates the tool name. While it mentions checking login status and handling empty space scenarios, it doesn't clearly articulate what the tool actually does (e.g., retrieve information about a Web3 storage space). The name suggests it gets space information, but the description doesn't confirm this with a specific verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage guidance by mentioning login prerequisites ('first make sure you are logged in') and handling of edge cases ('no current space and no space given' or empty spaces array). However, it doesn't explicitly state when to use this tool versus alternatives like w3_space_ls or w3_space_create, nor does it provide clear context about when this tool is appropriate versus when other space-related tools should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that 'ABSOLUTE paths' are required for file arguments, which is useful operational context. However, it doesn't describe what 'revoke' actually does (permanent deletion? temporary suspension?), what permissions are needed, whether the operation is reversible, or what side effects might occur. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences. The first sentence is redundant (tautology), but the second sentence provides critical operational information about absolute paths. While the first sentence could be eliminated, the overall structure is efficient with no wasted words beyond the initial tautology.
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 mutation tool ('revoke') with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool actually does behaviorally, what happens when invoked, what permissions are required, or what the expected outcome is. The absolute path requirement is helpful but insufficient for understanding the tool's purpose and effects in 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?
Schema description coverage is 100%, so both parameters are documented in the schema. The description adds value by emphasizing that 'ABSOLUTE paths' are required for file arguments, which clarifies the 'proof' parameter requirement beyond what the schema states ('ABSOLUTE path to a file'). This provides important operational guidance that compensates for the baseline expectation of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tool for w3_delegation_revoke operation' is a tautology that merely restates the tool name without explaining what 'revoke' means in this context. It doesn't specify what resource is being revoked (delegation) or what the operation entails, though the sibling tool 'w3_delegation_create' suggests this is likely a deletion/removal operation. The description fails to provide a clear verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. While the sibling list includes 'w3_delegation_ls' (likely for listing delegations) and 'w3_delegation_create' (likely for creating them), the description doesn't explain when revocation is appropriate versus other operations like modification or when to use this versus other deletion tools like 'w3_rm'. The only usage hint is the technical requirement about absolute paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions login requirements and possible empty results ('no current space and no space given' or '{"spaces":[]}'), which adds some behavioral context. However, it lacks details on what the tool returns, error conditions, or other operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences but includes redundant phrasing ('Tool for w3_space_ls operation'). The note about login and empty results is useful but could be more efficiently integrated. It is not overly verbose but lacks optimal structure.
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 hints at login requirements and possible empty outputs but does not explain what the tool returns (e.g., a list of spaces), error handling, or how it differs from sibling tools like 'w3_ls'. More context is needed for a tool in this environment.
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 with 100% schema description coverage, so no parameter documentation is needed. The description does not add parameter information, but this is acceptable given the lack of parameters, aligning with the baseline score for 0 params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Tool for w3_space_ls operation', which is a tautology that merely restates the tool name. It does not specify what the tool actually does (e.g., list spaces, show space details). However, it adds a note about login requirements, which provides some context beyond the name.
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 includes a note about ensuring login before use, which provides implied usage guidance. However, it does not explicitly state when to use this tool versus alternatives like 'w3_ls' or 'w3_space_info', nor does it provide clear exclusions or prerequisites beyond login.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool 'Does not automatically use it for the agent' and 'Requires ABSOLUTE paths for file arguments', adding some behavioral context. However, it lacks details on permissions, side effects, or output format. The description is partially helpful but incomplete for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that are front-loaded with key information. However, the first sentence about key generation is misleading and wastes space, reducing efficiency. It could be more structured by clarifying the tool's true purpose upfront.
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 (3 parameters, no annotations, no output schema) and the contradiction between description and schema, the description is incomplete. It fails to accurately describe the tool's purpose or provide sufficient context for safe and effective use. The mismatch between description and schema creates confusion, making it inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (paths, hidden, noWrap). The description adds 'Requires ABSOLUTE paths for file arguments', which provides extra meaning for the 'paths' parameter beyond the schema. However, it doesn't fully explain parameter interactions or usage. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Generates and prints a new ed25519 key pair' which is a specific verb+resource, but the input schema and sibling tools reveal a contradiction: the schema describes file upload parameters (paths, hidden, noWrap), not key generation. The description is misleading about the tool's actual purpose, making it unclear what the tool truly does.
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 'Does not automatically use it for the agent' but this is vague and doesn't help differentiate from sibling tools like w3_key_create or other key-related operations. No explicit when/when-not or alternative tools are named.
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 the tool 'generates authentication tokens' but lacks details on behavioral traits: it doesn't specify if this is a read-only or mutating operation, what permissions are needed, whether tokens are stored or transient, rate limits, or error conditions. The description is minimal and misses key operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/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 redundancy. It is appropriately sized and front-loaded, with no wasted words 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 the complexity of authentication token generation, no annotations, and no output schema, the description is insufficient. It lacks details on what the tool returns (e.g., token format, headers), error handling, security implications, or integration with other tools. For a critical operation like token generation, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing clear documentation for all parameters (capabilities, expiration, json). The description adds no additional parameter semantics beyond the schema, such as examples of capability strings or implications of expiration settings. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'generates' and the resource 'authentication tokens', specifying they are for 'using the UCAN-HTTP bridge'. It distinguishes from most siblings by focusing on token generation rather than operations like listing or creating resources, though it doesn't explicitly differentiate from similar tools like w3_login or w3_delegation_create.
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. It doesn't mention prerequisites (e.g., authentication state), compare to siblings like w3_login for initial authentication or w3_delegation_create for delegation, or specify scenarios where token generation is required.
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 'claims delegated capabilities,' which implies a mutation or authorization action, but does not specify if this requires special permissions, is idempotent, has side effects, or what happens on success/failure. For a tool with potential security implications, this lack of detail 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.
Conciseness4/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. It avoids redundancy and wastes no words, making it easy to parse. However, it could be slightly more structured by explicitly separating the action from the parameter context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a capability-claiming tool with no annotations and no output schema, the description is incomplete. It fails to explain what 'delegated capabilities' are, how they are used after claiming, or what the tool returns. For a security-related operation, this leaves critical gaps in understanding the tool's full context and 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?
Schema description coverage is 100%, with the schema fully documenting the single 'proof' parameter. The description adds minimal value beyond the schema, as it repeats the parameter's purpose without providing additional context like example formats or constraints. Since the schema handles the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('claims delegated capabilities') and the resource ('for the authorized account'), specifying the method ('using a provided proof'). It distinguishes itself from siblings like w3_delegation_create or w3_proof_add by focusing on claiming capabilities rather than creating or adding them. However, it lacks explicit mention of what 'delegated capabilities' entail in this context, slightly reducing 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 does not mention prerequisites (e.g., needing a proof from another tool like w3_delegation_create), exclusions, or compare it to siblings such as w3_delegation_ls or w3_proof_ls. The context is implied but not explicit, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the requirement for 'ABSOLUTE paths', which adds some context, but fails to cover critical aspects like whether this is a read/write operation, authentication needs, rate limits, or what happens after storage (e.g., returns an ID). This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that are front-loaded and efficient. However, the second sentence could be integrated more smoothly, and there's minor redundancy with the schema description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., side effects, return values) and doesn't compensate for the absence of structured data, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 'path' parameter fully. The description adds no additional meaning beyond what's in the schema (e.g., it repeats 'ABSOLUTE path'), resulting in a baseline score of 3 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Stores') and resource ('a single file as a blob'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'w3_can_blob_ls' or 'w3_can_blob_rm', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 sibling tools like 'w3_can_store_add' or 'w3_can_upload_add'. It mentions a requirement ('ABSOLUTE paths') but doesn't explain context or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as whether removal is permanent, requires specific permissions, has side effects (e.g., affecting linked data), or provides confirmation feedback. This is inadequate for a destructive operation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/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 without unnecessary words. Every part earns its place by specifying the action, resource, and key identifier.
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 destructive tool with no annotations and no output schema, the description is insufficient. It lacks critical context like safety warnings, return values, error conditions, or dependencies, leaving significant gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'multihash' fully documented in the schema. The description adds no extra meaning beyond restating the schema, so it meets the baseline of 3 where 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 action ('Removes') and resource ('a blob from the store'), specifying it's identified by a 'base58btc encoded multihash'. It distinguishes from siblings like 'w3_can_blob_add' (add) and 'w3_can_blob_ls' (list), but doesn't explicitly contrast with general deletion tools like 'w3_rm'.
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. It doesn't mention prerequisites (e.g., needing an existing blob), exclusions, or compare to similar tools like 'w3_can_store_rm' or 'w3_rm', leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Gets' information, implying a read-only operation, but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what 'advanced use' entails. The description is too vague to provide meaningful operational context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point without unnecessary words. It's front-loaded with the core purpose. However, the '(advanced use)' qualifier could be more integrated or explained, slightly reducing clarity without adding waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavioral aspects, usage context, and return values. Without annotations or output schema, more guidance would be helpful, but it's not entirely incomplete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'pieceCid' fully documented in the schema. The description adds no additional meaning beyond what's in the schema, such as format examples or constraints. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.
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 ('Gets') and resource ('Filecoin deal information for a given Piece CID'), making the purpose understandable. It distinguishes from siblings like w3_can_blob_ls or w3_can_store_ls by focusing on Filecoin-specific data retrieval rather than general listing operations. However, it doesn't fully differentiate from other 'info' tools like w3_space_info, which might have similar patterns.
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 minimal guidance with the phrase '(advanced use)', which implies this tool is for specialized scenarios but doesn't specify when to use it versus alternatives. There's no explicit mention of prerequisites, when-not-to-use cases, or comparisons to sibling tools, leaving the agent with little 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. It mentions 'advanced use' and refers to external docs, but does not disclose key behavioral traits such as whether this is a read/write operation, potential side effects, authentication needs, or rate limits. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core action, consisting of two sentences. However, the second sentence defers to external documentation, which slightly reduces self-contained clarity but maintains efficiency without 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 the lack of annotations and output schema, and the description's reliance on external documentation, it is incomplete for an AI agent. The tool's complexity (implied by 'advanced use') is not adequately explained, leaving gaps in understanding how to use it effectively in context with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'cid' documented as 'CID of the index to add.' The description adds no additional meaning beyond this, as it repeats the same phrasing. Given the high schema coverage, the baseline score of 3 is appropriate, as the description does not compensate with extra 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 states the specific action ('Registers an index CID') and resource ('with the service'), making the purpose clear. However, it does not explicitly differentiate from sibling tools like 'w3_can_blob_add' or 'w3_can_store_add', which also involve adding operations, leaving some ambiguity in sibling context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by labeling it as 'advanced use' and referring to external documentation, but it does not specify when to use this tool versus alternatives (e.g., other 'add' tools in the sibling list) or any prerequisites. This lack of explicit context reduces its utility for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'advanced use' but lacks details on permissions, rate limits, pagination behavior (implied by cursor param), or output format beyond JSON option. This leaves significant behavioral gaps for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without fluff. It could be slightly more front-loaded with key details, but it's appropriately sized and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is minimal but covers the basic action. It lacks details on output format, error handling, or advanced usage implications, making it adequate but incomplete for a tool with three parameters and no structured behavioral hints.
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 parameters (cursor, json, size). The description adds no additional parameter meaning beyond what's in the schema, meeting the baseline of 3 for high coverage without extra value.
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 ('Lists') and resource ('stored CAR files (shards)') with context ('in the current space'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like w3_can_blob_ls or w3_can_upload_ls, which also list resources, missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'advanced use', implying a specific context but not explaining when to use this tool versus alternatives like w3_can_blob_ls or w3_can_upload_ls. No explicit when/when-not rules or prerequisites are stated, leaving usage 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'advanced view' and 'shows underlying structure,' hinting at detailed output, but fails to describe critical behaviors like pagination (implied by 'cursor' parameter), output format defaults (JSON vs. pretty print), or mutation effects (likely read-only based on 'ls' convention). For a tool with 5 parameters and no annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/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 ('Lists uploads registered in the current space') and adds a clarifying note ('advanced view, shows underlying structure'). There is no wasted verbiage, though it could be slightly more structured by separating purpose from behavioral hints.
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 (5 parameters, no output schema, no annotations), the description is incomplete. It lacks details on output structure, error conditions, pagination behavior, and how the 'advanced view' differs from standard listings. Without annotations or output schema, the agent must rely heavily on schema parameters, leaving gaps in understanding the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter well-documented in the input schema (e.g., 'cursor' for pagination, 'json' for output format). The description adds no additional parameter semantics beyond what the schema provides, such as explaining interactions between 'json' and 'shards' or typical 'size' values. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lists') and resource ('uploads registered in the current space'), making the purpose evident. It distinguishes itself from generic listing tools by specifying 'uploads' rather than other resources like accounts or stores. However, it doesn't explicitly differentiate from sibling upload tools like 'w3_can_upload_add' or 'w3_can_upload_rm' beyond the 'ls' suffix.
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 minimal guidance, mentioning an 'advanced view' that 'shows underlying structure,' which implies usage for detailed inspection rather than simple listing. However, it lacks explicit when-to-use criteria, prerequisites, or comparisons to alternatives like 'w3_can_blob_ls' or 'w3_ls,' leaving the agent to infer context from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Attempts to create/claim,' implying a mutation with potential failure, but doesn't disclose behavioral traits like required permissions, rate limits, idempotency, or what happens on success/failure (e.g., coupon activation). For a mutation tool with zero annotation coverage, this is inadequate, warranting a 2.
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: 'Attempts to create/claim a coupon using a claim code.' It's front-loaded with the core purpose, has zero wasted words, and appropriately sized for a simple tool. Every word earns its place, making it a 5.
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 (a mutation with no annotations, 1 parameter, and no output schema), the description is incomplete. It lacks details on behavioral aspects (e.g., side effects, error handling) and output expectations, which are crucial for an agent to use it correctly. With no annotations or output schema, the description should do more to compensate, scoring a 2.
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 schema documenting the 'claimCode' parameter as 'The claim code for the coupon.' The description adds no additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline is 3, 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.
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: 'Attempts to create/claim a coupon using a claim code.' It specifies the verb ('create/claim') and resource ('coupon'), and distinguishes it from siblings like w3_coupon_* tools (none listed) or w3_plan_get. However, it doesn't explicitly differentiate from non-coupon siblings, keeping it at 4 rather than 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 (e.g., needing a claim code), exclusions, or related tools like w3_can_access_claim (which might check claim validity). Without any usage context, the score is 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions listing blobs but doesn't describe key behaviors like pagination (implied by the 'cursor' parameter), output format details, or potential rate limits. This leaves significant gaps for a tool with 3 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/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 with zero wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation with 3 parameters and no output schema, the description is minimal but functional. It covers the basic action but lacks details on output format, pagination behavior, or error conditions, which would be helpful given the complexity. The high schema coverage helps, but more context is needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters ('cursor', 'json', 'size') thoroughly. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline for high coverage but not providing extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lists') and resource ('blobs stored in the current space'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'w3_can_blob_add' (adds blobs) or 'w3_can_blob_rm' (removes blobs), 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 like 'w3_can_store_ls' or 'w3_can_upload_ls', nor does it mention prerequisites such as needing to be in a specific space. It only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Displays,' which suggests a read-only operation, but doesn't confirm if it's safe, requires specific permissions, or has side effects. It also doesn't describe the output format (e.g., JSON structure, error handling), leaving the agent uncertain about what to expect beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core functionality without unnecessary words. It's front-loaded with the main action and resource, making it easy to parse. There's no redundancy or fluff, earning a top score for conciseness.
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 low complexity (1 optional parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, output format, and usage context. Without annotations or an output schema, the agent is left with gaps in understanding the full tool behavior, making it incomplete for optimal 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 the parameter 'accountId' well-documented in the schema itself. The description adds minimal value beyond the schema by mentioning 'the current or specified account,' which aligns with the schema's default behavior. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't provide additional semantic details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Displays') and resource ('plan'), making the purpose understandable. It specifies that the plan is associated with 'the current or specified account,' which adds context. However, it doesn't explicitly differentiate this tool from potential siblings like 'w3_space_info' or 'w3_usage_report,' which might also provide account-related information, so it falls short of 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 minimal guidance: it implies usage when needing to view a plan, but offers no explicit when-to-use criteria, no exclusions, and no alternatives. For example, it doesn't clarify if this is for billing, feature access, or other purposes, nor does it reference sibling tools. This lack of context makes it harder for an agent to decide when to invoke this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('associates') but doesn't clarify if this is a read-only or mutating operation, what permissions are required, potential side effects (e.g., billing implications), or error handling. This leaves significant 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 directly states the tool's purpose without unnecessary words or redundancy. It is front-loaded with the core action, making it easy to parse and understand quickly, which is ideal for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters with full schema coverage but no annotations and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage context, or return values, which are important for a tool that likely involves billing or account management. This results in a moderate level of completeness with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for both parameters ('customerId' and 'spaceDid') in the input schema. The tool description adds no additional meaning beyond what the schema provides, such as format details or usage examples. However, since the schema fully documents the parameters, a baseline score of 3 is appropriate as the description doesn't compensate but also doesn't need to.
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 ('associates') and the resources involved ('a space with a customer/billing account'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'w3_space_add' or 'w3_space_create', which might involve similar resources but different 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, such as 'w3_space_add' or 'w3_space_create', nor does it mention prerequisites, exclusions, or specific contexts. It lacks explicit usage instructions, leaving the agent to infer based on the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'displays' a report, which implies a read-only operation, but doesn't clarify if this requires specific permissions, how the report is formatted beyond the JSON parameter, whether it includes real-time data, or what happens on errors. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 without unnecessary words. Every part of the sentence earns its place by specifying the action, resource, and scope, making it highly concise and well-structured for quick understanding.
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 (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and scope but lacks details on behavioral traits, output format beyond the JSON parameter, or error handling. Without annotations or output schema, more context would be helpful 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?
Schema description coverage is 100%, so the schema already fully documents both parameters (spaceDid for optional space targeting, json for output format). The description adds no additional parameter semantics beyond what's in the schema, such as explaining what 'space' entails or default behaviors. Baseline 3 is appropriate when the schema does all the work.
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 ('Displays a storage usage report') and resource ('for the current or specified space'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from potential sibling tools like 'w3_space_info' or 'w3_ls' that might also provide space-related 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'current or specified space,' suggesting it can be used for either the active space or a targeted one. However, it provides no explicit guidance on when to choose this tool over alternatives like 'w3_space_info' or 'w3_ls,' nor does it mention any prerequisites or exclusions, leaving usage decisions somewhat ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds some behavioral context by specifying 'advanced use' and the prerequisite relationship with another tool, but it lacks details on permissions, side effects (e.g., whether it overwrites existing files), rate limits, or error handling. This leaves gaps in understanding the tool's behavior beyond basic functionality.
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 front-loaded: it states the core purpose in the first sentence, adds usage context in the second, and includes a critical requirement in the third. Every sentence earns its place with no wasted 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 has 1 parameter with full schema coverage and no output schema, the description provides adequate basics like purpose and usage context. However, as a mutation tool (implied by 'Stores') with no annotations, it lacks details on behavioral aspects such as permissions, idempotency, or return values, which would be needed for more complete understanding in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'path' parameter. The description adds value by emphasizing 'ABSOLUTE paths for file arguments' in a separate sentence, reinforcing the requirement beyond the schema's description. This extra emphasis helps clarify usage, though it doesn't introduce new parameter details.
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 ('Stores a CAR file') and resource ('with the service'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'w3_can_store_ls' or 'w3_can_store_rm', which would require more specific context about what 'store' means versus 'list' or 'remove'.
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 when to use this tool: it's for 'advanced use' and 'often a prerequisite for `w3_can_upload_add`'. This gives practical guidance on its role in workflows. However, it doesn't explicitly state when not to use it or mention alternatives among siblings, which could further clarify usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates this is a 'manual registration' tool for 'advanced use,' which implies it's a write operation that requires specific knowledge. However, it lacks details on permissions needed, side effects, error conditions, or what happens after registration (e.g., does it verify shards?). This leaves behavioral 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 two sentences that are front-loaded with the core purpose and followed by usage context. Every word earns its place with zero waste, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, no annotations, and no output schema, the description is adequate but incomplete. It covers the purpose and basic usage but lacks details on behavioral aspects like authentication requirements, rate limits, or return values. Given the complexity of a manual registration operation, more context would be beneficial 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%, with both parameters (rootCid, shardCids) well-documented in the schema. The description adds minimal value beyond the schema by reinforcing the purpose but doesn't provide additional context like format examples or constraints. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('manually registers an upload DAG') and identifies the resources involved ('by its root CID and shard CIDs'). It distinguishes this tool from sibling tools like w3_can_upload_ls and w3_can_upload_rm by focusing on registration rather than listing or removal.
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 about when to use this tool ('typically used after storing CAR shards manually') and labels it as 'advanced use,' which helps guide appropriate usage. However, it doesn't explicitly state when not to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool's action ('Removes an upload listing') and a key limitation ('Does not remove the underlying blobs/shards'), which is valuable context. However, it lacks details on permissions, side effects, error handling, or response format, leaving behavioral aspects partially uncovered for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the core action and efficiently convey essential information: the operation, target, usage context, and limitation. Every sentence earns its place with no wasted words, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is partially complete. It covers the purpose and a key behavioral trait (non-destructive to blobs/shards), but lacks details on permissions, return values, error conditions, or integration with sibling tools, leaving gaps for an advanced-use mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'rootCid' fully documented in the schema as 'Root CID of the upload to remove from the list.' The description adds no additional parameter details beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Removes an upload listing') and the target resource ('by its root CID'), distinguishing it from sibling tools like w3_can_upload_ls (list) and w3_can_upload_add (add). It also specifies the scope ('advanced use') and what is not affected ('Does not remove the underlying blobs/shards'), making the purpose highly specific and well-differentiated.
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 with 'advanced use', indicating this is for specialized scenarios rather than routine operations. However, it does not explicitly state when to use this tool versus alternatives like w3_rm or w3_can_blob_rm, nor does it mention prerequisites or exclusions, leaving some guidance gaps compared to explicit sibling differentiation.
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 the tool's behavior: it generates a key pair, prints it (implying output to the user), and clarifies that it doesn't auto-apply the key. This covers key aspects like mutation (creation) and output format, though it could add details on security implications or error handling.
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—two short sentences that directly state the tool's function and a key behavioral note. Every word serves a purpose, with no redundancy or fluff, making it easy to parse and front-loaded with essential information.
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 low complexity (one optional parameter, no output schema, no annotations), the description is mostly complete. It explains what the tool does and a critical behavioral trait (no auto-use). However, it could be slightly more complete by mentioning the output format (e.g., printed as text or JSON) or any side effects, though this is minor.
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 'json' fully documented in the schema as controlling export format. The description does not add any parameter-specific information beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Generates and prints') and resource ('a new ed25519 key pair'), making the purpose immediately understandable. It distinguishes itself from sibling tools by focusing on key generation rather than account management, storage operations, or other functions listed in the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'Does not automatically use it for the agent,' which suggests this tool is for creating keys that must be manually applied elsewhere. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., if other tools handle key management) or any prerequisites, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 discloses critical behavioral traits: it's a destructive operation ('deletes the underlying data shard'), has irreversible consequences, and is intended for advanced users. This goes beyond what minimal annotations would cover.
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 perfectly concise with two sentences that each earn their place: the first states the purpose, the second provides critical behavioral warnings. No wasted words, and the most important information (the destructive nature) is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description does well by emphasizing the irreversible deletion. It could be more complete by mentioning what happens on success/failure or if there are prerequisites, but given the tool's single parameter and clear warning, it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'carCid' parameter thoroughly. The description doesn't add any additional parameter semantics beyond what's in the schema, maintaining the baseline score 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 verb ('Removes') and resource ('stored CAR shard by its CID'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'w3_can_blob_rm' or 'w3_can_upload_rm', which also perform removal operations on different resources.
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 with 'advanced use' and 'Use with extreme caution', indicating when this tool should be used. It doesn't explicitly name alternatives or state when not to use it, but the cautionary language implies high-risk scenarios.
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 full burden. It discloses key behavioral traits: the tool initiates a process requiring email confirmation, may return 'Too Many Requests' errors requiring waiting, and successful authorization is indicated by specific output text ('Agent was authorized by'). It doesn't cover rate limits beyond the error case or detailed auth flow, but provides essential operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized but could be better structured. It front-loads the core purpose, but mixes operational instructions with error handling. Sentences like 'IMPORTANT: The command expects email confirmation...' are clear, but the flow could be more organized. It avoids redundancy but includes some imperative phrasing that might be verbose.
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 (authentication flow with user interaction), no annotations, no output schema, and 0 parameters, the description is fairly complete. It covers the initiation process, user action required, success indication, and error handling. It doesn't detail the exact output format or all possible error cases, but provides enough for an agent to use it correctly in 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%. The description adds value by explaining the email source ('W3_LOGIN_EMAIL env var') and emphasizing user interaction requirements. Since there are no parameters to document, the baseline is 4, and the description provides useful context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Initiates the w3 login process using the pre-configured email', which specifies the verb ('initiates') and resource ('w3 login process'). It distinguishes from siblings by focusing on authentication initiation rather than account management or storage operations. However, it doesn't explicitly differentiate from potential login alternatives (though none appear in the sibling list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'before running the `w3_login` tool, emphasize ATTENTION to the user... they MUST check email to complete authentication' and 'If the final output includes 'Agent was authorized by'... CONTINUE using mcp-ipfs tools.' It also specifies when to retry: 'Too Many Requests': wait a moment before requesting it again.' This covers when to use, prerequisites, and next steps.
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 reveals a critical behavioral trait: the tool cannot be executed via MCP due to interactive prompts, requiring manual terminal use. This goes beyond the basic 'creates' action, disclosing execution constraints that are essential for the agent to know. However, it doesn't mention other potential behaviors like permissions needed, rate limits, or what happens on success/failure.
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 perfectly concise and well-structured: two sentences that each earn their place. The first sentence states the core purpose, and the second provides critical usage guidance with a clear NOTE prefix. There is zero wasted text, and the most important information (the limitation) is front-loaded in the second sentence.
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 creation operation with interactive prompts), no annotations, and no output schema, the description does a good job of covering the essential context. It explains the purpose and, crucially, the execution constraint that prevents MCP use. However, it doesn't describe what happens after creation (e.g., space ID returned, error conditions), which would be helpful given the lack of output schema.
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 schema already documenting the single optional 'name' parameter. The description repeats 'with a user-friendly name' but adds no additional semantic context beyond what the schema provides (e.g., naming conventions, length limits, or examples). The baseline score of 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: 'Creates a new space with a user-friendly name.' It specifies the verb ('creates') and resource ('new space'), though it doesn't explicitly differentiate from sibling tools like 'w3_space_add' or 'w3_space_provision'. The purpose is clear but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'NOTE: `w3 space create` cannot be run via MCP due to interactive recovery key prompts. Please run this command manually in your terminal.' This clearly states when NOT to use this tool (via MCP) and provides an alternative (manual terminal execution), which is crucial for avoiding failed invocations.
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. It discloses key behavioral traits: the tool depends on authorization state, agent state may be ephemeral (e.g., in Docker), and it's used for confirmation/status checking. However, it doesn't detail output format, error conditions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: purpose, primary usage context, and a note about ephemeral state with reconnection guidance. Every sentence adds value without redundancy, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no annotations, no output schema), the description is largely complete for its purpose. It explains authorization dependencies and ephemeral state considerations. However, without an output schema, it doesn't describe what the list of accounts looks like (e.g., format, fields), leaving a minor gap.
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, so no parameter semantics are needed. The description doesn't add param info beyond the schema, but with 100% schema coverage and no params, a baseline of 4 is appropriate as the description focuses on usage context rather than compensating for missing param documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Lists all accounts the current agent is authorized for.' It specifies the verb ('Lists') and resource ('accounts'), and distinguishes itself from siblings like 'w3_login' (which authenticates) and 'w3_ls' (which likely lists other resources).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'after `w3_login` and email validation to confirm the agent is successfully linked' and 'after (re)connecting' to check authorization status. It also specifies an alternative action: 'use `w3_login` if needed' when authorization is lacking.
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 communicates the dangerous nature of the operation ('DANGEROUS'), specifies what gets destroyed ('removing all proofs and delegations') and what is retained ('retaining the agent DID'), and mentions the confirmation requirement. However, it lacks details on irreversible effects or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads critical information ('DANGEROUS'), states the action and its effects, and ends with the confirmation requirement. Every word serves a purpose with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a dangerous, single-parameter tool with no annotations and no output schema, the description is nearly complete: it covers purpose, behavioral risks, and parameter context. It could improve by specifying output behavior or error cases, but given the simplicity, it's largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter (confirmReset). The description adds context by explaining why the parameter is required ('Requires explicit confirmation argument'), which provides semantic meaning beyond the schema's technical constraint. No parameters are missing documentation.
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 ('resets the agent state'), specifies what is removed ('all proofs and delegations'), and what is retained ('the agent DID'). It distinguishes this destructive operation from sibling tools that manage proofs/delegations (e.g., w3_proof_ls, w3_delegation_create) without performing resets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: for resetting agent state when confirmation is provided. It implies when not to use it (e.g., for routine operations like listing or adding proofs/delegations, which are handled by sibling tools), and the confirmation requirement serves as a usage prerequisite.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Lightport: Open-Sourcing Glama's AI Gateway
By punkpeye on April 27, 2026.
open source
OpenAI
Tool Definition Quality Score (TDQS)
By punkpeye on April 3, 2026.
mcp
The Hackers Who Tracked My Sleep Cycle
By punkpeye on March 26, 2026.
security

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/alexbakers/mcp-ipfs'

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