Skip to main content
Glama

Get monitor changes

monitoring_get_changes
Read-onlyIdempotent

What the workspace's monitors found: new mentions and spikes in them, new posts and posts taking off, reviews, new jobs, prices and text on watched pages, ads that start and stop and a brand's first ads, ranking moves, and moves, new citations and new brands in AI answers, oldest first from since.

Use when: "what changed this week", "anything new from my monitors", "what did the mentions monitor find", or to follow up on a monitor email. Not for: a fresh look right now, call the underlying tool. The numbers over time, use monitoring_get_history. Returns: List, oldest first. rows[]: change_id, monitor_id, monitor_name, kind, urgent (sent as an alert), summary, url, quote (the post, review or page text; cleared after 30 days), before, after, details (author, likes, comments, views, platform where known; cleared after 30 days), found_at. next_since is the value to pass as since next time; dedupe on change_id. More rows than limit come back with meta.cursor. Cost: 0 credits. Example: {"since": "2026-10-13T00:00:00Z"}

Input Schema

NameRequiredDescriptionDefault
limitNo
sinceNoISO 8601. Default seven days ago. Pass next_since from the last call.
cursorNoFrom meta.cursor of the previous page.
monitor_idNoOne monitor. Default: every monitor.

Output Schema

NameRequiredDescriptionDefault
metaYes
rowsNo
errorNo
hintsYes
next_sinceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / meta / properties / credits_remaining / description
      Previous value: -"The workspace's credits left after this call. null when the call did not check the balance (free tools, cache hits, dry runs, tasks) or the balance has no limit."New value: +"The workspace's credits left after this call. null when the call did not check the balance (free tools, cache hits, dry runs, tasks) or the balance has no limit. Leaves out credits held for calls still running, so it can dip during parallel calls and come back; credits_charged is what this call cost."
  2. Changed1 schema field changed
    • addedOutput schema / properties / meta / properties / feedback_request
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Once per workspace: after the task, ask the user once for feedback and send any answer with submit_feedback.",
      +  "properties": {
      +    "message": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "message"
      +  ],
      +  "type": "object"
      +}
  3. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover read-only/idempotent/non-destructive safety, but the description adds substantial context beyond them: ordered oldest-first, 0-credit cost, 30-day retention on quote/details, cursor pagination, and dedupe-on-change_id. It stops short of describing error or empty-result behavior, so it is strong rather than exhaustive.

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 clearly sectioned Use when / Not for / Returns / Cost / Example, which is easy to scan. The opening enumeration of change kinds is lengthy and could be trimmed, but every clause describes a distinct return category rather than padding.

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 four-parameter read tool with an output schema, it covers purpose, exclusions, ordering, field-level return shape, retention caveats, pagination, dedupe key, and cost. Nothing an agent needs to call it correctly or interpret the response 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 75% and each of the four parameters is documented, but the description adds the paging contract: next_since is the value to pass as since next time, and extra rows arrive with meta.cursor. Only limit lacks extra semantics in the description, and the example call anchors the since format.

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?

Opens with a specific verb+resource framing ("what the workspace's monitors found") and enumerates the change kinds it covers, so an agent knows exactly what comes back. It explicitly separates itself from monitoring_get_history and from the underlying live-lookup tool.

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?

Has explicit "Use when" phrasing with three concrete example queries plus a follow-up-on-a-monitor-email case. The "Not for" line names both exclusions and routes the agent to the right alternative for each (underlying tool for fresh data, monitoring_get_history for trends).

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