Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the description reinforces this by calling the profile 'public' and noting that it is 'ledger-derived,' which adds context about data provenance and trustworthiness. However, it does not disclose other behavioral traits such as error handling, response format, or whether the profile can be empty. It adds some value beyond the annotation, matching a baseline of behavior disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that packs meaningful information about the tool's output, with a dash adding a clear list of contents. Every part earns its place; there is no fluff or repetition. It is also front-loaded with the core noun phrase 'A node's public MeshVibe profile.'

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple read-only tool with one parameter and no output schema, so the description covers the main idea well. However, it omits any explanation of the 'handle' parameter and does not give usage context or sibling differentiation, which leaves some gaps. For a tool of this simplicity, the description is adequate but not complete enough to fully guide an agent without prior knowledge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one parameter, 'handle', with no description (0% schema description coverage). The description does not mention or explain this parameter at all, leaving the agent to guess what 'handle' refers to or how to format it. Since the schema provides no help and the description offers no compensation, the parameter semantics are critically underspecified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource (a node's public MeshVibe profile) and enumerates its contents (sells, reliability, followers, regulars, earnings), making the tool's purpose evident. It lacks an explicit verb like 'get' or 'fetch,' but the noun-phrase format still conveys a retrieval/read operation. It is specific enough to distinguish from sibling discovery tools, though it does not explicitly contrast with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as mesh_discover or mesh_follow. There is no mention of prerequisites, context, or exclusions. The sole sentence simply states what the profile contains, leaving the agent without direction on selecting this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.