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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since there are no annotations, the description carries the behavioral disclosure burden. It fully discloses that the service is free, that every request is catalogued, that repeated requests drive development, and that no identifying information is stored. It also states what the return will be (whether a service exists and the endpoint if so). This is transparent and informative, though it does not mention potential side effects like rate limits or error cases.
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?
The description is concise, with each sentence contributing value: price (FREE), scope guidance, expected response, and privacy policy. It is front-loaded with the most important fact (free) and avoids fluff. Slightly verbose in the privacy clause but generally efficient.
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?
Given the tool has a single parameter and no output schema, the description adequately explains what the caller can expect (a yes/no response plus an MCP endpoint if available) and any side effects (cataloguing). It covers purpose, usage, return value, and privacy. Minor gaps include error conditions or format of the endpoint, but for a simple request tool this is sufficient.
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?
The schema description for 'need' is minimal ('What you are looking for') but has 100% coverage. The tool description adds meaning by explaining the parameter should be a natural-language description ('in your own words') and broadening scope ('anything, not just web pages'). This goes beyond the schema and clarifies the intent of the parameter, elevating it above the baseline of 3.
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 a specific verb ('describe the data you are trying to buy') and resource ('our service'), and the outcome ('get back whether we operate a service that supplies it'). It distinguishes itself from the sibling tools (page_links, read_page) by emphasizing 'anything, not just web pages', making its broader scope explicit.
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 this tool ('when you are trying to buy data') and explicitly excludes web-only focus, but does not name alternative tools or provide explicit when-not-to-use conditions. It gives context for use but lacks explicit routing to or away from sibling tools like read_page or demand_report.
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 serves a clearly distinct purpose: demand_report aggregates market demand, page_links extracts URLs, read_page fetches page content, and request_data handles custom data inquiries. There is no functional overlap or ambiguity between them.
Two tools follow a noun_noun pattern (demand_report, page_links) while two follow verb_noun (read_page, request_data). The mix is minor but inconsistent, yet all names remain intuitive and descriptive.
With four tools, the server is well-scoped for its dual purpose of web extraction and demand aggregation. Each tool earns its place, and the count is neither too thin nor excessive.
Core extraction capabilities—fetching readable content and enumerating links—are covered, with additional market intelligence tools. Missing advanced features like JavaScript rendering or screenshots are stated limitations rather than obvious gaps.