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

With no annotations, the description carries the full burden and does disclose the two most important behavioral facts: a protected object (General pipeline is immutable) and an authorization requirement (admin/owner). It still omits error behavior, whether the change is reversible, and what happens to leads already in the branch when members are replaced.

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?

Three short sentences, front-loaded with what the tool does followed by the two hard constraints. No filler, no restatement of the title, nothing to trim.

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?

For a mutation tool with no annotations and no output schema, the description covers the key guardrails but leaves real gaps: whether at least one of name/member_user_ids must be supplied, what is returned, and any side effects on leads already assigned to the branch. Adequate but not sufficient to call confidently.

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?

Schema coverage is 67% — the `name` parameter has no schema description at all, and the description only implies it via 'Rename'. The 'replace its member list' phrasing reinforces member_user_ids semantics but largely repeats the schema's own 'Replaces the member list' note, so added value is modest.

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: rename a pipeline and/or replace its member list, which maps cleanly onto the two optional write fields. The only weakness is terminology drift — the tool and its siblings (crm_create_branch, crm_get_branch, delete_crm_branch) say 'branch' while the description says 'pipeline', which could momentarily confuse an agent about whether these are the same object.

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 General pipeline cannot be changed' and 'Admins/owner only' give concrete when-not and prerequisite conditions that an agent cannot infer from the schema. It stops short of naming alternatives (e.g. crm_add_lead_to_branch / crm_move_lead_to_branch for membership changes versus replacing the whole list), but the usage context is clear.

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