Gamedev Tavern — MCP for the game industry

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is carried structurally. The description usefully adds that 'skip'/'enough' close the question, but says nothing about irreversibility, who consumes the answer, or what happens to text beyond the character cap.

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

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

Three short sentences, front-loaded with the action and target, with no filler. The telegraphic phrasing ('decision skip or enough closes it') is slightly cryptic but 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?

For a destructive, open-world mutation with no output schema, the description covers the essential call and close semantics but omits consequences of closing (is the question gone permanently?) and how the 'ask the human' path interacts with the quest flow. Adequate but with clear gaps.

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%, including descriptions for id, text length limits, the decision enum, and the idempotency key, so the schema does the heavy lifting. The description only restates the id source and the effect of the decision values, adding little beyond structured data.

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 ('Answer a quest's Bar question') and identifies the target item type ('needs_human bar_question id'). It is clearly distinct from siblings like interview_answer or chat_summary, though it never names an 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?

It gives concrete operational guidance: answer from known facts, ask the human for unknowns, and use 'skip'/'enough' to close without an answer. It lacks explicit when-not conditions or named alternative tools, but the selection among text vs. decision is spelled out.

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

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

Annotations already cover read-only, idempotent, non-destructive, so the bar is lower; the description still adds real value by disclosing that recent messages are returned only for private chats where the agent may write, and that the counterparty's text is isolated in an 'untrusted' field. It omits what happens when access is denied or the chat is missing.

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 clauses, front-loaded with the identity of the resource, then the returned fields, then the trust caveat. No padding; telegraphic style is dense but every clause carries information.

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

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

With no output schema, the description compensates by naming the returned components (counters, deadline, quote, recent messages, untrusted text). Adequate for a 2-parameter read tool; only the failure/empty-case behavior is unaddressed.

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

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

Schema coverage is 100% and the schema already explains 'after' as a cursor returning up to 8 newer messages via data.next_after. The description restates the cursor idea and adds the write-permission condition, but contributes little 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+resource ('One chat by chat_id') and enumerates what comes back (counters, deadline, quote), which distinguishes it from list_chats. It never names the sibling explicitly, so the differentiation is implied rather than declared.

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

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

Usage is only implied: the id parameter description points at list_chats/quest_status as the source of chat_id, and 'when the agent may write there' conditions the private-chat branch. There is no explicit 'use this instead of X when Y' guidance against list_chats or message-reading siblings.

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

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

Annotations already declare the mutation/idempotency/open-world profile, so the bar is lower. The description does add real context beyond them: the chosen goal is placed in the Agents Bar automatically, so the agent needn't take a follow-up action. It omits failure behavior (invalid or already-consumed suggestion_id) and any permission requirements.

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

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

Two short sentences with no filler, and the primary action is front-loaded. It is terse almost to a fault, but nothing in it is wasted.

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

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

For a two-parameter, fully documented tool with rich annotations and no output schema, the description covers the essential effect. It leaves gaps around idempotency behavior (partially implied by 'like start_quest'), error cases for a stale suggestion_id, and confirmation of what the caller sees after the goal starts.

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

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

Schema description coverage is 100%, with both parameters documented (suggestion_id source, idempotency key semantics), so the baseline is 3. The description itself contributes nothing about parameters, which is acceptable given the schema does the work.

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

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

States a specific verb and resource ('Start the goal'), and the qualifier 'the person picked' scopes it to a suggestion selected from suggested_goals. The comparison 'like start_quest' helps an agent separate it from that sibling, though the relationship to suggested_goals is only made explicit in the schema, not the description.

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

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

Usage is implied ('the person picked') rather than stated as a rule: no explicit 'call this after suggested_goals' or 'do not use this to create a brand-new goal'. The reference to start_quest hints at the alternative but never says when to prefer one over the other.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds real substance: what actually changes ('the Bar closes and leads fade') and how to reverse it ('Reopen with start_quest and the same text'). It does not mention how the outcome text is handled (truncated to 280 chars) or error behavior, but the core state-change consequences are covered.

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

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

Two short sentences with zero filler; the trigger and effect come first and the recovery path second. Every clause carries information an agent needs.

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 terminal mutation with no output schema, the description covers the trigger, the visible consequence, and the undo path, while the schema covers idempotency and field semantics. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so id, outcome, and request_key are fully documented in the schema, including idempotency semantics and the outcome length cap. The description adds nothing about parameters beyond 'the same text' tying back to reopening, so the baseline 3 applies.

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

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

States a specific verb and resource ('Close a quest') plus its trigger ('when the human says it is done') and its effects ('the Bar closes and leads fade'). It also names the inverse operation, start_quest, so an agent can distinguish it from the sibling without opening either schema.

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

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

Gives a concrete trigger condition (the human confirms the quest is done) and points to start_quest as the alternative for reopening. It does not state any exclusion, such as not closing a quest on the agent's own initiative, so a small amount of judgment is left to the caller.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds real content beyond them: it discloses that the payload spans owned studios, join requests and invite links, and both confirmed and pending work relationships — useful shape-of-data context.

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

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

A single sentence, front-loaded with the primary resource and ending with the actionable downstream pointer. It is dense (em-dash clauses, mixed ownership/directionality) but every clause carries information; slight re-reading is needed to parse 'studios where the human works'.

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

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

There is no output schema, so the description must carry the return-value burden, and it does: it enumerates the returned groups and the confirmed/waiting distinction. Minor gaps remain — no sense of ordering, volume, or what an empty result means — but an agent could invoke this correctly.

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

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

The tool takes zero parameters, so the baseline is 4. The mention of member_id is a returned field, not an input, and the description correctly does not invent parameter semantics for a no-arg call.

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

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

The description names the resource precisely — the human's studios, their teams, join requests, invite links, plus studios where the human works (confirmed or waiting). That enumerates the returned entity set well enough to separate it from queries like profile_card or project_status, though the verb is elided into a noun phrase rather than stated as 'returns/lists'.

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

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

There is one concrete routing hint: 'member_id for edit_company_team', which tells the agent this is the source of the identifier the edit tool needs. Beyond that the when-to-use context is only implied (call it to see team/studio membership state); there are no explicit exclusions or alternatives 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the scope of checks (connection, abilities, limits, interview readiness, quests, next steps) but does not explain output, permissions, or what 'both doors' means.

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

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

It is a single front-loaded sentence with little waste. However, the cryptic phrase 'through both doors' adds ambiguity rather than clarity.

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 read-only status tool, the description lists what is checked but does not clarify the return shape or how this relates to more specific sibling status tools. With no output schema, that leaves a meaningful 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 tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description does not need to document parameter semantics.

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

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

States the verb 'Check' and lists several resources, but the list is broad and 'through both doors' is opaque. It does not clearly distinguish this overview from siblings like interview_status, quest_status, or operation_status.

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 on when to use this tool versus the many status-related siblings, and no exclusions or prerequisites are given. Usage is only implied by the word 'Check'.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds little beyond that — it does not warn that rejecting permanently discards the addition or that accepting mutates a quest/profile/project, nor does it explain what happens on retry. Adequate but thin for a destructive mutation.

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

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

A single, front-loaded sentence with the action verb leading and the scoping hint trailing in parentheses. No wasted text, though the parenthetical packs several concepts into an ambiguous phrase.

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

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

For a 3-required-parameter destructive mutation with no output schema, the description covers the core action but omits outcome shape ('what do I get back'), the irreversibility of reject, and any precondition on the proposal state. The rich schema partially compensates, leaving it adequate but with clear gaps.

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

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

Schema coverage is 100%, so the baseline is 3. The description only echoes the 'id' semantics already spelled out in the schema ('id of the needs_human bar_context_proposal item or its object_ref') and says nothing about decision or request_key beyond what the schema documents.

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 pair (accept/reject) and a specific resource (a Bar agent's addition to the human's quest). It's distinguishable from siblings like answer_bar_question or close_quest, though the 'needs_human bar_context_proposal id' phrasing is internal jargon that partly obscures what is actually being decided.

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

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

Usage is only implied: the parenthetical suggests the tool applies when you hold a pending bar_context_proposal item. There is no explicit when-not guidance, no mention of prerequisites (e.g., the proposal must be pending), and no routing to alternatives such as answer_bar_question for related Bar interactions.

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

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

Annotations already declare `destructiveHint: true` and `idempotentHint: true`, so the safety profile is covered. The description adds useful behavioral detail beyond that: `not_fit` is destructive because it drops the lead, while `restore` reverses that effect. It does not explain side effects of `clarify` or what `fit` retains, but the key destructive behavior is disclosed.

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

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

Two tight sentences, front-loaded with the action and the allowed values, followed by the consequence of the two non-obvious decisions. There is no redundant text.

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 tool has rich schema and annotations, no output schema, and the description covers the decision options and their main effects. It is nearly complete, though it could clarify what `clarify` triggers and whether `fit` has any downstream effect, leaving a minor gap.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema. The description restates the decision enum semantics already present in the schema and adds no extra syntax, format, or edge-case detail about `id` or `request_key`, 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 states a specific verb+resource ('Decide on a quest candidate (lead)') and enumerates the four possible decisions, so the agent knows what the tool does. It does not distinguish this from the sibling `decide_context_proposal`, which is a different kind of decision, so a 4 rather than 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 gives the practical consequence of two options ('not_fit drops it and lets the Bar keep matching; restore undoes not_fit'), which helps an agent choose. However, it gives no explicit when/when-not guidance, prerequisites, or comparison with alternatives such as `decide_context_proposal`, so usage is only implied.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the description is not required to carry the safety profile. It does add that only the owner may act, that invite produces a link for a person or their AI agent, and that a username-restricted invite can only be accepted by that user — genuine context beyond the structured fields. It stops short of saying what `remove`/`revoke` actually destroy or whether they are reversible.

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

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

A single compact sentence with the actor and resource front-loaded and the action inventory following. The parenthetical about agent links is dense but earns its place; no filler text.

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 7-parameter, multi-action mutation tool with no output schema, the description covers purpose, actor, and the full action surface, and the schema fills in required fields and idempotency. Missing is any hint about what success returns or which parameters pair with which action beyond what the schema states.

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 explains each parameter and the enum documents the eight actions. The description only restates the action set with no additional syntax, format, or per-action parameter mapping, so the baseline 3 applies.

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

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

States a specific verb-and-resource pair ('manages their studio team') and enumerates the eight operations the single tool performs, so an agent can match it to a team-management request. It does not, however, distinguish itself from the sibling `company_team`, which clearly supplies the ids this tool consumes.

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 'owner manages their studio team' framing implies the actor and setting, but there is no explicit when-to-use/when-not guidance, no mention of calling `company_team` first to obtain `member_id`/`invite_id`, and no exclusions. Usage must be inferred from the action list.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and non-read-only, so the safety profile is covered. The description adds two genuinely new pieces of context: that the page is publicly visible ('Others see it') and that publishing/taking down changes that visibility, plus the caution about shareable facts. It does not discuss the async/202 behavior or the effect of removals, but those are in the schema.

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

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

Two compact sentences, front-loaded with the edit surface and ending with the visibility caution. No filler, no restatement of the title, 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 nine-parameter destructive mutation with no output schema, the description covers the edit surface and the public-visibility consequence, which are the non-obvious parts. The remaining mechanics (idempotency key, wait_s/202, item shapes) are fully specified in the schema, so nothing critical is missing from an agent's point of view.

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

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

Schema coverage is 100%, so the schema already documents all nine parameters in detail (including add/edit/remove item shapes and wait_s semantics). The description only echoes the 'about/company/role' topics and the publish/take-down notion, adding essentially nothing beyond the schema. Baseline 3 is appropriate.

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

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

The description names a specific verb (Edit) and enumerates the resources it touches: card facts, the «О себе» story, company, role, and the public page's publish/take-down state. That is enough to distinguish it from most siblings, but it never names profile_card (the read counterpart) or edit_company_team, so differentiation is left implicit.

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

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

Usage is implied rather than stated: an agent can infer this is the mutation path for a profile card, and the closing line adds a content constraint ('only use facts the human may share'). There is no explicit when-to-use/when-not, and no sibling such as profile_card or edit_company_team is named as the alternative.

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

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

Annotations already declare it is not read-only, is idempotent, and is open-world. The description adds non-obvious behavior: the interview prerequisite, the always-202 async response, and the event chat becoming read-only after delivery. It does not contradict annotations, though it could clarify what the 202 response implies for the caller.

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

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

It is very short and front-loads the prerequisite before the mode and state information, with no filler. The telegraphic fragments ('Text or prepare:true; always 202') are concise but slightly reduce readability.

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

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

For a four-parameter tool with annotations and full schema coverage, the description supplies the key operational context: prerequisite, async response, and post-delivery restriction. It does not need to explain return values because there is no output schema, though it could clarify the consequence of the 202 response.

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. The description reinforces the text-vs-prepare choice ('Text or prepare:true'), but it does not add format, length, or idempotency semantics beyond what the schema already documents.

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 never states a clear verb+resource such as 'send a message to the event chat'; it relies on the title and fragments like 'Text or prepare:true.' An agent can infer it composes an event-application message, but the purpose is not stated directly, and sibling differentiation is only implicit through the post-delivery read-only note.

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 prerequisite ('Complete the full interview first'), a choice of modes ('Text or prepare:true'), and an explicit when-not/alternative ('After the application is delivered the event chat is read-only; continue in the private chat from links.chat'). That covers when to use it, when not to use it, and where to go instead.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real value by flagging the candidate's summary as untrusted (a prompt-injection caution) and by bounding the payload ('no contacts or files'). It doesn't describe pagination behavior directly, 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?

A single dense sentence that front-loads the resource, then the returned fields and the explicit exclusion, with zero filler. Every clause corresponds to something an agent needs.

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

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

With no output schema, the description does the work of sketching the return shape (name, role, summary, chat/inbox link) and its limits (no contacts or files), which is exactly what's needed to decide whether to call it. Only the cursor/pagination story is left entirely to the schema.

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

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

Schema description coverage is 100%, including the non-obvious 'pass data.next_since from the last call' cursor instruction, so the schema already carries parameter meaning. The description adds nothing on slug or since semantics, which is acceptable at this coverage level but is baseline only.

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

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

States the resource precisely ('applications to an event you organize or observe') and enumerates the payload fields, so an agent knows this is a read of applicant records rather than messages or status changes. It does not name the near-siblings (event_application_status, event_application_message, send_event_application), so differentiation is left to inference, keeping it just below 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?

'an event you organize or observe' implies the access condition and thus when the tool is applicable, but there is no explicit when-to-use/when-not statement and no routing to the sibling tools that handle messaging or status decisions. Usage is implied, not guided.

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

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

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior. The description adds non-obvious privacy/visibility context: the organizer's AI hint is private and not returned, and review.card is the human-reviewable portion. It does not add auth/rate/permission details, but with annotations the bar is lower.

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 compact sentences, front-loaded with the returned resource and followed by field-role clarifications. No redundant text, though the first sentence is terse enough to be slightly underspecified.

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 read-only status tool with one fully documented parameter and no output schema, the description identifies the returned state/card and one key exclusion. It still leaves 'application state' vague and does not describe response shape or status values, so it is only adequately 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 single slug parameter is fully documented in the schema, including its source via connect_status events_open[].slug, so the baseline is 3. The description adds no further parameter meaning or format guidance 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 the resource (event application) and what it returns (state and card), and distinguishes review.card from the private organizer AI hint. However, it omits an explicit verb and does not name or contrast sibling tools such as event_applications, start_event_application, or send_event_application.

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?

Implies usage for inspecting an event application's current state/card and clarifies that review.card is what a human reviews before sending. It does not state when to use this rather than event_applications, start_event_application, or send_event_application, nor any prerequisites or exclusions.

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

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

Annotations already cover safety with readOnlyHint, idempotentHint, and destructiveHint=false, so the description only needs to add behavioral context. It does so by noting public pages, ranking relevance to the human, and returning a person's page plus quests to respond to.

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

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

It is short and front-loads the main action and trigger. The second sentence is somewhat elliptical, but it still packs useful ranking and return-value hints without 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 six optional parameters, full schema coverage, and no output schema, the description supplies enough context about when to use it, ranking behavior, and the kind of result returned. Minor gaps around pagination and filtering are covered by the schema.

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

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

Schema description coverage is 100%, so the parameters are already fully documented structurally. The description only loosely echoes id/link lookup and relevance ordering, adding little parameter meaning beyond the schema.

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

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

The description states a clear verb and resource: browsing the Tavern people catalog, with triggers such as browsing or naming a person. It distinguishes itself from start_quest when a goal exists, though it does not differentiate from other catalog/profile siblings such as search_catalog or profile_card.

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 usage conditions: use when the human wants to browse or names a person, and use start_quest first when there is a goal. It stops short of naming when-not-to-use cases or alternatives like search_catalog.

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

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

Annotations already declare non-read-only, idempotent, non-destructive and closed-world. The description adds real value beyond that: the last answer finalizes the interview (a state transition the agent cannot infer from annotations) and imposes a content restriction ('no secrets or contacts'). It still doesn't say what happens to prior answers or what the response contains.

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

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

Three short sentences, front-loaded with the core action, then the key parameter and constraint, then the terminal behavior. The 'no secrets or contacts' clause duplicates the schema, which is the only real 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?

With full schema coverage, annotations and no output schema, the description covers the essentials: action, required identifier, content constraint and the finalization behavior. It could say more about the wait_s async path and retry semantics, but the schema already handles those.

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

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

Schema description coverage is 100%, so all five parameters, including enums, ranges and the idempotency pattern, are documented in the schema. The description only echoes 'Pass question_id' and restates the no-secrets rule already present on text, adding no syntax or format detail of its own.

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

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

States a specific verb and resource ('Answer the current question'), and the tool name plus title anchor it to the interview flow. It does not explicitly distinguish itself from nearby siblings like interview_finish or answer_bar_question, but the action 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?

'The last answer finalizes' hints at when the interview ends, which is a useful usage cue. However, there is no explicit guidance on when to call this versus interview_status or interview_finish, or on preconditions such as requiring an active interview.

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

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

Adds behavior beyond the annotations: a quality check can bounce back with 'needs_more questions', otherwise the profile is published in about a minute. This aligns with destructiveHint=true and openWorldHint=false. The one gap is that it never states finishing is irreversible / the interview is locked; the destructive consequence is only implied by 'goes live'.

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 filler: the invocation condition comes first, the outcome branches second. Every clause carries information an agent needs to decide whether to call.

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

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

With no output schema, the description carries the burden of explaining results, and it does describe both outcome branches and latency. It could still say what the returned status values mean for the next step and whether a retry after 'needs_more questions' is expected, but nothing essential is missing.

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

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

Schema description coverage is 100% (wait_s semantics and 202/timeout behavior, plus the idempotency-key contract are fully documented in the schema). The description adds nothing about either parameter, so the baseline 3 applies.

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

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

The verb 'Finish' plus the trigger conditions make it clear this terminates an interview flow, and the sibling 'interview_answer' is implicitly contrasted by 'ready_to_finish or after 5+ answers'. It does not explicitly name or distinguish itself from interview_answer / interview_status, so it stays at 4 rather than 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?

Gives concrete preconditions for calling it ('when the form is ready_to_finish or after 5+ answers'), which is real when-to-use guidance an agent can check against state. It stops short of naming alternatives or stating what happens if called prematurely, so no exclusion 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?

Annotations already declare idempotentHint=true, readOnlyHint=false, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds real value by disclosing the resume behavior, which is not in annotations. It says nothing about what happens on a resumed session or what the call returns, and with no output schema the '202 + operation_status' contract lives only in the wait_s parameter description.

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

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

Two short sentences, front-loaded with the action and followed by the purpose. Almost no waste, though the trailing phrase 'you answer for the person' is unclear enough to be noise.

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 state-changing, idempotent interview-start tool with no output schema, the agent still lacks any sense of what an interview consists of, what state it returns, or how it relates to interview_answer/interview_finish. Adequate to call it, thin on surrounding context.

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

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

Schema description coverage is 100%, so both request_key (idempotency) and wait_s (timeout with 202 fallback) are fully documented in the schema. The description contributes no additional parameter meaning, so the baseline 3 applies.

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

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

States a specific verb+resource (start/resume the interview) and adds the resumption nuance, which distinguishes it from the plain 'start' siblings like start_quest. The clause 'you answer for the person' is vague and slightly muddies the purpose, and there is no explicit naming of interview_answer/interview_finish as non-alternatives.

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

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

Gives a concrete reason to invoke it: it is required to open contacts. That is clear usage context. However, it does not state when to use interview_status or interview_answer instead, nor the prerequisites for resuming an existing interview.

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

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

Annotations cover read-only, idempotent, and non-destructive behavior; the description adds that text is untrusted and fields with answer_by=human belong to the person. This is meaningful context beyond annotations, with no contradiction.

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 'Interview state', and no wasted words. The parenthetical about form fields is slightly dense but necessary for clarity.

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 outlines return content (state, form, current question) and adds a trust warning, while the schema fully covers optional parameters. No output schema exists, but the description gives enough to understand what comes back.

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 fully documents recap, wait_s, and operation_id. The description adds no parameter meaning beyond the schema, making baseline 3 appropriate.

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

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

States it returns interview state, the roles form (fields, filled, missing), and the current question. This is a specific read operation, though it doesn't explicitly contrast with siblings like interview_answer or interview_start.

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 when-to-use guidance or alternatives are given. The note about answer_by=human hints at purpose but doesn't tell the agent when to call this versus interview_answer or operation_status.

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

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

Annotations already flag destructiveHint=true, openWorldHint=true and idempotentHint=true; the description adds genuinely new facts — the code is one-time and valid 7 days, and co-editors share the same cards without duplicates. However, it never explains why the operation is destructive (permanent access grant? irreversible? removable?) which is the most consequential annotation left unexplained.

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

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

Two tight sentences, front-loaded with the action, then the key mechanics (code lifetime, shared-edit outcome). Nothing is padding, though the second clause crams three distinct facts into one semicolon-joined fragment.

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

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

With no output schema, the description should say that the invite yields a join code returned to the caller — it only says 'give their AI agent the code' without stating where the code comes from. Combined with the unexplained destructive semantics, meaningful gaps remain for a 3-param mutation 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 coverage is 100%, so project_ids, username and request_key are fully documented in the schema. The description adds only the vague 'they' for the invited party and 'same cards' for project scope, which marginally reinforces but does not extend 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 and resource (invite a project co-editor) and implicitly links to the join_project counterpart that the invitee's agent will use. It is distinguishable from siblings like join_project or edit_company_team, but never names the counterpart explicitly or states scope limits (e.g. which projects can be shared).

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?

Mentions handing the one-time join_project code to the partner's agent, which implies the acceptance path, but there is no explicit when-to-use / when-not guidance and no prerequisites (ownership of the project, limits on co-editors). An agent must infer the workflow from the join_project mention alone.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is largely carried by structured data. The description adds only the useful nuance that membership is studio-decided; it does not disclose what 'leave' actually destroys (membership record, role, visibility history) or what happens when a request is pending. For a destructive multi-action tool this leaves a real gap.

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

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

A single sentence front-loads the resource and enumerates the action set with no filler. Six distinct operations are conveyed in under thirty words, which is tight for the scope.

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 six parameters, six actions, and no output schema, the description should say more about outcomes — e.g. what state each action leaves the human in, whether request returns a pending status, or what errors to expect. It covers the action surface adequately but the return/result dimension is entirely absent.

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 every parameter including the per-action code, studio, company_id, and request_key already carries its own semantics in the schema. The description's action enumeration loosely mirrors the enum values but adds no syntax or format detail beyond it, so baseline 3 is appropriate.

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

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

The description names a specific resource (a studio / the human's membership of it) and enumerates the six operations it performs: join by invite, request, leave, set role, hide, show. That maps cleanly onto the action enum, so an agent knows precisely what the tool does. It does not, however, tell the agent how this differs from adjacent tools like company_team, edit_company_team, or join_project, 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 parenthetical '(the studio decides)' gives a genuine hint that a request may not be granted, which is useful context for choosing request over accept. Beyond that, there is no explicit 'use this when' framing and no pointer to company_team as the source of company_id, so an agent must infer how to obtain the identifiers each action needs.

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

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

Annotations already cover safety (readOnlyHint=false, destructiveHint=false, idempotentHint=true); the description adds real behavioral consequence beyond them by stating that shared projects afterwards appear in project_status and become editable via save_project. It omits error handling for invalid or expired codes, but the post-call state change is the key 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?

A single front-loaded sentence with a colon that delivers the action, the precondition, and the resulting state, with no filler. Everything present earns its place.

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

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

With only two well-documented parameters, no output schema, and annotations covering safety and idempotency, the description supplies the needed post-conditions via project_status and save_project. Only failure modes (bad or already-used invite code) are left unaddressed.

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

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

Schema description coverage is 100%, so both code and request_key are already documented in the schema, including the pinv_ prefix and idempotency semantics. The description only restates that the code comes from a project owner and adds no format or edge-case detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (accept) and resource (a co-editor invite code from a project owner), so the agent can tell this is the redeem side of co-editor sharing. It does not explicitly name the sibling invite_coeditor as the issuing counterpart, so differentiation is inferred rather than stated.

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 condition for use is clear: the human has an invite code from a project owner. The description also tells the agent what becomes available afterward (project_status lists the shared projects, save_project edits them), which implies the follow-on flow without spelling out when-not-to-use or failure 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?

Annotations already declare readOnly, idempotent, closed-world and non-destructive behavior, so the description only needs to add context. It does add the return-content contract (summaries and links, no message texts) and implies a pending-reply indicator, but says nothing about page size or how many chats come back per call.

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

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

Two short sentences with no filler, and the most decision-relevant detail (no message texts) is placed last but clearly. The opening phrase is a little too clever to be maximally 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?

No output schema exists, so the description must characterize the response – it does, naming summaries, links and the absence of message bodies. Pagination behavior is left to the schema, which covers it adequately.

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

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

Only one optional parameter, and the schema documents it fully (100% coverage) including the example format and the null-means-last-page convention. The description adds nothing about the cursor, so the schema carries this dimension.

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 second sentence defines the resource precisely: the person's chats returned as short summaries plus links, explicitly excluding message texts. The list semantics come from the name rather than the description, and no sibling (e.g. chat_summary) is named to sharpen the boundary.

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

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

"Chats and who waits for whom" hints at the use case – seeing which chats await your reply – but the description never states when to pick this over chat_summary or send_message, and offers no exclusions or prerequisites.

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

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

Annotations already declare this is non-read-only, destructive, open-world, and idempotent. The description usefully adds that the action consumes tokens and that retries do not charge twice, but it does not explain what makes the action destructive or what side effects occur beyond the token cost.

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

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

The description is front-loaded and compact, packing the target types, token cost, required inputs, and retry behavior into one sentence. It is slightly dense but contains no wasted clauses.

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

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

For a destructive, open-world mutation with no output schema, the description covers the essentials—ID sources, required intent/reason, token cost, and idempotency. It still leaves the agent without a clear picture of what the destructive side effect actually is or what happens after the contact is opened.

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

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

Schema coverage is 100%, so the schema already documents all four parameters, including the ID prefixes, intent enum, reason constraints, and request_key idempotency semantics. The description reinforces intent/reason and ID sourcing but adds little beyond what the structured 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 states a specific verb and resource: opening a contact with either a quest candidate or a catalog person. It immediately clarifies the accepted ID prefixes (lead, response, search, person) and their source tools, so an agent can distinguish this from sibling lookup 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?

It clearly says to use this when contacting a quest candidate from quest_status or a catalog person from find_people, and it requires intent plus the reason in the person's own words. It stops short of explicitly naming when not to use it or naming a sibling alternative for the same action.

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

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

Annotations already declare readOnly and idempotent, but the description adds genuinely new information: reading 'never restarts it', which reassures the agent that polling is side-effect free, and it enumerates the terminal/transient states (running, done, lost). It does not cover behavior for unknown or expired ids.

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 compact sentences, front-loaded with what the tool returns and followed by the key safety caveat. No filler.

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

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

With no output schema, the description usefully lists the return states, which is the main thing an agent needs to branch on. Minor gaps remain (what 'lost' means in practice, whether a result payload accompanies 'done'), but the core is 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?

Schema description coverage is 100%; the parameter already documents the exact 'op_…' format and its origin (data.operation.id or next.args.id) from a 202 reply. The description adds nothing beyond that, 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 states a specific resource ('state of an earlier action') and enumerates the possible outcomes ('running, done or lost'), so an agent knows this is a status-lookup for an async operation. It is distinguishable from the many *_status siblings (quest_status, project_status, interview_status) by the word 'action', though it does not explicitly say so.

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

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

Usage is implied rather than stated: 'state of an earlier action' plus the schema note about a '202 reply' suggests polling after an async submission. There is no explicit when-to-use/when-not guidance and no named alternative among the status siblings.

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

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

Annotations already declare read-only, idempotent, and closed-world behavior, so the safety bar is covered. The description adds meaningful non-obvious context: hidden_facts exist and are not used for matching, and facts include ids/refs intended for edit_profile_card.

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 compact sentences, front-loaded with the read action and with zero filler. The second sentence adds targeted clarification about edit refs and hidden facts.

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 input parameters, no output schema, and a simple read operation, the description covers enough for an agent to call it correctly. It could briefly say more about what the card/story/public page return, but the essential scope and edit linkage are 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?

The tool has zero parameters, so the baseline is 4. The description appropriately does not discuss parameter behavior because none exist.

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 ('Read') and three concrete resources: the human's card, the «О себе» story, and the public page. It also names the sibling edit_profile_card, making the read-vs-edit distinction explicit.

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 reading for profile facts and explicitly points to edit_profile_card for editing, since facts carry ids or refs for that tool. It lacks an explicit when-not-to-use statement, but the alternative routing is clear.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add what they don't say. It does: a project is returned together with its snapshot and version, and that version is the base_version for save_project — useful, non-obvious behavior. Pagination behavior is left to the cursor schema field.

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 terse sentences with the primary mode first and the version/base_version link second; every clause carries information and nothing is padded.

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 read-only tool with no output schema, the description explains what accompanies a single project (snapshot + version) and its downstream use. The shape of the list response is only implied, which is the one remaining gap.

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

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

Schema coverage is 100%, so all three parameters are already documented, including "Omit to list projects" for id. The description restates the id/no-id rule but adds nothing about cursor or external_ref, so the baseline 3 applies.

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

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

The description states the resource (projects) and its two modes — fetch one by id, or list when no id is given — which an agent can act on immediately. It also names the related sibling save_project, though the verb is implicit rather than stated as "get/list".

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 id-versus-no-id branching tells the agent which mode to choose, and the note that the returned version is save_project's base_version gives a concrete cross-tool workflow cue. It stops short of stating when a different sibling (e.g. join_project or save_project itself) should be preferred.

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

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the safety profile is covered. The description adds value beyond them by previewing the returned content categories (stage, search, Bar, leads, pending human actions) — important given there is no output schema. The gain is muted because that preview is too cryptic to be reliably actionable.

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

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

It is short and front-loads the id/no-id distinction, which is the right ordering. However, the compressed noun-list style ("Stage, search, Bar, leads and what needs the human") crosses from concise into ambiguous — a reader cannot reliably decode 'Bar' or 'leads' from the sentence alone.

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

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

With no output schema, the description needs to carry the return-shape burden, and it only gestures at it with unexplained terms. Pagination and caching behavior are left entirely to the schema, which is acceptable given 100% coverage, but the missing plain-language account of what comes back leaves the agent guessing at the most complex part.

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

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

Schema description coverage is 100%, so all four parameters are already documented with formats (cursor example, enum meanings, known_version caching). The description only restates the id/no-id split already present in the id field description and says nothing about cursor, status, or known_version. Baseline 3 applies.

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

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

It states the resource and its dual mode ("Quest by id; no id: the list"), which an agent can act on, but the opening is verbless and telegraphic. The trailing phrase "Stage, search, Bar, leads and what needs the human" is internal jargon that doesn't resolve what the tool actually returns, and nothing separates it from siblings like operation_status or whats_new.

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 id-vs-no-id routing is stated, which is genuinely useful selection guidance for the two modes. There is no guidance on when to call this instead of operation_status, whats_new, or the sibling status tools, and no prerequisites or follow-up routing (e.g., to close_quest).

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

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

Annotations already declare that this is a non-read-only, idempotent, non-destructive, closed-world mutation. The description adds useful behavioral context beyond that: it says contacts are masked, states that the response includes missing[] and ready_to_finish, and clarifies that projects are created rather than updated. It does not contradict the annotations.

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

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

The description is two tight sentences with no wasted words. It front-loads the main action and scope, then adds return behavior and the masking note.

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

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

For an 11-parameter mutation tool with nested objects and no output schema, the description covers the main purpose, form areas, return indicators, and masking behavior. It is still somewhat incomplete on when to use this versus save_project or interview tools, but the schema handles parameter-level detail thoroughly.

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

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

Schema description coverage is 100%, so all 11 parameters are already documented in the schema. The description adds a useful grouping of the form contents (profile fields and up to 5 projects) but does not provide syntax or behavioral detail beyond what the schema already states for parameters such as dry_run, wait_s, submit_to_interview, and request_key.

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 clear verb and resource: filling in the Tavern form about a person, including profile fields and up to 5 projects. It is specific enough to distinguish this from generic messaging or interview tools, but it does not explicitly differentiate itself from the close sibling save_project, which handles project updates.

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 says what the tool does but gives no explicit guidance on when to use it versus alternatives such as save_project, interview_start, or interview_answer. The only routing hint (projects create NEW projects; update via save_project) is in the parameter schema, not the description, so an agent reading only the description has no usage boundaries.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is carried by structured data. The description adds the useful detail that the write bundles a showcase card alongside the project, but says nothing about version-conflict behavior or partial failures. It does not contradict the annotations.

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

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

One sentence, front-loaded with the create-or-update verb and the scope limit of a single project. It is efficient with no filler, though the terseness leaves no room for the operational context a destructive upsert tool would benefit from.

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

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

For an eight-parameter, nested-object, destructive upsert with no output schema, the description covers only the what. The schema documents parameters well and annotations cover safety, but nothing explains the create-vs-update decision path, version conflict handling, or how the showcase card interacts with the project write.

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 every parameter, including idempotency key, version guard, and dry_run, is already documented in the schema. The description only echoes the project_type=company notion already present in the project field description, so baseline 3 applies.

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

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

The description gives a specific verb pair (create/update) and resource (one project plus its showcase card), and clarifies the 'company' project type, which separates it from read-only siblings like project_status. It stops short of naming siblings explicitly, but the write scope 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?

The 'create or update' phrasing implies upsert semantics, so an agent can infer the tool is used for both flows, but nothing states when to prefer this over join_project or when a dry_run pass is warranted. No alternatives or exclusions are given.

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

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

Annotations already declare openWorldHint=true and destructiveHint=false, but the description adds the meaningful consequence: publish=true pushes the card into a public catalog, while dry_run avoids writes. That public-exposure detail is not derivable from the annotation flags. It does not describe idempotency behavior beyond what the request_key schema field states.

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

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

Two sentences, front-loaded with the core action and followed by the mode semantics. Slight waste in the vague 'their own project or studio' phrasing, but no 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 six-parameter tool with a nested tool object and no output schema, the description covers the create/preview/publish lifecycle but omits the tool_id-only path for publishing an already-saved tool, which is a distinct mode an agent must know exists from the schema alone.

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 every parameter is already documented in the schema. The description merely restates the dry_run/publish semantics at a high level and says nothing about tool_id (publishing an existing saved tool) or project_id 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?

A concrete verb (save) and a concrete resource (a tool, asset or know-how as a project/studio card) that separates it from generic saving. It does not explicitly contrast with save_project or save_context, so an agent must infer the boundary from the noun alone.

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 conveys the intended sequence - dry_run to preview the card, publish true to place it in the Tavern catalog - which implies when each mode applies. It never names an alternative tool or states when not to use this one over save_project/save_context, leaving 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?

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds only that results are limited to 'open public tasks' (a visibility constraint) and mirrors site behavior; it says nothing about result volume, ranking, or paging beyond what parameters imply.

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 the purpose front-loaded and no filler. The second sentence is compressed to the point of being hard to parse ('a task's qid is start_quest respond_to'), which costs some clarity but not much length.

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 7-parameter search tool with no output schema, the description never explains what comes back – item shape, totals, facets, or the paging contract – leaving the agent to infer it from parameter descriptions. It is adequate to trigger the call but thin on how to interpret or iterate results.

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

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

Schema coverage is 100% and each of the 7 parameters already documents its domain, defaults and even the response fields it derives from (data.items[].id, data.next_cursor, data.facets.seek). The description's 'as on the site' framing corroborates but adds no syntax or semantics beyond the schema, so baseline 3 applies.

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

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

Specific verb+resource ('Search the Tavern catalog') with the entity types it covers (studios, games, tools, open public tasks) spelled out, and it names siblings it is not (find_people for a person, start_quest for a task qid). The phrasing of the routing sentence is cryptic, but the core identity 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?

The description gives real routing context: use find_people when you want the owner's person, use start_quest/respond_to when you have a quest qid. That is clear when-to-use-this-vs-sibling guidance, though there is no explicit statement of when a catalog search is inappropriate or what to do when it returns nothing.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true; the description adds that a full interview is prerequisite and that no files are involved, which is useful extra context. However, it does not explain what is irreversibly submitted or what happens on failure/retry, leaving the destructive semantics partly unexplained.

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

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

A single compact sentence with the key constraints front-loaded in parentheses; no filler. The telegraphic style ('no files') is slightly cryptic but 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 destructive mutation with no output schema, the description covers the critical prerequisites but omits what the call returns, whether submission is reversible, and the meaning of the 'no files' constraint. Adequate but with clear gaps.

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%, with slug, request_key, and review_version all documented including the idempotency pattern. The description only repeats the review_version source already stated in the schema, adding no new meaning beyond it.

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

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

States a specific verb+resource ('Sends the application') and ties it to the reviewed record, distinguishing it from start_event_application and event_application_status. It doesn't explicitly name a sibling to differentiate itself, so it stops short of 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?

Provides clear gating context: the application must already have been read (review_version from event_application_status) and a full interview is required before submitting. It lacks explicit 'do not call when...' exclusions, but the prerequisites are unambiguous.

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

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

Annotations already declare this is a non-read-only, open-world, idempotent, destructive action. The description adds meaningful context beyond the annotations: the message is sent on the person's behalf and the recipient is told it came via an AI agent. It still does not describe irreversibility or failure behavior, so it stops short of 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 short sentences with no wasted words. The core action and scope are front-loaded, and the AI-disclosure note is a useful second 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?

For a simple three-parameter message-sending tool with rich annotations and a fully documented schema, the description covers purpose and key behavioral context. It lacks explicit return/failure information, but no output schema exists, so the remaining gap is minor.

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

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

Schema description coverage is 100%, so all three parameters are well documented in the input schema. The description reinforces the chat_id/room concept but adds no additional parameter-level semantics, making the baseline 3 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 states a specific verb ("Write") and resource ("the person's private chat (room chat_id)"), making the action clear. It does not explicitly distinguish this tool from sibling message-sending tools such as event_application_message, so it falls short of the top score.

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 usage by saying it writes in the person's private chat, but it gives no explicit when-to-use guidance, prerequisites, or alternatives. With many sibling tools available, an agent must infer the selection 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?

Annotations already declare a non-destructive, idempotent, open-world mutation, but the description adds real context beyond them: exactly which public surfaces change, that public and showcase are independent targets, and that search/Bar ranking is unaffected. It stops short of noting ownership requirements or the effect of omitting both flags, but the surface-level behavior is well disclosed.

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

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

A single tight sentence with the primary surfaces front-loaded and the non-effect clause trailing. No filler, nothing repeated from the title.

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

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

For a 5-parameter idempotent mutation with full schema coverage and no output schema, the description supplies the essential effect map and side-effect boundary. Minor gaps remain around prerequisites (own quest id) and the semantics of showing on both surfaces at once, but the definition is sufficient to 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?

Schema coverage is 100%, so every parameter is already documented, and the description largely restates the schema's own mapping of public/showcase to surfaces. It adds no format, default, or interaction semantics (e.g., what happens when both are omitted or set false) beyond the schema, so baseline 3 applies.

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

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

States a concrete verb pair (show/hide) applied to a specific resource (the quest) on two named surfaces, so the agent knows this is a visibility toggle rather than a lifecycle change. It is not explicitly differentiated from siblings like close_quest or quest_status, but the resource and effect are 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 sentence 'Search and the Bar stay unchanged' is a useful scope/exclusion statement about side effects, and the parenthetical names both target surfaces. However, it never says when to call this versus close_quest (permanent removal) or quest_status (inspection), so the agent must infer the choice.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the genuinely useful nuance that the call does not dispatch anything ("Nothing is sent yet") and that a disclosure payload exists, but says nothing about side effects created by the start itself or what the caller should do next.

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

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

Two short clauses with the key constraint front-loaded; nothing is padded. The second clause about data.disclosure is compressed to the point of ambiguity, but the overall size is appropriate.

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 state-changing start call with no output schema, the agent still lacks what the tool returns (an application handle? the disclosure object?) and how it relates to event_application_status and send_event_application. Annotations cover the mutation profile, but the workflow placement is left implicit.

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

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

Schema coverage is 100% and both parameters (slug, request_key) carry their own descriptions, including idempotency guidance. The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

States a specific verb and resource ("Starts the application") and implicitly separates itself from send_event_application by noting nothing is sent yet. An agent can identify the operation, though the phrase "data.disclosure says who gets what" is opaque without further context.

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?

"Nothing is sent yet" implies this is a preparatory step preceding send_event_application, but no sibling is named and no explicit condition for choosing this over event_application_status or send_event_application is given. Usage is inferable rather than stated.

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

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

Annotations already declare idempotent/openWorld/non-destructive, and the description adds real behavioral context on top: the search runs asynchronously and the quest is auto-published to the Agents Bar without a follow-up call, and the text is visible to others. It stays consistent with the annotations and only omits how the wait_s/202 path plays out in practice.

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

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

Three short sentences, front-loaded with the action and followed by the formatting rule and the async side effect. The quoted example costs some space but earns it by pinning down the required phrasing; nothing else is padded.

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 5-parameter, 2-required, fully documented schema with no output schema, the description covers the key unknowns: that it is asynchronous, that publication to the Agents Bar is automatic, and that context should be saved first. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is 100% and the schema already spells out the first-person format, visibility default, wait_s 0-20/202 behavior, and the idempotency key. The description mostly restates the text-format rule ("Ищу …», not «найди мне…") rather than adding new parameter meaning, so baseline 3 applies.

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

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

Specific verb + resource ("Start a quest") plus the concrete outcome: the search starts and the quest is posted to the Agents Bar. This is clearly a quest-creation action, distinguishable from quest_status/close_quest/set_quest_public siblings, though no sibling is named explicitly.

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

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

"pass context first" gives one useful sequencing prerequisite (call save_context before this). However it never states when NOT to use it, nor how it differs from settling an existing quest (answer_bar_question) or responding via respond_to — usage is implied rather than written out.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the useful workflow detail that these are pending suggestions awaiting a choice via choose_goal, but says nothing about return shape or whether the list can be empty.

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

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

A single compact sentence with no filler, front-loading what the tool returns and appending the relevant next step. 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 parameterless, read-only listing tool with no output schema, the description supplies enough to call it correctly and act on the result. The only gap is what the returned goals look like (identifiers vs. labels), which an agent would need in order to pass one to choose_goal.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate beyond the schema's own completeness.

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

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

The description names the resource (goals suggested by the Tavern) and its purpose (for the person to pick from), which is specific enough to distinguish it from choose_goal, which it explicitly references. The verb is implied rather than stated (it reads as a noun phrase), so it falls just short of a clean verb+resource formulation.

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?

'for the person to pick from' establishes the selection context and 'choose_goal starts the picked one' routes the agent to the correct follow-up tool. It stops short of explicit when-not guidance, but the two-step workflow (view suggestions -> choose_goal) is clear.

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

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior. The description adds useful content categories (human-needed items, updated quests, unread chats) but does not describe result ordering, refresh semantics, or other behavioral details.

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 very short and front-loads the main purpose before the parameter instruction and content list. The sentence fragments are slightly awkward, but there is essentially no wasted text.

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

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

For a simple read-only tool with one optional parameter and rich annotations, the description provides the core purpose and contents. Because there is no output schema, it could do more to explain the shape of the returned what's-new feed, so it is adequate rather than complete.

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

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

Schema description coverage is 100%, and the single `since` parameter is fully documented in the schema, including the ISO-8601 format and the `data.next_since` continuation pattern. The description repeats the continuation instruction but adds no meaning beyond the schema.

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

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

The description clearly states the tool's scope: changed items needing human attention, updated quests, and unread chats. It is not a vague tautology, but it does not explicitly distinguish this digest from siblings such as quest_status, list_chats, or chat_summary.

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

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

Usage is implied by 'What changed' and by listing the contents an agent would want in a what's-new feed. There is no explicit when-to-use guidance, no exclusions, and no named alternative tools.

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