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

Annotations declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with the key admission that the tool "opens nothing by itself" and only returns instructions. That is genuinely useful context beyond the annotations, and it also sketches the return shape (screens, buttons, fields). Minor deduction because the API-key/email remark is tangential and adds no behavioral clarity.

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 core behavior is front-loaded, which is good, but the second sentence is long and runs together three separate ideas with semicolons. The closing paragraph quoting Virtuagym's API email and a future "checked 9 Nov 2026" date does not help an agent select or invoke the tool.

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?

With no params and no output schema, the description must carry the burden of explaining what comes back and what the agent should do next, and it mostly does. But it never addresses a significant gap: with zero parameters, the member identity and note content must come from conversation, and the description gives no guidance on that dependency.

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 tool takes zero parameters and the schema has nothing to document, so the baseline applies. The description does not need to explain parameters, and it does not waste space doing so.

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 states a specific verb and resource ("Add member note in the user's own Virtuagym account") and then immediately clarifies the real behavior: it "Returns how to do it in Virtuagym step by step (screens, buttons, fields) and opens nothing by itself." This resolves the ambiguity in the name, though it does not contrast itself against siblings like virtuagym_add_lead or cotlet_app_guide.

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?

It gives a clear follow-on path ("then do it with the cotlet_browser_* tools in the user's Virtuagym Cloud Browser"), so the agent knows the next step. However, it never states the trigger condition (e.g., when the user asks to leave a note on a member) or when to prefer a sibling such as cotlet_app_guide. Usage is implied rather than explicit.

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