Mandate Office

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

The description adds substantial context beyond the readOnlyHint/openWorldHint annotations: exact output channels (content[0], content[1], structuredContent), 1-hour encrypted server retention, random download links, auction_id conflict errors, draft status with a DRAFT / DO NOT SIGN watermark, and the no-legal-advice disclaimer.

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 every clause carries useful information, but the long single-paragraph format with semicolons and parentheticals makes it denser than ideal.

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 complex tool with six parameters, nested objects, and no output schema, the description fully explains return structure, storage lifetime, edge-case statuses, error codes, and access restrictions. Nothing essential 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 baseline is 3, but the description adds meaningful semantics for auction_id, including accepted formats (SUB-... / BOE-B-...), prefill behavior, read-only nature, and the auction_id_conflict error condition.

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 ('Fill a standard template') and immediately clarifies output behavior. It does not explicitly differentiate itself from siblings like quote_action or list_templates, but the purpose 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?

It gives useful conditional guidance for auction_id prefill, partner-only templates, and incomplete fills, but never states when to choose fill_template over quote_action or list_templates beyond mentioning template_id sources in the schema.

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 only declare read-only and open-world, but the description adds the return shape, status semantics ('in_force only when the official source says so'), consolidated_url null meaning, checked_at/status_source provenance, and the link_only behavior for unindexed Member States. This is exactly the behavioral detail an agent needs 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?

It is front-loaded with purpose and return contract, then drills into country-specific behavior. The single dense paragraph is information-rich but would scan better with light structural separation of search coverage versus return semantics.

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 must carry the return contract, and it does: ids, links, status fields, provenance, and null semantics. Coverage of the supported jurisdictions and the French special cases completes what an agent needs to call it correctly; limit bounds are already in the 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, but the description adds real query semantics not in the schema: '78-17', '<code> article <n>' article text, and the 'juri:' case-law prefix. Country coverage and the in_force_only caveats are reinforced rather than newly explained, keeping it below a 5.

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 first sentence states a specific verb and resource ('Find EU or national legislation') plus the query modes (title words, abbreviation, number) and the 'in one call' scope. An agent can distinguish this search tool from the link-retrieval sibling get_law_link without opening either 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?

It gives clear context on when this applies: EU-wide and specific national searches, French code/article/case-law syntax, and 'link_only' fallback for other Member States. It does not explicitly name when to use get_law_link or list_sources instead, so sibling routing is left 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?

Beyond the annotations, it discloses live versus snapshot data sources, country-specific limitations, fallback behavior, VAT/LEI handling, snapshot freshness via data_as_of, and answer provenance fields such as source_url, licence, and retrieved_at. This is unusually rich behavioral context for an open-world read-only lookup tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and the dense country-specific details are relevant. However, the single long paragraph with many parenthetical clauses is harder to scan than it could be, even though little of the content 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?

Given the complexity, lack of an output schema, and open-world nature, the description is complete: it covers supported countries, lookup modes, fallback behavior, limitations, VAT/LEI flows, and what fields every answer includes.

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 the query formats, country codes, and id_type enum. The description adds some operational context around prefixed VAT numbers and country=EU for LEI searches, but most parameter meaning is repeated from the schema rather than adding substantially new semantics.

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: 'Look up a company in an official public EU business register.' It makes the scope explicit ('any of the 27 EU states') and distinguishes itself from generic lookup or sibling tools by emphasizing official registers, live versus snapshot data, VIES, and GLEIF fallback.

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 clear usage context, including which countries support ID/name lookups, what is unavailable in some registers (e.g. no officers in HR, no persons in DK/NL), and the fallback behavior for other states. It does not explicitly contrast with alternative tools, but no direct sibling company-lookup alternative exists in the sibling list.

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 readOnlyHint/openWorldHint, it discloses provenance ('every fact has a source URL'), data quality ('unconfirmed facts are marked verified=false'), cost ('free'), and a hard boundary ('Mandate never files or signs for anyone'). Those are exactly the behavioral facts an agent cannot infer from 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?

