Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations or output schema, the description carries the disclosure burden. It makes clear this is a status-check/read operation returning user info, but it does not describe behavior for an invalid session, prerequisites like a prior mp_set_session call, or the response shape.

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 concise, front-loaded sentence that conveys the main purpose without filler. Every word contributes meaning.

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 zero-parameter tool, this is minimally viable, but without an output schema or discussion of invalid-session behavior and dependencies, an agent is left uncertain about what the return value will look like in different states.

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 tool has zero parameters and 100% schema description coverage, so the schema fully defines the input surface. The description adds no parameter details, which is acceptable because there are no parameters to document.

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 action ('Check whether... valid') and resource ('Mountain Project session'), and notes that it returns user info. It is distinguishable from the sibling mp_set_session, though it does not explicitly name that alternative.

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?

There is no guidance on when to call this tool, such as before making authenticated requests, or how it relates to mp_set_session. The usage context is only implied by the name and description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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. 'Force-refresh' hints at a side effect (invalidating/refreshing local data), but it does not disclose whether authentication is required, how the refresh behaves if auth is missing, whether it makes a network request, or what happens to existing cached data.

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?

A single, front-loaded sentence with no filler. Every word contributes: the action, the scope, and the data source are all present.

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 zero-parameter tool, the description is mostly adequate, but with no output schema and no annotations, it should at least hint at authentication requirements or what the agent can expect after the refresh completes. The absence of any return/result information leaves a meaningful gap.

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 tool has zero parameters, so the schema already fully covers invocation requirements. The description correctly adds no parameter noise, and the baseline of 4 for zero-parameter tools 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 uses a specific verb ('Force-refresh') and identifies the resource ('your personal tick list from Mountain Project'). It is clear about the operation, though it does not explicitly name the sibling tool mp_list_ticks to draw a contrast, so it stops just short of full differentiation.

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 word 'Force-refresh' implies this tool is for updating cached tick data, so the usage context is somewhat inferable. However, there is no explicit guidance on when to prefer this over mp_list_ticks or mp_tick_stats, and no mention of prerequisites such as authentication.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full responsibility for behavioral disclosure, but it only states the action. It does not mention pagination, default size/order behavior beyond the sort description, authentication needs, rate limits, or the shape of the returned route data.

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?

A single, front-loaded sentence with no filler. Every word adds meaning, and it is immediately clear what the tool does.

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 plus a fully documented schema is enough to make a basic call, but without an output schema or annotations, an agent is left guessing about the return format and whether results are paginated or capped. The description could usefully add one sentence about the response.

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 description coverage is 100%, so each parameter is already documented. The description adds no parameter-specific detail, which is acceptable; the baseline of 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 uses a specific verb ('Find') with a clear resource ('routes in an area') and identifies the mechanism ('route finder filters'). This distinguishes it from sibling tools like mp_get_route (single route) or mp_get_area (area details), though it doesn't explicitly name them.

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 mention of 'in an area' implies this is the filter-based route-listing tool, which gives some context for selection. However, it never states when to prefer mp_find_routes over mp_search or mp_get_route, and no exclusions or alternatives are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. 'Get' clearly indicates a read-only operation, but the description does not disclose what 'detailed information' includes, how missing or invalid IDs are handled, or whether authentication is required. Basic behavioral intent is clear, but important details remain implicit.

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, front-loaded sentence that conveys the essential information with no filler. It is appropriately concise for a tool with one parameter.

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 one-parameter getter, the description covers the core operation but lacks details about the response content, error behavior, or prerequisites such as authentication. Without an output schema or annotations, these gaps are noticeable but not crippling for a simple read tool.

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 description coverage is 100%, with areaId documented as 'Mountain Project area ID'. The description only echoes that it is a numeric ID, adding no extra semantic meaning beyond the schema. Baseline 3 is appropriate.

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 uses a specific verb ('Get'), identifies the resource ('climbing area'), and specifies the access method ('by numeric ID'). This clearly differentiates it from siblings like mp_search (search-based) and mp_get_route (route-specific).

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 the tool is used when the caller already has a numeric area ID, but it does not explicitly state when to prefer this over mp_search or mp_resolve_id, nor any exclusions. Usage context is clear but not elaborated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get detailed information', implying a read operation, but does not disclose output shape, failure behavior, authentication needs, or any side effects. This is a thin description for a tool that could return complex route data.

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 one succinct sentence with no filler. It front-loads the action and resource, then states the identifying input. Every word contributes to the tool's purpose.

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 lookup tool, the description plus schema is largely sufficient to select and invoke the tool correctly. It could mention what information is returned or note that no auth is required, but the low complexity makes the current description acceptable.

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 description coverage is 100%, with the single routeId parameter already documented as 'Mountain Project route ID'. The description adds the word 'numeric', which matches the integer type but does not add meaningful new semantics 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 states a specific verb ('Get'), a clear resource ('detailed information about a climbing route'), and the key selection criterion ('by numeric ID'). This distinguishes it from siblings like mp_get_area and mp_search, which target different resources or use different lookup modes.

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?

