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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it says nothing beyond the bare action. It does not state whether the operation is read-only, what happens if the activity does not exist, whether auth is required, or what the response format is. The word 'get' weakly implies a safe read, but no confirmation or edge-case behavior is disclosed.

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?

At three words, the description is under-specified rather than appropriately concise; this is the classic case of under-specification masquerading as brevity. A simple GET with two parameters and two competing sibling families could merit multiple clarifying sentences, and none of that content is present.

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?

The tool has no output schema and no annotations, so the description should clarify return values and distinguish it from commsharbor_crm_activities_list and the platform-scoped variant, but it does neither. The self-explanatory parameter names prevent this from being unusable, but the definition is not complete enough for an agent to confidently select it over its siblings or know what it will receive.

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?

Although schema coverage is nominally 100%, both parameter descriptions are tautologies ('activity_id' describes 'activity_id'), so they add no real semantic value and the baseline-3 condition is not genuinely met. The tool description itself adds nothing about the parameters. An agent can guess that activity_id identifies the activity and organization_id scopes the request, but only because the parameter names are self-evident, not because the description helps.

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?

"get CRM activity" is nearly a verbatim restatement of the tool name commsharbor_crm_activities_get, which the rubric treats as a tautology. It conveys a single-record fetch only because the name already implies it, and it offers no definition of what a CRM activity is. It fails to distinguish itself from nearby siblings like commsharbor_crm_activities_list or commsharbor_platform_crm_activities_get.

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 zero guidance on when to use this tool versus the list, create, update, or delete siblings, or the platform-scoped variant. No context, prerequisites, or alternative tools are mentioned. The agent is left to infer usage purely from the parameter names.

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