Pactum — legal services in Uzbekistan

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

Annotations cover the generic profile (non-readonly, openWorld, non-idempotent, non-destructive), and the description adds the traits annotations cannot express: this is a prepaid/paid action, the charge is credited if the client orders the service, and it stores/forwards personal data to Pactum and a partner lawyer. It also enumerates the return payload (order number, price, payment instructions, status link), which matters since no output schema exists.

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?

Four sentences, each load-bearing: capability, prerequisite sequence, call precondition, return payload, and the sibling alternative. The precondition and the routing sentence are not buried.

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 12-parameter, high-coverage schema with no output schema, the description fills the two real gaps: the correct call ordering (price lookup before booking) and the shape of the response. Nothing an agent needs before invoking it 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 83%, so the schema already documents nearly every field, including the const-true gates on user_accepts_price and user_consent. The description reinforces the consent/price-acceptance prerequisites but adds no format or syntax detail beyond what the schema provides, so the 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?

States a specific verb+resource ('Book a consultation with a Pactum lawyer') plus the commercial model (prepaid, credited toward the service). It also names what it is not (request_quote) so an agent can separate it from the sibling quote tools.

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?

Gives an explicit prerequisite chain ('get_consultation_price first'), a hard gating condition ('Call ONLY after the user asked... accepted that price, gave their real name and phone, and agreed that Pactum stores these details'), and an explicit alternative for the adjacent case ('For a price quote on a whole task use request_quote instead').

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, so safety is covered; the description reinforces it ('Read-only, books nothing') and adds the meaningful workflow constraint that the price must be surfaced to the user before booking. It stops short of describing caching or how current the price is, so it doesn't fully saturate the dimension, but it adds real context beyond 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?

Two tight sentences: the first defines what is returned, the second gives the sequencing instruction. Nothing is redundant and the ordering guidance is front-loaded where it matters most.

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 naming the returned values (price and length). Combined with the annotations and the fully documented single param, an agent has everything needed to invoke this correctly in a booking flow.

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?

Only one parameter with 100% schema description coverage, and the enum values are already documented in the schema. The description adds no syntax or default detail for 'locale'; per the baseline rule this is a clear 3.

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 resource and its two returned facts ('current price and length of a prepaid consultation'), plus the domain qualifier 'Pactum lawyer'. This clearly separates it from get_service and request_quote without needing to open any 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?

Explicitly states the ordering condition relative to a named sibling: 'Call it BEFORE book_consultation and tell the user the price: book_consultation needs the user to accept it first.' This tells the agent both when to call and why, which is exactly the guidance an agent needs to sequence a booking flow.

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=false, so the safety profile is covered. The description goes beyond that by enumerating what the response contains (inclusions, price anchor, FAQ, page URL to cite), which is valuable since there is no output schema.

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 tight sentence that front-loads the action and resource and packs the return contents into the tail. No filler, no redundancy with the title.

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 usefully enumerates the payload (inclusions, price, FAQ, URL) and identifies the required input source. It omits any note on locale behavior for a multi-locale service, but the schema covers that, leaving only a minor 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 both slug and locale are already documented in the schema with format and enum values. The description only reinforces that slug is a service slug sourced from search_services and says nothing about locale, so 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?

States a specific verb (retrieve full description), a specific resource (one Pactum service), and the key (slug). It also names the sibling (search_services) where the slug comes from, so an agent can distinguish it from search_services, request_quote, and search_articles without opening any 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?

The parenthetical '(from search_services)' tells the agent this tool is the follow-up drill-down after searching, which is clear usage context. It does not state when NOT to use it or contrast explicitly with siblings like request_quote, so it falls short of a 5.

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=false, so the safety profile is covered. The description adds the output shape (slug + name), which is useful, but says nothing about whether the list is static, paginated, or filtered by anything other than locale.

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, zero filler. The resource definition is front-loaded and the actionable routing hint follows immediately.

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 naming the returned fields (slug + name) and the integration point with request_quote. Only minor gaps remain, such as whether the list is locale-dependent.

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 single 'locale' parameter is fully documented with its enum and default in the schema. The description adds no extra semantics about the parameter, so the 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 the specific resource ('Practice areas Pactum works in') and even the return shape ('slug + name'), which no sibling shares. An agent can immediately tell this apart from get_service or search_services.

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?

