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

Annotations already declare readOnlyHint=true, so the safety profile is covered, and "Fetch" is consistent with a read-only operation. The description adds the concrete payload shape an agent can expect, but says nothing about not-found/error behavior, permissions required, or any rate limits.

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?

One front-loaded sentence led by the verb, followed by a compact endpoint note. The field list is dense but informative rather than redundant, and there is no filler.

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 output schema, the description compensates by listing the fields the activity record contains, which is genuinely useful. For a one-parameter read tool this is nearly sufficient; only error/not-found handling and permission requirements are unaddressed.

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?

There is a single parameter with 100% schema description coverage, and the schema already documents activity_id. The description only reinforces this indirectly via the REST path template "GET /activities/{id}", adding no format, source, or constraint detail beyond the schema; baseline 3 applies.

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?

States a specific verb and resource ("Fetch one activity") and even defines the domain term ("a logged interaction or task"), which removes ambiguity for a word like "activity". The enumeration of returned content (subject, note, dates, linked accounts, assigned users, status, priority) makes the scope concrete. It does not, however, explicitly distinguish itself from siblings such as neon_search or the list_* family.

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?

Usage is only implied: the singular "one activity" plus the GET /activities/{id} mapping signal that this is the lookup-by-id path rather than a search or list. There is no explicit statement of when to prefer it over neon_search or a list tool, and no note about what to do when the id is unknown.

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