report

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

Annotations already declare destructiveHint=false and openWorldHint=false, so the safety profile is partly covered. The description adds nothing about what session_end or health actually do, whether ending a session is reversible, or what any action returns, which is a meaningful gap for a tool whose actions span reads and lifecycle changes.

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 first two sentences are rambling and abstract while the actual useful information is crushed into a single dense parenthetical list. It is information-dense but poorly front-loaded, and the cryptic prose does not earn its space.

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?

Eight distinct actions, a free-form nested `params` object, no output schema, and low schema coverage demand far more explanation than provided. No return values, no per-action meaning, and no guidance on the nested params structure are given.

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 33% and the critical `action` parameter has no description or enum. The description does compensate somewhat by enumerating valid action values and their per-action params, but those names (said, about, replaces, lens, pane, look) are never defined, leaving real ambiguity.

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 opening prose is cryptic ("Say that something happened or is so") but the enumerated action list (session_update, session_end, tell, run_report, rechecked, show, check_connections, health) does reveal that this is a multi-action reporting/dispatch tool. It never distinguishes itself from close siblings like query, ask, or capture, so an agent cannot tell why it should pick report over those.

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 when-to-use, when-not-to-use, or alternative routing guidance; the only instruction is the tautological "Call with the action and its params." The pointer "query actions says what each does" offloads the semantics to a sibling tool rather than explaining them here.

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