Gives a concrete downstream use: 'Pass a slug as practice_area in request_quote to route the request to the right lawyer.' This tells the agent when it needs this tool (as a prerequisite to request_quote), though it names no exclusions or competing alternatives.

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?

Adds substantial context beyond the annotations: it discloses that accepting this creates an external, non-idempotent request that a partner lawyer will act on and follow up by phone/e-mail, enumerates the consent preconditions, and forbids fabricating contact details. Annotations only say openWorld=true and non-idempotent; the description explains what that actually means for the user's privacy and follow-up.

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 purpose, then the gating conditions, then content guidance, then the return value. Every clause carries a distinct instruction (consent gate, phrasing rule, anti-test warning, return value) 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 16-parameter submission tool with 94% schema coverage, the description covers the risky parts well: consent, contact integrity, phrasing, and the returned request number (important since there is no output schema). It leaves optional-parameter selection entirely to the schema, which is acceptable but leaves a small gap around when budget/deadline/documents matter.

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 94%, so the baseline is 3, but the description adds real meaning: how the task text should be phrased (situation, goal, key facts in the user's own terms) and an integrity rule for the contact fields ('never invent contacts'). It does not explain any of the 12 optional fields, which the schema already handles.

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 and outcome: send the user's legal task to Pactum lawyers, who review it and contact the user with a price. That is clearly distinguishable from the sibling read/search tools (get_service, list_practice_areas, search_articles, search_services) without opening any 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?

Gives explicit preconditions (call ONLY after the user asked to be contacted, gave real name and phone/e-mail, and consented to storage and partner-lawyer sharing) plus a clear prohibition ('never call it "to test"'). It stops short of routing the agent through the sibling discovery tools (search_services, list_practice_areas) before submitting, which is implied only via the schema's service_slug/practice_area descriptions.

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=false, so the safety profile is covered. The description adds real value by disclosing the return payload shape (titles, short summaries, URLs) and the intended behaviour of citing results, which is not visible in any structured field since there is no output schema.

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, zero filler, with the resource and scope front-loaded before the return/citation note. Every clause 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?

With no output schema, the description correctly compensates by naming the returned fields and the citation expectation, and all three parameters are fully documented in the schema. Only the absence of any sibling-routing guidance keeps it from being fully 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 description coverage is 100%, with each of the three parameters documented including examples and defaults, so the baseline is 3. The description adds no parameter-level detail (e.g. query syntax, locale interaction) beyond what the schema already 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?

States a specific verb (Search) and resource (Pactum articles explaining Uzbek law) with the topical scope enumerated (company law, trademarks, tax, labour, licensing). This clearly separates it from the sibling search_services, which targets a different resource type.

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 clause 'cite them when answering the user' implies the usage context (answering legal questions with sourced answers), which is genuine guidance. However, it names no alternatives or exclusions, so an agent gets no explicit routing rule against search_services or get_service.

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 cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description adds real value beyond them by disclosing the response shape (slug, price anchor, page URL) and the intended follow-up chain, though it says nothing about auth, rate limits or empty-result behavior.

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 tight sentences: the corpus and domain list come first, then the trigger, then the return shape and next-step routing. No clause is redundant with the schema or annotations.

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 usefully names the returned fields and the downstream tools, which is what an agent needs to chain calls. It omits any note on pagination/limit interaction or empty results, but nothing critical for correct invocation 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%, so the schema already documents query, limit and locale with examples and constraints. The description adds no syntax or default detail beyond that, so the baseline 3 applies; the 'pass a slug' note refers to an output field, not an input parameter.

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 (search the Pactum catalog of legal services in Uzbekistan) plus the covered domains, so the agent knows exactly what corpus is being queried. It also contrasts implicitly with search_articles and list_practice_areas by scoping to bookable services.

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?

Gives a clear trigger condition ('Use when the user describes a task they want done') and routes the agent onward to get_service or request_quote once a slug is in hand. It stops short of naming when NOT to use it versus search_articles, so it is strong but not fully exhaustive.

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