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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds context the annotations cannot: the figures are statutory government fees rather than FastCAC's own price, which is essential for interpreting the result correctly, and it discloses the ₦1,000,000 default share capital.

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 the resource and scope, followed by the usage rule and the pricing caveat. Every sentence carries distinct information with no repetition of the title.

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 only two parameters, an output schema present and read-only annotations, the description covers nearly everything an agent needs to invoke it correctly. The only omissions are the non-company share_capital edge case and any note on currency assumptions beyond the naira symbol.

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 only 50% (the entity enum has no description), but the description compensates by expanding each enum value into plain language and tying share capital to the company case with its default. It does not state what happens if share_capital is supplied for a business name or NGO, leaving one edge case implicit.

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 a specific output (CAC official registration fees, line by line) and enumerates the three supported entity types with the key differentiator for each (share capital for companies, Incorporated Trustees for NGOs). No sibling tool computes fees, so this is unambiguous against the surrounding toolset.

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?

"Use it for any question about what CAC charges to register" gives a clear selection rule and is the right breadth for a fee-lookup tool. It stops short of naming an alternative or a when-not condition (e.g. don't use it for FastCAC service pricing), so it is strong but not exhaustive.

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