Baromio

Create Monitor Tool

create-monitor

Create a website or service monitor for the current user. Requires Full Access MCP token and eligible paid plan.

Input Schema

Name	Required	Description
`url`	No	URL to monitor: required for http and keyword types (e.g., https://example.com)
`host`	No	Hostname or IP address: required for tcp, ping, and dns types (e.g., db.example.com)
`name`	Yes	Name of the monitor (e.g., My Personal Website)
`port`	No	TCP port number 1–65535: required for tcp type (e.g., 5432)
`type`	No	Type of check: http, keyword, tcp, ping, dns, or heartbeat (Pro+, passive inbound check-in — see the returned ping URL)
`keyword`	No	Keyword to search for: required for keyword type
`timeout`	No	Response timeout in seconds before the check fails: 5, 10 or 15. Default: 10
`monitor_ssl`	No	True to monitor SSL certificate expiry (http/keyword only). Defaults to true for https:// URLs; send false to turn it off.
`keyword_type`	No	Alert when keyword exists or not_exists
`notify_uptime`	No	True to receive uptime notification events
`check_interval`	No	Frequency of checks in seconds (e.g. 300 for 5 minutes)
`monitor_domain`	No	True to monitor underlying domain registration validity (http/keyword only)
`dns_record_type`	No	DNS record type: required for dns type
`monitor_consent`	No	True to enable the weekly Consent Scan, which records the cookies the page sets before and after consent (http/keyword only, counts toward the plan's Consent Scan limit). Reports observations, never a compliance verdict.
`request_headers`	No	Optional HTTP request headers as objects with name and value
`dns_expected_value`	No	Optional expected DNS value for hijacking detection (e.g., 93.184.216.34)
`monitor_page_speed`	No	True to enable Page Speed monitoring when allowed by plan
`pinned_region_code`	No	Location this monitor is checked from. Use list-check-regions for valid values; omit or send an empty string for automatic selection.
`private_location_id`	No	UUID of one of your own Private Locations to check this monitor from instead of the Baromio fleet. Use list-private-locations for valid values. Only http, keyword, and tcp types are eligible.
`accepted_status_codes`	No	HTTP monitors only: status codes 400-599 (at most 10) to count as up in addition to 200-399, for a URL that answers 401, 404 or 503 on purpose. Send an empty array to clear the list. Not available for keyword monitors.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 1, 2026

changedInput schema / properties / timeout / description

Previous value: -"Timeout in seconds before marking down"New value: +"Response timeout in seconds before the check fails: 5, 10 or 15. Default: 10"

Changed1 schema field changedOct 23, 2026

addedInput schema / properties / monitor_consent

Added value: +{
+  "description": "True to enable the weekly Consent Scan, which records the cookies the page sets before and after consent (http/keyword only, counts toward the plan's Consent Scan limit). Reports observations, never a compliance verdict.",
+  "type": "boolean"
+}

Changed1 schema field changedOct 12, 2026

changedInput schema / properties / monitor_ssl / description

Previous value: -"True to monitor SSL certificate validity (http/keyword only)"New value: +"True to monitor SSL certificate expiry (http/keyword only). Defaults to true for https:// URLs; send false to turn it off."

Changed1 schema field changedOct 10, 2026

addedInput schema / properties / accepted_status_codes

Added value: +{
+  "description": "HTTP monitors only: status codes 400-599 (at most 10) to count as up in addition to 200-399, for a URL that answers 401, 404 or 503 on purpose. Send an empty array to clear the list. Not available for keyword monitors.",
+  "items": {
+    "type": "integer"
+  },
+  "type": "array"
+}

Changed1 schema field changedOct 6, 2026

addedInput schema / properties / private_location_id

Added value: +{
+  "description": "UUID of one of your own Private Locations to check this monitor from instead of the Baromio fleet. Use list-private-locations for valid values. Only http, keyword, and tcp types are eligible.",
+  "type": "string"
+}

First observedSep 26, 2026

TDQS

B3.3/5.0

Behavior3/5

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

Annotations only declare openWorldHint, so the description carries most of the burden; it usefully discloses the auth scope and plan requirement that annotations omit. It says nothing about side effects, whether the monitor starts checking immediately, rate limits, or the fact that heartbeat monitors return a check-in URL (that detail lives only in the schema).

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?

Two front-loaded sentences with zero filler: the purpose first, the prerequisite second. It is arguably too sparse for a 20-parameter tool, but no sentence is wasted.

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

Completeness2/5

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

For a mutation tool with 20 parameters whose required fields vary by monitor type, no output schema, and only a single openWorldHint annotation, this is thin. It omits the type-driven parameter dependencies, how to obtain pinned_region_code/private_location_id alongside the named list-check-regions and list-private-locations siblings, and what the call returns (e.g., the monitor id needed for subsequent get/update/delete calls).

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?

Schema description coverage is 100%, so every parameter including its type-conditional requirements is already documented in the schema. The description adds no parameter meaning and the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("Create a website or service monitor") and scopes it to "the current user". It is distinguishable from update-monitor and list-monitors by the verb, but the description never names the sibling used to modify or inspect existing monitors.

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

Usage Guidelines3/5

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

It gives a real prerequisite (Full Access MCP token, eligible paid plan), which an agent genuinely needs before attempting a call. However, there is no when-to-use-vs-alternative guidance: nothing says to use update-monitor for existing monitors, or that list-check-regions / list-private-locations should be called first for region and location parameters.

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

All Baromio 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?