Skip to main content
Glama

Report data you expected but did not find

request_missing_data

Report data you expected and did not find. Free, no auth. looking_for is required and at most 500 characters. Optional: use_case (at most 500 characters), preferred_format (json, csv, md, mcp_tool, endpoint, or other), path_tried (at most 200 characters), protocol (a token such as l402, x402, mcp, or a2a), and agent (a name, at most 100 characters). Unknown fields are rejected. The text is stored for the operator. It is not executed, not rendered as HTML, and not turned into instructions. There is no public list. Output is { id, status } with status accepted. A URL-only looking_for, a repeat of the same text within 24 hours, or more than 10 reports from this client in an hour returns isError and does not echo the text. The same report is POST https://api.agentpaywire.com/v1/feedback.

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": {
      "looking_for": "<looking_for>"
    },
    "name": "request_missing_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
agentNoOptional name, at most 100 characters.
protocolNoOptional token, for example l402, x402, mcp, or a2a. At most 40 characters.
use_caseNoOptional. What you would do with the data, at most 500 characters.
path_triedNoOptional. Path or URL you tried, at most 200 characters.
looking_forYesRequired. What you expected and did not find, at most 500 characters. Not only a URL.
preferred_formatNoOptional. One of json, csv, md, mcp_tool, endpoint, or other.

Output Schema

NameRequiredDescriptionDefault
idYes
statusYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Given only minimal annotations (readOnlyHint=false, destructiveHint=false, non-idempotent), the description carries the full behavioral burden and does so well: free/no-auth, character limits, unknown fields rejected, text stored for the operator and explicitly not executed/rendered/instruction-interpreted, no public list, output shape { id, status }, and precise error triggers (URL-only text, repeats within 24 hours, >10/hour) that return isError without echoing the text.

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 the essential purpose and the required field, then layered with constraints and failure modes in a logical order. A few clauses restate schema facts (the 500-character cap, unknown-field rejection), which is mildly redundant, but nothing pads meaningfully.

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 six-parameter write tool, the description is complete: it covers the required/optional split, all limits, the storage/execution guarantees, the failure cases, and even the return values despite an output schema existing. An agent has everything needed to call it correctly and interpret both success and error outcomes.

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 description coverage is 100%, so the baseline is 3; the description adds real semantic value beyond it by stating constraints the schema implies but does not spell out as behavior, notably that a URL-only looking_for is rejected and that unknown fields are rejected, plus enumerating the preferred_format tokens.

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?

The description states a specific verb and resource: 'Report data you expected and did not find,' and immediately clarifies the effect ('The text is stored for the operator'). This is a write/report tool that is clearly distinguishable from the sibling set, which is entirely get_/list_/search_/submit_ reads, so an agent will not confuse it for a retrieval tool despite the 'request_' name.

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?

Usage is implied by the purpose statement rather than stated: it never explicitly says when to prefer this over other means of feeding back information. It does note that 'The same report is POST https://api.agentpaywire.com/v1/feedback,' which hints at an alternative channel, but there is no explicit when-to-use or when-not-to-use guidance.

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