request_dataFREE, no payment. Describe in your own words the data you are trying to buy — anything, not just web pages — 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 provided, the description carries the full behavioral disclosure burden and does so well: it states the tool is free ('no payment'), that requests are catalogued for future data-building, that nothing identifying is stored, and that the response indicates service availability plus endpoint. It stops short of describing the exact behavior when no matching service exists, but the core traits are disclosed.
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 earning its place: cost, function/response, and privacy/cataloging behavior. The key differentiator ('FREE, no payment') is front-loaded, and the purpose statement precedes the caveats. Slightly verbose in the middle section, but well-organized.
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 simple single-parameter tool with no output schema and no annotations, the description covers what an agent needs: what to submit, what to expect back (availability + endpoint), and behavioral caveats (cataloguing, privacy). The only gap is the precise response structure when the service does not supply the requested data, which the absent output schema forces the description to carry.
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 coverage is 100% and the schema already documents 'need' with an example. The description adds meaning beyond the schema by specifying that the input is freeform natural language ('in your own words') and that it accepts any data type, not just web pages, which clarifies the expected input format and scope.
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 states a specific action and resource: describe the data you want and receive whether the service supplies it plus the MCP endpoint. It clearly distinguishes itself from the page-focused siblings (read_page, page_links) by emphasizing 'anything, not just web pages', and the title reinforces the free-form request nature.
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?
Usage context is implied rather than explicit. 'Anything, not just web pages' signals the agent this is the general-purpose discovery tool and contrasts with the page-oriented siblings, but no sibling is named and there is no explicit when-to-use/when-not-to-use guidance or exclusion statement.
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.
Each tool has a clearly distinct role: read_page extracts page content, page_links extracts hyperlinks, request_data submits a data request, and demand_report reads aggregate demand. There is no real overlap that would cause an agent to pick the wrong tool.
All names are lowercase snake_case two-word names, which helps, but the pattern is mixed: read_page and request_data are verb-object while page_links and demand_report are noun-noun. The set is readable but does not follow a single predictable naming convention.
Four tools is a well-scoped size for a focused web-extraction and data-request server. Each tool earns its place and none feel redundant or missing as a category.
The core web extract loop is covered with page_links for navigation and read_page for content, plus demand_report and request_data for the data marketplace side. Minor gaps exist such as no batch/pagination handling or JS rendering, but those are explicitly out of scope and workable.