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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It openly states that the request is free, that requests are catalogued to inform future data builds, and that no identifying information is stored—only the text of the request. This provides meaningful side-effect and privacy context beyond the bare schema, though it does not cover response format or error behavior.
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 with no redundancy: the first emphasizes the free nature, the second explains the action and expected result, and the third covers privacy and side effects. Every sentence earns its place and the key behavioral points are front-loaded.
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?
This is a simple one-parameter tool with no output schema, so the description must explain both input and expected output. It does so clearly: describe the needed data and receive a yes/no plus an MCP endpoint if available. Side effects and privacy are also covered, making the description sufficient for an agent to invoke the tool correctly.
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%, so the baseline is 3. The description adds value by clarifying that 'need' is free-form natural language and not restricted to URLs, which is nontrivial guidance beyond the schema's 'What you are looking for.' This helps an agent craft better parameter values.
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 that the tool accepts free-form requests for data and returns whether the service can supply it, plus the MCP endpoint if available. This distinct purpose—discovery rather than direct retrieval—differentiates it from URL-specific siblings like resolve_url and url_headers. The phrase 'anything, not just URLs' reinforces its broad scope.
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 gives clear context: use this tool when you need to find out if a data service exists for a need expressed in natural language. It implies broad applicability ('anything, not just URLs') and indicates that the tool returns availability rather than data itself. However, it does not explicitly name sibling tools or state when not to use them, so it falls short of full alternative routing.
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 purpose: demand_report and request_data split aggregate demand from individual submissions, while resolve_url, site_pages, and url_headers cover separate URL-inspection workflows. There is no real overlap after reading the descriptions.
Names are readable and descriptive but do not follow one pattern: request_data and resolve_url use verb_noun, while demand_report, site_pages, and url_headers use noun_noun or adjective_noun. The inconsistency is noticeable but not chaotic.
Five tools is a reasonable size and each tool contributes a distinct function. The slight scope mismatch is that demand_report and request_data are data-marketplace tools under an 'URL Intelligence' server name, but the count itself is appropriate.
The URL side covers redirect resolution, sitemap enumeration, and header inspection, which covers the core stated purpose well. Minor gaps exist, such as no direct page-content fetching and no explicit way to browse child sitemaps automatically, but nothing that would force an agent into a dead end.