run_checks

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals the tool's unavailability but does not say what happens on invocation—whether it returns an error, a message, or nothing—nor what the tool would do if configured, leaving key behavioral traits undisclosed.

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 a single, front-loaded sentence with no filler. Both the unavailability notice and the call instruction earn their place, making it appropriately sized for what it conveys.

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 no-parameter stub, the description is largely complete: it states the tool is unavailable, gives the reason, and provides an explicit next action. The main gap is that it does not describe the invocation result or normal configured behavior, but the simplicity of the stub makes this a minor omission.

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?

There are zero parameters, so the empty input schema fully covers the invocation surface and no parameter documentation is needed. The instruction to call the tool is consistent with a parameterless call, making the description sufficient on this dimension.

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 communicates a status—'Unavailable: signal-mcp is not configured'—and instructs the agent to call the tool to see why, but it never states the tool's actual function of running checks. It is not a tautology, but the operational purpose is vague and undifferentiated from siblings like run_check and start_checks.

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 only guidance is 'Call it to see why,' which tells the agent when to invoke it for an explanation but provides no conditions for preferring it over alternatives or when not to use it. No exclusions or alternative routing are mentioned despite many closely related sibling tools.

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