Usage context is implied: an agent should call this when it has a numeric route ID and wants route details. However, there is no explicit guidance on when to prefer this over mp_search or mp_find_routes, nor any mention of prerequisites or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses a meaningful side effect: it will auto-fetch from MP when cache is empty or stale, revealing network and cache behavior not visible in the input schema. However, it does not explain cache freshness criteria, authentication requirements, or whether the returned data could be stale, so not all behavioral traits are covered.

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?

One sentence that immediately states the operation and the key caching behavior, with no filler or repetition of schema details. It is well structured and 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?

The tool has 6 optional filters and no output schema, and the description omits return value shape, pagination/limit behavior, and how it differs from mp_fetch_ticks. Without annotations, this leaves an agent under-informed for constructing the best call.

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?

All six parameters are fully described in the input schema, so the description does not need to repeat them. The description adds no extra meaning or examples for grade/area filter formats, leaving baseline schema value intact.

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 clear action ('List') and resource ('your personal ticks'), and indicates the MP data source and caching behavior. It does not explicitly distinguish itself from the sibling mp_fetch_ticks, leaving some ambiguity about when to prefer this over that tool.

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 about when to use this tool versus alternatives such as mp_fetch_ticks. The auto-fetch note implicitly says cache is handled, but there are no exclusions, prerequisites, or conditions specifying when a different tool should be chosen.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral disclosure burden. It clearly states the transformation performed (extracting a numeric route/area ID) and the accepted input formats, which is strong transparency for a simple resolver. It does not specify behavior for invalid or ambiguous inputs, but this is a relatively minor gap for a utility of this simplicity.

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, front-loaded sentence with no filler or redundant information. Every word contributes to explaining what the tool does and what inputs it accepts.

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 one-parameter utility with full schema documentation, the description covers the input forms and clearly states the expected output. The main missing piece is the exact return format or error behavior, but given the low complexity of the tool and the absence of an output schema, the description is largely 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 provides 100% coverage of the urlOrId parameter with a helpful description of accepted formats. The main description reinforces those formats but does not add substantial new semantic meaning beyond what the schema already documents, so a baseline score of 3 is appropriate.

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 uses a specific verb ('Extract') and clearly identifies the resource (numeric route or area ID) and the accepted input forms (URL or prefixed ID). This clearly distinguishes it from sibling tools like mp_search or mp_get_route, which operate on queries or resolved IDs rather than converting input into an ID.

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 the tool should be used when you have a Mountain Project URL or prefixed ID and need the numeric ID for subsequent calls, but it does not explicitly state when to use it versus alternatives. There is no explicit when-not-to-use guidance, though the intended context is fairly inferable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does 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.

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 only says 'set or refresh' without mentioning side effects like disk persistence (despite a persist parameter in the schema), whether prior authentication is needed, or what happens to the running session. This is a significant gap for a state-mutating tool.

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 concise sentence that immediately states the core action and target. It is front-loaded with the primary verb and resource, with no filler or redundant wording.

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 session-mutation tool with no output schema and no annotations, so the description needs to provide more operational context. It omits return behavior, side effects, and the authentication flow it participates in. While the schema thoroughly documents parameters, the description alone would not fully prepare an agent to call this tool correctly 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?

Schema description coverage is 100%, so the baseline of 3 applies. Each parameter already has a clear explanation ('ap_session cookie value', 'Save to session file'), and the tool description adds nothing beyond what the schema provides. No parameter semantics are missing or ambiguous.

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 uses specific verb-resource language ('Set or refresh the Mountain Project session cookie at runtime') and clearly distinguishes this tool from the read/search siblings like mp_search and mp_get_route. The purpose is immediately understandable.

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?

There is no explicit guidance on when to use this tool, when not to, or how it relates to the similarly authentication-oriented sibling mp_auth_status. The phrase 'at runtime' hints at dynamic use, but no prerequisites, exclusions, or alternative routing is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral disclosure burden. It states the operation is aggregation, but does not disclose what statistics are produced, whether it is read-only, how missing data is handled, or what output shape to expect. This is minimal behavioral transparency for a no-annotation tool.

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 one short, front-loaded sentence with no wasted words. It communicates the core action and scope immediately, though it lacks any structural breakdown of options or outputs.

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?

There is no output schema, so the description should compensate by explaining what the aggregate statistics look like, but it does not. It also does not clarify how yearFrom and yearTo interact, whether all years are included by default, or how grouped results are returned. For a tool with 3 parameters and no output schema, this is incomplete.

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 description coverage is 100%, and the schema already explains groupBy, yearFrom, and yearTo, including the enum values for groupBy. The description adds the 'personal tick list' scoping context, which is useful, but does not need to repeat parameter details. Baseline 3 is appropriate given the high schema 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 clearly states a specific verb ('Aggregate statistics') and a resource ('your personal tick list'), which makes the tool's core purpose understandable. It does not explicitly distinguish itself from siblings like mp_list_ticks or mp_fetch_ticks, but 'statistics' implies aggregation rather than raw listing.

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?

There is no guidance about when to use this tool versus alternatives such as mp_fetch_ticks or mp_list_ticks. The phrase 'your personal tick list' implies it operates on the user's own ticks, but no explicit context, exclusions, or alternative routing is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.