call

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

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose key behaviors: it can call hidden tools, and it auto-injects the database parameter into arguments unless already present (via schema but also implied). It also implies single-call behavior. However, it does not describe what happens if a tool fails, error handling, or any side effects, leaving some gaps. Still, given the tool's meta nature, it covers essential aspects.

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 extremely concise, just two sentences. The primary purpose is front-loaded in the first sentence, and usage guidance follows immediately. Every word earns its place with no fluff 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?

Given the tool's complexity as a meta-tool with nested objects and an output schema, the description is fairly complete. It clarifies the main use case (single hidden-tool calls), the differentiation from batch, and the auto-injection behavior. However, it could benefit from a brief note on what the output schema represents (e.g., the result of the called tool) and how errors might be returned, but the output schema itself may cover return values. The absence of these details loses a point.

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 100%, so the schema documents all three parameters (tool, database, arguments). The description adds context about how the database parameter is auto-injected into arguments, which is additional value beyond the schema. However, it does not elaborate on the tool parameter's format or how arguments are structured. With full schema coverage, a baseline of 3 is appropriate, and the auto-injection note adds slight value.

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 clearly states the tool's purpose: 'Call any tool by name, including hidden tools not in the client tool list.' It specifies the verb (call) and the resource (any tool by name), and distinguishes itself from batch for multiple calls. However, it does not explicitly differentiate from the sibling 'execute' or other calling mechanisms, so it loses one point for not naming alternatives beyond batch.

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?

The description provides explicit guidance: 'Use for single hidden-tool calls. For multiple calls, prefer **batch**.' This clearly indicates when to use this tool and names the alternative batch for multiple calls. It does not, however, mention other potentially relevant alternatives like execute or when not to use call, so it loses a point for not being more comprehensive.

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