request_dataFREE, no payment. Describe in your own words the data you are trying to buy — anything, not just URLs — and get back whether we operate a service that supplies it, with the MCP endpoint if so. Every request is catalogued so repeatedly-requested data gets built. Nothing identifying is stored, only the words of the request.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | What you are looking for. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / need / examplesAdded value: +[
+ "live electricity spot prices by ZIP"
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and meets it: it states the operation is free, that requests are catalogued, that no identifying information is stored, and what the response will contain. This gives an agent a clear picture of side effects and privacy expectations beyond the bare schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying necessary information: cost, expected outcome, and data-handling behavior. The description is front-loaded with the most actionable detail and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description fully equips an agent: what to submit, what to expect back, cost implications, and privacy guarantees. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the 'need' parameter with an example. The description reinforces that the parameter can be free-form ('anything, not just URLs'), but adds no new semantic detail beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: users describe in their own words what data they want, and the tool returns whether a service supplies it plus the MCP endpoint. It distinguishes itself from sibling tools by explicitly covering 'anything, not just URLs,' positioning it as a free-form request tool rather than a concrete URL/page/header resolver.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when the desired data isn't easily expressed as a URL and you want to check availability before buying. It does not explicitly name sibling tools or state 'use resolve_url/site_pages/url_headers for URL-based lookups,' so some inference is required, but the 'anything, not just URLs' phrasing provides reasonable context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The three URL tools are sharply separated: resolve_url handles redirects, site_pages enumerates sitemaps, and url_headers inspects headers. The only mild ambiguity is demand_report versus request_data, but their descriptions make the read-aggregate vs query/submit distinction clear enough.
All names are snake_case and readable, but the set mixes imperative verb phrases (resolve_url, request_data) with bare noun compounds (site_pages, url_headers, demand_report). There is no consistent verb_noun or noun_noun convention across the server.
Five tools is a manageable count and not bloated. However, demand_report and request_data are data-marketplace features rather than URL intelligence, so the scope is slightly broader than the server name implies.
The URL tools cover a coherent pre-fetch workflow: redirect resolution, header/status profiling, and sitemap enumeration. There is no content-fetch or reputation-check tool, but those appear to be out of scope, and demand_report/request_data provide a way to ask for missing data, so the surface has no dead end.