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

With only a title annotation, the description carries the behavioral burden and does substantial work: it discloses that returned data is live and volatile ('it will change'), that answers should be timestamped, that results must not be persisted as memories, and that a child/subagent must wake with its own session. Gaps remain around failure modes, permissions, and whether calls are read-only against the external system.

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?

Purpose is front-loaded, but the prose is packed into long run-on clauses ('its own and those of Kits linked to it', 'recall first, then ask the system for the current figures') that force re-reading. Every idea is relevant, yet the same content could be structured as short mode bullets with far less parsing cost.

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 multi-mode gateway with a nested `arguments` object and no output schema, the description covers mode dispatch, ordering with recall, volatility, and session requirements. The notable omission is return shape — with no output schema, saying what a system listing or a tool run yields would help an agent plan the follow-up call.

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 100%, so baseline is 3; the description exceeds it by explaining the dispatch chain the parameters form — bare call lists systems, `system` alone returns that system's tools and their arguments, `system` plus `tool` executes — which the schema only states piecewise. It does not add format details for `arguments` beyond deferring to the target tool's schema.

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 concrete verb and resource: query live records held by connected business systems (accounting, HR, a shop), including systems of linked Kits. It also distinguishes itself from the sibling `recall` by contrasting 'history, decisions' with 'today's records'. The name 'systems' alone is vague, and the three modes (list systems / list a system's tools / run a tool) are only spelled out later, but the overall purpose is recoverable.

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?

It gives explicit sequencing against a named sibling: 'recall first, then ask the system for the current figures', and says recall names the record to ask for. Mode selection is fully enumerated: nothing lists systems, `system` shows a tool's arguments, `system`+`tool` runs it. It also includes a negative instruction — never save the answer as a memory — which is exactly the when-not guidance an agent needs.

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