ground-truth-mcp

Create Monitor

create_monitor

Create persistent monitors that track URLs, pricing pages, package versions, endpoint status, vendor claims, or custom keyword patterns on a recurring schedule.

Instructions

Create a persistent monitor that tracks a URL, pricing page, package version, endpoint status, vendor claim, or custom keyword pattern over time. Monitors run automatically on their configured schedule (hourly/daily/weekly) via the Cloudflare cron trigger, or on demand with run_monitor_now. Results are stored in the Durable Object SQLite database. Requires a team API key.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	Human-readable name for this monitor.
`target_type`	Yes	What to monitor. url/endpoint: HTTP reachability and status. pricing_page: pricing signals (prices, plans, free tier). package: package version on npm or pypi (target_value as 'npm:pkg-name' or 'pypi:pkg-name'). vendor_claim: keyword presence at a URL (target_value=claim text, instructions=URL to check). custom_prompt: comma-separated keywords checked against a URL (target_value=URL, instructions=keywords).
`target_value`	Yes	Primary target. For url/endpoint/pricing_page/custom_prompt: a public https URL. For package: 'npm:package-name' or 'pypi:package-name'. For vendor_claim: the claim text to search for.
`instructions`	No	Supplementary instructions. For vendor_claim: the URL to check. For custom_prompt: comma-separated keywords. Optional for other types.
`schedule`	No	How often the monitor runs automatically. manual means only via run_monitor_now.	daily
`notification_destination`	No	Optional destination for change alerts (email or webhook URL). Stored for future use.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Unique monitor ID.
`name`	Yes	Monitor name.
`target_type`	Yes	Monitor target type.
`target_value`	Yes	Monitor target value.
`schedule`	Yes	Monitor schedule.
`created_at`	Yes	Creation timestamp ISO 8601.
`error`	No	Error message if creation failed.

Tool Definition Quality

A4.2/5.0

Behavior4/5

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

Annotations show readOnlyHint=false, destructiveHint=false. The description adds that it creates a persistent resource, runs automatically, and persists results, which is consistent and adds useful behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with purpose, and every part is informative. No fluff or repetition.

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?

Given the tool creates a monitor with 6 parameters (3 required) and has an output schema, the description covers purpose, execution, storage, and API key requirement. It does not explain the output, but that's expected with an output schema. Minor missing details like error conditions are not critical.

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

Parameters3/5

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

The input schema has 100% coverage with detailed parameter descriptions. The tool description summarizes target types and schedule but does not add significant new meaning beyond the schema, so baseline 3 applies.

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 clearly states the verb 'Create' and the resource 'persistent monitor', and lists the various target types (URL, pricing page, etc.), distinguishing it from siblings like list_monitors, delete_monitor, check_endpoint, etc. It is specific and actionable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains scheduling (automatic via cron or on-demand via run_monitor_now), storage in SQLite, and the requirement for a team API key. It provides context for when to use the tool but does not explicitly contrast with sibling tools like check_endpoint for one-time checks.

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

Install Server

Other Tools

Latest Blog Posts

Lightport: Open-Sourcing Glama's AI Gateway
By punkpeye on April 27, 2026.
open source
OpenAI
Tool Definition Quality Score (TDQS)
By punkpeye on April 3, 2026.
mcp
The Hackers Who Tracked My Sleep Cycle
By punkpeye on March 26, 2026.
security

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/anish632/ground-truth-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server