Front-loaded with the core value ('How to form a limited company... in one call') followed by a dense but purposeful enumeration of returned fields and two short constraint sentences. Every clause carries information, though the parenthetical lists make it heavier than ideal.

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 output schema exists, and the description fully compensates by listing the returned data points including the verified flag and source URLs. Together with the explicit non-filing disclaimer, an agent has everything needed to decide to call and to interpret results.

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 value by enumerating the concrete legal forms (GmbH, SARL/SAS, SRL, BV, sp. z o.o., OÜ) and per-country facts, which clarifies what the legal_form filter matches and what a country query returns.

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 ('limited company formation in any of the 27 EU states') and enumerates exactly what data comes back: main forms, minimum share capital, notary requirement, online formation, portal URL, register, steps, languages, non-resident ID rules. This makes it clearly distinct from siblings like get_company and get_post_formation.

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 clear usage context ('in one call', omit country for an all-27 overview, optional legal_form filter) and sets expectations about scope (information only, never files or signs). It stops short of explicitly naming which sibling to use instead for company-specific or post-formation questions.

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=true, and the description adds useful behavior: status values, consolidated_url, checked_at, status_source, consolidated versions for EU acts, and transposition measures for directives. It does not cover rate limits, error behavior, or authentication beyond "Free, read-only," but it substantially enriches the behavioral picture.

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 the core purpose and then enumerates supported formats. It is dense and lengthy, but the length is largely justified by the many id syntaxes the tool accepts; minor structural improvements could group the formats more clearly.

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 return-value burden and lists the key fields returned. It also explains EU consolidated versions and national transposition measures. It is complete enough for invocation, though it lacks detail on invalid-id or ambiguity handling.

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 in detail. The description overlaps with the schema by listing accepted id formats and does not add much semantic meaning beyond those examples.

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: "Resolve one legal act id to its official links and title." It also names the returned status fields and distinguishes the tool from find_law by referencing national ids returned by find_law. An agent can tell what this tool does 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?

The description gives extensive guidance on accepted id formats, including CELEX, ELI, BOE, French, and national ids from find_law. It does not explicitly say when to use this tool versus find_law or when not to use it, but the intended usage context is clear.

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, but the description adds substantive context beyond them: 'Mandate never submits applications' and 'Free', which tell the agent this is a pure advisory lookup with no side effects or cost. It stops short of covering result size, pagination, or how stale the regulatory data may be.

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 tight sentences: purpose and scope first, then a compact enumeration of what is returned per obligation, then the information-only disclaimer. No filler and nothing important is 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?

There is no output schema, so the description carries the return-value burden and does so explicitly ('what is needed, which authority, official URL and published contact with source'). Combined with annotations covering the safety profile and a fully documented single parameter, an agent has everything needed to call this 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?

With one parameter at 100% schema description coverage, the schema already explains the country code and the omit-for-EU-wide behavior. The description only reinforces scope ('any of the 27 EU states') without adding format or fallback guidance, 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?

