monity.ai

Get recent changes across all monitors

get_recent_changes

Read-only

Account-wide feed of completed checks, newest first, each already carrying its monitor (name + URL), the AI summary of what changed, and the extracted output. This is the tool to use for reporting questions — 'what changed this week?', 'summarise my monitors', 'which pages moved?' — because it answers them in ONE call. Do not loop get_check_history over every monitor for that. Call it once per question: each call shows its own card to the user. Defaults to alerts only, which is what 'what changed' means; set alertedOnly false only when the user asks about every check (e.g. 'did my monitors run?'), never to look for more changes. pageAccess says what the browser reached; when reachedContent is false the check saw a challenge, login or error page, so report that, not a change in content. To show one change to the user, open it once with get_check. When you link to a check, use its checkUrl (its comparison in monity.ai), never the raw screenshot, diff or HTML file URLs.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_recent_changes"
  }
}

Input Schema

Name	Required	Description
`to`	No	ISO date upper bound (inclusive)
`from`	No	ISO date lower bound, inclusive — e.g. last week's date for a weekly report
`page`	No	Page number (default 1)
`label`	No	Only monitors carrying this label
`limit`	No	Results per page (default 25, max 100)
`status`	No	Explicit status filter: ALERT_SENT, CHANGE, NO_CHANGE or ERROR. Ignored when alertedOnly is true.
`alertedOnly`	No	true (default) returns only checks that detected a change and alerted; false returns every completed check
`monitorUuid`	No	Restrict to a single monitor (from list_monitors)
`includeHidden`	No	Include changes the user hid (hide_change) or their team hid in Monity (teamHidden: true). Default false.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds genuinely useful behavior beyond them: each call renders a card to the user, defaults to alerts only, and pageAccess/reachedContent must be interpreted rather than reported as content changes. It does not describe pagination capacity or ordering guarantees beyond 'newest first'.

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, then when-to-use, then interpretation rules, then linking guidance — a sensible progression with no filler sentences. It is dense and long for a list tool, and the trailing checkUrl/linking rule is more of an output-presentation norm than tool selection information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With nine parameters, no required fields, and no output schema, the description carries the burden well: it sketches the returned row shape and explains how to read pageAccess and reachedContent. It still leaves pagination behavior (how to know there are more pages) and total counts unstated.

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 decision semantics the schema cannot: what alertedOnly's default means conceptually and the precise condition for flipping it to false, plus the caveat never to use it to hunt for more changes. Other parameters (from/to, label, monitorUuid) get no extra meaning beyond their schema text.

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+resource and scope: 'Account-wide feed of completed checks, newest first' and enumerates what each row already carries (monitor name+URL, AI summary, extracted output). It is clearly separable from get_check_history (per-monitor history) and get_feed, which the agent can distinguish 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?

Names the exact question shapes it serves ('what changed this week?', 'summarise my monitors') and gives an explicit anti-pattern: 'Do not loop get_check_history over every monitor'. It also gives a call-frequency rule ('once per question'), a default rationale for alertedOnly, and routes single-change display to get_check.

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

All monity.ai tools Inspect

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

Need Help?