Consensus rankings for 75,000+ products across 2,600+ niches.
Scored across 3 tools
Each tool has a distinct core role: find_niche resolves requests to slugs, get_rankings fetches ranked lists, and get_item retrieves item details. However, get_rankings also accepts natural-language requests, overlapping with find_niche's main purpose and creating some potential for misselection.
All tool names follow a consistent verb_noun pattern with snake_case: find_niche, get_item, get_rankings. The verbs are clear and the objects match the tool's function.
Three tools is on the lower end, but the server's scope is narrow—niche ranking lookups—so each tool maps to a clear workflow step. The count feels sufficient rather than thin.
The set covers the core read-only workflow: resolve a niche, fetch rankings, and inspect an item. It lacks a broader browse/category tool, but for the stated purpose of returning ranked results with item details, the coverage is adequate.
Resolve a natural-language ranking request to one or more verified Lunoo niche slugs. Pass the user's request instead of guessing a slug. It handles common aliases, typos, and use-case terms, and returns item counts, match explanations, confidence, and tracked Lunoo URLs. Unsupported or unclear requests return an error instead of an unrelated fallback. Choose the closest returned slug, then call get_rankings with that exact slug. Never invent a niche slug or ranking.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language ranking request, for example "anime", "coffee makers", or "best laptop for video editing". Use the user's request rather than a guessed slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals behavior beyond annotations: it handles aliases and typos, returns item counts and confidence, returns errors for unclear requests instead of unrelated fallsbacks, and forbids inventing slugs. The read-only and idempotent annotations are consistent with this behavior; no contradiction.
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 compact, front-loaded with the tool's purpose, and each subsequent sentence adds practical guidance: how to call it, what it returns, error behavior, and the next step. No filler or redundancy that weakens the definition.
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?
With only one parameter and no output schema, the description adequately covers return fields, error behavior, and follow-up action. It tells the agent exactly what to do after resolution, making the tool self-sufficient in context.
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 already fully documents the query parameter, including examples and the instruction to use the user's request rather than a guessed slug. The description reinforces this but does not add meaningful new parameter-level guidance beyond the schema.
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 resolves a natural-language ranking request into verified Lunoo niche slugs. It uses a specific verb ('resolve'), names the resource ('niche slugs'), and explains its role as a lookup step before get_rankings, which distinguishes it from the siblings.
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?
It explicitly says to pass the user's request instead of guessing a slug, and tells the agent to call get_rankings with the returned slug. It does not explicitly contrast with get_item, but the workflow guidance is clear enough for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this after a ranking result when the user wants details about one item. Pass the exact item slug from a Lunoo result or URL. It returns the canonical Lunoo URL for the item and public structured metadata. This is read-only and must not be used to invent rankings that were not returned by get_rankings.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Exact item slug from a Lunoo ranking result or item URL, for example "frieren-beyond-journeys-end". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds value beyond annotations by stating what the tool returns (canonical Lunoo URL and public structured metadata) and by prohibiting use for fabricating rankings.
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 focused sentences with no filler. Usage context, required input, return value, and a critical constraint are all front-loaded and each sentence earns its place.
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, read-only lookup tool with rich annotations and no output schema, the description is largely complete. It states the return values at a useful level, though enumerating the specific metadata fields would make it fully complete.
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 already documents the single 'slug' parameter with a description and example, so schema coverage is 100%. The description reinforces that the slug must be exact and come from a Lunoo result or URL, but mostly restates information already present in the schema.
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?
States a specific verb ('get'), resource ('item details'), and the exact context (after a ranking result, for details about one item). Clearly distinguishes from siblings by tying it to individual item lookup rather than rankings or niche finding.
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?
Explicitly tells the agent when to use the tool: after a ranking result, when the user wants details about one item. It also gives a when-not instruction by warning not to use it to invent rankings not returned by get_rankings, effectively directing ranking needs to a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch ranked Lunoo results for a verified niche slug or natural-language request. It returns rank, score, description, confidence, and a canonical Lunoo URL for every item, plus the selected niche and resolution explanation. Prefer calling find_niche first, but this tool can resolve natural language itself. Cite the returned ranking URL and do not invent items, scores, or slugs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of ranked items to return, from 1 to 50. Defaults to 10. | |
| niche | Yes | Exact niche slug returned by find_niche, or a natural-language request such as "best laptop for video editing". Examples: "anime" or "japanese-city". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, and the description does not contradict that. It adds useful behavioral context by detailing the return contents (rank, score, description, confidence, canonical URL, selected niche, resolution explanation) and by warning against hallucinating results, which goes beyond the annotations.
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 four tight sentences with no filler. It front-loads the core purpose, then efficiently covers return values, routing guidance, and an important anti-hallucination constraint. Every sentence earns its place.
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 tool with only two parameters and no output schema, the description is remarkably complete: it explains what the tool returns, how to route to find_niche, when it can resolve natural language itself, and what the agent must not do. Nothing essential for correct invocation 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?
The input schema already describes both parameters fully, including the niche slug/natural-language dual meaning and the limit range, so the description adds limited new semantic value. It reinforces the natural-language option and 'verified' nuance but does not materially exceed the schema's coverage.
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 verb ('Fetch'), a specific resource ('ranked Lunoo results'), and the input format ('verified niche slug or natural-language request'). It clearly differentiates from siblings by naming find_niche and noting this tool can resolve natural language itself, so an agent can distinguish it from get_item and find_niche.
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 explicitly says 'Prefer calling find_niche first', giving the preferred alternative and the fallback condition. It also instructs the agent to cite the returned ranking URL and avoid inventing items, scores, or slugs, which is actionable usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_niche3 fields changedInput schema / properties / query / descriptionPrevious value: -"Search query (e.g., \"anime\", \"restaurants in Paris\")"New value: +"Natural-language ranking request, for example \"anime\", \"coffee makers\", or \"best laptop for video editing\". Use the user's request rather than a guessed slug."Input schema / properties / query / maxLengthAdded value: +240Input schema / properties / query / minLengthAdded value: +1get_item4 fields changedInput schema / properties / slug / descriptionPrevious value: -"Item slug (e.g., \"frieren-beyond-journeys-end\")"New value: +"Exact item slug from a Lunoo ranking result or item URL, for example \"frieren-beyond-journeys-end\"."Input schema / properties / slug / maxLengthAdded value: +160Input schema / properties / slug / minLengthAdded value: +1Input schema / properties / slug / patternAdded value: +"^[a-z0-9]+(?:-[a-z0-9]+)*$"get_rankings7 fields changedInput schema / properties / limit / descriptionPrevious value: -"Number of items to return (1-50, default 10)"New value: +"Number of ranked items to return, from 1 to 50. Defaults to 10."Input schema / properties / limit / maximumAdded value: +50Input schema / properties / limit / minimumAdded value: +1Input schema / properties / limit / typePrevious value: -"number"New value: +"integer"Input schema / properties / niche / descriptionPrevious value: -"Niche slug (e.g., \"anime\", \"japanese-city\")"New value: +"Exact niche slug returned by find_niche, or a natural-language request such as \"best laptop for video editing\". Examples: \"anime\" or \"japanese-city\"."Input schema / properties / niche / maxLengthAdded value: +240Input schema / properties / niche / minLengthAdded value: +1find_nicheget_itemget_rankingsConsensus 'best X for Y' rankings from ChatGPT, Claude, Gemini & Grok. Search, verdicts, history.
Smart home product intelligence: 1,080+ products with expert consensus scores and compatibility.
S-to-F tier lists for 208 product categories. Every placement cited, with barcodes.
Live rankings and pricing for 10,000+ AI products and LLMs. Free tier; paid data via x402.
Add one secure layer between your agents and this server.