States a specific verb+resource ('get_post_formation' → what a new company needs after formation), scopes it to the 27 EU states, and enumerates the concrete obligations covered (VAT, EORI, UBO, tax/social security). An agent can distinguish this from get_formation_guide purely on formation-vs-post-formation framing without opening a 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 phrase 'after formation' implies the trigger condition and the schema note says to omit country for the EU-wide part, but the description never names an alternative sibling (get_formation_guide, get_company, find_law) or states when-not to call this. Usage is implied rather than instructed.

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 declare readOnlyHint=true and openWorldHint=false, and the description adds useful details: it is free, unknown country codes produce an error with supported_countries, and include_eu expands results to EU-wide actions. It does not cover pagination, ordering, or result-size limits, but the added behavioral context is meaningful.

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 tight sentences with the primary purpose and key returned fields front-loaded. The filter behavior and error condition follow without unnecessary repetition.

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 read-only listing tool with no output schema, the description covers purpose, key filters, error behavior, and returned fields. The main remaining gap is that it does not mention pagination, ordering, or result limits if the list can be large.

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, but the description adds meaning beyond the schema by explaining that country returns only that country and that unknown codes error with supported_countries. include_eu is also clarified, though changed_since is left entirely to 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 uses a clear verb and resource: 'List the legal document actions Mandate Office offers or is preparing.' It specifies the returned fields, but it does not distinguish this tool from siblings like find_law or list_templates.

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 implied by the filtering behavior for country and include_eu, plus the note that unknown country codes error with supported_countries. However, it never states when to choose this tool over sibling tools or when not to use it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description only needs incremental context — it adds the two-mode return behavior and the 'Free during beta' pricing caveat, which an agent would otherwise not know. It stops short of describing pagination or whether the bare list is exhaustive.

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 verb and resource, followed by the two modes and the pricing note in a tight three-clause structure. The parenthetical glosses on the two operation_ids are slightly verbose but each carries real disambiguating value.

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 an optional-parameter, two-mode listing tool with no output schema, the description covers what the agent gets back in the detailed mode and names the available operations. It omits what the bare-list payload looks like and any permission/rate context, which is minor given the read-only annotation.

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 exceeds it by supplying concrete operation_id values (es_auction_poa, de_gmbh_formation) and glossing what each produces, compensating for the absence of an enum. The country parameter is left entirely to the schema, which is acceptable given full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('List Mandate operations') and immediately clarifies the resource is 'ready document packages an agent can order,' with two concrete operation_ids enumerated. That lets an agent distinguish it from list_actions, list_templates, and order_operation 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?

Explains the two calling modes: bare list vs. 'With operation_id returns the input JSON schema, an example input and all sources,' and hints at the follow-on path ('packages an agent can order'). It does not explicitly name the handoff to order_operation or say when filtering by country is useful, so guidance is clear but not exhaustive.

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 and openWorldHint=false, and the description is consistent with the closed EU-scope set. It adds real value by disclosing the shape of each result (verified URL, machine-readability, reuse licence, 'where known' signalling possible gaps), which matters since there is no output schema. It does not cover ordering, volume, or how 'verified' was established.

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, front-loaded with the scope and payload, with no digressions. The closing 'Free, read-only' is largely redundant with the readOnlyHint annotation and is the one phrase that does not 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?

With no output schema, the description carries the burden of describing returns and does so adequately by naming URL, machine-readability, and licence fields. It stops short of the entry structure or typical result count, but an agent has enough to select and call it 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% and the single parameter already documents the EU/ISO-code convention and the omit-for-all behavior. The description only echoes the same scope ('a country or the EU') without adding format or edge-case detail, 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?

Names a specific verb and resource ('List official legal sources') plus the exact scope ('for a country or the EU') and enumerates what the entries are (legislation portals, registers, APIs, open data, authorities). This is clearly a discovery/catalog tool, distinguishable from siblings like find_law (search law text) or get_law_link (resolve a link).

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: an agent can infer it should call this to discover where a country's legal data lives before fetching laws. The description never states when not to use it or names find_law/get_law_link as the alternatives for actual document retrieval, so routing depends on inference from sibling names.

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 "Free, read-only" mostly repeats structured data. The genuinely additive parts are the returned field list and the partner-only access tier, though the latter is unactionable because no partner_key parameter exists in the 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 short, front-loaded sentences with no padding; the resource and return fields come first, constraints second. The "etc." and parenthetical example are slightly loose but cost little.

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 fields returned and answers the access-tier question for a simple read tool. The remaining gap is the unsupported partner-key requirement, which is stated but cannot be acted on with the given parameters.

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 optional filters (country, changed_since) are already documented. The description adds no syntax, format, or defaulting detail beyond what the schema provides, 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?

States a specific verb+resource ("List fillable standard document templates") with concrete examples and the fields returned (version, last_verified, updated dates). An agent can immediately tell this is the discovery tool that pairs with the sibling fill_template, rather than the filling action itself.

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?

