Skip to main content
Glama

Check a site every week

monitor_site
Idempotent

Paid plans: have a site crawled with crawl_site crawled again every week, the same way and with the same settings, compressing only the images that are new or changed since the last check, and email the account a link to a zip of them when a check finds some. Pass the crawl's id; the crawl must have scanned at least one page. Nothing runs now and nothing counts against the day: the first check is a week from now, at next_run_at. A crawl already checked answers its check. The plan sets how many sites can be checked at once (get_usage, limits.monitors). Another plan is refused with pro_required. The weekly site checks reference: https://www.iminify.com/docs/site-checks

Input Schema

NameRequiredDescriptionDefault
crawl_idYesThe id of a site crawl on the account, as crawl_site returned it.

Output Schema

NameRequiredDescriptionDefault
idNoThe check's id, for stop_monitor.
urlNoThe sitemap each run reads again, or the first of the pages it takes.
hintNoWhen the first check runs, and how to read what it finds.
emailsNoWhether a run that finds new or changed images emails the account.
pausedNoTrue while the check does not run on the plan: the plan has no weekly checks, or it checks fewer sites than the account holds and this is not among its oldest. The check is kept and runs again once the plan covers it.
sourceNo
crawl_idNoThe site crawl the check was made from, or null once that crawl is deleted.
last_runNoThe newest run, a site crawl: get_crawl with its id for its pages and report, create_zip with crawl_id for the images it compressed. Null before the first.
settingsNo
created_atNo
next_run_atNoWhen the next run is due.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / paused / description
      Previous value: -"True while the plan has no weekly checks: the check is kept and runs again once the account is back on Pro."New value: +"True while the check does not run on the plan: the plan has no weekly checks, or it checks fewer sites than the account holds and this is not among its oldest. The check is kept and runs again once the plan covers it."
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond annotations, it discloses scheduling behavior, delayed first run, quota/plan constraints, idempotent handling of already-checked crawls, and error behavior. These details materially help an agent understand the side effects and operational boundaries.

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?

The description is dense but substantially informative, with the core action and paid-plan constraint front-loaded. Some sentences are awkward and run-on, especially the opening sentence, but little content is extraneous.

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?

For a scheduling/monitoring tool with an output schema and annotations, the description covers prerequisites, timing, plan restrictions, idempotency, and failure behavior. An agent has enough context to invoke it correctly without needing undocumented assumptions.

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?

The schema already fully documents crawl_id at 100% coverage, but the description adds a meaningful constraint: the crawl must have scanned at least one page. This goes beyond the schema's basic identifier description, though no additional parameter syntax is needed.

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?

The description states a specific recurring action: re-crawl a site weekly using an existing crawl_site crawl, compress only new/changed images, and email a zip link. This clearly distinguishes monitor_site from the one-time crawl_site sibling and from list_monitors/stop_monitor.

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?

It gives explicit prerequisites and exclusions: paid plans only, pass a crawl_id from crawl_site, the crawl must have scanned at least one page, nothing runs immediately, and the first check occurs at next_run_at. It also names plan-limit guidance via get_usage and the pro_required refusal condition.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources