customer_success_health_score_report

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

The description adds routing/scoping context (dispatcher under JWT, tenant, and company scope), which is useful. It does not contradict the annotations, and the destructive/open-world hints are already covered structurally, so no additional side-effect warning is strictly needed.

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 concise and front-loaded with the action name. The routing sentence and two argument bullets each earn their place, with no filler or redundancy.

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?

For a generic domain-agent wrapper, it covers invocation, scoping, and both parameters, while the output schema handles return-value documentation. However, with no usage guidance and generic input semantics, an agent selecting among many customer_success_* siblings gets no differentiation help.

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 0%, so the description is the only source of parameter meaning. It says message is a free-text objective and inputs is an optional JSON string, adding basic semantics beyond the bare schema. It stops short of giving acceptable keys, examples, or expected structure for the JSON, so the added value is limited.

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 states a specific verb ('Run') and resource ('customer_success domain agent action `health_score_report`'), and the tool name itself differentiates it from sibling customer_success tools. However, it does not describe what the health score report contains or what it produces, so it stops short of full clarity.

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?

No when-to-use or when-not-to-use guidance is provided, and no alternative tools are mentioned. The only contextual clause is about routing and scoping, not about selecting this tool over sibling customer_success_* actions such as churn_risk_scan or renewal_pipeline.

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