Monito

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

Annotations cover the safety profile (readOnlyHint=false, openWorldHint=true, destructiveHint=false), and the description adds substantial context beyond them: the call spends credits, a repeated requestId retries the original launch without re-charging, hosted calls reject loopback/private/LAN hosts, local stdio tunnels up to 3 ports and requires the MCP server to stay running. It also discloses the result contract (done, status meanings, 'error is not a product verdict').

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?

Front-loaded with purpose and the sibling differentiator, and each subsequent sentence carries routing or constraint information rather than filler. It is a dense run-on paragraph, however, and the downstream-tool instructions could be trimmed without losing callable 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?

With no output schema, the description carries the return contract itself: the done flag, checkId/projectId/runId, status vocabulary with the passed/failed/error distinction, cause, replay, reportUrl, and the resume path when the wait budget expires. Nothing an agent needs to call or interpret the result is missing.

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 coverage is 100%, so the baseline is 3, but the description adds real semantics on top: projectId's reuse-or-create fallback when omitted, environmentId's dependency on projectId, requestId's retry/no-charge behavior, and timeoutSeconds being capped by the server budget. Minor gap: it references localPorts, which does not appear in the schema's property list.

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?

States a specific verb and resource ('Run one public HTTP or HTTPS URL and an expectation in Chromium') and immediately distinguishes itself from the closest sibling by naming the alternative selector ('use run_scenario when you have a saved scenario id'). An agent can route between check and run_scenario without opening either schema.

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?

Explicit when-to-use with the alternative condition ('when you have a URL' vs 'when you have a saved scenario id'), plus follow-on routing for every branch: get_run for evidence, get_screenshot for images, save_check to persist, wait_for_run when done is false. Exclusions are stated for hosted vs local stdio hosts.

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

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

Annotations cover the safety profile, but the description adds real behavior the annotations cannot: no credit spend, no waiting, no image bytes returned, capture-attached screenshotUrl, and the retention caveat that deleted evidence leaves verdict/bug-report text with bundleWarning. That last item is operational context an agent cannot infer from structured fields.

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?

It is long, but it is front-loaded with purpose, usage and required param before the detail, and nearly every clause carries distinct information (credits, image bytes, limits, retention). A tighter grouping of the evidence-field inventory would help, but there is little outright waste.

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?

There is no output schema, so the description carries the full return-value burden and does so: reportUrl, evidence contents, displayLimits counting, bundleWarning, and the verified-verification object. An agent has everything needed to call it correctly and interpret the result.

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 coverage is 100%, so the baseline is 3, but the description goes beyond it by enumerating exactly what evidence=true yields and by stating the conditional interaction 'With evidence left at its default, requireVerified adds a verification object' — a dependency the schema does not express. It stops short of clarifying limit semantics beyond pointing at evidence.displayLimits.

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?