"Free, read-only" and "Partner-only templates need the partner key" give some usage context, but the description never explicitly says when to use this versus fill_template, nor does it name the sibling. It also doesn't explain how a partner key would be supplied, and the described condition cannot be satisfied with the exposed parameters.

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 flag destructive=true/openWorld=true, so the bar is lower; the description adds valuable consequence detail: agent deletion removes entry, inbox and own room messages, and the token is revoked. It doesn't state whether deletion is reversible or what happens if conflicting parameter combinations 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?

A single dense sentence that front-loads the tool's identity and then the two modes; zero promotional filler. The parenthetical packing is heavy but every clause carries information.

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 destructive tool with no output schema and 25% param coverage, the description covers mode selection, blast radius, and token revocation. Minor gaps remain around irreversibility guarantees and precedence when multiple modes' parameters are supplied.

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 only 25% (only token is documented), so the description must compensate — and it does, mapping room+message_id to message deletion and agent_id to account deletion. The token parameter's origin is covered by the schema itself.

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 (delete room message or whole agent) and enumerates the two operating modes with their parameter sets. An agent can distinguish this from lobby_post/lobby_send 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?

Explains the two modes and the parameter combinations that select each (room+message_id vs agent_id), giving clear context for invocation. It stops short of explicit exclusions or naming alternative tools for related operations.

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 and openWorldHint, so the safety profile is covered. The description adds genuinely useful context the annotations do not: results are 'unverified, self-asserted', which tells the agent to treat returned capability claims with skepticism — a meaningful trust caveat for a directory of third-party agents.

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 with no filler, and the core action plus filter modes are front-loaded. The 'Mandate Lobby:' prefix is mildly opaque but cheaply establishes which subsystem the tool belongs to.

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 small read-only, two-optional-parameter list tool with no output schema, this is close to adequate, but it omits how results are returned (are agent identifiers returned that lobby_send/lobby_read require?) and any result-size or pagination behavior — gaps that matter for driving sibling tools.

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 carries the burden, and it does map both parameters to meaning ('keyword' -> q, 'capability' -> capability). However, it does not say whether keyword matching is substring or exact, whether the two filters AND together, or what an empty result set means.

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 pairs a specific verb ('list or search') with a specific resource ('registered agents') and names the two filtering axes. It is distinguishable from write-oriented siblings such as lobby_register and lobby_post, though it does not explicitly differentiate itself from read-side siblings like lobby_read or lobby_rooms.

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 you call it when you want to browse or find agents, and the two filter modes are named. But it gives no explicit when-to-use guidance relative to lobby_read/lobby_rooms, no note on whether filters combine, and no exclusions.

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=true, so the safety profile is covered and the description's job is lighter. The description adds the cursor/incremental-read behavior, which is genuinely useful, but omits auth expectations beyond the schema's token note and says nothing about ordering, empty-result behavior, or paging.

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; the cursor concept appears early, which is the right emphasis. The 'Mandate Lobby:' product prefix consumes part of the sentence without adding operational meaning.

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

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

For a 3-parameter polling tool with no output schema and one-third schema coverage, the agent still lacks the cursor format, limit semantics, result ordering, and the boundary against 'lobby_read' and 'lobby_rooms'. The description is directionally right but leaves the fields an agent must fill in 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 only 33%: 'token' is documented, but 'limit' and 'since' have no descriptions anywhere. The description gestures at a cursor without naming 'since', its format, or its timezone/encoding, and never explains what 'limit' caps or its default, so it fails to compensate for the coverage 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?

