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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavioral context: incidental image URLs are dropped by default, and view:"full" returns TripAdvisor's entire record. This is concrete, beyond the structured annotations, and does not contradict them.

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?

Two purposeful sentences: the first enumerates the returned fields, the second explains the compact/full projection behavior. It is front-loaded with the core purpose and contains no filler or redundant restatement of the schema.

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, the description compensates by listing the main returned field categories and clarifying the default projection behavior. The main gap is the absence of guidance for selecting this tool over sibling location tools, but overall the description is sufficient for correct invocation given the low complexity and full schema coverage.

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 is 3. The description adds meaning to the view parameter by giving a concrete example of what compact drops (rating-icon and incidental image URLs). It does not independently explain locale or locationId, but the schema already does that adequately.

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 clear verb ('get full details'), a specific resource (TripAdvisor location), and enumerates the fields returned: names, descriptions, address, coordinates, ratings, phone, category, and listing URLs. This distinguishes it from photo/review/search siblings by content, though it does not explicitly differentiate from ta_web_get_location.

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 explicit when-to-use guidance or alternatives are given. The only conditional instruction is about passing view:"full", which is a behavior choice, not a routing decision. Using this after a search is implied by the schema note on locationId, but the description itself does not say when to choose this tool over siblings.

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?

Annotations already indicate a read-only, open-world operation. The description adds useful behavioral context: results are paginated and include specific image-related fields. It does not explain pagination termination semantics, but given the annotation coverage this is acceptable.

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 sentence that front-loads the action and resource, then packs the return details and pagination into a parenthetical. Every phrase earns its place; no filler or redundancy.

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 gives the key return fields and mentions pagination, and the schema fully documents parameters. However, with no output schema, an agent is not told how to detect the last page or what the response envelope looks like, leaving a minor but real 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?

Schema description coverage is 100%, so the schema already documents all four parameters. The description only generically references pagination, adding no meaningful parameter semantics beyond what the schema provides.

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 action ('Get photos') and a specific resource ('TripAdvisor location'), then lists the meaningful payload characteristics (multi-size image URLs, source, dimensions). It is clearly distinct from sibling tools like reviews, details, and search.

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 intended use is inferable: call this when you need photos for a TripAdvisor location. However, it does not explicitly state when not to use it or mention alternatives like ta_get_location_details or ta_get_location_reviews.

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?

Annotations already mark the tool read-only, and the description adds real behavioral detail: pagination support and the default stripping of reviewer avatars/image URLs, plus the view:'full' opt-in. It does not discuss rate limits or response envelopes, but that is less critical given the readOnlyHint.

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?

Two sentences deliver the purpose, pagination, and the non-obvious default behavior up front. Every clause earns its place with no filler.

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 read-only paginated listing with a fully documented schema and clear annotations, the description is sufficient. An agent knows what it retrieves, how to paginate, and how to opt into full records without needing further 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 all five parameters are already documented with types, constraints, and enum meanings. The description's view commentary mirrors the schema's view description rather than adding new parameter meaning.

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 operation ('Get traveler reviews'), the resource ('a TripAdvisor location'), and a key capability (pagination). This clearly distinguishes it from related siblings like ta_get_location_photos and ta_get_location_details.

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 phrasing makes the intended use obvious: retrieve reviews for a location. It does not explicitly name alternatives or exclusion cases, but siblings are semantically distinct enough that an agent is unlikely to confuse this with photo or location-detail tools.

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 annotations already mark this read-only and open-world, but the description adds genuinely useful behavior: unknown or unlicensed ids are silently omitted, and slim summaries are returned by default unless full is requested. This goes well beyond the structured fields.

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 sentences, front-loaded with the core purpose, and every sentence earns its place: what it does, how to invoke it, and the key behavioral caveat. No filler or redundancy.

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 batch read tool with full schema coverage and read-only/open-world annotations, this description is complete enough for an agent to select and call it correctly. It covers the batch behavior, output shape options, and important silent-omission behavior without needing an output schema.

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 100%, so the baseline is 3; the description adds extra meaning by explaining the batch benefit, the silent omission of invalid ids, and the default/compact vs full response distinction. This goes beyond the schema's field-level descriptions.

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: getting details for multiple locations in one batch call. It explicitly distinguishes itself from the sibling ta_get_location_details, so an agent can tell them apart immediately.

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?

Names the alternative (repeated ta_get_location_details), explains why batch is cheaper, and gives the action required (pass an array of ids). It also tells the agent how to switch output shape with view:"full", leaving little to inference.

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?

