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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world behavior, so the safety profile is covered. The description does add one genuinely useful behavioral fact — results are 'names only', i.e. labels without numeric values — plus the structural grouping of returned sections. It does not describe pagination, response shape, or failure behavior for an unknown activity_key.

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?

Two sentences with no filler, but the first is convoluted ('The questions CFO+ asks for one activity (its drivers)') and the payload — what is actually returned — is buried behind branding references. The key behavioral constraint ('names only') appears mid-sentence rather than front-loaded.

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 must convey the return structure, and it does list the content sections reasonably well. However, two undocumented parameters, an unexplained language default, and no guidance on when this beats sibling info tools leave real gaps for an agent deciding whether to call it.

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% for both parameters, so the description carries the burden and largely fails: 'one activity' loosely implies activity_key, but nothing explains its format or where to obtain it, and the lang parameter (default 'ar') is never mentioned at all, leaving an agent unaware it can request another language.

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 enumerates the content returned (drivers/questions, revenue lines, cost items, input sections) but never states a verb such as 'returns' or 'lists', and leans on domain jargon ('The questions CFO+ asks', 'as shown on cfoplus.ai'). It is not distinguished from siblings like find_activity or how_the_numbers_are_made, so an agent must infer that this is the per-activity detail lookup.

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 explicit statement of when to call this versus find_activity (to locate an activity) or the other info tools. The required activity_key implies a prerequisite lookup, but that inference is never written down, and no exclusions or alternatives are named.

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