demand_reportFREE, no payment. The aggregate of what agents have told us they are looking for, most-requested first, with the categories nothing available yet serves.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Window in days, default 30, max 90. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure and does reveal that the tool is free, returns an aggregate ranking, and includes categories with no available service. However, it does not disclose data source, freshness, output limits, or whether the report is read-only, leaving several behavioral traits unstated.
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 short and front-loaded with the free caveat, but 'FREE, no payment' is redundant and the final clause 'with the categories nothing available yet serves' is grammatically tangled. The unclear phrasing reduces the value of what would otherwise be a concise description.
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?
The description conveys the core output concept, ordering, and gap categories, but omits output shape, the effect of the days window, and any usage guidance. Since there is no output schema and no annotations, these omissions leave an agent with only partial knowledge of how to invoke and interpret 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?
The only parameter, 'days', is fully described in the schema with default and maximum values, so the description does not need to repeat it. The description adds no extra semantic nuance about how the window affects the report, but the schema already provides complete coverage, so baseline 3 applies.
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 identifies the resource as a free aggregate report of what agents are asking for, sorted by request frequency, and mentions unmet categories. It lacks an explicit action verb like 'returns' or 'lists,' and it does not explicitly distinguish itself from sibling tools such as request_data, so it is clear but not maximally precise.
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?
No guidance is given on when to use this tool versus alternatives or when not to use it. The 'FREE, no payment' note implies a cost consideration but does not name any sibling tools or conditions, leaving the usage dimension largely unaddressed.
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.