list_runsList recent test runs. Filter by target, status, or test slug. Returns run status, score, summary, duration, and finding count.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of runs to return | |
| status | No | Filter by run status | |
| targetId | No | Filter by target ID | |
| testSlug | No | Filter by test definition slug (e.g. "security-headers") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It clearly states the return fields (status, score, summary, duration, finding count), but does not disclose ordering, pagination limits, or access scope. It is adequate for a read-only list, but not rich in behavioral detail.
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 concise sentences, front-loaded with the core purpose and followed by return information. No unnecessary words 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?
Without annotations or an output schema, the description still manages to cover the main purpose, filters, and return fields, which is sufficient for a list operation. It could benefit from mentioning default ordering or pagination behavior, but it is largely complete for the tool's complexity.
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 input schema has 100% descriptive coverage for all parameters, so the description's mention of filters adds minimal value beyond what the schema already documents. The phrase 'recent' hints at a default ordering, but it does not provide additional parameter syntax or format details.
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 opens with a specific verb and resource: 'List recent test runs.' It also clarifies the allowed filters (target, status, test slug) and what is returned, making its purpose unambiguous. It distinguishes itself from siblings like get_run (single run) and active_runs (currently running runs).
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 indicates when to use it for recent runs and mentions filter capabilities, but it does not explicitly state when not to use it or suggest alternatives like active_runs. The context is present but exclusions are not articulated.
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 separated by resource (targets, runs, findings, incidents, etc.) and action. A few close pairs like active_runs/list_runs and mute_finding/create_muting_rule could confuse, but descriptions clarify the distinctions.
The majority of tools follow verb_noun naming (create_target, get_target, delete_journey). A few outliers use noun phrases (active_runs, daily_trends, system_health, team_stats) which slightly breaks the pattern, but overall the convention is predictable.
74 tools is extreme for any MCP server. Even for a comprehensive monitoring platform, this overwhelms agents with too many granular operations (e.g., enable_all_tests vs disable_all_tests vs update_test, or import_targets duplicating create_target). A more consolidated set would be appropriate.
The tool surface is remarkably complete for the monitoring domain: full CRUD for targets, journeys, rules, reports, secrets, and fragments; plus run triggering, incident management, findings handling, SEO tracking, guest scans, and admin tools. Only maintenance windows lack an update operation, which is minor.