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

No annotations are provided, so the description carries the full burden, yet it says nothing about permissions, pagination, ordering, or whether the result includes sub-areas. It only communicates that this is a listing operation.

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. It is efficient, though its brevity borders on under-specification rather than deliberate 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?

With no output schema and no annotations, the description leaves unclear what an area record contains and how prefecture_id is obtained or structured. An agent can guess the intent but lacks enough to invoke confidently.

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 single required parameter prefecture_id has 0% schema description coverage, and the description adds no meaning about its format, source, or valid range. With one undocumented parameter the description must compensate and does not.

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 and resource ('List first level areas') that maps cleanly to the tool name and implicitly contrasts with the sibling area_level2. It does not explicitly name area_level2 as the alternative, so differentiation is inferred rather than stated.

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 choose this over area_level2 or stations, nor any prerequisite for obtaining a prefecture_id. The hierarchy is only hinted at by the word 'first level'.

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 disclosure burden. It says 'List', implying a safe read, but discloses nothing about return shape, ordering, pagination, or whether an invalid area1_id errors or returns empty.

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 front-loaded sentence with no wasted words, but its terseness is under-specification rather than economy — a clause on the ID source or return content would earn 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 simple one-parameter lookup, the description omits the essentials an agent needs: the meaning/source of area1_id and what the returned list contains (names, IDs, child counts). No output schema or annotations exist to fill these gaps.

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 0%, so the description must compensate for the single undocumented parameter. It never explains what area1_id is, where to obtain it, or whether it refers to an area_level1 identifier.

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 ('List') and resource ('second level areas inside a first level area'), so the geographic-hierarchy intent is clear. It doesn't explicitly name the sibling area_level1 as the source of parent IDs, but the hierarchy wording implicitly distinguishes it.

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 statement of when to use this versus area_level1 or the other lookup tools, and no prerequisite guidance (e.g., that area1_id must come from area_level1). Usage can only be inferred from the tool name and the hierarchy phrasing.

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 does not disclose what 'popular' means (rating? review count?), whether a radius can be controlled, how many results return, or whether this is a read-only lookup — leaving the agent with only the word 'popular' as a hint.

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 short sentence with the key concept front-loaded and no filler. Its brevity is honest rather than padded, though it comes at the cost of detail covered under other dimensions.

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 no annotations, no output schema, and 0% parameter description coverage, the definition would need to explain ranking, result shape, and coordinate format. It supplies none of these, so an agent cannot confidently invoke it over the search_restaurants sibling.

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 0% and both parameters are required numbers, but the description only vaguely ties them to 'a coordinate' — no format (decimal degrees), valid ranges, or coordinate system is specified.

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 verb and resource ('Get popular items') scoped to 'near a coordinate', but 'items' is undefined — it could mean venues, dishes, or reviews — and nothing distinguishes it from search_restaurants or suggest_search in the sibling list.

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 on when to use this versus search_restaurants or area_level1/area_level2, and no prerequisites or exclusions. The agent must guess based on geo-proximity versus keyword 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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing. It does not state whether this is read-only, what happens with an invalid restaurant_id, or what kind of detail (address, hours, rating, etc.) is returned.

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 single sentence is front-loaded and free of filler. Its brevity is not severely wasteful, but it borders on under-specification rather than a deliberate, information-dense summary.

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 no annotations, no output schema, and an undocumented parameter, the description is too thin for an agent to know what will be returned or how to source a valid restaurant_id. It should at least name the detail categories returned or point to the search tool that produces IDs.

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 0%, so the description must compensate for the undocumented restaurant_id parameter. It only implies a single restaurant is targeted, without saying what form the ID takes, where to obtain it, or whether it must come from search_restaurants or tabelog_get.

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 and resource ('Get details for one restaurant'), which distinguishes it from search_restaurants by scoping to a single entity. However, it does not distinguish it from restaurant_reviews, restaurant_menu, or restaurant_photos, which all also return details for one restaurant.

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 use this tool versus the many sibling restaurant_* tools. The only implied usage is that a known restaurant_id is required, which the schema already conveys through the required field.

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 behavioral burden yet says nothing about whether this is a safe read, whether the menu is paginated, whether prices/availability are included, or whether results are localized. Only the most obvious trait (a read) is implied by 'Get'.

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 short, front-loaded sentence with no filler. It is efficient but so terse that nothing beyond the core action is communicated.

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 simple one-param lookup with no output schema and no annotations, the description should at least say what is returned (sections, items, prices) and how to source the ID. Neither is present, so an agent cannot predict the response shape.

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 0%, so the single required restaurant_id is undocumented everywhere. The description does not say where the ID comes from (e.g., search_restaurants/restaurant_detail) or what form it takes, leaving the only parameter ungrounded.

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+resource ('Get a restaurant's menu list'), which clearly separates it from restaurant_reviews, restaurant_photos and restaurant_detail by implication. It doesn't explicitly name those siblings, so it stops short of a 5.

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 on when to call this versus restaurant_detail (which may already include menu data) or how to obtain the restaurant_id. The agent must infer the call context entirely.

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 and delivers nothing: it does not say whether results are paginated (despite a 'page' parameter), how many photos come back, what fields each photo has, or whether any auth/rate limits apply. It repeats the title-level fact and adds no behavioral context.

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 short sentence with no filler, but its brevity is under-specification rather than efficiency — there is no front-loaded scope, return shape, or pagination note to anchor the agent.

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 no annotations, no output schema, and a paged input whose semantics are undocumented, the definition leaves the agent guessing about the result shape and pagination behavior. Only the bare minimum needed to attempt a call is present.

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 0%, so the description must compensate and does not. It never mentions the 'page' parameter, so pagination semantics, page size, and how to know when to stop are entirely undocumented; only 'restaurant_id' is loosely implied by the word 'restaurant's'.

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 names a specific verb and resource (get + a restaurant's photos), which is enough to tell it apart from siblings like restaurant_reviews or restaurant_menu. It stops short of explicitly contrasting with those siblings, but the resource noun does the disambiguating work.

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 versus restaurant_detail (which may also return photos) or any other sibling, and no prerequisites or exclusions are stated. The agent must infer usage entirely from the name.

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 doesn't disclose pagination behavior, result ordering, whether reviews are capped, error behavior for invalid IDs, or whether the call is read-only/safe — all of which matter for a review-listing 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?

A single clean, front-loaded sentence with no waste, but its brevity comes from under-specification rather than from disciplined editing.

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 simple two-parameter read tool with no output schema, the agent still needs pagination semantics and a rough sense of the returned review fields; neither is present, leaving the definition underpowered for correct invocation.

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 0%, so neither parameter is documented anywhere. The description implies restaurant_id by saying 'for a restaurant' but says nothing about the 'page' parameter, its default of 1, or what page size to expect.

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 and resource ('Get reviews for a restaurant'), which naturally separates it from siblings like restaurant_detail, restaurant_menu, and restaurant_photos. It stops short of explicitly naming those alternatives or clarifying scope (all reviews vs. a page).

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 statement of when to use this tool versus restaurant_detail or restaurant_photos, no prerequisites, and no note on how pagination should be driven. The agent must infer all usage context from the tool name alone.

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 behavioral burden but only implies a read via 'Get'. It doesn't say whether status is real-time or cached, whether it requires the restaurant to be in a reservation network, or whether unavailable restaurants error out or return an empty result.

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 tight, front-loaded sentence with no redundancy. It is efficient, though the brevity contributes to the missing behavioral detail rather than compensating for it.

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 no annotations and no output schema, the description leaves key questions unanswered: how many days 'next few days' covers, what the vacancy status values look like, and granularity (per-slot vs per-day). The agent has no structured fields to fall back on.

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 0% and the single parameter restaurant_id is undocumented in both schema and description. It doesn't explain how to obtain an ID (e.g., from search_restaurants) or what format is expected beyond the integer type.

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?

A specific verb ('Get') and resource ('vacancy status') scoped to a restaurant and a near-term horizon. It is clearly distinguishable from siblings like restaurant_detail, restaurant_menu, and restaurant_photos, though the differentiation is implicit rather than stated.

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 on when this tool is preferred over restaurant_detail or search_restaurants, and no prerequisites mentioned. The agent must infer that this is for checking availability, and there is no hint whether restaurant_detail already returns vacancy data.

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 behavioral burden. It lists some allowed parameter values and an ID prerequisite, but does not explain what the search types mean, how latitude/longitude/range interact, pagination behavior, result limits, or what the response contains.

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 front-loaded with purpose and then parameter value lists, with little wasted text. It is dense and readable, though the run-on enumeration of parameter values is less structured than it could be.

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 10-parameter tool with no annotations and no output schema. The description omits too much: it does not clarify how the search modes work, how coordinates and range are used, pagination defaults, or what a caller receives back.

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 0%, so the description must supply parameter meaning. It does add important domain values for search_type, area_datatype, genre_datatype, and sort_mode, and points to the source for area/genre IDs, but leaves page, range, latitude, and longitude entirely unexplained.

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 verb and resource: 'Search Japanese restaurants.' It distinguishes the tool from detail-oriented siblings only indirectly by naming the area tools and suggest_search as ID sources, not by explicitly contrasting use cases.

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 a useful prerequisite: 'Get ids from the area tools and suggest_search.' However, it does not explain when to choose this tool over restaurant_detail, suggest_search, or popular_nearby, nor does it state exclusions or required combinations.

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 and discloses almost nothing: read-only behavior is only implied by 'List', and there is no mention of result volume, ordering, pagination, or what a station record contains.

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 short sentence with no padding, which is appropriately front-loaded. However, the terseness comes at the cost of the details an agent needs, so brevity here reads as under-specification rather than economy.

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?

No annotations, no output schema, and an undocumented parameter mean the description must compensate for all of it, and it does not. Nothing about the hierarchy linking area_level1/area_level2 to area2_id is explained, leaving the calling workflow 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 coverage is 0% for the single required parameter, so the description is the only source of meaning. 'Second level area' hints that area2_id refers to a level-2 geographic area, but it gives no format, range, or how to obtain a valid id.

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 verb+resource ('List stations') is specific, but the scope phrase 'second level area' is unexplained jargon that only indirectly maps to the area2_id parameter. An agent can guess this retrieves stations within a level-2 area, but must infer the relationship rather than being told.

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 use this versus siblings such as area_level2, popular_nearby, or tabelog_get, nor any stated prerequisite for obtaining an area2_id. The agent is left to infer the workflow entirely.

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 does not state that this is a read-only, side-effect-free lookup, nor does it describe return shape, result limits, or what happens when a keyword yields no matches. 'Autocomplete' hints at lightweight suggestions but no behavioral specifics are given.

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 well-formed sentence with no filler and the purpose front-loaded. It is efficient, though its terseness borders on under-specification rather than being optimally informative.

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 3-parameter tool with no annotations and no output schema, the description should explain the geo parameters and the nature of returned suggestions. It omits the lat/long semantics entirely and gives no sense of result shape, leaving the agent under-equipped to call it 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 0%, so the description is responsible for documenting three parameters. It mentions only 'keyword' implicitly and says nothing about current_latitude/current_longitude, which control proximity-based suggestions — a significant unexplained gap.

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 verb 'Autocomplete' with resources 'restaurants, areas and genres' is specific and distinguishes it in spirit from search_restaurants (completions vs full search). However, the description does not explicitly differentiate itself from its sibling search_restaurants or explain what an 'autocomplete' result is, leaving the distinction to inference.

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 is only implied by the word 'Autocomplete' — the agent can infer it is for typeahead-style suggestions, but there is no explicit when/when-not guidance and no reference to the obvious alternative search_restaurants for full 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, the description carries full behavioral burden. It usefully declares the operation 'Read-only' and points to the spec for valid endpoints, but says nothing about auth requirements, error behavior for unknown endpoints, or response shape — significant gaps for an unannotated 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?

A single front-loaded sentence with zero waste that names the operation, scope, and spec reference. Nothing to trim.

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 generic escape-hatch GET with no annotations and no output schema, an agent needs the endpoint format, how params are passed, and where the spec lives. The spec pointer and path prefix are present, but the params passthrough and error/response behavior are missing, leaving it only partially 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?

Schema coverage is 0%, so the description must explain both parameters. It adds meaning for 'endpoint' (a name under the /tabelog_inbound_appli/ path) but the 'params' passthrough object — the key to actually using a generic GET — is entirely unexplained, leaving the more important half undocumented.

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) and resource scope (any endpoint under /tabelog_inbound_appli/), and the phrase 'escape hatch' distinguishes it from the named sibling tools like restaurant_detail or search_restaurants. It is clear this is a raw passthrough for endpoints not covered by a dedicated tool, though it doesn't name any sibling explicitly.

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?

'Escape hatch' implies fallback usage — call this when no dedicated tool fits — and 'see tabelog-api-spec' points to where endpoint names come from. But there is no explicit statement of when to use this versus the 11 named siblings, nor any exclusion guidance.

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