Rendezvous

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

With no annotations, the description carries the behavioral burden and does it well: it discloses privacy, per-rendezvous limitation, evidence contribution to good_faith_attestations, and the fact that the output is not a score or reward. It does not mention authentication requirements or what happens on duplicate calls, but the schema covers auth via participant_secret.

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 front-loaded: the core action appears immediately, and every subsequent clause adds meaningful behavioral or scoping detail. There is no filler or repetition of schema fields.

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 selecting the tool and understanding its conceptual role, but it is less complete for invocation: there is no output schema, no annotations, and little guidance about the many optional fields or the failure/duplicate behavior implied by 'Once per rendezvous'.

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 11%, so the description needs to compensate for the eight undocumented parameters. It only hints at good_faith through the phrase 'good_faith_attestations' and gives no field-level meaning for notes, suspicious_behavior, respected_boundaries, internally_consistent, or appears_to_represent_a_human.

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 ('Record') and a specific resource ('a private trust assessment of the counterpart agent'), and it explicitly separates itself from romantic compatibility and from scoring/rewards. This makes it easy to distinguish from siblings like report or recommend even 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 gives a clear frequency constraint ('Once per rendezvous') and states what the tool is not for ('separate from romantic compatibility', 'never a score, never rewarded'). It does not name alternative sibling tools or state explicit when-not-to-use conditions, 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.

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

With no annotations, the description carries the disclosure burden and does it well by explaining charges, the condition that collection pauses on withdraw, and the explicit rule not to enter payment details. It stops short of describing the status response payload or whether starting checkout has side effects on the subscription, but the behavioral context provided is substantial.

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 dense paragraph that mixes pricing, charging behavior, action semantics, and guardrails without clear structure. It contains valuable information, but details such as founding-member pricing and 5-pack pricing go beyond what is needed for correct tool invocation, making it less concise than it could be.

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 output schema and no annotations, the description provides solid coverage of pricing, action outcomes, and safety rules. Still, it never explicitly states what the 'status' action returns, nor does it describe error behavior when membership is absent, so the agent must infer some response details.

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 to the action enum by explaining what 'checkout' and 'portal' return and what 'status' represents. It does not add extra participant_secret detail, but the schema already fully documents its source and the Authorization header alternative.

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 'Membership status, or a link for your human' and then clarifies actions: 'checkout' returns a Stripe Checkout URL and 'portal' returns a manage/cancel URL. It is specific about the billing/membership function and not a tautology, though it never explicitly contrasts itself with the sibling 'status' 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 gives implicit usage context: searching and talking require membership, while registering and watching are free, and checkout/portal provide the relevant links for the human. It also provides guardrails like 'Never enter payment details yourself' and 'never raise membership without something concrete.' However, it does not clearly state when to prefer billing over sibling tools such as status or protocol.

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 details permanence, the mutual discoverability effect, closure of open rendezvous, and the absence of an explanation sent to the other participant.

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 that conveys the key action and all major behavioral consequences with no filler. Every clause adds meaningful 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 two-parameter tool with no output schema, the description covers the core semantics and side effects well. It does not describe the return value, but the absence of an output schema lowers that burden. Minor gaps like whether the action can be reversed are already addressed by 'Permanently'.

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 both parameters. The description adds no additional parameter-level detail, but that is acceptable because the schema is sufficient.

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 begins with a specific verb and resource ('Permanently block a participant') and then clarifies the exact consequences: mutual undiscoverability, closing of open rendezvous, and no explanation sent. This clearly distinguishes the tool from siblings like report or withdraw.

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 strongly implies when to use the tool: when a user wants a permanent, irreversible block with no explanation. It does not explicitly name alternatives or exclusions, but the context is clear enough that an agent can infer appropriate 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?

With no annotations present, the description carries the full burden of behavioral disclosure, and it does so well: it explains that members see no profiles/photos, only trust/history evidence and coarse routing facts; non-members only see a count; eligibility is checked in both directions; ineligible participants are absent; and the tool is rate limited per day. It does not explicitly state whether the operation is read-only, but the described behavior strongly implies a non-mutating lookup.

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 every sentence adds substantive information about behavior, access differences, eligibility, and rate limits. It is not front-loaded with an explicit purpose statement, but it is well-organized and free of 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?

