Search Mountain Project for climbing routes and areas by name or keyword. Filter results by entity type and limit to find the information you need.
Search Mountain Project for routes and/or areas by name or keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results | |
| query | Yes | Search query | |
| types | No | Entity types to search (default: routes and areas) |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says 'Search' which suggests a read-only operation, but it does not explicitly state that there are no side effects, nor does it mention any authentication requirements or output behavior. It is honest but incomplete.
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 a single, clear sentence with no unnecessary words. It is well-structured and immediately understandable, earning the highest score for conciseness.
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 is adequate for a basic search, but it does not mention what the output looks like, pagination, or any constraints beyond the parameters. Given that there is no output schema, it would benefit from a note about the result format or how to interpret the returned list. It is not incomplete enough to be a 2, but lacks some contextual detail.
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 covers all three parameters with descriptions ('Max results', 'Search query', 'Entity types to search'), giving 100% coverage. The tool description adds a little clarity by specifying 'by name or keyword' for the query parameter, but it does not significantly enhance understanding 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 verb 'Search' and the resource 'Mountain Project' with the specific objects 'routes and/or areas' by name or keyword. This distinguishes it from sibling tools like mp_get_route or mp_find_routes, which have more specific purposes.
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 mentions 'by name or keyword' which gives some hint about usage, but it does not explicitly explain when to use this tool versus alternatives like mp_find_routes or mp_get_area. There is no direct guidance on selecting this over siblings, though it is implied as a general search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.