Aptos NPM MCP

Official

by aptos-labs

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v0.0.22
Disambiguation3/5
The tools have some clear distinctions, such as between Geomi CRUD operations and Aptos resource management, but there is significant overlap and ambiguity. For example, multiple 'build' tools (build_dapp_on_aptos, build_smart_contract_on_aptos, build_ui_frontend_on_aptos) cover similar development guidance with unclear boundaries, and several 'prompt' tools (aptos_debugging_helper_prompt, aptos_development_reminder_prompt, build_dapp_on_aptos_guidance_prompt) serve overlapping advisory functions, which could confuse agents about when to use each.
Naming Consistency2/5
Naming conventions are inconsistent and chaotic. There is a mix of snake_case (e.g., list_aptos_resources), verbose phrases with underscores (e.g., aptos_debugging_helper_prompt), and camelCase-like patterns (e.g., get_mcp_version). Verbs vary widely (e.g., 'build', 'create', 'get', 'list', 'update', 'delete'), and some names are overly descriptive while others are terse, lacking a predictable pattern across the set.
Tool Count3/5
With 22 tools, the count is borderline high for the server's purpose of Aptos development and Geomi management. While the domain is broad, the tools include many overlapping or redundant ones (e.g., multiple prompt tools and build guidance tools), making the set feel heavy and potentially over-scoped. A more streamlined set of 10-15 tools might better cover the core functionalities without excess.
Completeness4/5
The tool set provides good coverage for the inferred domains of Aptos development resources and Geomi organization management. For Geomi, it offers full CRUD operations for organizations, projects, applications, and API keys, with no obvious gaps. For Aptos resources, it includes listing and fetching, though it lacks direct blockchain interaction tools. Minor gaps exist, such as no tools for deploying or testing smart contracts, but agents can work around these with the available guidance tools.
Average 3.2/5 across 22 of 22 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool 'can be used to create a Gas Station application' but doesn't disclose important behavioral aspects: whether this is a mutating operation, what permissions are required, what happens on success/failure, whether the created application is immediately usable, or any rate limits. The description mentions what Gas Station is but not how the creation process works.
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 reasonably concise with two sentences. The first sentence directly states the tool's purpose, and the second provides context about what Gas Station is. However, the second sentence could be more tightly integrated with the first, and there's some redundancy ('Geomi is the essential toolkit for Aptos developers' could be omitted as 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?
For a complex creation tool with 8 parameters (6 required), no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, what happens after creation, error conditions, or practical usage scenarios. The description provides basic purpose but lacks the operational context needed for effective tool invocation given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 88% schema description coverage, the schema already documents most parameters well. The description adds minimal value beyond the schema - it mentions creating 'a Gas Station application' which hints at the purpose of the parameters, but doesn't explain relationships between parameters (like how organization_id, project_id, and api_key_name relate) or provide usage examples. The baseline of 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool creates a new Gas Station application for a Geomi Organization, which is a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'create_geomi_api_key' or 'create_geomi_api_resource_application' - all create different Geomi resources but the description doesn't clarify what makes a Gas Station application unique from other application types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 (like needing an organization and project first), when Gas Station applications are appropriate versus other application types, or what happens after creation. The sibling tools list includes related creation tools but the description offers no differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that API keys are 'secret keys' requiring security, which is helpful context. However, it doesn't describe important behavioral aspects: what permissions are needed to create keys, whether there are rate limits on creation, what the response contains (e.g., the actual key value), or whether creation is idempotent. For a security-sensitive creation tool, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise at three sentences, but the first sentence is front-loaded with the core purpose. The second sentence about Geomi being 'the essential toolkit for Aptos developers' is marketing fluff that doesn't aid tool selection. The third sentence partially repeats the first. Some trimming would improve focus without losing essential information.
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 (5 parameters with nested objects, no annotations, no output schema), the description is insufficient. It doesn't explain what happens after creation (e.g., where the key is stored, how to retrieve it), security implications, or error conditions. For a tool that creates sensitive credentials, more contextual guidance 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 80%, providing a strong baseline. The description adds minimal parameter semantics beyond the schema—it mentions API keys are for 'Api resource application to interact with the Aptos blockchain,' which loosely relates to the application_id parameter. However, it doesn't explain relationships between parameters (e.g., organization_id, project_id, application_id hierarchy) or provide context for complex nested parameters like frontend_args.
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 creates a new API key for a Geomi Organization, specifying it's for interacting with the Aptos blockchain. It distinguishes from sibling tools like 'create_geomi_api_resource_application' by focusing on key creation rather than application creation. However, it doesn't explicitly differentiate from 'update_geomi_api_key' in terms of create vs. modify 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 minimal guidance on when to use this tool. It mentions it's for creating API keys for applications to interact with Aptos blockchain, but doesn't specify prerequisites (e.g., needing an existing organization, project, and application), nor does it contrast with alternatives like 'update_geomi_api_key' for modifying existing keys or 'delete_geomi_api_key' for removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it correctly identifies this as a deletion operation (implying mutation/destruction), it fails to mention critical behavioral aspects: whether deletion is permanent, what permissions are required, if there are confirmation prompts, rate limits, or error conditions. For a destructive operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is direct and front-loaded with the core functionality. However, the second marketing sentence ('Geomi is the essential toolkit for Aptos developers') adds no value to tool understanding and wastes space. A more concise version would omit this irrelevant information.
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 insufficient. It doesn't explain what happens after deletion (success response, error handling), doesn't mention side effects, and provides no behavioral context. The agent lacks critical information needed to use this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four parameters clearly documented in the input schema. The description adds no additional parameter information beyond what's in the schema (e.g., it doesn't explain relationships between parameters or provide examples). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('API Key for your Geomi Organization'), making the purpose unambiguous. It distinguishes itself from sibling tools like 'create_geomi_api_key' and 'update_geomi_api_key' by specifying deletion. However, it includes an unnecessary marketing statement ('Geomi is the essential toolkit for Aptos developers') that doesn't enhance purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing API key), exclusions, or compare it to related tools like 'delete_geomi_application' or 'delete_geomi_project'. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action is 'Delete,' implying a destructive operation, but does not clarify permanence, permissions required, or side effects (e.g., impact on related resources). This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action but includes a superfluous marketing sentence that does not aid tool selection. While concise in length, the second sentence adds no operational value, reducing efficiency.
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 details like confirmation prompts, error handling, or return values, leaving the agent with incomplete operational context despite good schema coverage.
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 clear parameter descriptions in the schema. The tool description adds no additional parameter semantics beyond what the schema provides, such as format examples or interdependencies. The baseline score of 3 reflects adequate coverage from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('Application for your Geomi Organization'), making the purpose evident. It distinguishes itself from siblings like 'delete_geomi_api_key' and 'delete_geomi_project' by specifying the resource type. However, it includes an unnecessary marketing phrase ('Geomi is the essential toolkit for Aptos developers') that slightly dilutes focus.
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 explicit guidance is provided on when to use this tool versus alternatives. While siblings like 'get_geomi_applications' and 'update_geomi_application_name' exist, the description does not mention them or specify prerequisites, leaving usage context unclear beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Delete,' implying a destructive mutation, but doesn't clarify if deletion is permanent, reversible, requires specific permissions, or has side effects (e.g., cascading deletions). For a destructive tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is direct and front-loaded, but the second marketing sentence ('Geomi is the essential toolkit for Aptos developers') adds no operational value and wastes space. A more concise version would omit this, improving structure without losing clarity.
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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context: what happens upon deletion (e.g., confirmation, error handling), return values, or behavioral nuances. The agent is left guessing about outcomes, which is inadequate given the tool's complexity and risk.
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 ('organization_id' and 'project_id') clearly documented in the schema. The description adds no parameter-specific information beyond what the schema provides, such as format examples or contextual constraints. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a Project for your Geomi Organization'), making the purpose unambiguous. It distinguishes from sibling tools like 'create_geomi_project' and 'update_geomi_project' by specifying deletion. However, it includes an unnecessary marketing sentence about Geomi being 'the essential toolkit for Aptos developers,' which slightly dilutes focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing project), exclusions, or comparisons to sibling tools like 'delete_geomi_api_key' or 'delete_geomi_application.' The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation but doesn't mention what gets updated (beyond the API key), whether it requires specific permissions, if changes are reversible, or what happens to existing settings not mentioned. For a mutation tool with complex parameters, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) but includes irrelevant marketing content ('Geomi is the essential toolkit for Aptos developers') that doesn't help tool selection. The first sentence is functional but could be more specific about what aspects of the API key are updated.
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 with 6 parameters (including complex nested objects), no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, error conditions, or behavioral implications. The high schema coverage helps, but the description should provide more context about this update operation's effects.
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 83%, which is high, so the baseline is 3. The description adds no parameter information beyond what's in the schema, but the schema itself provides good documentation for most parameters. The description doesn't compensate for the 17% coverage gap or explain relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('API Key for your Geomi Organization'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'create_geomi_api_key' or 'delete_geomi_api_key' beyond the obvious verb difference, and includes marketing fluff ('essential toolkit for Aptos developers') that doesn't clarify functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'create_geomi_api_key' or 'delete_geomi_api_key'. The description doesn't mention prerequisites, use cases, or constraints, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is an update operation, implying mutation, but doesn't disclose behavioral traits like required permissions, whether changes are reversible, rate limits, or what happens on success/failure. The second sentence about Geomi being a toolkit is irrelevant to behavior.
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 first sentence is clear but could be more front-loaded (e.g., starting with 'Update the name of a Geomi application'). The second sentence ('Geomi is the essential toolkit...') adds no value to tool usage and wastes space. Overall, it's moderately concise but includes irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, this is a mutation tool with incomplete context. The description lacks behavioral details (e.g., side effects, response format) and usage guidelines, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds no meaning beyond what the schema provides—it doesn't explain parameter relationships, formats, or constraints. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update an Application name') and resource ('for your Geomi Organization'), with a specific verb and target. However, it doesn't differentiate this tool from sibling tools like 'update_geomi_organization' or 'update_geomi_project', which have similar naming patterns but update 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing application), exclusions, or relationships to sibling tools like 'get_geomi_applications' (for listing) or 'delete_geomi_application' (for removal).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states 'Update a Project' implying mutation, but doesn't disclose permissions required, whether changes are reversible, rate limits, or what happens to unspecified fields. The marketing sentence adds no operational value.
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 brief but not optimally structured. The first sentence states the purpose, but the second marketing sentence ('Geomi is the essential toolkit...') adds no value for tool selection or invocation, wasting space. It could be more front-loaded with actionable details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., side effects, error handling), usage context, and expected outcomes, leaving significant gaps for an AI agent to understand how 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?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no parameter-specific information beyond implying 'project' is the resource being updated, which is already clear from the schema. Baseline 3 is appropriate as the schema handles parameter semantics 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 ('Update a Project') and resource ('for your Geomi Organization'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'update_geomi_organization' or 'update_geomi_application_name' beyond the resource type, and includes marketing fluff ('essential toolkit for Aptos developers') that doesn't clarify the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing project), exclusions, or comparisons to sibling tools like 'create_geomi_project' or other update tools, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Create a new Application' implying a mutation, but doesn't disclose behavioral traits such as required permissions, whether the operation is idempotent, rate limits, or what happens on failure. The mention of creating API keys is contextual but not detailed enough for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences. The first sentence directly states the purpose, and the second adds useful context about Geomi and API keys. It's front-loaded and avoids unnecessary verbosity, though the second sentence could be more tightly integrated.
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 for a mutation tool. It lacks details on behavioral aspects like error handling, response format, or side effects. The context about Geomi and API keys is helpful but doesn't compensate for missing operational transparency.
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 5 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, such as explaining relationships between parameters or usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new Application') and the resource ('for your Geomi Organization'), with additional context about Geomi's purpose. It distinguishes from siblings like 'create_gas_station_application' by specifying 'API resource application' and mentions creating API keys for Aptos blockchain interactions, though not all sibling differences are explicit.
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 explicit guidance on when to use this tool versus alternatives like 'create_gas_station_application' or 'create_geomi_project'. The description mentions creating API keys as a follow-up, but lacks clear prerequisites, exclusions, or comparative context with other Geomi 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. It states this is a creation tool, implying a write operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, side effects, or what happens on success/failure. The description adds minimal context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: the first states the tool's purpose, and the second provides background on Geomi. The second sentence adds context but isn't strictly necessary for tool selection. It's front-loaded with the core functionality.
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 is a write operation with no annotations and no output schema, the description is incomplete. It lacks details on authentication, response format, error handling, or any behavioral context needed for an agent to use it effectively. The background on Geomi doesn't compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the 'name' parameter. The description doesn't add any parameter-specific information beyond what's in the schema. With high schema coverage, the 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 ('Create a new Organization') and the resource ('for your Geomi account'), with additional context about Geomi's purpose. It distinguishes from siblings like 'update_geomi_organization' by specifying creation vs. update, but doesn't explicitly differentiate from other creation tools (e.g., 'create_geomi_project').
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), scenarios where it's appropriate, or exclusions. The description 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 the tool creates a project but does not mention permissions required, rate limits, whether the operation is idempotent, or what happens on success/failure. 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 a single, efficient sentence that front-loads the core purpose. The second sentence about Geomi being a toolkit for Aptos developers adds minimal value but does not significantly detract from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, error handling, and return values, leaving the agent with insufficient context 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%, so the schema fully documents all three parameters. The description adds no additional meaning beyond the schema, such as explaining parameter interactions or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new Project') and the resource ('for your Geomi Organization'), providing a specific verb+resource combination. However, it does not differentiate this tool from its sibling 'create_geomi_organization' or other creation tools in the list, missing explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'create_geomi_organization' or 'create_gas_station_application'. The description lacks context about prerequisites, such as needing an existing organization, or exclusions for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's an update operation, implying mutation, but lacks details on permissions, side effects, error handling, or response format. This is inadequate for a mutation tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without redundancy. The second sentence about Geomi provides context but is arguably extraneous; however, it doesn't detract significantly from clarity, making this highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., what 'update' entails, success/error responses), making it insufficient for an agent to use the tool confidently without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters ('name' and 'organization_id'). The description adds no additional meaning beyond the schema, such as format constraints or examples, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('Organization for your Geomi account'), making the purpose unambiguous. It distinguishes from siblings like 'create_geomi_organization' by specifying it's an update operation, though it doesn't explicitly contrast with other update tools (e.g., 'update_geomi_api_key').
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 organization), exclusions, or comparisons with sibling tools like 'create_geomi_organization' or other update operations, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions retrieval by exact filename but doesn't disclose behavioral aspects like error handling (e.g., what happens if filename doesn't exist), response format, authentication needs, or rate limits. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and every part contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too minimal. It doesn't explain what the retrieved resource contains, how it's formatted, or potential errors. Given the complexity of retrieving development resources, more context about the return value and usage constraints would be beneficial.
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 'filename' well-documented in the schema. The description adds minimal value by reinforcing the exact filename requirement and providing examples, but doesn't go beyond what the schema already specifies. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and the resource 'Aptos development resource', specifying it's by exact filename without .md extension. It distinguishes from the sibling 'list_aptos_resources' by focusing on a single resource rather than listing, though it doesn't explicitly name that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need a specific resource by filename, but doesn't provide explicit guidance on when to use this versus alternatives like 'list_aptos_resources' or other sibling tools. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool 'returns all resources from move and management directories,' which hints at output behavior, but lacks details on permissions, rate limits, or side effects. For a tool with no annotations, this is insufficient to fully understand its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and followed by usage guidance. It avoids redundancy and is efficiently structured, though it could be slightly more precise in differentiating from siblings.
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 no parameters, no annotations, and no output schema, the description provides basic purpose and usage but lacks depth. It doesn't explain what 'returns all resources' entails or potential errors, making it incomplete for a tool that might involve complex operations like smart contract building.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, earning a baseline score of 4 for not introducing unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'builds an Aptos smart contract' and mentions it 'returns all resources from move and management directories,' which gives a vague purpose. However, it doesn't clearly differentiate from sibling tools like 'build_dapp_on_aptos' or 'build_dapp_on_aptos_guidance_prompt,' leaving ambiguity about its specific role.
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?
It explicitly states 'Use this tool when you need guidance on how to build a smart contract for a dapp on Aptos,' providing clear context for when to use it. However, it doesn't specify when not to use it or mention alternatives among siblings, such as 'build_dapp_on_aptos,' which might overlap in functionality.
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 'returns all resources from frontend directory,' hinting at output behavior, but doesn't disclose critical traits like whether it's read-only, requires authentication, has rate limits, or what 'resources' entail (e.g., files, data). For a tool with zero annotation coverage, this leaves significant gaps in understanding its operation.
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 two sentences, front-loaded with the purpose and followed by usage guidance, with no wasted words. It's appropriately sized for a simple tool, though it could be slightly more specific in the first sentence to enhance clarity without losing 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 0 parameters and no output schema, the description is moderately complete but lacks depth. It states the purpose and usage but misses details on behavioral aspects (e.g., what 'returns all resources' means, any side effects). For a tool with no annotations or output schema, it should provide more context about the return value and operational constraints to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter info, which is acceptable here. Baseline is 4 for 0 parameters, as the schema fully covers the absence of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Build a UI frontend for Aptos dApp' which provides a clear verb ('Build') and resource ('UI frontend for Aptos dApp'), but it's vague about what 'Build' entails—whether it generates code, provides instructions, or something else. It doesn't distinguish from siblings like 'build_dapp_on_aptos' or 'build_smart_contract_on_aptos', leaving ambiguity in scope.
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 explicitly says 'Use this tool when you need guidance on how to build a frontend for a dapp on Aptos,' providing clear context for when to use it. However, it doesn't specify when not to use it or mention alternatives like 'build_dapp_on_aptos' for broader dApp development, which could help differentiate usage scenarios.
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 API Keys are secret and should be kept secure, which is useful behavioral context. However, it doesn't mention authentication requirements, rate limits, pagination, or what happens if no organizations exist. The security warning adds value but leaves other behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with some redundancy (e.g., mentioning Geomi twice in the first sentence). The first sentence clearly states the purpose, but the second sentence about Geomi being an 'essential toolkit' is promotional rather than functional. The last two sentences about filtering are useful but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0 parameters, the description provides adequate context about what data is retrieved and how to interpret it. However, it lacks details on return format (e.g., structure of organizations/projects/applications), error conditions, or authentication needs, leaving gaps for a tool that handles sensitive API keys.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose and usage. This meets the baseline for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Geomi Organizations along with their projects, applications, and API Keys. It specifies the resource ('Geomi Organizations') and the associated data, but doesn't explicitly differentiate from sibling tools like 'get_specific_aptos_resource' or 'list_aptos_resources' that might also retrieve Geomi-related data.
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 implied usage guidance by explaining how to filter results for specific API key types (full node vs. gas station), but doesn't explicitly state when to use this tool versus alternatives like 'get_specific_aptos_resource' or other Geomi-related tools. No explicit exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool is a 'prompt' and for 'reinforcing habits', but doesn't disclose key behaviors: what the prompt outputs (e.g., a reminder message), whether it's read-only or has side effects, or any rate limits. This leaves the agent uncertain about the tool's actual behavior upon invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and usage guidelines without any fluff. It's front-loaded with the key concept ('MID-DEVELOPMENT REMINDER') and every word adds value, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description adequately covers usage context. However, it lacks details on what the prompt actually does (e.g., output format or effect), which is a gap since there are no annotations or output schema to fill in behavioral aspects. For a zero-parameter tool, it's minimally complete but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description correctly avoids discussing parameters, focusing instead on usage context. A baseline of 4 is appropriate since no parameters exist to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is a 'MID-DEVELOPMENT REMINDER' prompt to 'reinforce MCP consultation habits', which clarifies its purpose as a behavioral nudge rather than a functional tool. However, it's vague about what the prompt actually does—does it output text, trigger an action, or something else? It distinguishes from siblings by focusing on reminders, but lacks specificity about the mechanism.
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: 'when you notice the conversation has gone few exchanges without using MCP tools, or when implementing new Aptos features'. This provides clear, actionable context for invocation, distinguishing it from alternatives like debugging or building tools. No exclusions are mentioned, but the guidance is sufficient for decision-making.
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 the tool 'returns all resources from move, management, and frontend directories,' which hints at read-only behavior, but doesn't clarify if this is a generative, instructional, or retrieval tool. It lacks details on permissions, rate limits, or what 'guidance' entails (e.g., step-by-step instructions vs. code snippets).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose and output, the second provides usage guidance. It's front-loaded with the core functionality and efficiently structured without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (building a full-stack dApp) and lack of annotations or output schema, the description is adequate but incomplete. It explains what the tool does and when to use it, but doesn't detail the format or depth of the returned 'guidance' or resources, which could leave the agent uncertain about behavioral outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and usage. This meets the baseline for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Build a complete full-stack Aptos dApp' with the specific action of returning resources from move, management, and frontend directories. It distinguishes from siblings like 'build_smart_contract_on_aptos' and 'build_ui_frontend_on_aptos' by emphasizing 'complete full-stack' coverage, though it doesn't explicitly name these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/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 it: 'when you need guidance on how to build a full-stack dapp on Aptos.' This gives clear context for usage, but it doesn't specify when NOT to use it or detail alternatives beyond the implied scope difference from 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?
No annotations are provided, so the description carries full burden. It discloses the core behavior (returning version information) but doesn't mention any behavioral traits like whether it requires authentication, has rate limits, returns structured data, or has side effects. For a simple read-only tool with no parameters, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential information immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool with no output schema, the description provides complete enough context about what it does. However, it doesn't specify the return format (e.g., string, object) or any metadata, which could be helpful given the lack of output schema. The simplicity of the tool makes the description largely sufficient.
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. The description doesn't need to add parameter information beyond what the schema already provides (no parameters). This meets the baseline of 4 for zero-parameter tools, as no compensation is needed.
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 ('Returns') and resource ('version of the MCP server'), making the tool's purpose immediately understandable. It distinguishes itself from all sibling tools, which are focused on Aptos/Geomi development tasks, by being a meta-tool about the server itself.
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 (when you need to know the server version), but doesn't explicitly state when to use it versus alternatives or provide any exclusions. Given that it's a unique meta-tool among development-focused siblings, some implicit guidance exists, but no explicit alternatives or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 behavioral traits: it's a prompt tool for error recovery that redirects to an MCP-first approach, implying it guides rather than executes actions. However, it lacks details on what the prompt contains, how it redirects, or any constraints like rate limits or permissions. This is adequate but leaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: it's a single sentence that front-loads key information ('ERROR RECOVERY PROMPT') and efficiently lists usage scenarios. Every word earns its place, with no wasted text, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (simple prompt with no parameters), no annotations, no output schema, and rich usage guidelines, the description is fairly complete. It covers purpose and usage well but lacks details on what the prompt outputs or how the MCP-first approach works. For a zero-parameter tool, this is sufficient, though not exhaustive.
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 parameters need documentation. The description doesn't add parameter semantics, which is acceptable here. A baseline of 4 is appropriate as it doesn't need to compensate for any parameter gaps, but it doesn't exceed expectations by providing extra context.
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 as an 'ERROR RECOVERY PROMPT' for Aptos-related errors, stuck debugging loops, or when about to try generic blockchain solutions, with a specific action to 'redirect to MCP-first debugging approach.' It distinguishes from siblings by focusing on error recovery rather than development, building, or resource management. However, it doesn't specify the exact verb or resource beyond 'prompt,' making it slightly less specific than a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'Use this immediately when encountering Aptos-related errors, stuck in debugging loops, or when about to try generic blockchain solutions.' It clearly states when to use the tool (in error scenarios) and implies when not to use it (in non-error or non-Aptos contexts), effectively distinguishing it from sibling tools that handle development, building, or resource operations.
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 behavioral traits: it 'Sets up mandatory MCP consultation workflow' (implying it enforces a specific process) and 'prevents outdated knowledge usage' (indicating it controls information recency). However, it doesn't detail execution mechanics, side effects, or response format, leaving gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: a single sentence with two clauses that efficiently convey purpose and key behaviors. Every part earns its place, with no redundant information, making it easy to parse and understand quickly.
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 prompt with no parameters and no output schema), the description is reasonably complete. It explains the tool's role and key behaviors. However, without annotations or output schema, it could benefit from more detail on what the prompt contains or how it's applied, slightly limiting completeness.
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. The description doesn't need to explain parameters, so it meets the baseline. It adds no parameter semantics, but that's acceptable given the lack of parameters, warranting a score above the minimum.
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 what the tool does: 'Use this as the main system prompt when building any Aptos dApp.' It specifies a verb ('use') and resource ('main system prompt'), and distinguishes its purpose from siblings by focusing on dApp building guidance. However, it doesn't fully differentiate from similar prompt tools like 'aptos_development_reminder_prompt'.
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: 'when building any Aptos dApp' specifies the context, and 'Sets up mandatory MCP consultation workflow and prevents outdated knowledge usage' explains when to use it. It implicitly distinguishes from other tools by being the 'primary prompt' for dApp building, though it doesn't name specific alternatives.
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 implies this is a read-only operation ('Get a list'), which is consistent with a listing tool, but doesn't disclose behavioral traits like rate limits, authentication needs, or pagination. The description adds some context about the workflow but lacks details on how the list is returned or any constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured in two sentences. The first sentence states the purpose, and the second provides usage guidelines. Every sentence earns its place with no wasted words, making it easy to understand quickly.
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 (0 parameters, no output schema, no annotations), the description is reasonably complete. It explains the purpose and usage, which is sufficient for a simple listing tool. However, it could be more complete by mentioning the format of the returned list or any limitations, but the absence of an output schema doesn't heavily penalize this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but this is acceptable as there are no parameters. A baseline of 4 is appropriate since the schema fully covers the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a list of all available Aptos development resources.' It uses a specific verb ('Get') and resource ('Aptos development resources'), making the intent unambiguous. However, it doesn't explicitly differentiate from all sibling tools, though it mentions one sibling (get_specific_aptos_resource).
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: 'Use this first to see what guidance is available, then use get_specific_aptos_resource to fetch the relevant one.' This clearly indicates when to use this tool (first, for listing) versus an alternative (get_specific_aptos_resource, for fetching specific resources), establishing a workflow.
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:

[![aptos-npm-mcp MCP server](https://glama.ai/mcp/servers/aptos-labs/aptos-npm-mcp/badges/card.svg)](https://glama.ai/mcp/servers/aptos-labs/aptos-npm-mcp)

Score Badge

Copy to your README.md:

[![aptos-npm-mcp MCP server](https://glama.ai/mcp/servers/aptos-labs/aptos-npm-mcp/badges/score.svg)](https://glama.ai/mcp/servers/aptos-labs/aptos-npm-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aptos-labs/aptos-npm-mcp'

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