Nerf Watch

Nerf Watch history

get_nerfwatch_history

Read-onlyIdempotent

Retained public Nerf Watch score history for one model, oldest first, including each point's suite version. The required model id is available from get_nerfwatch_scores. Missing days are missing, not zero; comparisons are within one suite version. A lower score is a lower score on this suite, not proof that a provider changed a model. Unofficial, not affiliated with OpenAI or Anthropic. Source: https://tokenusage.dev/nerfwatch

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": {
      "model": "<model>"
    },
    "name": "get_nerfwatch_history"
  }
}

Input Schema

Name	Required	Description	Default
`model`	Yes	A model id from get_nerfwatch_scores: 1 to 64 lowercase letters, digits, dots, underscores or hyphens, starting with a letter or digit.

Output Schema

Name	Required	Description
`name`	Yes	The selected model's published display name.
`model`	Yes	The selected model id.
`source`	Yes	The fixed credit URL, https://tokenusage.dev/nerfwatch. When showing the data to other people, show Data: tokenusage.dev linked to this URL on the same screen or in the same message. Personal use needs no visible credit. API and MCP relays must retain source and pass on this credit condition.
`history`	Yes	Retained points, oldest first, including older suite versions; days without a run are missing, not zero.
`provider`	Yes	The selected model's published provider name.
`generatedAt`	Yes	When the cached data was read, ISO 8601 UTC; the cache TTL is 300 seconds from read start.
`historyDays`	Yes	The returned retention bound per model; clients read this setting rather than assuming 366.
`dataUpdatedAt`	Yes	When the newest retained run across the dataset was stored, ISO 8601 UTC; null without runs. This is dataset metadata, not a timestamp for this model alone.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive, closed-world, so the description is free to add real behavioral context: ordering (oldest first), per-point suite version, and the semantic rule that missing days are missing rather than zero. It also pre-empts a likely misinterpretation (a lower score is not proof a provider changed a model), which is exactly the kind of context annotations cannot carry.

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-loaded with what the tool returns, then caveats, then provenance. The interpretive warnings earn their place, but the affiliation disclaimer and source URL add bulk that could be trimmed or moved without losing agent-relevant information.

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?

For a single-parameter read tool with a full output schema and complete annotations, everything an agent needs to call it correctly and interpret the results is present: input provenance, ordering, gaps, and suite-version comparability.

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

Parameters4/5

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

Schema coverage is 100%, so the pattern and format are already documented; the description adds the non-obvious provenance of the value — it must come from get_nerfwatch_scores. That is genuine meaning beyond the schema, though it does not discuss format edge cases.

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 — retained public score history for one model — and adds concrete scope details (oldest first, each point's suite version). It is clearly distinguishable from the sibling get_nerfwatch_scores, which provides the model ids and current scores.

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?

Explicitly tells the agent where the required model id comes from (get_nerfwatch_scores), which effectively routes between the two siblings. It stops short of saying when to prefer history over current scores, but the data-shape cues make the intent clear.

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

All Nerf Watch 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.