States a specific verb and resource ('Read one run's bug reports and evidence') and immediately carves out scope with siblings: wait_for_run for pending runs, list_runs for recent runs, get_screenshot for images. An agent can pick this apart from every relevant sibling without opening a schema.

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?

Gives explicit trigger conditions ('Use it after check, run_scenario, run_project, or wait_for_run reports a verdict') and an explicit exclusion with the alternative named ('For a run still pending or running, call wait_for_run'). Both when-to-use and when-not are covered.

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

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

Goes well beyond the readOnly/idempotent annotations: it states the call does not spend credits, that images over 5 MB are refused, that retention-window deletion produces a failure naming the deletion time, and that other users' private sessions are inaccessible while public sessions are readable by id. These are exactly the operational constraints an agent cannot infer from the schema.

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?

Four sentences, each carrying a distinct load (output form, argument provenance, cost/size limits, failure and access rules), with the core action front-loaded. No redundancy or filler.

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 two-parameter read tool with no output schema, the description covers the return type (an MCP image), the credit/size economics, and the two realistic failure modes. Nothing needed to invoke it correctly is missing.

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 only 50% (sessionId has a trivial "Session ID" note; fileName is undocumented). The description compensates by explaining where each value comes from — the run's sessionId and the filenames emitted by get_run — which is meaning the schema does not carry.

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?

States a specific verb and resource ("Return one screenshot from a session as an MCP image") with concrete scope: a single screenshot, streaming back as an image rather than metadata. It also implicitly separates itself from get_run, which only lists file names.

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?

Gives clear prerequisites and provenance for both arguments: sessionId from the run, fileName from the names get_run lists. That is actionable routing between this tool and its sibling. It stops short of an explicit when-not-to-use statement, but the context is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered; the description adds ordering (newest first) and enumerates the returned fields (id, name, url, scenarioCount, lastRunStatus, lastRunAt, passRate), which compensates for the missing output schema. It does not mention pagination or result caps, a minor gap given annotations carry the rest.

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?

Front-loaded with the core scope and ordering, and nearly every clause carries information (domain definition, search semantics, returned fields, id handoff, check boundary). The final sentence packs the check relationship and projectId alias densely, costing a bit of readability, but nothing is wasted.

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 one-optional-param read tool with no output schema, the description supplies both the returned field list and the cross-tool id usage, so an agent has everything needed to call it and consume the result. No meaningful gaps remain.

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% and the schema already documents the search parameter as a case-insensitive substring over name or URL with a 200-character cap. The description's 'Optional search matches the name or URL, case-insensitive, up to 200 characters' is a near-verbatim restatement rather than added meaning, so baseline 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?

States a specific verb and resource ('List every project owned by the authenticated account'), defines scope, ordering ('newest first'), and even defines the domain object ('A project is one web app'). The agent can distinguish this from siblings like list_scenarios or check without opening any schema.

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?

Explicitly routes the returned id to list_scenarios, run_project, or check as projectId, and clarifies the boundary with check ('check creates a project when no owned environment matches the URL'). Both the when-to-use and the alternative-tool conditions are spelled out rather than implied.

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

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

Going beyond the readOnly/idempotent annotations, it discloses that logs, prompts, and the full run record are omitted, and that the call 'does not spend credits' – useful cost context. It stops short of describing error conditions or response shape details beyond the field list, keeping it at 4.

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?

Front-loads the core action and scope, then the return fields, then the constraints and next-step routing. Every sentence carries distinct information with no 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?

Though there is no output schema, the description enumerates the returned fields (id, status, outcome cause, timestamps, scenario/project ids, names, sessionId, reportUrl) and the omissions, so an agent knows exactly what it gets and how to proceed.

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 coverage is 100%, so both parameters (limit range/default, projectId filter) are already fully documented. The description restates the limit range and the projectId omit-behavior, adding reinforcement but little genuinely new meaning, so the baseline 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?

States a specific verb and resource ('List the signed-in user's recent runs') plus ordering ('newest first'), and scoping ('the signed-in user's'). It is clearly distinguishable from siblings like get_run, list_projects, and list_scenarios.

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?

Explicitly explains the projectId filter ('keep one project; omit it for...across that user's projects') and routes the agent onward: use get_run for bug reports/screenshot file names, then get_screenshot. Also states 'no further page,' preventing pagination attempts.

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

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

Adds behavioral context beyond the annotations: unsaved checks are omitted, results are newest first, only the newest 20 are returned, and there is no pagination. It also lists the returned fields, which matters because there is no output schema.

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?

Front-loads the core action and scope, then adds only operationally necessary details: unsaved exclusion, field list, sibling routing, and the 20-item limit. No filler sentences.

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?

Complete for a read-only list tool with one optional parameter and no output schema. The description covers scope, ordering, truncation, returned fields, and next-step sibling calls.

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 coverage is 100%, and the schema already explains projectId's scope. The description reinforces that omission lists across the account but adds no new syntax or format detail beyond the schema baseline.

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?

States a specific verb and resource ("List saved scenarios") and immediately clarifies what a scenario is. It distinguishes the tool from siblings by explaining that unsaved checks are omitted until save_check.

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?

Explicitly covers when to omit projectId to list across the account and when to pass it. It also routes ids to run_scenario and projectId to run_project, making the alternatives clear.

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

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

Annotations are sparse (readOnlyHint=false, openWorldHint=true), so the description carries real weight and delivers: per-scenario credit spend, a credit check before any member starts, shared launch concurrency, requestId deduplication, and the exact result shape ('id, status, cause, timestamps, and report link, not the full run record'). This is disclosure well beyond what the annotations provide.

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?

Core purpose and constraints are front-loaded before the operational details, and most sentences earn their place. Some redundancy exists, notably the requestId dedup and wait-budget explanations, which restate what the schema fields already say.

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 12-parameter mutation tool with no output schema, the description covers everything an agent needs: preconditions, credit behavior, dedup, wait-budget exhaustion handling, next-tool routing, and the shape of the returned result. No material gap remains.

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 coverage is 75%, so the baseline sits at 3; the description adds genuine meaning on top by explaining the suite membership constraint and why one would 'Pass baseUrl to test a preview deployment.' Several parameters (pr, live, branch, commitSha, requireVerified) get no description-level treatment, and the requestId explanation largely restates the schema.

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?

States a specific verb and resource with an explicit scope limit: 'Run the newest 20 saved scenarios in one project, or one named suite, and wait for the verdicts.' The project-vs-suite-vs-single-scenario distinction is unambiguous, letting an agent separate it from run_scenario without opening either schema.

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?

Gives explicit when-to-use context plus named alternatives and next steps: 'call wait_for_run with each pending run id and do not launch again' and 'Call get_run for evidence.' It also states exclusions ('Unsaved checks are not included') and rejection preconditions ('A suite runs only when every member is among those 20').

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

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

Annotations only mark this as non-read-only, non-idempotent, open-world; the description adds materially more: it spends credits, requestId replays the earlier launch without charging again, wait=false returns an id with done=false, the wait budget may expire, and it clarifies verdict semantics ('failed means a bug was found; error is not a product verdict').

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?

Purpose and cost warning are front-loaded, then routing, parameters, and return/follow-up behavior in a logical order. It is dense and runs long, but nearly every clause carries operational information (credits, idempotency, resume path), so little is waste.

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?

With no output schema, the description carries the return contract itself: done, run (status, bugReportsCount, creditsCharged), and reportUrl, plus the follow-up chain to get_run, get_screenshot via run.sessionId and evidence.screenshots fileName, and wait_for_run. Nothing needed to invoke or interpret the result is missing.

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 coverage is 100%, so the schema already documents all seven parameters and the baseline would be 3. The description still adds value by scoping environment to the exact name on that scenario's project, tying requestId to the charge-avoidance behavior, and explaining live as skipping a recorded path and timeoutSeconds as capped by the server's per-call budget.

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?

States a concrete verb+resource+scope ('Run one saved scenario in Chromium', one scenarioId, waits for verdict by default). It explicitly distinguishes itself from the two nearest siblings, check and run_project, so an agent can route without opening either schema.

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?

Gives explicit when-to-use routing: list_scenarios to obtain scenarioId, check when you have a URL and expectation instead of a saved scenario, run_project for the newest 20 or a suite. Also states what to do on non-completion (wait_for_run) and after completion (get_run, then get_screenshot).

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

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

Goes well beyond the annotations by disclosing side-effect scope: keeps existing run history, does not spend credits or start a run, and returns a conflict error on duplicate saves. The 'newest 20' inclusion rule for run_project is a non-obvious behavioral detail that only the description supplies.

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?

Front-loaded with the core action and required params, then layered with downstream effects and edge cases. It is long but nearly every sentence carries distinct information; only the name-length and checkId-origin restatements are redundant with the schema.

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 2-param mutation with no output schema, the description covers the return value shape ('returns the scenario with the same id'), id reuse across list_scenarios/run_scenario, project-run inclusion, history retention, cost, and the duplicate-save failure mode. Nothing an agent needs is missing.

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 both params are already documented in the schema. The description restates the 1–255 name bound and the 'checkId returned by check' origin, adding little beyond the schema, so the baseline 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?

States a specific verb and resource: 'Save the check from check as a named scenario.' It names the upstream source (check) and downstream consumers (list_scenarios, run_scenario, run_project), so an agent can distinguish it from every sibling without opening a schema.

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 context is clear: this persists a check as a reusable scenario that later feeds run_scenario and project-wide runs. It even gives a precondition-style exclusion (conflict error when the check is already a scenario). It stops short of explicitly stating when NOT to save versus, say, running a check ad hoc.

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

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

Annotations already establish a safe, idempotent, read-only poll, lowering the bar, but the description still adds real behavioral context: no credit spend, a server-capped per-call budget, the semantic split between failed (bug found) and error (not a product verdict), and the resume path (done false plus resume.tool) when the budget expires. The only gap is pagination/partial-result timing beyond the budget case.

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?

Purpose and the negative scope are front-loaded in the first two sentences, then required vs optional parameters, verdict semantics, and the resume instruction follow in a logical order. Despite its length, every sentence carries routing, parameter, or return-behavior information with no filler.

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?

There is no output schema, so the description carries the full return burden and does so: done true with run and reportUrl on passed/failed/error, done false with status and resume.tool on budget exhaustion, and the requireVerified verification object. An agent knows both how to call it and what shapes to expect.

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 coverage is 100%, so the schema already documents runId, timeoutSeconds (including the server budget cap), and requireVerified. The description still adds workflow meaning the schema lacks: runId must come from the specific launch, and requireVerified 'adds a verification object when every required outcome passed with current evidence,' clarifying its return-level effect rather than just its boolean meaning.

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 names a specific verb and resource ('Wait for a run already started by ... then return its verdict') and immediately draws the boundary against siblings with 'Does not spend credits or start a run,' which separates it from run_scenario, run_project, and check. An agent can select this tool without opening any schema.

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?

It gives explicit call conditions ('Call once per runId when several runs are in progress, including each pending id from run_project'), prerequisites ('Required: runId from that launch'), and routes to named alternatives for adjacent needs (get_run for bug reports, get_screenshot for evidence files). Both when-to-use and when-to-go-elsewhere are covered.

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