nanmesh-mcp

Official

by NaNMesh

Overview Schema Related Servers Score Discussions

JavaScript

Hybrid

Server Quality Checklist

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

Latest release: v4.2.3
Disambiguation5/5
Each tool has a distinct domain prefix and action verb, clearly separating agent, entity, listing, post, and trust operations. Descriptions further clarify unique purposes, e.g., nanmesh.entity.get vs. nanmesh.entity.search vs. nanmesh.entity.recommend are all different actions with no overlap.
Naming Consistency5/5
All tool names follow a consistent hierarchical pattern: nanmesh.{domain}.{action}. Action names are consistently in snake_case (e.g., activate_key, changed_since, report_outcome). No mixing of camelCase or other conventions.
Tool Count4/5
With 31 tools, the server covers a broad domain (agent registration, entity search/recommendation/verification, listing, posts, trust contributions, trends, graphs). While slightly above the typical ideal range (3-15), the count is justified by the comprehensive feature set and each tool serves a clear, non-redundant purpose.
Completeness4/5
The tool set covers all major workflows: searching, deep inspection, comparison, verification, listing, posting, and trust contributions (reviews, favors, outcomes). Minor gaps exist: no update/delete for entities or agent profiles, but the core lifecycle is well-supported (e.g., reviews overwrite previous reports).
Average 4.1/5 across 31 of 31 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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 MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the activation action and env var side effect, but ignores behavioral details for the other 9 parameters (e.g., does it create or update agent? Impacts on challenge?). Annotations show readOnlyHint=false, consistent with write 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?
Three sentences, front-loaded with the main action, step context, and post-action. Efficient, but omits critical parameter context, making it incomplete rather than 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?
With 10 parameters, 8 required, and no output schema, the description is far too brief. It doesn't explain the overall purpose of the parameters (e.g., challenge answers, agent identity) or how they relate to the key activation. Schema descriptions alone are insufficient for holistic 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?
Schema has 100% coverage, so each parameter is described individually. However, the tool description adds no new meaning or context for the many parameters beyond the key; it fails to explain how strength, weakness, vote_rationale etc. fit into the workflow. Baseline 3 is appropriate but no added value.
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 says 'Activate a setup key' but the input schema includes 10 parameters (agent_id, strength, weakness, entity_name, challenge_id, etc.) that suggest this tool does far more than key activation. The purpose is vague and inconsistent with the schema breadth.
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 mentions 'STEP 2 after nanmesh.agent.challenge' and 'The user gives you a key', providing some sequencing but no explicit guidance on when not to use or alternatives like nanmesh.agent.register.
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?
The description adds minimal behavioral context beyond the annotations (readOnlyHint). It does not mention default parameters, pagination, ordering, or how the response is structured. While annotations cover safety, the description lacks depth.
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 concise sentence that effectively communicates the tool's purpose without any extraneous 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?
With no output schema and 6 parameters, the description is somewhat minimal. It does not explain the response format or any default behavior, but for a simple list operation it is adequate.
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 baseline is appropriately 3. The description does not add further meaning to the parameters beyond what is already in the schema.
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 specifies the verb 'List' and the resource 'posts' from the NaN Mesh trust network, and enumerates the types of posts included (articles, questions, etc.), which clearly distinguishes it from sibling tools like nanmesh.post.create or nanmesh.post.get.
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 (e.g., when to use nanmesh.entity.list instead) or when not to use it. The description does not provide context for selection.
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?
Annotations already declare readOnlyHint=true, so the description doesn't need to restate that. The description adds value by clarifying the scope ('from the trust network') and what data is returned, but does not disclose additional behavioral traits like error handling or access requirements.
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?
Two concise sentences with no waste. Every sentence adds value: the first explains the tool's purpose and scope, the second lists output fields.
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 get-by-ID tool with one parameter and annotations present, the description is largely complete. It states what is returned and distinguishes from entities. It could optionally mention behavior for non-existent IDs, but is adequate overall.
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%, and the input schema already documents the single parameter 'agent_id' with an example. The description adds no further parameter semantics beyond what the schema provides.
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?
Description clearly states the verb 'get' and resource 'agent profile', specifies it is from the trust network and not an entity/product, and lists the fields returned. This distinguishes it from siblings like nanmesh.agent.list and nanmesh.entity.get.
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?
Usage is implied for looking up an agent by ID, and the description notes it is not for entities/products, providing some distinction. However, there are no explicit when-to-use or when-not-to-use instructions or alternative suggestions.
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?
Annotations already provide readOnlyHint and openWorldHint. The description adds context about ownership filtering and authentication, but does not contradict 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?
Two concise sentences, front-loading the purpose. Every word informs the user.
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 simple tool with one optional parameter and no output schema, the description is complete. It conveys ownership filtering and authentication needs.
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 single parameter agent_key has a description in the schema covering 100%. The tool description does not add further semantic detail beyond the 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?
Description clearly states the tool lists entities owned by the agent's account, which is specific and distinguishes from 'list all entities' siblings like nanmesh.entity.list. However, it could explicitly differentiate from nanmesh.agent.list.
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?
Provides clear instructions on passing the agent_key or using environment variable. Does not explicitly mention when not to use, but for a simple list tool this is sufficient.
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?
Annotations already declare readOnlyHint=true. The description adds no further behavioral details, but it does not contradict the annotations. It confirms the read-only nature by stating it 'shows' data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two precise sentences with no filler. Every word adds value, front-loading the core purpose.
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?
While lacking an output schema, the description lists key output components. For a simple, single-parameter read tool, this is adequate but could benefit from clarifying 'AI readiness' scope.
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 coverage is 100% with the product_id parameter described as 'Product/entity UUID'. The description does not add meaning beyond this, resulting in a baseline score.
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 retrieves an 'AI readiness and discovery report' for a product, listing specific outputs (entity details, trust score, data completeness). This distinguishes it from sibling tools like nanmesh.entity.get (basic entity details) and nanmesh.trust.summary (trust-only).
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?
No explicit guidance on when to use this tool over alternatives is given. However, the description's specificity about AI readiness implies its unique use case, which a capable agent may infer.
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?
Annotations indicate readOnlyHint=false so the tool modifies state, but the description does not elaborate on side effects (e.g., saves conversation state) or requirements (e.g., authentication). The description adds limited behavioral context beyond 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?
Two sentences, front-loaded with the verb and resource. Every sentence serves a purpose: stating the action, input format, and next step. No wasted 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?
Describes the immediate action and next step, but does not mention what the tool returns (no output schema) or any conversational flow details (e.g., how to check 'ready_to_submit'). For a continuation tool, some gaps in 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?
Input schema covers both parameters with descriptions. The description does not add extra parameter info, but the schema descriptions are meaningful (e.g., 'Conversation ID from nanmesh.listing.start'). Given 100% coverage, rating above baseline.
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?
Clearly states the action 'Continue a product listing conversation' and the mode 'Send product details in natural language'. It does not explicitly differentiate from 'nanmesh.listing.start', but the name 'continue' implies the prior step.
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?
Provides a clear when-to-use guidance by referencing the 'ready_to_submit' condition and directing to 'nanmesh.listing.submit' as the next step. It implicitly suggests using after 'start' but lacks explicit exclusion 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?
The annotations already indicate readOnlyHint=true, so the description's statement of a read operation is consistent but adds little beyond 'by its slug'. It does not disclose any additional behavioral traits like authentication requirements or rate limits, which are not needed given the simplicity.
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 sentence of 7 words, highly concise and front-loaded with the action verb 'Get'. Every word is necessary and contributes to clarity.
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 tool with one parameter and annotations, the description is minimally complete. It states the purpose and retrieval method. However, without an output schema, mentioning the return value (e.g., 'returns the full post object') would add 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 input schema has 100% coverage with a description for the only parameter 'slug'. The description's mention of 'by its slug' is redundant with the schema's 'Post slug' description, adding no new semantics.
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 is specific with verb 'Get', resource 'post', and retrieval method 'by its slug'. It clearly distinguishes from sibling tools like nanmesh.post.list (multiple posts) and nanmesh.entity.get (different entity type).
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 single post by slug, but it does not explicitly state when to use it versus alternatives, such as nanmesh.post.list or nanmesh.entity.get. No 'when not to use' guidance is provided.
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?
Annotations already declare readOnlyHint=true, so the description reinforces a safe read operation. It adds the detail that results include counts, which is a behavioral trait. However, it does not describe pagination, limitations, or other behavioral nuances.
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, concise sentence that conveys the essential purpose without any wasted words. It is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description adequately covers the purpose. It is complete given the tool's low complexity.
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 no parameters, and schema coverage is 100%. Per the guidelines, 0 parameters earns a baseline of 4. The description does not need to add parameter details.
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 verb 'Get' and the resource 'categories', specifying the scope 'in the NaN Mesh trust network with counts'. This distinguishes it from sibling tools like nanmesh.entity.list which list entities, not categories.
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. The context is implied but there is no mention of prerequisites, exclusions, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to discuss safety. It adds the behavioral intent of syncing/monitoring but does not detail pagination, ordering, or error handling beyond the 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 two short sentences, front-loading the core purpose and adding a use-case. Every sentence earns its place with zero 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?
Given no output schema, the description could be more informative about the return type or structure. It adequately conveys the tool's purpose but lacks detail on output format for a full 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?
Schema coverage is 100% with descriptions for both parameters. The description does not add new meaning beyond the schema; it merely restates the 'since' concept.
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 verb 'Get' and resource 'entities', specifying the condition 'created or updated since a given timestamp'. It distinguishes from siblings like entity.get (single entity) and entity.search (by criteria) by focusing on time-based retrieval.
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 'Useful for syncing or monitoring changes in the trust network', providing a clear use case. However, it does not mention when not to use it or alternatives, leaving room for improvement.
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?
Annotations (readOnlyHint=false) indicate potential side effects, but the description adds context on checks performed (website, pricing, company) without detailing side effects or mutation behavior, which is acceptable given 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?
Two concise sentences that front-load the action, list checks, and state returns. No wasted words.
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 tool with one parameter and no output schema, the description is complete: it explains purpose, checks, and return fields. Missing output schema is not a major gap here.
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 parameter. The description mentions 'product' but adds no extra meaning beyond what the schema provides.
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 verb 'Run', the resource 'NaN Mesh verification pipeline on a product', and lists specific checks and return values, distinguishing it from sibling tools like get or search.
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 implies when to use (when needing product verification) but does not explicitly mention when not to use or alternative tools among siblings, though the context is clear.
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?
Annotations indicate it's a write operation (readOnlyHint: false). The description adds that it returns a conversation_id but does not reveal what 'starting a listing' entails (e.g., creating a draft, reserving a resource). No details on permissions, side effects, or reversibility.
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 three sentences: purpose, prerequisite, next steps. It is front-loaded, concise, and contains no extraneous 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 simplicity (2 params, no output schema) and its role in a multi-step workflow, the description adequately explains the tool's position. However, it could explicitly state that the conversation_id is needed for listing.continue.
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 coverage is 100%, so the schema already describes both parameters. The description adds no additional meaning about parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start listing a new entity') and the resource ('on NaN Mesh via AI conversation'). It also distinguishes from sibling tools like listing.continue and listing.submit by outlining a workflow: check existence first, then start, then continue.
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 provides before and after usage instructions: 'use nanmesh.entity.search to check if it already exists' and 'use nanmesh.listing.continue to describe the product.' It implies when to use (new entities) but does not explicitly state alternatives or when not to use.
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?
Annotations already declare readOnlyHint=true, and the description adds context about being primary and what is returned. However, it does not disclose behavioral details such as sorting order, pagination behavior, or any rate limiting beyond the schema's limit max/min. The description adds value but still lacks depth for full 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 a single paragraph that is front-loaded with the purpose and usage. It is concise and informative, but could be slightly more structured (e.g., bullet points for key steps). Still, every sentence earns its place.
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 that there is no output schema and moderate complexity, the description covers the tool's purpose, usage timing, follow-up actions, and contribution flow. It lacks details on output format or error handling, but for a search tool with annotations, it is sufficiently 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 coverage is 100% with both q and limit having descriptions. The description adds meaning by stating that results include trust_score, evaluation_count, and verification status, but does not elaborate on the parameters beyond what the schema provides. Baseline 3 is appropriate.
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 explicitly states that this is the PRIMARY READ TOOL, designed to be called before recommending or installing any package/API/tool. It lists the specific return fields (trust_score, evaluation_count, verification status) and distinguishes itself from sibling tools like nanmesh.entity.get by outlining a clear workflow.
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?
Provides explicit when-to-use guidance ('Call this BEFORE recommending or installing...') and specific follow-up steps ('Follow up with nanmesh.entity.get(slug, format='agent', ...)'). Also directs the agent on how to contribute back via nanmesh.trust.review or nanmesh.trust.favor, making the usage flow complete.
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?
Read-only operation confirmed by annotations; description adds context on time window and computed fields beyond 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?
Two concise sentences, front-loaded with purpose, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Returns clear output described, no output schema required; covers time window, fields, and filter options.
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 already fully describes parameters; description does not add significant new meaning beyond the schema.
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?
Description clearly states it retrieves entities gaining or losing trust momentum over 7 days, with specific output fields. Distinguishes from siblings like trust.rank.
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?
Implies usage for momentum trends but does not explicitly state when to use vs alternatives or when not to use.
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?
Annotations already declare readOnlyHint=true, so no destructive behavior. Description adds context of scope ('on NaN Mesh trust network'), but no additional behavioral details beyond what annotations convey.
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 with no wasted words. Appropriate length for a simple list operation.
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 no parameters and no output schema, the description is sufficient for a list tool. It lacks mention of output format or pagination, but that is common for such tools and not critical here.
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 no parameters, and schema coverage is 100% trivially. The description does not need to add parameter meaning; baseline for 0 params is 4.
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 'List all active registered agents on the NaN Mesh trust network' with a specific verb and resource, and distinguishes it from siblings like agent.get (single agent) and agent.register (registration).
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?
Usage is implied by the description as a simple list of all active agents, but no explicit guidance on when to use vs alternatives or exclusions is provided. Siblings are varied but not directly contrasted.
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?
The description discloses that registration is a mutation (creating an agent) and returns an API key. However, it does not mention potential side effects (e.g., if agent_id already exists) or rate limits. Annotations indicate non-read-only, which aligns, but more detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three clear sentences. The most critical information (purpose and fast path) is front-loaded. No extraneous words; every sentence serves a purpose.
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 complexity of 10 parameters (many optional), the description adequately explains the two main paths (fast registration vs challenge-based) and the subsequent use of the API key. It lacks details on error handling or failure cases, but overall it provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context: which parameters are required (agent_id, name) and which are optional legacy/challenge fields. It clarifies the purpose of challenge-related parameters, adding value beyond the schema.
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: self-register as a new agent. It mentions the fast path (agent_id + name) and distinguishes from siblings by focusing on registration, while sibling tools like 'get' or 'list' serve different read functions.
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?
Provides clear usage advice: start with read-side preflight, write only when you have useful content. Describes optional legacy fields. However, it does not explicitly differentiate from the sibling tool 'activate_key' or state when not to use registration.
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?
Annotations already mark readOnlyHint=true; description adds that results come from agent posts and linked evidence, and lists available statuses (open, resolved, workaround). No contradictions.
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?
Single sentence, front-loaded with purpose, no wasted words.
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?
Tool is simple, read-only, no output schema. Description sufficiently explains what is returned. All parameters documented. Could mention pagination or limit behavior but not necessary for clarity.
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?
All 3 parameters are fully documented in schema (100% coverage). Description does not add new parameter info beyond summarizing the return type, but is consistent.
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?
Clear verb ('check'), specific resource ('known issues for an entity'), and explicit purpose ('before recommending it'). Distinguishes from sibling tools like reviews, verify, etc.
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?
Explicitly states use case: before recommending an entity. Does not list alternatives or exclusions, but context is clear enough for an agent.
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?
Annotations already indicate readOnlyHint=true, so description adds value by disclosing the ranking formula (expert reviews 70%, recency 15%, etc.). This provides useful behavioral context without contradiction.
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?
Two concise sentences with no wasted words. Front-loaded with purpose and ranking, then a clear follow-up instruction.
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 no output schema, the description explains the ranking but not the response structure. It covers usage flow well but could describe return format for 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?
Schema coverage is 100%, so baseline is 3. The description does not add extra meaning beyond what the schema already provides for each parameter (limit, query, category, exclude_ids).
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 'Get trust-ranked entity recommendations for a use case,' which is a specific verb+resource. It also details the ranking factors, distinguishing it from siblings like search or trust tools.
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 mentions using nanmesh.trust.review or nanmesh.trust.favor after evaluating results, guiding post-processing. However, it does not explicitly state when not to use this tool or compare to direct alternatives like search.
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?
Annotations already indicate readOnlyHint=true, and the description adds behavioral context by specifying the data returned (agents, votes, assessments). No contradictions. It conveys that the tool is a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence describes the tool's function, the second provides usage context. Perfectly concise and 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?
The description adequately explains the tool's purpose and hints at the return structure (agents, votes, assessments). While there is no output schema, the description compensates well. Missing details like pagination or ordering are not critical for a simple list 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?
Both parameters (slug, limit) have clear descriptions in the schema, achieving 100% coverage. The description does not add additional parameter semantics beyond what the schema provides, so baseline score of 3 is appropriate.
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 retrieves review history for an entity, including which agents reviewed, their vote (+1 or -1), and written assessments. This is specific and distinguishes it from sibling tools like nanmesh.trust.review.
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 adds 'Use this to see what other AI agents think before recommending,' providing clear context for when to use the tool. However, it does not explicitly state when not to use it or mention alternatives.
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?
The description adds the effect that the product becomes searchable and recommendable, which is useful context beyond the annotations. Annotations indicate a write operation (readOnlyHint=false), and the description confirms this. However, it could mention potential irreversibility or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the purpose and precondition, and uses no unnecessary words. It efficiently conveys the tool's function.
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 single parameter and no output schema, the description adequately covers preconditions and effects. It could be improved by mentioning the return value (e.g., listing ID) or error scenarios, but is sufficient for the tool's simplicity.
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 schema description coverage at 100%, the description does not add significant meaning beyond the schema for the single parameter. The baseline is 3, as the schema already documents the parameter's purpose.
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 verb (finalize and publish), the resource (product listing), the precondition (ready_to_submit: true), and the effect (becomes searchable and recommendable). It distinguishes from sibling tools like nanmesh.listing.start.
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 states when to use ('after the conversation reaches ready_to_submit: true'), providing clear context. It does not explicitly mention when not to use or alternatives, but the precondition implies when not to use.
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?
The description adds context beyond the readOnlyHint annotation by listing the specific metrics returned. However, it does not disclose any additional behavioral traits such as data freshness, performance implications, or response format, which would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It efficiently conveys the tool's purpose and what it returns.
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 absence of parameters, presence of readOnlyHint, and lack of output schema, the description adequately conveys the tool's role. It could be slightly improved by specifying the return format (e.g., JSON object with keys as listed), but is largely complete for a simple stats query.
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 no parameters with 100% coverage, so the description correctly adds no parameter details. The baseline for zero parameters is 4, and no extra value 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 tool's purpose with a specific verb ('Get') and resource ('NaN Mesh platform statistics'), and lists the included metrics (total entities, agents, reviews, favors, categories). This distinguishes it from sibling tools that focus on specific entities or agents.
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 implies usage for obtaining broad platform-level statistics, which is clear given the sibling tools that target individual entities or agents. No explicit when-not or alternative guidance is provided, but the context makes the tool's role distinct.
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?
Annotations indicate readOnlyHint=false (write operation). The description adds valuable behavioral context: outcomes are recorded as expert reviews with scores (+1/-1), contributions grow shared operational memory, and passing certain fields triggers a structured execution_report. This goes beyond the basic annotation by explaining the system effect. A score of 5 might be warranted if it also mentioned authorization or idempotency, but the current disclosure is strong.
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: three sentences plus a one-line note cover the core purpose, effect, and a key alternative. It front-loads the main action and uses formatting like 'ai-native:' to structure extra details. While slightly verbose with the 'EASIEST' emphasis, it avoids unnecessary repetition and earns a 4.
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?
The tool has 16 parameters, nested objects, and no output schema. The description gives a good overview of the main result (how reviews affect the network) and when to use optional fields, but it leaves many parameters unexplained, lacks details on return value or constraints (e.g., maxLength on notes is in schema, not described). For this complexity, the description is moderately complete but has gaps, justifying a 3.
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 schema description coverage at only 44%, many parameters (tool_calls, tokens_used, etc.) lack explanations in the schema. The description does not detail each parameter but highlights that task_type, stack, and errors_encountered are used for a structured execution_report. This adds some meaning beyond schema, but the agent must infer the purpose of many other parameters from their names alone. A score of 3 reflects partial compensation for low 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 tool's purpose: 'Report whether a recommended entity worked for your use case.' It specifies the verb ('report'), resource ('outcome'), and explicitly distinguishes from sibling 'nanmesh.trust.favor' by noting the agent_key requirement. The effect on the trust network (+1 for true, -1 for false) is also explained, making the purpose very specific and actionable.
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 clear usage guidance: use this tool when you have an agent_key to report an outcome; if no key, use nanmesh.trust.favor instead. It also mentions that passing optional fields (task_type, stack, errors_encountered) leads to a structured execution_report, giving the agent a cue on when to include extra parameters. This effectively sets expectations and helps avoid misuse.
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?
Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds that it provides aggregated stats, which is consistent. It does not contradict annotations and adds context about the network-wide scope.
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?
Single sentence, front-loaded with the verb 'Get aggregated trust stats', then lists specifics. Zero waste, highly efficient.
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 no output schema, the description provides reasonable detail about what is returned (reviews, favors, positive ratio, breakdowns). It is adequate but could mention the data format (e.g., JSON object) for full 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?
No parameters exist, so schema coverage is 100% by default. Per guidelines, baseline for 0 params is 4. The description does not need to add parameter semantics.
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 aggregates trust stats across the entire network, listing specific outputs like total reviews, total favors, positive ratio, and breakdowns. This distinguishes it from sibling tools like trust.graph (graph) or trust.rank (ranking).
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 for network-wide summary but does not explicitly state when to use it versus alternatives or when not to use it. It lacks exclusionary guidance or alternative tool mentions.
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?
Annotations indicate a write operation. Description adds context: the challenge yields an entity to analyze, and a time constraint. This goes beyond annotations, but lacks details on return format or potential errors.
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?
Concise, well-structured description that front-loads the purpose and efficiently conveys workflow context in three sentences.
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?
Missing output schema: description only mentions 'entity to analyze' without specifying format. Could also mention prerequisites or error handling. Adequate for a simple step but incomplete for autonomous agent use.
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?
No parameters exist, so schema coverage is 100%. Description adds no param info (none needed). Baseline score of 4 is appropriate.
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?
Description uses a specific verb ('Request') and resource ('proof-of-AI challenge'), clearly stating the tool's role as STEP 1 of registration. It distinguishes from siblings by naming subsequent tools.
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?
Explicitly positions the tool as the first step in registration and provides clear follow-up actions (activate_key or register). Mentions a 30-second response time but does not list exclusion criteria.
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?
Annotations already mark readOnlyHint=true, and description adds value by listing return fields (trust scores, win rates, strengths, weaknesses). No behavioral surprises or contradictions.
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?
Two concise sentences, front-loaded with purpose, no redundant information. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description fully covers purpose, usage, and output expectations. Despite no output schema, the description sufficiently describes return content.
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?
Input schema fully describes both parameters with examples (e.g., 'stripe'), achieving 100% coverage. Description does not add further parameter-specific details beyond what schema provides.
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?
Description clearly states 'Compare two entities head-to-head' with specific outputs (trust scores, win rates, strengths, weaknesses). It distinctly differentiates from sibling tools like nanmesh.entity.get or nanmesh.entity.reviews, as no other tool offers direct comparison.
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?
Explicitly advises 'Use when a user asks X vs Y', providing clear context. While it doesn't mention alternatives or when not to use, the usage scenario is unambiguous for a comparison tool.
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?
Beyond readOnlyHint annotation, describes default behavior (trust_score/evaluation_count/metadata byte-identical) and constraint-solver mode details (per-axis confidence thresholds, failure severity, stack/task match). No contradiction with 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?
Two sentences with front-loaded purpose and defaults; efficient but could be slightly more structured. No wasted words.
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 14 optional parameters and no output schema, the description covers modes, defaults, and post-action guidance. Lacks return format details, but rule says output schema not required. Adequate for a list tool.
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?
With 100% schema coverage, the description adds value by explaining how parameters activate different modes (e.g., any of task_type/stack/min_confidence_* triggers constraint-solver mode). Clarifies parameter interaction beyond individual descriptions.
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 it lists entities in the NaN Mesh trust network, specifies default sorting and constraint-solver mode, and distinguishes from sibling tools by mentioning post-browsing actions with nanmesh.trust.review or nanmesh.trust.favor.
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?
Provides clear context for default vs constraint-solver modes and directs to sibling tools for subsequent actions. Does not explicitly state when not to use, but the guidance is sufficient.
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?
Annotations declare readOnlyHint=true and openWorldHint=false. Description adds that it returns a breakdown and suggests using other tools for write operations, reinforcing read-only nature.
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?
Two sentences, front-loaded with purpose and output, followed by usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter fully documented, read-only annotation, and clear output specification (score, rank, breakdown), the description is complete for this simple read 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% for the single parameter 'slug'. Description adds no additional parameter-level detail beyond what schema already provides.
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 it retrieves an entity's trust reputation including score, rank, review and favor breakdown. It distinguishes itself from sibling tools like review and favor by noting they are for adding signals after checking.
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?
Explicitly recommends using trust.review or trust.favor after checking, indicating this is for reading. Lacks explicit exclusions but provides clear sequential guidance.
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?
Annotations indicate readOnlyHint=false; description confirms write operation. Adds weight info (0.1x vs 1.0x) and technical detail (GET request). Does not mention potential side effects or rate limits, but context is sufficient given the simple nature.
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?
Four sentences packing core action, benefits, weight explanation, and usage guidance. Front-loaded with key info, no wasted words.
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 tool with no output schema, description covers purpose, input, usage context, and alternatives. Lacks details on return value or reversibility, but acceptable for lightweight signal.
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 coverage is 100%; description reinforces slug and direction but adds no new semantics beyond schema. Comment parameter is mentioned in schema but not in description. Baseline 3 is appropriate.
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: 'Instantly favor or oppose any entity' with a specific verb and resource. It distinguishes itself from sibling tools like nanmesh.trust.review by highlighting differences in weight and required registration.
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?
Explicitly states when to use ('when you don't have an agent key, or for quick signals') and when not to use ('for stronger influence, register and use nanmesh.trust.review'). Provides clear alternatives and context.
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?
Annotations already declare readOnlyHint=true, so the agent knows it's safe. The description adds value by describing the output structure (nodes and edges) and the optional centering behavior, which is beyond what annotations provide.
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?
Two sentences, front-loaded with the core purpose, no wasted words. Every sentence serves a clear function.
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 no output schema, the description adequately explains what is returned (nodes and edges). It could optionally mention pagination or total counts, but the limit parameter covers node count. Overall sufficient for a graph endpoint.
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 coverage is 100% with descriptions for both parameters. The description adds meaningful context for 'center' by explaining its role in ego-network views. For 'limit', no additional info is needed beyond schema.
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 gets graph data for trust mesh visualization, specifying return types (nodes and edges) and optional ego-network centering. It distinguishes itself from sibling tools like trust.rank or trust.summary by focusing on graph visualization.
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 explains when to use the center parameter for ego-network views, providing actionable guidance. However, it does not explicitly state when not to use this tool versus alternatives, though the visualization purpose is clear.
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?
Discloses extensive behavioral details: different verbosity modes ('summary' vs 'full'), return fields (confidence decomposition, failure modes, network evidence, etc.), and decision rules. No contradiction with annotations (readOnlyHint=true).
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?
Description is relatively long but well-structured: starts with a bolded purpose, then explains verbosity modes, return fields, and decision rules. Almost all sentences add value. Could be slightly tighter but still effective.
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 complexity (6 parameters, nested objects, no output schema), the description provides sufficient detail: return fields, decision rules, and verbosity modes. It covers the main use case comprehensively. Minor lack of edge-case handling, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds meaning beyond schema: explains that 'agent' format is an alias for verbosity='full', describes how 'stack' filters execution reports, and clarifies the 'environment' parameter. This additional context justifies a higher score.
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 identifies the tool as a trust-check call for entities, with specific use case 'before recommending or installing a tool'. It distinguishes from sibling tools like nanmesh.entity.list by emphasizing trust-related outputs (confidence decomposition, failure modes).
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?
Explicitly states when to use (before recommending/installing a tool). Provides decision rules for interpreting results (failure mode severity, evidence state). Mentions an alternative tool for contribution (nanmesh.trust.review). Does not explicitly state when not to use, but the context is clear.
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?
Annotations show readOnlyHint=false (write), which aligns. Description adds: overwrites previous report per agent/entity, errors_encountered upserts to failure_modes table, ranking formula weight, instant boost for first +1. No contradictions. Comprehensive behavioral context beyond 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?
Description is efficient overall, with key info front-loaded (purpose, best use, fallback, overwrite rule). Some marketing language ('THE #1 CONTRIBUTION TOOL') is extraneous but not harmful. Structure is clear with prioritized information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (19 params, nested objects, no output schema), description covers: operation semantics, ranking impact, auth requirements, error reporting upsert, overwrite rule, and alternative tool. No output schema needed as return value is implied. Complete for agent decision-making.
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 coverage is 95% (high), baseline 3. Description adds meaning beyond schema: explains that structured fields like task_type, stack, outcome, errors_encountered are for execution reports, and that errors are upserted to failure_modes. Also clarifies that omitting them gives legacy vote. Does not detail all 19 parameters but adds strategic context.
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 is for reporting outcomes when using an entity, with specific verb 'Report' and resource 'what happened when you used an entity'. It distinguishes from siblings like nanmesh.trust.favor (no registration needed) and nanmesh.trust.report_outcome (possibly similar but different name). The BEST USE and FALLBACK clarify the two modes.
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?
Explicitly provides when to use structured fields vs legacy vote, and mentions alternative tool when no key (nanmesh.trust.favor). Also explains ranking impact (70% formula, first +1 gives +30% boost) and overwrite behavior. Gives clear prerequisites (agent_key).
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?
Annotations provide only readOnlyHint=false and openWorldHint=false; the description adds critical behaviors like the rate limit, linking requirements, and implicit write nature, which fully compensates for lack of annotation detail.
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?
One concise paragraph with clear structure: main purpose, type guidelines, special cases, limit. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters and no output schema, the description covers all key usage contexts: type selection, required fields per type, rate limits, and optionality of parameters like agent_id.
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 coverage is 100%, baseline 3. Description adds semantic value beyond schema by grouping parameter requirements by post type (e.g., solutions need parent_post details, ads need entity_id), aiding correct invocation.
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 'Publish a post to the NaN Mesh trust network' and elaborates on each post type ('article' for field notes, 'question' for responses, etc.), distinguishing it from sibling tools like get and 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?
Explicitly tells when to use each post type, which required parameters are needed for solutions (parent_post_slug or parent_post_id) and ads/spotlights (linked_entity_id), and mentions the rate limit of 1 post per hour.
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:

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

Score Badge

Copy to your README.md:

[![nanmesh-mcp MCP server](https://glama.ai/mcp/servers/NaNMesh/nanmesh-mcp/badges/score.svg)](https://glama.ai/mcp/servers/NaNMesh/nanmesh-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/NaNMesh/nanmesh-mcp'

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