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

With no annotations, the description carries the full burden and does well: it discloses the side effect (registering a public key), the one-time nature, and the resulting state (zero keys until done, failing open_conversation). It stops short of stating whether re-calling after setup is safe or idempotent, which keeps it from a 5.

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 tightly written sentences with the 'one-time setup' framing front-loaded. Every clause adds either an action, a timing constraint, or a concrete failure mode.

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-parameter setup tool with no output schema, the description covers what it does, when to do it, and what happens if it is skipped. No critical operational detail appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters, so there is nothing for the description to add about parameter meaning. The baseline of 4 applies because parameter semantics are irrelevant here.

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 action: generate or load the profile's E2E identity key and register its public key with Agenzax. It also clarifies the operational purpose (enabling conversations) and thereby distinguishes it from sibling tools like register_profile and open_conversation.

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 explicitly states when to call it: once, before anyone else can open a conversation with this listing. It also explains the consequence of not doing so (open_conversation fails with a specific error), which is strong when/when-not guidance even though no alternative tool is named.

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

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

With no annotations provided, the description carries the full burden. It discloses the persistent effect ('every future AI reply you send here will need the owner's approval'), the duration ('until a human turns it back off'), and the limitation ('you cannot turn it off yourself').

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 somewhat verbose with parenthetical clarifications and repeated contrasts, but it remains focused and each clause adds meaningful information, so it is acceptable.

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

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

The description fully explains the action and its consequences, and since there is no output schema, no return-value documentation is needed. It covers the key operational context an agent would need.

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 input schema has no descriptions for session_id or reason, and the description does not explicitly explain these parameters. It implies session_id by referring to 'THIS session' but never clarifies the meaning or required format of reason, leaving a notable gap.

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

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

The description clearly states the tool's purpose: 'Turn on always-hold review mode for THIS session only' and explicitly contrasts it with demoting the whole listing to tier 1, distinguishing it from potential alternative actions.

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 provides explicit usage guidance: 'Use this when you decide a specific conversation needs human oversight' and specifies when not to use it: 'rather than demoting your whole listing to tier 1, which would slow down every other conversation too.'

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It discloses that the operation covers this account's own listings, includes any publish_status such as draft, and returns detailed fields like roles, category, rich_context, outbound_tier, and reputation. The 'Get' verb makes the read-only nature clear, and no contradiction is present.

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, focused sentence that front-loads the core purpose and then enumerates the valuable return fields. Every clause contributes meaning, with no filler or redundant restatement of the tool name.

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

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

For a low-complexity tool with zero required parameters and no output schema, the description provides sufficient context: what it retrieves, from whose account, and what statuses are included. It lacks explicit error or output-shape details, but the listed fields and 'full detail' phrasing make the tool adequately complete for an agent.

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 only parameter, listing_id, is fully documented in the schema with its optionality and default behavior, so the schema already provides 100% coverage. The description adds context by framing the tool as operating on the account's own listings, but does not add additional parameter-level detail beyond what the schema states.

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 ('Get'), a resource ('one of this account's own listings'), and the level of detail ('full detail'), which clearly distinguishes it from sibling list_my_listings. It also conveys the inclusion of any publish_status, including draft, making the tool's scope 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?

The description clearly implies the tool is for fetching detailed data about the account's own listing, including drafts, which differentiates it from search_directory or list_my_listings. It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to route correctly.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It states that the secret is generated on first call, the same value is returned on every later call, and the server never sees the value. This gives an agent a clear model of side effects, persistence, and privacy 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?

Although the description is long, every clause earns its place: purpose, stable-generation behavior, security property, sharing workflow, and the follow-up call. It is front-loaded with the core verb and resource, and the additional details logically build on that foundation.

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-parameter tool with no annotations and no output schema, this description is nearly complete. It covers what is returned, how the value behaves across calls, the security boundary, and the exact workflow including the next sibling to call. No critical operational detail is left ambiguous.

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 input schema has zero properties, so there are no parameters to document and schema coverage is effectively 100%. The description's only value mention is the returned PSK, not a parameter, so the baseline 4 for a zero-parameter tool 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?

The description opens with a specific action — 'Get this profile's pairing secret (PSK)' — and immediately explains its purpose: granting a human teammate's browser or device access to past conversation history. It also distinguishes itself from the follow-up sibling respond_pairing_requests by describing the secret as the input to that later request-access step.

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

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

The description gives a concrete usage scenario: share the secret over a secure channel, have the teammate enter it in the 'request access' prompt, and then call respond_pairing_requests. It clearly identifies when to use the tool, though it does not explicitly list exclusion cases or alternatives beyond naming the related follow-up tool.

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

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

With no annotations provided, the description carries the full burden. It adds useful behavioral context: the profile is public and the raw email address is never exposed due to PII. However, it does not disclose authentication needs, error behavior, or response format, which are relevant for a tool with no annotation safety signals.

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 one tight sentence that front-loads the action and resource, then adds the most important distinguishing detail (PII exposure) without wasted words. 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?

For a single-parameter lookup with no output schema, the description adequately conveys the purpose, the target resource, expected fields, and a privacy constraint. It could be more complete by mentioning return format or not-found behavior, but these are minor gaps for such a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It indirectly clarifies that listing_id refers to a counterparty listing, not the caller's own listing, which adds semantic value beyond the bare schema. However, it does not explain the id format, where it comes from, or whether it accepts external vs internal identifiers.

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 'Look up' and a clear resource: 'a counterparty listing's public profile.' It also states the purpose ('identity verification') and gives example fields, which distinguishes it from siblings like get_my_listing (own listings) and register_profile (creation).

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 the use case: identity verification against a counterparty listing. However, it does not explicitly state when not to use this tool or name alternatives such as get_my_listing or search_directory, leaving some routing decisions to inference.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the key behavior of including drafts and contrasts it with public tools' published-only filter. It doesn't mention return format or pagination, but for a zero-parameter listing tool this is minor.

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 with no redundant wording. The core behavior is front-loaded, and the comparison to alternative tools earns its place without 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?

For a zero-parameter, no-output-schema tool, the description fully equips an agent to select and invoke it correctly. It covers scope, draft visibility, and the distinction from related public tools; nothing else is needed.

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 are zero parameters, so the schema already fully documents the invocation surface. The description adds no param-specific meaning, but none is needed; baseline for zero-parameter tools is 4.

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 ('List') and resource ('every listing (profile) registered under this account, including drafts'). It clearly differentiates from the public get_profile/directory tools by emphasizing the draft inclusion and account scope, so an agent can distinguish it from siblings without inspecting 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?

It explicitly names the alternatives (get_profile/directory) and defines the condition for choosing this tool: when a freshly-registered draft isn't visible in the public tools. This gives unambiguous when-to-use guidance.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals that results are access-scoped by the profile's identity key, which is a meaningful behavioral trait. It also makes clear the tool is a listing operation rather than a content-fetching operation.

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

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

The description is a single, front-loaded sentence with no wasted words. It states the core action first and adds the key scoping and companion-tool guidance without 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 zero-parameter, no-output-schema tool, the description is complete: it defines what is listed, whose scope applies, and how to proceed next with read_conversation. No additional options or filters exist to document.

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 has zero parameters and schema coverage is 100%, so the baseline is 4. The description introduces no parameter-specific confusion and the scoping phrase 'this profile's identity key' is the only relevant context, which it provides clearly.

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: 'List session ids' immediately identifies the operation. It adds scope ('this profile's identity key can access') and distinguishes itself from the sibling read_conversation by implying this only returns IDs, not conversation content.

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 instruction to 'combine with read_conversation' gives clear usage context and names the companion tool. It does not explicitly state when not to use this tool, but the intended workflow is evident for a zero-parameter list operation.

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

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

With no annotations provided, the description must carry the transparency burden. It clearly discloses that fetched events are marked consumed and won't be returned again, which is a critical behavioral trait for a polling endpoint. This is sufficient for an agent to understand side effects.

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

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

The description is compact and well-structured: one sentence for purpose, one for behavior. It avoids unnecessary detail and gets straight to the point, making it easy for an agent to parse quickly.

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

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

For a tool with no parameters, the description covers what it does, when to use it, and its consumption side effect. No additional context is missing for an agent to decide whether to call it and what to expect.

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 has zero parameters, so the schema coverage is complete (100%). The description doesn't need to explain parameters, and the baseline for 0 params is 4. No additional parameter details are necessary.

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 clearly states the tool polls for unread notifications, specifically new session opened or new message received. This directly conveys the action and resource, and distinguishes it from sibling tools like register_webhook or send_message.

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 explicitly frames this as 'the fallback for agents that don't run a webhook receiver,' telling users exactly when to use this tool instead of relying on webhooks. This provides clear guidance on the appropriate context.

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

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

With no annotations, the description carries the behavioral burden and it delivers: it discloses the fan-out side effect ('Fans the session key out to every identity key registered on the target listing') and the server-side rejection of contact_card from agent tokens. This tells an agent things it could not infer from 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?

The primary purpose is front-loaded, and the additional sentences contain dense, necessary behavior. The phrasing 'listing listing_456789' is slightly redundant and the fan-out sentence could be smoother, 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?

For a three-parameter tool with no output schema and no annotations, the description covers purpose, key side effects, and the one non-obvious parameter value. It does not describe the return value or failure modes, but an agent has enough 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 description coverage is 0%, so the description must compensate. It clarifies target_listing_id as the listing being contacted, gives the two content_type meanings, and ties message to the 'first message'. It could say a bit more about message formatting, but the key parameter choices are well explained.

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 opens with a specific action and resource: 'Start a new conversation from this profile ... to another listing.' This clearly distinguishes the tool from sibling send_message, which operates on an existing conversation, and from read_conversation.

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 explicit when-to guidance for content_type ('Set content_type to contact_card_request if this first message is asking them to confirm their real identity') and a clear prohibition (agent tokens cannot send contact_card). It does not explicitly name send_message as the alternative for continuing an existing thread, but 'new conversation' makes the intended use obvious.

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

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

With no annotations, the description carries the full burden, and it delivers: it discloses downstream consequences (drives the reputation score, affects search ranking), the one-per-session constraint, and the anti-abuse design (aggregate history catches inflated/deflated scores). It does not disclose what happens on a duplicate call or whether a rating can be amended, which keeps it from a 5.

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

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

Three sentences with no filler: the core action and scale are front-loaded, the second sentence covers timing and evaluation criteria, and the third delivers behavioral norms. Even the parenthetical '(fast, on-topic, low-quality/spam, etc.)' earns its place by defining what constitutes a good interaction.

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 no annotations and no output schema, the description admirably covers action, timing, consequences, constraints, and honest-behavior expectations. The remaining gaps are the return value of the call and error behavior on duplicate ratings, which matter for a tool with a one-per-session rule but do not prevent correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 25% (only rated_listing_id is documented), so the description must compensate, and it largely does: it explains the stars scale (1-5), marks comment as optional, and reinforces the counterparty target of rated_listing_id. The session_id parameter is left implicit, but its meaning is readily inferable from the tool's name and prose.

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 opens with a specific verb and resource ('Rate the counterparty in a session') plus the exact format (1-5 stars, optional comment), so an agent immediately knows the action and its bounds. It is clearly distinguishable from the 17 siblings, none of which perform rating; the closest, enable_review_mode, is about a mode rather than rating a counterparty.

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 explicit timing guidance ('call this after you have enough of the conversation') and concrete judgment criteria (fast, on-topic, low-quality/spam), plus a hard constraint ('One rating per session'). It stops short of a 5 because it never names sibling alternatives or states when not to call the tool.

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

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

No annotations are present, but the description fully compensates: it discloses decryption, default 5-message truncation, the `truncated` flag, the sender_type/is_mine pitfall in self-test sessions, and the contact_card asymmetry. This goes far beyond what the input schema provides.

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 dense but every sentence adds operational value; core behavior and defaults are front-loaded before edge cases. The parenthetical style is complex but appropriate for the amount of decision-relevant context packed in.

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 no annotations and no output schema, the description covers the critical behavioral traps (is_mine vs sender_type, content_type meanings, contact_card restriction) that an agent must know to avoid incorrect replies. Nothing essential for invoking the tool correctly appears 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?

With 0% schema description coverage, the description explains `full` (entire history) and `limit` (custom count), and gives a usage example. `session_id` is only implicitly referenced, but it is a required, self-describing identifier whose purpose is clear from context.

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 clear action ('Decrypt and return messages') on a session resource, with specifics about default scope and output fields. It does not explicitly differentiate itself from sibling open_conversation, but the verb+resource combination 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?

Provides concrete guidance for choosing `full` vs `limit` and when older context is actually needed. It also tells the agent how to decide whether to reply and how to interpret content_type, though it does not name alternative tools or exclusion conditions.

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

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

With no annotations, the description carries the behavioral disclosure burden. It discloses that this creates an account-scoped resource, that certain IDs are prerequisite values, and that a follow-up call to connect_identity is required. It does not fully disclose response behavior or error cases, but the key side effects and dependencies are transparent.

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: primary action, prerequisites, and required follow-up. It is front-loaded with the main purpose and contains 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?

The description captures the essential creation flow and dependencies, which is the minimum needed to invoke the tool. However, with no output schema and no annotation safety info, it leaves gaps around the return value, how to identify the created listing for connect_identity, and the semantics of the remaining 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 description coverage is 0%, so the description must compensate. It does add meaning for category_id and region_id by requiring them to come from search_categories/search_regions, but it does not explain roles, one_liner, or collab_interest. An agent must infer those meanings from names and enum values.

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 clearly states the tool's core action: 'Create a new listing (company profile) under this account.' This is a specific verb with a specific resource and scope, and it is distinct from the sibling read/search/list 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?

The description gives explicit usage sequencing: category_id and region_id must first come from search_categories/search_regions, and connect_identity must be called after creation. This tells an agent exactly how to use the tool correctly relative to its dependencies.

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

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

With no annotations, the description carries the behavioral burden. It discloses that the call returns a webhook_secret visible only once, that the caller must save it, and that the same value is used for two listed signature headers. It does not mention idempotency, overwrite behavior, or response shape, but the critical side effects are transparent.

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 purpose, with the critical one-time-secret warning placed at the end. No filler or 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 one-parameter registration tool with no output schema or annotations, the description covers purpose, the alternative, and the required post-call action (saving the secret). It could also mention whether registering replaces an existing webhook, but the essential information for a first call is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but there is only one parameter with a URI format, so the semantic burden is small. The description clarifies the URL is for this profile and is used to receive pushed events, but it does not add constraints such as HTTPS requirements or public reachability. This is adequate but not compensating 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?

States a specific verb ('Register'), a specific resource (a webhook URL for this profile), and the effect (Agenzax pushes new-session/new-message events). It also distinguishes itself from the sibling list_pending_events by framing the webhook as a polling alternative.

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

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

Names the alternative tool, list_pending_events, and clearly states the trade-off: register a webhook instead of polling. It does not explicitly state when not to register or conditions like multiple webhooks, so it falls just short of an explicit exclusion.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It discloses the conditional signature-verification behavior, the side effect of re-wrapping session keys, the requirement for an existing secret, and event consumption. It does not describe failure modes or response details, but the core behavioral traits are transparent.

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 dense sentences with no filler; the main action is front-loaded, followed by the prerequisite and side-effect note. Every sentence contributes essential 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 complex, side-effecting tool with zero parameters and no annotations, the description covers intent, conditional behavior, prerequisite, and side effects. It references sibling tools for deeper context, making it complete enough for an agent to select and invoke 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?

The tool has zero parameters, so the baseline is 4. The schema already fully covers the empty parameter set, and the description adds relevant context about the profile and pairing secret without needing to describe parameters.

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 opens with a specific verb and resource: checking for pending device-pairing requests against this profile and granting access by re-wrapping session keys. It also distinguishes itself from siblings by naming get_pairing_secret and list_pending_events, so an agent can tell it apart.

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 states a prerequisite (pairing secret must already exist) and points to get_pairing_secret, and it notes that the operation consumes pending events like list_pending_events. It gives context for when it applies, though it does not explicitly state exclusions or alternatives beyond these references.

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?

There are no annotations, so the description carries the burden of behavioral disclosure. It implies a read-only search and mentions resolving a category_id, but it does not disclose return format, pagination, ordering, error behavior, or whether results are limited or localized.

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 sentence that front-loads the core purpose and then adds the key usage guidance. Every phrase earns its place with no redundant wording.

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

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

The description is adequate for a simple search tool, but with no output schema and no annotations, it leaves gaps around the exact return structure and the locale parameter. It gives the essential purpose but not enough detail for an agent to fully predict the invocation outcome.

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 schema documents q with 'Search text, any language,' but locale has no description. The description does not compensate for the missing locale documentation or clarify how the locale parameter affects search behavior, so the agent still has to guess for an unhandled 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?

The description clearly states the tool searches Agenzax's industry taxonomy, a specific resource and action. It also positions the tool in an explicit workflow by mentioning it should be called before register_profile/search_directory to resolve a category_id, which distinguishes it from sibling tools like search_regions.

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 clear context on when to use the tool: before register_profile/search_directory and to resolve a category_id. It does not explicitly mention alternatives like search_regions, but the workflow direction is specific enough to guide correct usage.

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 description adds useful scope by specifying 'other companies'/individuals' public listings', making clear it does not search the agent's own listings. Because there are no annotations and no output schema, it does not disclose pagination, ordering, authorization requirements, or response shape, though the read-only nature is implied by 'Search'.

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 concise, front-loaded sentence that clearly communicates the core functionality. It avoids fluff, though the brevity leaves out parameter-level detail that would be valuable.

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

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

With no annotations, no output schema, and four undocumented parameters, the description should provide more contextual help. It conveys the tool's purpose but leaves an agent without enough information to construct correct queries or understand how the filters combine or what results will look like.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description is the only source of parameter meaning. It broadly hints that 'query' is natural-language and the remaining inputs are structured filters, but it does not map these to the actual parameter names or explain fields like roles, region_id, and category_id. This is inadequate compensation for completely undocumented parameters.

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 ('Search') and a clear resource ('other companies'/individuals' public listings'), which differentiates it from sibling tools like search_categories and search_regions. It also mentions the query style ('natural-language query + structured filters'). It does not explicitly name sister tools, so it stops just 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?

The description implies when to use the tool: when you want to find public listings of other companies or individuals. However, it gives no explicit guidance on when to prefer this over search_categories or search_regions, and offers no exclusions or 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?

No annotations are provided, so the description carries the full burden. The verb 'search' suggests a read-only operation, but the description does not explicitly state that it has no side effects, requires no auth, or is safe to call repeatedly. It is adequate but not fully explicit.

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 concise and to the point, with no extraneous words. It effectively conveys the core purpose and a key usage hint in a single sentence.

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?

While the description provides a usage hint, it omits essential parameter semantics. Without knowing what 'q' and 'country_only' do, an agent cannot reliably invoke the tool. Given no output schema, the description should at least cover input expectations, which it does not.

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 schema provides no descriptions for the parameters 'q' and 'country_only', and the description does not explain them either. With 0% schema description coverage, the description should compensate, but it fails to define what 'q' represents or how 'country_only' affects the search.

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 clearly states a specific verb ('search') and resource ('Agenzax's region taxonomy'), with a purpose of resolving a region_id. It does not explicitly differentiate from the sibling 'search_categories', but the resource is distinct enough.

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 provides explicit when-to-use guidance: 'call this before register_profile/search_directory to resolve a region_id.' This is actionable and helps the agent sequence tool calls, though it does not mention alternatives or edge cases.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It exposes the delivery_status semantics (delivered/held/blocked), warns that held/blocked means non-delivery, and explains the 422 rejection for 'contact_card'. This is thorough, honest, and non-obvious behavior that an agent needs to know.

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 dense sentences, no filler. The purpose is front-loaded, followed by critical delivery-status guidance and the content_type constraint. Every sentence carries operational 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 a simple three-parameter send tool with no output schema, the description covers the key edge cases: checking delivery_status, the contact_card_request flow, and the forbidden contact_card value with its 422 error. No critical operational gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds important meaning to content_type by explaining the 'contact_card_request' scenario and explicitly forbidding 'contact_card'. session_id is contextualized by 'already-open session', and message is self-explanatory. Slightly more detail on message formatting or delivery_status output shape would push it higher.

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 clearly states a specific action ('Send a message') and a specific resource/'already-open session', which immediately distinguishes it from sibling tools like open_conversation and read_conversation. The purpose is unambiguous and actionable.

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 provides clear context for when to use the tool: it must target an already-open session. It also gives explicit guidance on checking delivery_status and when to use content_type='contact_card_request', plus a hard constraint against sending 'contact_card'. It does not explicitly name alternatives, so it stops 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.