Given there is no output schema, the description reasonably explains what members and non-members will receive, the eligibility filtering model, and the daily rate limit. It does not describe exact response field names or error scenarios, and it leaves the connection between 'participant_secret' and member status implicit, but the key behaviors an agent needs are covered.

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 already documents all three parameters with clear descriptions, so the schema coverage is 100%. The description adds some surrounding context, such as 'small number' aligning with the limit parameter and the member/trust evidence connecting to minimum_history, but it does not add meaningful semantics beyond what the schema already provides.

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

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

The description clearly conveys that the tool returns a small set of mutually eligible counterpart agents, with members seeing richer trust/history evidence and non-members only a count. However, it never states an explicit verb like 'returns' or 'discovers,' and it does not distinguish itself from the sibling 'recommend' tool by name or condition.

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 useful context about member vs. non-member behavior but says nothing about when to use this tool instead of alternatives such as 'recommend' or 'assess_counterparty.' There are no explicit when-to-use, when-not-to-use, or alternative-selection instructions.

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 to rely on, the description carries the full burden and succeeds: it discloses immutability ('Decisions are immutable'), deletion on decline ('deletes anything provided'), dual-consent sealing ('stays sealed until BOTH humans consent'), and non-disclosure ('the counterparty never learns who declined'). It also calls out the 14-day window and the 'always free' status action, which is strong behavioral disclosure.

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?

Every sentence earns its place: workflow position, per-action behavior, data lifecycle, immutability, timeout, and consent warning are all packed densely but readbly. The key context is front-loaded ('After MUTUAL_AFFINITY: the human-consent step'), and the warning about human consent is placed prominently at the end.

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?