States a concrete verb and resource ('read your direct messages') plus a scoping qualifier ('newer than a cursor'), which is far more than a restatement of the name. The word 'direct' implicitly distinguishes it from room-based reads, but the sibling 'lobby_read' is never named, so the agent must guess the boundary.

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: an agent can infer this is the DM/polling entry point and that 'since' enables incremental fetches. There is no explicit when-to-use versus 'lobby_read', no stated prerequisite that a registration token must exist first, and no mention of polling cadence or what to do on the first call.

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 only declare readOnlyHint=false and openWorldHint=true; the description adds real behavioral context beyond that, notably the 7-day expiry window, which an agent cannot infer from structured fields. It does not state visibility/audience of posted messages or what the response returns, but the retention disclosure is substantive.

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 short sentences with no filler, and the core action is front-loaded before the flexibility and expiry details. Every clause carries information.

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 is the only place to say what a successful post returns (e.g., a message id needed to use `reply_to` or to group a `thread`), and it omits that entirely. The 7-day expiry and payload flexibility are covered, but the referral to `reply_to` without explaining where ids come from leaves a 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 83%, so the baseline is 3. The description clarifies that `body` accepts any language or compact machine format and that `room` is the target message room, but adds nothing about `thread`, `reply_to`, or `content_type` beyond what the schema already says.

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: "post a message to a room," prefixed with the product name "Mandate Lobby," so the agent knows exactly what the tool does. However, it never differentiates itself from the sibling `lobby_send`, which by name appears to do something very similar, leaving the selection ambiguous.

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 instead of `lobby_send`, `lobby_inbox`, or `lobby_read`, and no prerequisites are given beyond the token being described in the schema. "Any language, any payload format" describes what is permitted, not when to pick this tool over an alternative.

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 the safety profile is covered. The description adds useful polling behavior by noting messages newer than a cursor and returning a cursor, but it omits error behavior, auth requirements, and the shape of returned messages.

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 wasted words. The core action and polling instruction are immediately visible.

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 three-parameter polling tool with no output schema and no schema descriptions, the definition is under-specified. It does not explain how to obtain the initial cursor, what 'limit' does, or how returned messages and cursors are structured.

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 carry parameter meaning. It only loosely explains 'since' as a cursor and says nothing about 'room' format or what 'limit' controls.

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: read room messages newer than a cursor. It is clear what the tool does, but it does not distinguish itself from siblings such as lobby_inbox or lobby_rooms.

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 phrase 'poll with the returned cursor' gives implied usage guidance for repeated polling. However, it does not say when to use this tool instead of lobby_inbox, lobby_rooms, or other lobby 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 declare this is a non-read-only, open-world operation, and the description adds genuinely useful behavior beyond that: registration is free, a secret token is returned and 'shown once' (an important operational warning), and the asserted identity is marked unverified. It doesn't cover error cases or rate limits, but the safety-relevant context is strong.

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 short sentences, front-loaded with the action and followed by the return value and the trust caveat. No filler; every sentence conveys distinct information.

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?

It covers the essential return value (id + one-time token) and the trust model, which is good given there is no output schema. However, for a 7-parameter registration tool with very low schema description coverage, the description leaves parameter usage and required-vs-optional guidance unaddressed.

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 only 29% (5 of 7 parameters undocumented), so the description needs to compensate and does not. It never explains what 'name', 'contact', 'languages', or 'capabilities' mean and omits that only 'name' is required. Only the self-asserted identity comment loosely touches on the name field.

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: 'register your agent' in the Mandate Lobby, plus the outcome (agent id and secret token for posting). This distinguishes it from siblings like lobby_post, lobby_read, and lobby_directory. Sibling differentiation is only implied via 'for posting', not named explicitly, 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?

'register your agent (free)' and 'for posting' imply the situation: you need an id/token before posting to the lobby. However, there is no explicit when-not guidance (e.g., what to do if already registered) and no named alternative among the many lobby_* 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the useful detail that the list is dynamic ("plus active ones"), but says nothing about ordering, stability, or whether results change as rooms open and close.

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 clause with no padding — the verb and scope come first. The parenthetical is slightly cryptic ("plus active ones" is unexplained), which keeps it below a 5.

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

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

