Skip to main content
Glama

Create a monitor

monitoring_create_monitor

Sets up a monitor: a check Manifold repeats on a schedule, keeping each result so it can report what changed. Urgent changes reach the user as an email alert. Show the monthly cost from preview first, then create it once the user agrees. Give it a description saying why the user wants it, so an agent reading its changes later knows what to do with them.

Use when: "monitor this every week", "keep an eye on X", "tell me when Y changes", "check Z every hour", or the user ran the same check by hand before and wants it repeated. Not for: a one-off look, call the tool itself (reddit_search_posts, seo_get_page, seo_get_position, ads_get_advertiser_ads). Reading what a monitor found, use monitoring_get_changes. Returns: Record. monitor (monitor_id, name, description, preset, status, cadence, fields, est_credits_check, est_credits_month, next_check_at), created (false on preview). The first check runs within five minutes and records a starting point; changes are reported from the second check on. Fields by preset: mentions {keywords (up to 10), platforms (reddit, linkedin, instagram, tiktok, youtube; default reddit), communities (Reddit, every new post read in full), pages (1 to 3 per community per check)}, where Instagram searches each keyword as one hashtag ("acme crm" reads #acmecrm), so use a keyword people tag; social_accounts {accounts [{platform (twitter, linkedin, instagram, tiktok, youtube, facebook), account (handle, or URL for facebook and linkedin)}] (1 to 10)}; reviews {items [{source app_store or google_play, app_id} or {source google_maps, place_id or cid} or {source google_shopping, product_id, gid}] (1 to 5), stars, location}; website_changes {pages (1 to 10 URLs), mode (new_items: new links under the page and prices; any_change: new text), words}; ads {brands (1 to 5, a website works best), platforms (facebook, google, linkedin, tiktok)}; google_rankings {site, keywords (1 to 50), location}; ai_visibility {brand, aliases (other names for the brand, up to 5), domain (the brand's site, for citation share), questions (1 to 25; ones that name the brand are counted apart), competitors (up to 9), engines, samples (1 to 3), location, language}. cadence is hourly, daily or weekly; checks repeat from the first one. A bad field is InvalidTarget naming it. Cost: 0 credits to create. Each check charges for the calls it makes at their own prices, shown as est_credits_check and est_credits_month. Monitor checks read live data, never the cache. Example: {"preset": "mentions", "fields": {"keywords": ["acme crm"], "platforms": ["reddit", "linkedin"]}, "description": "Threads asking for a CRM, to answer while they are fresh.", "preview": true}

Input Schema

NameRequiredDescriptionDefault
nameNoDefault: made from the fields.
fieldsYesThe preset's fields, as the description lists them.
presetYesWhat to watch; the description lists each preset's fields.
cadenceNoDefault hourly for mentions and social_accounts, daily for reviews, website_changes and ads, weekly for google_rankings and ai_visibility.
previewNoReturn the monitor and its monthly cost without creating it.
descriptionNoWhy the user wants it and what to do with a change, in a sentence or two, so whoever reads its changes later knows. Default: a line made from the fields.

Output Schema

NameRequiredDescriptionDefault
metaYes
errorNo
hintsYes
createdNo
monitorNo

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.9/5.0
Behavior5/5

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

Annotations already say this is a non-read-only, non-destructive, non-idempotent create operation, and the description adds substantial behavior beyond that: creation costs 0 credits, each check charges for its calls, preview avoids creation, the first check runs within five minutes, and changes are reported from the second check onward. It also documents the InvalidTarget error for bad fields and states that monitor checks read live data rather than cache.

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 long, but the complexity of seven presets justifies much of the detail. It is well structured with purpose, use/not-for, returns, field details, cost, and example, though the middle field enumeration is dense and could be slightly more scannable.

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?

Given 6 parameters, nested preset fields, and the create-vs-preview distinction, the description covers what an agent needs to invoke it correctly. The output schema exists, and the description still summarizes the returned record and preview behavior usefully.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the freeform fields object would be opaque without the description's per-preset breakdown. The description defines constraints such as keyword limits, platform defaults, page counts, entry limits for accounts/reviews/brands/questions, and cadence options, adding major meaning beyond the schema.

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 opens with a specific verb and resource: it sets up a monitor that repeats checks and keeps results so changes can be reported. It clearly distinguishes creation from reading changes by routing the latter to monitoring_get_changes, and it names the presets and their fields.

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 when-to-use phrases and a clear 'Not for' section that points one-off checks to the underlying search tools. It also says to preview the monthly cost first, create only after user agreement, and include a purpose description for future readers.

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