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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description. The description adds essentially nothing beyond the endpoint path — no mention of what the assignments endpoint returns, whether results are paginated, or what scoping (book, chart of accounts, entity) applies.

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 description is short but wastes half its content on an exact duplicate of the first sentence. Repetition without added information is a structural flaw, not conciseness; nothing is front-loaded about purpose or usage.

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, an entirely generic query parameter, and no meaningful prose, an agent has almost no basis to call this correctly without first invoking describe_operation. A free-form query object on a list endpoint demands at minimum an enumeration of the supported filters.

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 description coverage is 0% and both parameters are opaque: 'query' is a free-form object with additionalProperties {} and 'params' is an empty object. The description provides zero guidance on which query keys are accepted (filter by account, book, entity?), so the agent must fall back to describe_operation. The only compensating value is the pointer to that helper.

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 is a verbatim restatement of the tool name and title ('GET /api/gl-accounts/assignments'), naming the HTTP method and resource path but never explaining what an 'assignment' is or what kind of records come back. It does not distinguish this tool from siblings like get_gl_accounts, get_gl_accounts_charts, or get_gl_accounts_types beyond the path suffix.

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?

There is no statement of when to use this tool, when not to, or which sibling to prefer. The only procedural hint is that 'describe_operation provides native request schemas', which tells the agent how to find the schema but not when this operation is the right choice.

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