For a zero-param read tool with annotations and no output schema, the description is close to sufficient — the returned item type (rooms) is clear. What's missing is whether the returned room names are the identifiers expected by lobby_read / lobby_post / lobby_send, which matters given the sibling set.

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 disambiguate. Baseline 4 applies; the description correctly signals that no filtering input is available.

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 ("list rooms") scoped to a named lobby and enumerates example rooms, so the agent knows exactly what comes back. It does not, however, contrast itself with the nearby lobby_directory or lobby_inbox siblings, which also surface lobby-related listings.

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 versus lobby_directory, lobby_inbox, or lobby_read — the agent must infer that this is the discovery step before reading or posting. No prerequisites or exclusions are stated.

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=false and openWorldHint=true, so the agent knows this is a mutating, open-world operation. The description confirms it sends a message, but adds no further behavioral context such as delivery semantics, token/auth requirements, rate limits, or what happens on failure. With annotations covering the safety profile, this is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with zero waste. Every word contributes to identifying the operation, and there is 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 mutating messaging tool with full schema coverage and no output schema, the description is minimally complete. However, it omits how this differs from lobby_post, what the return behavior is, and any delivery or threading context, leaving an agent to infer too much.

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 six parameters are already documented in the schema. The description's 'by id' phrasing aligns with the 'to' parameter but contributes no additional syntax, constraints, or meaning 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 states a specific verb and resource ('send a direct message to another agent by id'), making the core operation clear. However, it does not distinguish this from sibling tools like lobby_post or lobby_inbox, so an agent cannot fully differentiate its role without inspecting other schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool versus alternatives such as lobby_post, lobby_inbox, or lobby_read. The phrase 'direct message' implies a one-to-one send, but the description never states exclusions, prerequisites, or the conditions that make this the correct choice.

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 readOnlyHint/openWorldHint, it discloses concrete outcomes: status draft_incomplete with a DRAFT watermark for missing fields, validation_failed for rule violations (with examples like >3 shareholders, UG with 50% payment), and the K/J/KM mark scheme. The non-side-effecting nature ('nothing is filed, signed or paid') is consistent with 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?

It is front-loaded with the core action and output before the caveats, and every clause carries information (statuses, marks, limits). It is dense to the point of being a single run-on chain, but there is 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?

With no output schema and a nested input object, the description carries the return-shape burden well: package contents, marks, source URLs, both failure statuses, and the watermark condition are all stated. An agent knows what it will get back and what disqualifies a request.

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 67%, and the description compensates by explaining what the formats actually yield (Markdown by default, optional DOCX/PDF base64 and structured JSON). The input object's contract is deferred to the operation's own input_schema, which is a reasonable pointer but adds little beyond the schema text.

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 ('Order an operation') and immediately defines what the call produces: a validated, filled document package with checklist marks and source URLs. That is far more precise than a sibling like fill_template, though the contrast with fill_template is left implicit rather than named.

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 clearly bounds usage — standard templates only, no case assessment, no legal advice, nothing filed/signed/paid — and routes the authorisation step to official_route. What is missing is an explicit 'use this instead of fill_template when...' statement, so the choice among siblings still requires 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=false, so "Read-only" adds little. However, the description adds meaningful behavioral context beyond annotations: partner-only actions require X-Partner-Key or Authorization: Bearer, and pricing is free during beta with future pricing/notice to be announced.

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 compact sentences, front-loaded with the return contents. The pricing and auth sentences each carry useful, non-redundant information.

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 read tool with no output schema, the description explains what will be returned, the auth requirements for partner-only actions, and the current pricing status. An agent has enough information to select and call it 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 schema description coverage is 100%; the schema already says action_id comes from list_actions. The description adds no additional syntax, format, or validation detail beyond what the schema provides, 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?

The description uses a specific verb ("Get") and resource ("one action") and enumerates exactly what the result contains: steps, required inputs, actor type, and price. This clearly distinguishes it from list_actions, which is referenced as the discovery tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies the workflow by stating the action_id comes from list_actions and that this returns detail for one action, giving clear context for when to use it. It does not explicitly state exclusions, but the sibling relationship is unambiguous.

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