Skip to main content
Glama
Sign In
FluxProof

FluxProof

by equinoxaifinance-rgb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Start watching a page

fluxproof_create_monitor

Create a persistent monitor for a public webpage using your API key, run a baseline check, track changes, and send signed webhook alerts on a set schedule.

Instructions

Create a monitor using a buyer-owned FluxProof API key. Creates persistent state and performs a baseline check, consuming quota. Not idempotent: each call creates a new monitor.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "fluxproof_create_monitor"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesRequired: the full address of one public web page, for example https://example.com/ or https://store.example.com/products/item. Not a search phrase or product name. No sign-in, cookies, browser rendering or private-network targets.
labelNoOptional human-readable monitor label, up to 120 characters.
api_keyNoBuyer-owned FluxProof API key; a secret credential.
watch_termsNoOptional terms to track, each 2–80 characters; at most 20 distinct terms.
webhook_urlNoOptional public HTTPS webhook receiver; paid pass required. Delivery is signed and can occur when checks run.
interval_minutesNoRequested schedule in minutes. Free keys use 1440 (daily); paid passes have a 15-minute minimum.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.6/5.0
Behavior4/5

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

Beyond the annotations (which already flag readOnly=false and idempotent=false), the description discloses that the call creates persistent state, performs a baseline check, and consumes quota — meaningful operational context. The non-idempotent statement is somewhat redundant with idempotentHint=false, and it omits any note on rate limits or error behavior, keeping it below a 5.

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?

Three tight sentences with zero filler; the API-key prerequisite, the side effects, and the idempotency caveat are all front-loaded and immediately actionable.

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?

For a 6-parameter mutation tool with no output schema, the description covers creation semantics, side effects, and quota cost well. The one gap is that it never indicates what is returned (e.g. a monitor identifier) that the agent would need for follow-up calls, which is more relevant given no output schema exists.

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 the schema already documents all six parameters with detail (URL constraints, term limits, interval minimums). The description adds no parameter-level meaning beyond what the schema provides, which is the expected baseline of 3 when the schema does the heavy lifting.

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?

The description states a specific verb and resource ('Create a monitor') and reinforces it with the title's 'Start watching a page', making the core action unambiguous. It does not explicitly differentiate itself from siblings like fluxproof_check_now or fluxproof_preflight, so it falls short of a 5.

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

Usage Guidelines2/5

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

The description implies a prerequisite (a buyer-owned API key) but never states when to choose this tool over fluxproof_check_now, fluxproof_preflight, or fluxproof_get_free_key. There is no explicit when-to-use or when-not-to-use guidance, leaving the agent to infer selection from sibling names alone.

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

Deploy Server

Other Tools