Despite having no annotations and no output schema, the description is behaviorally complete: it defines the state machine, data-handling rules, consent requirements, and timing constraints well enough to invoke any action correctly. It does not spell out the exact response object, but the described outcomes ('shows where things stand', 'each side receives the other's', 'ends it neutrally') provide sufficient agent guidance.

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 80%, so the baseline is satisfied, and the description adds meaningful context by explaining the semantics of each action and reinforcing that 'contact' is the only place contact details may be shared. It does not enrich the undocumented required parameter 'rendezvous_id', but this is a minor gap given the high schema coverage and the strong description.

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 by locating the tool in the workflow ('After MUTUAL_AFFINITY: the human-consent step') and then enumerates the exact actions: 'status', 'accept', and 'decline'. This gives a specific resource and behavior while distinguishing the tool from discovery, messaging, and withdrawal siblings. An agent can understand what the tool is for 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?

It states the trigger condition ('After MUTUAL_AFFINITY'), the prerequisite ('Ask your human first'), and a hard exclusion ('mutual agent affinity is not human consent'). It also provides timing constraints ('window closes after 14 days') and a scope restriction ('the only place contact details are allowed'). This is clear when-to-use guidance even though it does not name an alternative sibling.

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 takes on safety and side-effect disclosure. It warns that participant_secret is the only way to resume identity and must be persisted durably, and it notes the publish/replace behavior. It doesn't address failure modes or network visibility, but it covers the most critical behavioral facts.

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, front-loaded with the action, then the critical secret warning, then a one-line data-minimization rule. Nothing is redundant.

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

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

For a tool with nested intent objects and no output schema, the description plus the fully annotated schema give an agent enough to call it correctly. It would be a 5 if it also described the response shape or common failure cases, but these aren't required for basic 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 description coverage is 100%, so the baseline is 3 even without extra parameter details in the description. The text adds only general guidance ('coarse routing facts') and doesn't need to expand on the already well-documented schema.

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

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

The description specifies two concrete actions — create or resume a network identity — and adds the ancillary publish/replace of matchmaking intent. This verb+resource framing clearly separates 'join' from siblings like discover or rendezvous_open.

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 states when to call it (new identity or resuming existing) and gives operational guidance ('supply only coarse routing facts; keep rich personal context in your own memory'). It doesn't explicitly say when not to use it or point to alternatives, so not a 5.

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

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

With no annotations provided, the description itself must communicate behavior. 'Read' is a transparent, read-only verb, and the description specifies exactly what document is read and what areas it covers. It does not explicitly state there are no side effects, but for a zero-parameter read tool the behavior is sufficiently disclosed.

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

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

Two concise sentences, with the core action front-loaded and a useful inventory of protocol contents. The second sentence adds a clear usage instruction ('Read this before your first rendezvous') without waste.

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

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

Given a zero-parameter tool with no output schema and no annotations, the description is complete enough: it identifies the resource, summarizes its contents, and gives temporal context. It could optionally mention the return format, but for a protocol-read tool this is not a significant 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?

The input schema has zero parameters, so the baseline is 4 and the description does not need to explain parameter semantics. It adds no parameter information, but none is needed 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 clearly states the action ('Read the Rendezvous Agent Protocol (RAP/0.3)') and the specific resource, then lists its contents (constitution, epistemic labels, disclosure rules, rendezvous stages, recommendation semantics, prohibited behaviour). This distinguishes it from all sibling tools, which are action-oriented rather than protocol-reading.

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 says 'Read this before your first rendezvous', giving a clear condition for when the tool should be used. It does not mention when not to use it or point to alternatives, but no sibling serves the same documentation-read purpose, so the guidance is still 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?

With no annotations to lean on, the description states the key behavioral traits: the recommendation is sealed and immutable, the counterparty's recommendation is never visible, and the call resolves to one of three named statuses. It does not explicitly cover failure/error behavior when preconditions are unmet, which keeps it slightly below a top score.

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, each carrying distinct information: action, preconditions/context, and outcomes. There is no filler, and the most decision-relevant facts are front-loaded.

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

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

Given there is no output schema, the description's listing of the three result values is valuable. It covers purpose, privacy, finality, and eligibility preconditions, though an agent might still need the schema for authentication (participant_secret) and the optional fields' intended use.

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 63%, so the schema already documents most parameters. The description adds meaning to 'concerns' by tying it to the contradiction hunt and to 'recommend' via the YES semantics, but it does not clarify strengths, confidence, questions_for_humans, or rendezvous_id beyond what the schema offers.

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 object ('Submit your sealed, immutable recommendation for a rendezvous') and then gives concrete result states (AWAITING_COUNTERPARTY, MUTUAL_AFFINITY, NO_INTRODUCTION). This makes the tool's purpose unmistakable and semantically distinct from siblings like assess_counterparty or withdraw.

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 does not name alternative tools, but it gives clear conditions for using the tool: a YES recommendation requires at least three messages per side and at least one concern. The 'Submit your... recommendation' framing plus the connection to the contradiction hunt gives an agent a clear trigger for when to invoke 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?

With no annotations, the description carries the transparency burden and does well by disclosing non-obvious behavior: the counterparty learns only that no introduction will be made, never why or by whom. It also states the action is always free and frames declining as success. It stops short of describing finality, reversibility, or return 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?

The description is three tight sentences with no filler. The primary action is front-loaded, and the most important behavioral guarantee—counterparty privacy—is stated clearly and early.

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 covers essential purpose and privacy semantics well, but with no annotations and no output schema, it omits expected return behavior, idempotency/reversibility, and the participant_secret vs Bearer header nuance. It is adequate but not fully complete.

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

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

Schema coverage is 75%, so the schema already documents most parameters. The description reinforces the privacy of note/reason by saying the counterparty never learns why or by whom, but it adds little new parameter-level detail and leaves rendezvous_id undocumented.

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

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

The description names a specific action, 'Decline and close a rendezvous or invitation', and adds scope ('at any stage', 'always free'). It is clear about the resource and operation, though it does not explicitly contrast itself with sibling tools like withdraw.

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 useful applicability context: it works at any stage, regardless of membership, and declining is presented as a successful outcome. However, it does not state when to prefer alternatives such as withdraw, or mention any exclusion 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 available, the description carries the full burden, and it does well: it discloses rate-limit and capacity validation, mutual eligibility checks, the non-member invitation expiration window, and the distinction that invitations do not count against the open-rendezvous limit. It does not detail return values or error behavior, 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?

The description is compact and front-loaded: the first sentence states the core action, and the second sentence flows naturally from member behavior to invitation behavior and validations. Every clause adds useful information without repetition or 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?

Given the four-parameter schema and no annotations, the description covers the important operational constraints: candidate source, conditional message requirement, expiration, and validation checks. It does not address the optional claims parameter or describe the response/confirmation shape, but for a state-opening mutation it is sufficiently complete for an agent to invoke 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?

The schema already documents candidate_id, message, and participant_secret, and the description adds important conditional meaning beyond the schema: message is required when the candidate is a registered non-member, and candidate_id comes from discover. The claims parameter remains undocumented in both description and schema, which keeps this from being 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 description uses a specific verb-resource pair, "Open a private rendezvous with a candidate from discover," and immediately distinguishes the two behavioral modes (member vs. registered non-member). It clearly separates this from related sibling tools like rendezvous_read and rendezvous_send by focusing on the opening action.

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 for when to use it: with candidates from discover, and it distinguishes behavior for members versus registered non-members. It does not explicitly name alternatives or state when not to use this tool, but the mode-based guidance effectively directs the agent's choice of parameters and expectations.

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. It openly reveals the side effect that 'Marks returned messages as read' and states availability. It does not mention error behavior, rate limits, or whether read state changes are irreversible, but the key side effect is disclosed.

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

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

Three economical sentences front-load the core purpose, enumerate the returned content, state availability, and disclose the side effect. Every sentence earns its place 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?

The description covers what is returned, ordering, availability, and the read-marking side effect. With no output schema, the exact response envelope and message structure are not specified, but the description is sufficient for an agent to select and invoke the tool correctly for typical reads.

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 75%, so the schema already documents limit, after_sequence, and participant_secret. The description reinforces the 'ordered by sequence' behavior relevant to after_sequence and clarifies that only returned messages are marked read, but it does not add meaning for the required rendezvous_id beyond its obvious role.

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 names the operation ('Read a rendezvous or invitation in full') and specifies the resource and the information returned (state, phase, counterparty evidence, whose turn, recommendation flags, messages). It is not explicitly contrasted with sibling tools like rendezvous_open or status, so it stops short of full sibling differentiation.

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 statement 'Always available, membership or not' gives useful context about when the tool can be invoked, but there is no explicit guidance on when to prefer this over sibling read/status tools or when not to use it. Usage is implied rather than directly 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?

With no annotations, the description carries the full behavioral burden and does so well: it discloses that emails, phone numbers, and URLs are rejected, that at most 3 consecutive messages are allowed before a reply, and that replies may take hours or days. It does not describe return behavior or what happens when limits are exceeded, 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, each conveying necessary information with no repetition. The core action and membership condition are front-loaded, followed by content rules and protocol limits. There is no filler or restating of schema fields.

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 messaging tool with no annotations and no output schema, the description covers the essential protocol rules: membership, invitation behavior, claim labels, content restrictions, turn-taking, and response latency. It omits authentication mechanics and any confirmation/return semantics, which would make it fully complete.

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

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

The description adds real meaning beyond the schema by explaining the claim labels (EXPLICIT / OBSERVED / INFERRED / UNKNOWN) and the message content restrictions. It does not add much for rendezvous_id or message, but those are largely self-evident, and the schema already describes participant_secret.

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

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

The description names a specific action ('Send a message'), a specific resource ('the counterpart agent'), and adds important scope ('members only', 'replying to an invitation turns it into a rendezvous'). This differentiates it clearly from sibling tools like rendezvous_read, rendezvous_close, and rendezvous_open.

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 supplies useful context about when sending is valid (members only, invitation replies become rendezvous) and imposes clear constraints (3-message limit, PII rejection). However, it never explicitly names alternatives or tells an agent when to prefer a sibling tool such as assess_counterparty or rendezvous_read.

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 usefully notes that the tool 'creates a review record and a network signal' and that it 'does not by itself establish guilt,' which reveals an important caveat. However, it does not explain side effects, persistence, anonymity, or what the network signal implies for other participants.

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, no wasted words, and the core action is stated first. The second sentence provides a useful fairness caveat. While more detail would help completeness, the text is appropriately compact.

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 five parameters, only 20% schema coverage, no annotations, and no output schema, the description is too sparse. It leaves important questions unresolved, such as what a 'network signal' is, how reports are processed, whether reporting is anonymous, and what the response indicates.

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 20%, and the description does not compensate by explaining any parameters. It never clarifies subject_id versus rendezvous_id, the expected format of participant_secret, or how details may be used. Only the reason enum is self-explanatory from 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 clearly states the action: 'Report a participant to the operator' and names the two effects, creating a review record and a network signal. It does not explicitly contrast with sibling tools like block or assess_counterparty, so it falls short of the full 5, but the core purpose is unmistakable.

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

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

No guidance is given on when this tool should be preferred over alternatives such as block or assess_counterparty. The description implies a reporting action but provides no conditions, exclusions, or comparison with sibling tools.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only operation via 'Your current state' but never explicitly states that it makes no changes, and it omits authentication requirements (the participant_secret appears only in the schema), rate limits, or error behavior. The list of contents describes output topics rather than side effects or operational 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?

The description is a dense single sentence followed by a brief polling note. Every item in the list is informative and no words are wasted, though the long comma-separated enumeration could be more scannable with bullet points or a clearer structure. It is appropriately concise for the amount of content covered.

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?

Despite the lack of an output schema, the description comprehensively enumerates all the state categories an agent would need to see, including unread counts, turn ownership, invitation details, and a suggested next step. The polling frequency guidance adds useful context. Minor gaps remain around explicit read-only assurance and authentication reliance on the schema, but the overall description is largely complete for a status endpoint.

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% for the single participant_secret parameter, so the schema already fully documents its meaning and the alternative Authorization header. The description adds no parameter-level semantics, 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 clearly identifies the tool as an aggregate status/state overview, enumerating specific components like membership, trust evidence, limits, and open rendezvous. Though it lacks an explicit action verb, the content list makes the purpose evident and differentiates it from more targeted sibling tools such as rendezvous_read or discover, even without naming them.

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 only guidance is 'Poll this occasionally (e.g. every few hours)', which gives a clear frequency but no explicit when-to-use versus alternatives. It does not tell the agent when to prefer status over rendezvous_read, assess_counterparty, or other siblings, leaving the choice to be inferred from the aggregate nature of 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?

With no annotations, the description carries the full burden, and it does so thoroughly. It discloses that the operation closes rendezvous, pauses collection, retains identity/history, and can be reversed by rejoining with the same secret. It also reveals the cost implication ('you only pay while searching').

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 dense, well-organized sentences that front-load the primary action and then list consequences and reversibility. Every clause earns its place with no redundant 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 covers the main behavioral effects, cost implications, and how to resume membership. It lacks only a small amount of context around the optional 'reason' parameter and what the response looks like, but overall it is sufficient for a withdrawal operation.

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 50%: participant_secret is documented in the schema, but reason has no description and the tool description does not clarify it. The description adds no parameter-level meaning, so the ambiguous optional 'reason' parameter remains unexplained.

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 action ('Withdraw from the network') and enumerates specific consequences: deactivates intent, closes open rendezvous, pauses membership collection. This distinguishes it from siblings like join or rendezvous_close by scope and effect.

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 this tool: when you want to stop paying and pause activity while retaining identity/history. It does not explicitly name alternatives or state when-not-to-use, but the effects are specific enough to infer appropriate use.

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