Read a monitor's live rolling health and drift. Health is unknown | healthy | degraded | critical. Drift is isolated by judge version: when our judge changes, the boundary is reported as judgeVersionChanged and NEVER as an agent regression — a score delta across that boundary says nothing about your agent.
| Name | Required | Description | Default |
|---|---|---|---|
| monitorId | Yes | The monitor to read. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It goes above and beyond by specifying the possible health values (unknown | healthy | degraded | critical) and the nuanced drift behavior: judge changes are reported as judgeVersionChanged and never as an agent regression. This critical caveat—that a score delta across a judge change says nothing about the agent—is essential for correct interpretation and is not obvious from any structured data.
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: two sentences. The first sentence front-loads the core purpose and scope. The second sentence packs important behavioral details about health and drift, and every clause earns its place. There is no fluff, repetition, or irrelevant information.
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 tool with minimal schema and no output schema, the description provides enough context to understand what the tool returns (health status and drift) and the key interpretation caveat. It does not explicitly describe the exact return structure (e.g., field names), but the information given covers the essential semantics. Given that the tool is simple, the description is nearly complete but could be improved with a brief mention of the return shape.
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 schema has 100% coverage for the single parameter monitorId, with the description 'The monitor to read.' The tool description itself does not add any further parameter-level semantics beyond what the schema already provides. Since the schema fully documents the parameter, the baseline score of 3 applies.
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 begins with 'Read a monitor's live rolling health and drift,' which clearly states the verb (read), resource (monitor health), and scope (live rolling). This distinguishes it from sibling tools like get_trends or list_monitors, which serve different purposes. The explicit mention of 'health and drift' makes the tool's purpose unambiguous.
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?
Usage is implied: this tool is for reading monitor health and drift. However, there is no explicit guidance on when to use it versus alternatives such as get_trends or list_monitors, nor when not to use it. The drift isolation explanation is helpful for interpreting results but does not address tool selection, so the guidance is only implicit.
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.
Most tools are clearly distinct by resource (monitors, suites, flows, numbers, recordings), but run_test and test_flow could be confused since both execute tests, though their scopes differ. The descriptions help disambiguate them.
All tool names follow a consistent verb_noun snake_case pattern (create_, get_, list_, run_, verify_, etc.), with no camelCase or mixed conventions. Even compound names like get_monitor_health and verify_number_confirm remain predictable.
At 16 tools, the set is slightly above the optimal 3-15 range, but the breadth of the voice-agent testing/monitoring domain justifies each tool's existence. It feels well-scoped rather than bloated.
The tool set lacks update/delete operations for most entities (monitors, suites, flows) and omits a get_run tool to retrieve individual live test results, leaving significant gaps that agents cannot work around. This will cause failures in lifecycle management and live-run result retrieval.
