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

The annotations already establish readOnlyHint=true and destructiveHint=false, so safety need not be restated. The description adds real value beyond them: it discloses the permission-scoping behavior of the entire API surface and the underlying implementation path (GET /civicrm/authx/id, then APIv4 Contact.get), which explains latency and the openWorldHint. It could say more about failure modes when the key is unauthenticated or expired.

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 identifying information is front-loaded in the first clause, and the permission-scoping note is a genuinely useful second sentence. The trailing implementation path is slightly technical, but it is short enough not to bury the payload.

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?

There is no output schema, so the description has to carry the return values itself, and it does so by naming the returned fields. It gives a complete picture for a zero-parameter read tool, though it does not specify the shape or type of the 'how it authenticated' value, leaving a small gap.

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, so the baseline is 4; there is no parameter surface the description could explain. Nothing in the description contradicts the empty input schema.

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 concrete resource — the CiviCRM contact the API key belongs to — and enumerates the identifying fields returned (contact id, display name, contact type), which sets it apart from civicrm_get_contact, which needs an id supplied by the caller. What is missing is an explicit statement that this is the zero-argument identity lookup versus that sibling, so differentiation is implied rather than stated.

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 points toward the use case by saying everything else is limited to that contact's permissions, which implies calling this first to establish scope. However, it never explicitly says when to use this instead of civicrm_get_contact or how to handle the case where the agent already knows the contact id, so routing is left to inference.

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