Check whether the org's benches are sending and how much has arrived. Call this first when logs seem missing - it distinguishes "the bench is down" from "the app logged nothing".
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It appropriately reveals that this is a diagnostic/status probe rather than a log retrieval command, and that it distinguishes infrastructure failure from application logging failure. However, it does not disclose the output shape, whether any state is changed, or what 'benches' refers to, leaving some ambiguity for an agent.
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?
Two sentences with no filler. The first sentence states the core function, and the second gives the actionable use case. The most important information is front-loaded, and every word earns its place.
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 parameterless status-check tool, the description gives enough context for an agent to know when to call it and what question it answers. The only notable gap is the lack of output-schema detail, but the tool's simplicity means an agent can still use it correctly from the given information.
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 tool has zero parameters and the schema coverage is 100%, so there is nothing for the description to add about inputs. The description instead provides useful operational meaning about what the tool checks. A baseline of 4 is appropriate for a parameterless tool.
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 ('Check'), a specific resource ('the org's benches'), and the exact information returned ('whether ... sending and how much has arrived'). It also draws a clear contrast with the app having 'logged nothing', which differentiates it from the log-focused 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?
The description explicitly says when to use this tool: 'Call this first when logs seem missing'. It also clarifies the diagnostic distinction it resolves, which gives strong context for choosing it. It does not explicitly name alternative tools or give a 'when not to use' case, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
