Skip to main content
Glama
Sign In

Monito

by dev.monito
OverviewDiscussionsAdmin

Check a change

check

Run one public HTTP or HTTPS URL and an expectation in Chromium. Spends credits. Use this when you have a URL; use run_scenario when you have a saved scenario id. Required: url (no username or password) and expectation (what a user does and what must be true, 1–20000 characters). Optional: projectId (keep the check in that project; when omitted, an owned environment with the same origin is reused, otherwise a project named after the host is created), environmentId (must belong to that project when both are set), requestId (1–64 characters; the same value retries the original launch and does not charge again; omitted values are generated per call), maxDurationMs (60000–600000, default 300000), wait (default true), and timeoutSeconds (capped by the server's per-call budget). A finished call has done true and includes checkId, projectId, runId, status (passed, failed, or error), cause, causeLabel, firstFailure, durationMs, creditsCharged, replay, and reportUrl. failed means a bug was found; error is not a product verdict. Call get_run with runId for bug reports, failed requests, console messages, and screenshot file names and URLs. Call get_screenshot with run.sessionId from that get_run result and one evidence.screenshots fileName (not a screenshotUrl) to receive the image. Call save_check to keep the check. If the wait ends first, done is false and resume.tool is wait_for_run; call wait_for_run with that runId. Hosted calls reject loopback, private, and LAN hosts. Local stdio accepts HTTP loopback URLs and localPorts (up to 3 distinct ports, 1024–65535); keep the MCP server running while that tunnel is in use.

Input Schema

NameRequiredDescriptionDefault
urlYesPublic http or https URL with no username or password. Hosted calls reject loopback, private, and LAN hosts.
waitNoWait for a verdict before returning. When the wait budget runs out the tool returns the run IDs; resume with wait_for_run instead of launching again.
projectIdNoExisting project for this check. When omitted, an owned environment with the same origin is reused, otherwise a project named after the host is created.
requestIdNo1–64 characters. The same value retries the original launch and does not charge again. Omitted values are generated per call.
expectationYesWhat a user does and what must be true afterwards. 1–20000 characters after trimming.
environmentIdNoEnvironment to run against. When projectId is also set, the environment must belong to that project.
maxDurationMsNoBrowser time limit in milliseconds, from 60000 to 600000. Default 300000.
timeoutSecondsNoMaximum seconds to wait. Capped by the server's per-call budget.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / environmentId / description
      Added value: +"Environment to run against. When projectId is also set, the environment must belong to that project."
    • addedInput schema / properties / expectation / description
      Added value: +"What a user does and what must be true afterwards. 1–20000 characters after trimming."
    • addedInput schema / properties / maxDurationMs / description
      Added value: +"Browser time limit in milliseconds, from 60000 to 600000. Default 300000."
    • addedInput schema / properties / projectId / description
      Added value: +"Existing project for this check. When omitted, an owned environment with the same origin is reused, otherwise a project named after the host is created."
    • addedInput schema / properties / requestId / description
      Added value: +"1–64 characters. The same value retries the original launch and does not charge again. Omitted values are generated per call."
    • addedInput schema / properties / url / description
      Added value: +"Public http or https URL with no username or password. Hosted calls reject loopback, private, and LAN hosts."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Monito toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources