Skip to main content
Glama

devtune_get_404_demand

Read-onlyIdempotent

Get project-scoped 404 Demand for one published window, separated into credible content-intent clusters and likely scanner or technical noise, with materialization state, machine-traffic sensor coverage, and inferred project relevance. windowDays 30 (default) is the window opportunities and actions use; 7 is mined from the same run over the last seven days, so its clusters, counts and ranking are its own. window gives the selected start and end dates and asOf, when the run that mined the clusters finished. window.coverage is read live when you call, with its own observedAt: coveredDays counts the days a crawler sensor that reports status codes recorded machine traffic. Hours recorded after asOf can raise it while the clusters stay as mined, so do not treat the two as one snapshot. Fewer covered days than windowDays means part of the window is unmeasured, not free of 404s. A null window with dataAvailability degraded means that window is not published, including after a failed run, which state still reports. Clusters prioritize project fit before request volume; unrelated demand remains visible but is excluded from automatic action suggestions. Optional hosts list each cluster's request counts for the 20 busiest request hosts across the window; a null host counts requests whose host is unknown or outside those hosts. When the window includes 404s from a source that reports page views only and cannot verify requests, the response names that source, its hosts and the qualifiers, and each cluster lists which of its hosts they came from; provenance with state unavailable means that could not be checked.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "devtune_get_404_demand"
  }
}

Input Schema

NameRequiredDescriptionDefault
windowDaysNoPublished 404 Demand window in days: 7 or 30. Defaults to 30.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / windowDays
      Added value: +{
      +  "anyOf": [
      +    {
      +      "enum": [
      +        "7",
      +        "30"
      +      ],
      +      "type": "string"
      +    },
      +    {
      +      "enum": [
      +        7,
      +        30
      +      ],
      +      "type": "number"
      +    }
      +  ],
      +  "description": "Published 404 Demand window in days: 7 or 30. Defaults to 30."
      +}
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

The annotations already mark this as read-only, idempotent, non-destructive, and closed-world, but the description adds substantial non-obvious behavior: live coverage can diverge from mined clusters, a null window with degraded dataAvailability means no published window, null hosts represent unknown/outside-host requests, and provenance may be unavailable. These details materially help an agent interpret the result and do not contradict 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.

Conciseness3/5

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

The purpose is front-loaded, and the content is relevant, but the description is a single dense paragraph with long compound sentences. Given the complexity and lack of an output schema, most details earn their place, but the structure could be clearer with better separation of return-shape, coverage, and host/provenance semantics.

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?

No output schema exists, so the description carries the full burden of explaining return semantics, and it does so thoroughly: it covers clusters, materialization state, live coverage versus mined clusters, degraded/null windows, host counts, and provenance limitations. An agent has enough context to call and interpret the tool correctly.

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?

Although the schema fully documents the single windowDays parameter, the description adds meaningful semantics beyond the schema by explaining that 30 is the default used by opportunities/actions and that 7 is mined from the same run with its own clusters, counts, and ranking. This is a real clarification of parameter impact, though it applies to only one parameter.

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: 'Get project-scoped 404 Demand' for one published window, and immediately specifies that results are separated into credible content-intent clusters and likely scanner/technical noise. It also names the returned dimensions (materialization state, sensor coverage, project relevance), making the tool's scope clear without needing to open 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 Guidelines4/5

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

The description gives clear usage context for the two window choices: 30 is the default used by opportunities and actions, while 7 is separately mined with its own clusters, counts, and ranking. It does not explicitly state when not to use this tool or name an alternative sibling, which keeps it short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources