Prostitution Laws

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds real behavioral value beyond that: the output is a table, the topic set is defaulted when omitted, and each row carries a link to the full profile. It does not say what happens for an unrecognized country, which is the remaining gap.

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 that leads with the output shape and packs the default topic list inline with no filler. It is dense but every clause carries information; a slightly shorter default listing would make it crisper.

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, and the description compensates by describing the returned table (legal model column, per-question statuses, profile links) plus the default topic behavior. Combined with a fully documented schema and read-only annotations, only error/invalid-country handling is left unexplained.

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 both parameters are already fully documented in the schema, including the topic enum meanings and country name/ISO examples. The description only restates the defaults and the 2–10 bound, adding no semantics beyond the structured fields. Baseline 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+resource: a side-by-side comparison table of 2–10 countries' prostitution regulation, including what columns come back. It implicitly separates itself from get_country_law (single full profile) via the 'link to each full profile' phrasing, but never names the 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?

The 2-to-10 country range and the default topic set are given, which scopes usage, but there is no explicit 'use this when you need to compare rather than look up one country' guidance nor a pointer to get_country_law for the detail behind a link. Usage is inferred from the output shape.

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 establish that this is a read-only, idempotent, non-destructive, non-open-world operation. The description adds useful matching semantics with 'and/or' and parameter examples, but it does not describe ordering, pagination, or behavior when no filters are supplied.

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 definition is two tightly written sentences with the core purpose front-loaded and examples that directly clarify usage. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter filtered-list tool with rich annotations and full schema coverage, the description is largely complete. It could say more about the result shape or what happens when no filters are provided, but it gives enough context to call the 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?

Schema coverage is 100%, so the schema already documents each parameter thoroughly. The description still adds value by showing concrete combinations, such as topic buying with status illegal and region europe, which helps an agent map natural-language questions to parameter usage.

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 and resource: it lists countries matching a legal model and/or status on a topic, optionally within a region. The purpose is clear, but it does not explicitly differentiate itself from sibling tools such as list_countries or compare_countries.

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 example questions clearly indicate when to use the tool, covering model-only, topic/status, and region-filtered cases. However, it does not explicitly state when not to use it or name alternatives like list_countries or get_country_law.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine context beyond that: every answer carries a last-checked date, official sources are returned, and the output is explicitly framed as descriptive law rather than legal advice. It does not say which countries are in the dataset or how to discover coverage.

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?

Front-loaded with the core purpose and only three sentences total, with no filler. The middle sentence is a dense list of returned fields, but each item is informative rather than redundant.

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 carries the burden of describing returns and does so well — legal model, per-topic answers, penalties, provisions, regional variation, pending bills, sources and freshness dates. For a two-parameter read-only lookup, nothing an agent needs before calling 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?

Schema description coverage is 100%, and the topics enum is documented exhaustively in the schema, so the description does not need to restate it. It only loosely signals the per-topic behavior ("for each question") and says nothing about the country parameter's accepted formats, which the schema already spells out. Baseline 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 — it explains how one country regulates prostitution and sex work — and enumerates the deliverable (legal model, per-topic legality, penalties, statutory provisions, regional differences, pending bills, sources, last-checked dates). The scoping word "one country" implicitly separates it from compare_countries and list_countries, so an agent can route correctly without opening the schema.

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?

Concrete example questions ("Is prostitution legal in Germany?", "Can sex workers advertise in Spain?") give a clear picture of the query shape this tool serves. It stops short of naming alternatives — an agent must infer that multi-country comparison belongs to compare_countries and country discovery to find_countries/list_countries.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context by explaining that coverage depth differentiates a full profile from an overview, which tells the agent what the records actually contain and why a country might be thinner than another. No pagination or ordering behavior is disclosed.

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 scope and then lists the payload fields in a compact clause; nothing is redundant and nothing is padding.

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 carries the burden of explaining the record shape, and it does so by listing the returned fields and clarifying the coverage-depth distinction. Adequate for a simple list tool, though it says nothing about result ordering or list size.

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?

With one parameter at 100% schema coverage and an enum, the schema already does the documentation work. The description's "Optionally one region" only confirms optionality and singular-region scope, adding marginal meaning 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 names the resource (every country in the reference) and enumerates the return fields: legal model, region, coverage depth, review date, link. That is far more specific than the title. It does not, however, explicitly distinguish itself from find_countries, which an agent could reasonably confuse with an unfiltered enumeration.

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?

"Optionally one region" implies the intended usage pattern — enumerate everything, or narrow by a single region — but there is no explicit when-to-use guidance and no mention of when find_countries or compare_countries would be the better pick. Usage is left implied.

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 carry readOnly/idempotent/non-destructive, so the bar is lower. The description adds genuinely new behavioral information: results are ordered by soonest known next step, and the returned set is limited to pending items. It does not describe record contents, but that is minor for a list 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?

Two short sentences with the resource and ordering stated first and the optional filtering second. No filler, though the second sentence is a fragment rather than a complete clause.

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, two-optional-parameter list tool with no output schema, the description covers scope, ordering and filtering adequately. Only the shape of an individual pending-change record is left unspecified.

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 both parameters are already documented with enums and examples. The description only restates that filtering is possible by one country or one region; it does not clarify precedence if both are supplied, so baseline 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 names a specific resource ('bills, consultations and reviews in progress that would change how prostitution is regulated'), which clearly separates it from the sibling tools that query current law or country facts. It stops short of naming an alternative, but the verb+resource is unambiguous.

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?

'Optionally for one country or one region' implies how filtering works, but there is no explicit statement of when to use this instead of get_country_law or compare_countries. The usage context (upcoming reforms vs. current law) must be inferred.

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