Skip to main content
Glama
Sign In

BotsRated (beta)

by com.botsrated
OverviewDiscussionsAdmin

What changed (free watch)

what_changed
Read-onlyIdempotent

Call this when you have a handle from watch_free and you want what changed on that free watch. Free. Pass handle from watch_free (token is the same value). Reads measured changes for the host on that alerts-free watch only: price, payTo, valid 402, listing or status, and tools-hash or tool changes already stored, plus a receipt link when a receipt was stored. If since is omitted, the window starts when the watch was created (window.basis is since_watch_created). If that time is missing, the window is the last 7 days. Confirm the email before the first read. Not charged. A paid plan token is rejected. changes_since stays the plan-bearer tool.

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": {
      "handle": "<handle>"
    },
    "name": "what_changed"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax events, 1 to 100. Defaults to 50.
sinceNoOptional ISO-8601 time. Omit it to start when this watch was created.
tokenNoSame value as handle. Used only when handle is omitted.
handleYesFree watch handle from watch_free. Same value as token. Pass it on every call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / required
      Added value: +[
+  "handle"
+]
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent/non-destructive annotations by disclosing cost ('Free. Not charged.'), auth constraints (paid plan tokens are rejected, email must be confirmed first), the default time-window fallback (watch creation, else last 7 days, reported as window.basis), and the returned fields including the conditional receipt link.

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-loads the routing condition, which is the highest-value information, and has no filler sentences. It is mildly repetitive, restating 'Free' and 'Not charged' and the token/handle equivalence that the schema already carries.

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?

With no output schema, the description compensates by listing what is returned and when the receipt link appears. Combined with cost, rejection behavior, and the default-window rule, an agent has everything needed to call this correctly and interpret the result.

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 coverage is 100%, so the baseline is 3. The description matters mostly for `since` (default window = watch creation, falling back to 7 days) and `token`/`handle` equivalence, but the schema already states both of these, so it adds little meaning beyond the structured fields.

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?

States a specific verb and resource ('what changed on that free watch') and enumerates exactly which change classes are read: price, payTo, valid 402, listing or status, tools-hash or tool changes, plus a receipt link. It also names the sibling it is not (changes_since is the plan-bearer tool), so an agent can route correctly without opening the schema.

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?

Gives an explicit entry condition ('when you have a handle from watch_free'), a prerequisite ('Confirm the email before the first read'), and an exclusion ('A paid plan token is rejected'), plus the alternative for paid tokens (changes_since). When-to-use, when-not, and the alternative are all present.

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

All BotsRated (beta) toolsInspect
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