company_unit_economics

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

No annotations are present, so the description carries the full transparency burden. 'supplied proofs are verified and provider effects remain external' is ambiguous and does not clearly state whether 'advance' mutates state, what side effects occur, or what permissions are required. It fails to disclose rate limits, destructive behavior, or data mutation risks.

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 a single sentence and does not contain padding or redundant details. However, it sacrifices clarity for brevity by using vague jargon like 'scoped lifecycle' and 'provider effects remain external,' making the compactness a liability rather than an asset.

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?

The description does not explain the tool's role in the broader ecosystem or how it relates to the many sibling tools. Despite having an output schema, the description lacks essential context about what unit economics are, what a lifecycle means here, and what the caller should expect. It is not sufficiently complete for an agent to use reliably.

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?

The schema has no parameter descriptions and the description explains none of the seven parameters. Required fields like project_id and bundle_json are completely opaque, and optional fields like operation, engine, entity_ref, and payload_json have no explained meaning. This makes correct invocation nearly impossible.

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?

Description says it can 'Inspect or advance unit economics' but does not define what unit economics means or what a 'scoped lifecycle' entails. The phrasing is cryptic and provides no concrete resource or action details. It also offers no differentiation from the many similar company_* sibling tools.

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 guidance on when to use this tool versus any alternative. The description does not mention scenarios, prerequisites, or how the 'operation' parameter should be chosen. It leaves all invocation decisions unexplained.

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