Annotations already declare readOnlyHint=true and openWorldHint=truecribing safety and world-open behavior. The description adds beyond that: a default slim summary response, the ability to pass view:"full" for complete records, the presence of pagination, and that returned IDs feed the detail tools. It does not contradict 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 compact and efficient: two sentences convey the verb, resource, scope, output behavior, pagination, and view switching. It front-loads the search name and purpose before touching response details, with no filler or redundant restatement of the tool name.

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 9-parameter tool with no output schema, the description covers the critical use context: it returns matches, each with a location id, supports pagination, and defaults to slim records unless view:"full" is passed. It does not describe the exact summary record shape or pagination mechanics, but those are adequately covered by the fully described parameter schema.

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 schema already documents every parameter. The description only reinforces the view parameter (e.g., pass view:"full") without adding new meaning to query, locale, geo_name, postal_code, or the pagination parameters. This matches the baseline 3 for a fully documented 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 uses a specific verb ('Search') and a clear resource ('TripAdvisor locations') with the enumerated categories (restaurants, attractions, hotels). It adds that results include a location id for the detail tools, which distinguishes this search tool from the sibling detail tools and from ta_search_nearby via the 'by name' qualifier.

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 a workflow: use this search to get a location id, then use the detail tools. However, it does not explicitly state when NOT to use this tool or name alternatives such as ta_search_nearby for proximity-based searches or ta_get_locations when IDs are already known. The guidance is present but only implicit.

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?

Annotations already convey read-only and open-world behavior, so the bar is lower. The description adds value by disclosing that slim summaries are the default and that view='full' returns whole records, plus that results carry distance and location id. It does not cover pagination or errors, but those are not critical given 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?

Three sentences, each carrying distinct information: purpose, parameter modes, and return shape. No filler or repetition; the structure front-loads the core action before the detailed modes.

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 17-parameter tool with no output schema, the description covers the essential conditional groups and response-shape options. It does not explicitly state that exactly one mode must be chosen or define pagination defaults, but the schema covers defaults and the mode phrasing implies alternatives. Overall it is sufficient 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 coverage is 100%, so the baseline is 3. The description adds real semantic value by grouping parameters into three accepted modes ('Center by lat+lon+radius, by a reference location_id+radius, or by a sw/ne bounding box') and clarifying the 'view' parameter's default behavior, which is above the baseline.

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: 'Find TripAdvisor locations near a point within a radius, or inside a bounding box.' This clearly distinguishes it from sibling search tools like ta_search_locations by emphasizing geospatial proximity and box searches.

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 explains three invocation modes (lat/lon+radius, location_id+radius, bounding box), giving clear context on how to parameterize the call. However, it does not explicitly state when to prefer this tool over ta_search_locations or mention exclusions, so usage guidance is implied rather than explicit.

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 annotations already signal read-only and open-world behavior, and the description adds meaningful context: it reads from the public page via the browser bridge, requires no API key, and does not return individual review text. This goes beyond what the annotations convey, though it does not discuss failure modes or rate limits.

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 three sentences with no wasted words: the first defines the operation and outputs, the second gives the alternative-selection condition, and the third clarifies scope and exclusions. Important information is 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?

Given a single documented parameter, read-only/open-world annotations, and no output schema, the description is complete enough: it names the returned fields, the data source, the no-API-key condition, supported place types, and a key exclusion. An agent can select and invoke this 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?

There is only one parameter and the schema already documents it fully ("TripAdvisor location ID (from a search tool)"). The description repeats that the lookup is by location ID but adds no new parameter-specific meaning, so 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?

States a specific verb and resource: "Get a TripAdvisor location's core details" and lists the exact fields returned. It also distinguishes itself from the sibling ta_get_location_details by noting it reads via the browser bridge and works without an API key, and from review tools by explicitly excluding review text.

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?

Provides an explicit condition: "use this when ta_get_location_details is unavailable or its key is blocked." It also clarifies the entity coverage (attractions, hotels, restaurants) and the exclusion of review text, giving clear when-to-use guidance relative to siblings.

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?

Beyond the annotations' readOnly/openWorld/idempotent hints, the description adds that no auth is required and, critically, discloses the full diagnostic payload and the enumerated failure states the hint distinguishes ('bridge never came up' vs 'extension not connected' vs 'browser can't serve a capability' vs 'real tripadvisor-side problem'). With no output schema, this behavioral disclosure is valuable and non-redundant.

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 action and return payload are front-loaded, and the final sentence provides the call condition. The first sentence is long and clause-heavy, but nearly every clause carries substantive information (payload contents, failure-state taxonomy), so little is wasted.

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 no-input, no-output-schema diagnostic tool, the description covers what it does, what it returns, the states it discriminates, and when to invoke it. Nothing an agent needs to call it correctly 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 tool takes zero parameters, so there is nothing for the description to add and the baseline of 4 applies. The description correctly signals there is no input to supply.

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 precise verb and resource ('Round-trips a small public www.tripadvisor.com URL through ContextMint Bridge') and enumerates exactly what the tool returns (role, port, version, extension link state, round-trip time, hint). This is unmistakably a diagnostic/healthcheck tool, cleanly separable from the location-data 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 gives an explicit trigger: 'Call this when a real tool fails and you want to know which hop broke.' That routes the agent directly to this tool as the fallback when a sibling fails, which is exactly the when-to-use guidance needed.

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