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

Annotations already establish the safe-read profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds real behavioral context beyond the annotations: idempotency ('safe to repeat'), canonicality ('reads current server state and does not manufacture company facts'), a confirmation boundary, and the settlement caveat that equity payment is not complete until a trusted payment provider verifies it. That is genuinely additive, though the 'every prerequisite stated above' clause is noise.

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 read purpose is front-loaded in the first sentence, which is good. But the remaining text is padded with templated labels ('Canonicality:', 'Idempotency:', 'Confirmation boundary:') and includes a meaningless self-referential prerequisite clause, plus an unrelated sentence about equity settlement. It is not bloated to the point of uselessness, but several sentences do not earn their place.

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 does partially cover return content (gates, voter decisions, effect status, next step), which helps. But it omits any parameter semantics, the nested _corply_context object is undocumented, and the prerequisite statement is circular. For a read tool with a nested input object and zero schema description coverage, more completeness was needed.

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 there are 3 parameters (companyId, caseId, and a nested _corply_context object) with no descriptions. The description provides no explanation of what caseId or companyId denote or how they identify the action, and never mentions the nested context object. With low coverage the description is expected to compensate, and it does not, leaving parameter meaning essentially unexplained.

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 names what is returned (action gates, frozen voter decisions, effect status, next step) and the title says 'View a company action', so the read intent is discernible. However, it never states the core identity of the resource being fetched (a single governed action keyed by caseId/companyId), and it gives no differentiation from close siblings like get_corporate_action_case, get_my_governed_document, or list_governed_actions. The result is a vaguely-scoped purpose rather than a precise verb+resource.

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 stated when-to-use versus alternatives among the many sibling read tools. The only guidance is a circular prerequisite ('authenticated active company access plus every prerequisite stated above') that references context that does not exist above it, so it conveys nothing actionable. No exclusions or conditions for selecting this over list_governed_actions or get_corporate_action_case are given.

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