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

With no annotations provided, the description carries the full behavioral burden. It clearly indicates a read-like operation and discloses important failure behavior: it raises SESSION_INVALID rather than returning an empty account for a dead session. It does not explicitly state that it has no side effects, but 'Reports' reasonably implies a non-mutating operation.

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

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

The description is two sentences with no filler. It front-loads the main purpose and then adds a valuable failure-mode detail without redundancy.

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

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

This is a simple zero-parameter tool with no output schema. The description sufficiently conveys what the agent will receive (username and token balance) and the key error condition. Nothing critical is missing for correct invocation.

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

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

The tool has zero parameters, so parameter semantics are not a concern. The baseline of 4 applies because no parameters means the description does not need to compensate for missing parameter documentation.

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

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

The description uses a clear verb ('Reports') and identifies the specific resource: the signed-in username and token balance. It is easily distinguishable from sibling tools like scibot_token_history or scibot_settings, though it does not explicitly name or contrast them.

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

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

There is no guidance on when to choose this tool over similar siblings such as scibot_token_history or scibot_settings. The description states what the tool does but not the conditions or scenarios where it is the right 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?

With no annotations provided, the description carries the behavioral burden. It discloses asynchronous submission, immediate ticket issuance, slow queue behavior, and the need to poll for the answer. It does not mention failure modes or queue limits, but it covers the most important runtime behavior.

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

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

Two economical sentences: the first states the action and immediate result, the second adds the essential async caveat and polling instruction. No filler or redundancy.

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

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

For an async submission tool with no output schema, the description supplies the key missing pieces: immediate ticket return and the ticketId-based polling flow. With full parameter schema coverage, the invocation contract is complete, though error handling and timing expectations are not detailed.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters and their defaults. The description adds only the queue/ticket context, not additional parameter-level meaning, which matches the baseline expectation of 3.

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

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

The description states a specific action ('Puts a question into the sci-bot.ru queue') and a concrete result ('returns a ticket immediately'). It also names the natural sibling, scibot_check_question, which makes the tool's role in the async workflow clear.

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

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

The description gives explicit guidance to poll scibot_check_question with the returned ticketId, and explains why (queue is slow, single generation slot). It does not enumerate other alternatives or exclusion cases, but the core usage flow is clearly communicated.

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

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

With no annotations, the description carries the behavioral burden and does well: it reveals that the operation is a service request, that it waits for acknowledgement, that it returns the terminal state, and that text is preserved. It does not detail failure/error behavior or what happens if the ticket is already terminal, but the core behavior is transparent.

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

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

Two sentences front-load the core action and result, with the important preservation guarantee placed second. Every sentence earns its place and there is no redundant restatement of the tool name.

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

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

For a one-parameter tool with no output schema and no annotations, the description covers the action, the applicable state ('active'), the synchronous acknowledgement behavior, the return value, and the preservation guarantee. It could add a note about invalid or already-terminal tickets, but the essential context is present.

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

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

Schema description coverage is 100%, and the schema already documents ticketId as returned by scibot_ask_question. The description adds no additional parameter semantics, so the schema-based baseline of 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 gives a specific action ('stop an active ticket'), the object ('ticket'), and the outcome ('returns its terminal state'). It also distinguishes itself from deletion-related siblings by noting that accumulated text is preserved.

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

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

The phrase 'active ticket' implies the tool is meant for in-progress questions, and the preservation note hints that it differs from delete tools. However, it never explicitly states when to use this versus scibot_delete_question or other siblings, nor does it state when not to use it.

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

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

With no annotations provided, the description clearly discloses that the tool reads process state only and never contacts the service, which is valuable safety-relevant behavior. It does not detail edge cases like missing tickets or partially complete processes, but the core non-mutating behavior is transparent.

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

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

The description is two compact sentences that front-load the tool's purpose and then add a key safety qualifier. Every clause adds information, and there is no redundant or filler content.

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

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

For a simple one-parameter read-only check tool, the description covers what it returns (state, finished answer, references) and its side-effect profile. Since there is no output schema, a bit more detail about the exact state values or error behavior would be helpful, but the description is still reasonably complete for the tool's simplicity.

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 parameter ticketId is already fully described in the schema as the id returned by scibot_ask_question. The description repeats that relationship without adding extra format, validation, or usage details, so it adds 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?

The description clearly identifies the tool as reporting the current state of a ticket, including the finished answer and references. It does not explicitly contrast itself with sibling tools like scibot_read_answer or scibot_queue_status, but the verb 'reports' plus the resource 'ticket issued by scibot_ask_question' is specific enough to understand what it does.

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 use for checking ticket progress or retrieving a completed answer without re-triggering work. However, it does not explicitly say when to prefer this tool over scibot_queue_status or scibot_read_answer, leaving some selection ambiguity among closely related 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?

With no annotations, the description carries the disclosure burden. It does indicate a read operation ('Returns'), a full-transcript behavior, and account scoping ('signed-in account'), which is useful. However, it does not disclose behavior on invalid ids, error responses, or whether authentication is explicitly required beyond the 'signed-in' phrase.

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 that starts with the verb, names the resource, and specifies scope. Every word earned its place; there is no fluff or redundancy.

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

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

For a one-parameter read operation with no output schema and no annotations, the description is mostly adequate: it says what is returned and to whom it is scoped. But it omits edge-case behavior (e.g., nonexistent conversation id) and does not reference scibot_conversations as the source of valid ids, a gap that the schema partially fills but the description does not.

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

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

The schema provides 100% coverage for the single parameter with the description 'Conversation id from scibot_conversations', so the baseline is 3. The tool description does not add syntax or format details beyond what the schema already states.

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

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

The description states a specific action ('Returns'), a clear resource ('the full transcript of one conversation'), and a scope ('of the signed-in account'). It distinguishes itself from siblings like scibot_conversations (which likely lists conversations) by emphasizing a single conversation's full transcript.

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: use this tool when you need the full transcript of a specific conversation. However, there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as scibot_conversations for listing conversations, which would help disambiguate in a large sibling set.

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

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

With no annotations, the description carries the full burden, and it does disclose that this is a read-only listing operation scoped to the signed-in account. However, it does not mention pagination, ordering, or the shape of the returned conversation objects, which would be useful behavioral 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 that front-loads the action and immediately states the resource and scope. There is no filler or redundant restatement of the tool name.

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

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

The description is adequate for a simple, parameterless list operation, but it lacks any mention of the response format or pagination behavior, and no output schema exists to fill that gap. It is minimally viable but not richly 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 tool has zero parameters and an empty input schema, so parameter-level description is not needed. The baseline of 4 applies because there is no semantic burden to compensate for.

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

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

The description clearly states a specific verb ('Lists') and resource ('multi-turn conversations of the signed-in account'), which differentiates it from the singular sibling scibot_conversation. The plural form and account scope make the tool's purpose 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?

No guidance is given about when to use this tool versus alternatives such as scibot_conversation or scibot_my_questions. The description implies its use case but provides no explicit conditions, exclusions, or comparisons to 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?

With no annotations provided, the description carries the behavioral disclosure burden. It clearly states the operation is permanent ('Permanently deletes') and scoped to the signed-in account, which are important destructive and auth-related traits. It doesn't mention cascading effects on related data or behavior for invalid ids, but the core side effect is disclosed.

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

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

A single, well-formed sentence delivers the action, scope, and permanence without filler. The most critical information is 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?

For a simple one-parameter delete tool with no output schema, the description covers the essential details: what is deleted, whose data is affected, and that it is permanent. It falls slightly short on describing related-data consequences and alternative routing, but is generally complete enough for correct invocation.

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

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

The input schema already documents the single parameter thoroughly, including that id comes from scibot_conversations. The description adds no extra parameter-level meaning, but because schema description coverage is 100%, the baseline score of 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 uses a specific verb ('deletes'), names the resource ('conversation'), and adds useful scoping ('one', 'signed-in account'). It is clearly distinguishable from siblings like scibot_delete_question, though it does not explicitly call out 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?

There is no guidance on when to use this tool versus alternatives such as scibot_delete_question or scibot_conversations. The use case is only implicit from the name and description, with no explicit conditions, 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Permanently deletes' is a genuinely valuable disclosure of irreversibility, the most important trait of a destructive action. However, it does not reveal cascading effects (whether an existing answer or token-history record is also removed) or any state restrictions on which questions are deletable (queued, in-progress, or answered).

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

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

A single sentence with zero waste: 'Permanently' carries irreversibility, 'deletes' carries the action, 'one question' carries the object scope, and 'of the signed-in account' carries ownership scope. It is front-loaded with the core action and free of filler or repetition.

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

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

Adequate for a simple two-parameter delete operation: action, scope, and irreversibility are stated, and the schema fully documents where parameter values come from. Gaps remain on whether id and handle must reference the same question, and on what happens to an associated answer or token-history records after deletion — questions an agent could reasonably face given siblings like scibot_read_answer and scibot_token_history.

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 of 3 applies. The schema itself does the heavy lifting: both id and handle specify that values come from scibot_my_questions or scibot_check_question. The tool description adds no parameter-level meaning beyond the schema, but none is needed given the coverage.

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

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

The description uses a specific verb ('deletes'), names the resource ('one question'), and adds meaningful qualifiers: 'Permanently' signals irreversibility and 'of the signed-in account' restricts scope. It implicitly differentiates from sibling scibot_cancel_question through the 'permanently' adverb, but never names that alternative or states the cancel-vs-delete distinction explicitly, so it falls 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?

No guidance is given for when to choose this tool over scibot_cancel_question (the likely alternative for non-permanent removal) or scibot_delete_conversation (which targets a different resource). The account-scope phrase provides context but no selection criteria, exclusions, or prerequisites, leaving the agent to infer the decision entirely from sibling names.

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

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

The description states the result scope (signed-in account) and organization (generating/answered), which is useful. However, with no annotations, it does not explicitly confirm read-only behavior, error conditions (e.g., not signed in), or whether the list is paginated. The verb 'lists' implies a safe read, but more disclosure would help.

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 that conveys the essential purpose and output structure with no wasted words.

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

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

For a zero-parameter listing tool with no output schema, the description covers the core behavior and output split. It could also state that the response contains the user's questions only and define 'generating' vs 'answered', but this is sufficient for an agent to invoke it correctly.

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

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

The input schema has zero parameters, so the baseline is 4. The description correctly adds no parameter-specific detail since 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?

The description uses a specific verb ('Lists') with a clear resource ('questions of the signed-in account') and adds a distinguishing output detail ('split into generating and answered'). This differentiates it from sibling tools that ask, check, cancel, read, or delete questions.

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

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

No guidance is provided about when to use this tool instead of alternatives. The usage can be inferred from the name and scoping, but there is no explicit mention of prerequisites, such as requiring authentication, or exclusions like 'use scibot_check_question for a single question's 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?

With no annotations provided, the description carries the burden of explaining behavior. It clearly states the read-only nature ('reports') and enumerates the specific information returned: waiting questions, generation slot count, and whether the service accepts work. No side effects are hinted at, and none are expected for a status tool.

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

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

Two concise sentences with no wasted words. The concrete output metrics are front-loaded, followed directly by the intended use case.

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

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

For a zero-parameter status tool, the description fully covers what the tool returns and why an agent would call it. There is no output schema, but the three reported values are explicitly named, so an agent can interpret the response correctly.

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

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

The schema has zero parameters, so there is no parameter information for the description to supplement. Per the baseline rule, a score of 4 is appropriate because no parameter ambiguity exists.

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 what the tool does: reports queue length, generation slots, and service acceptance status. It is distinct from sibling tools like scibot_ask_question or scibot_read_answer, so an agent can immediately identify its purpose.

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 explicitly advises using the tool to estimate wait time before asking, which is clear contextual guidance. It does not mention exclusions or alternatives, but for a unique status-checking tool among siblings, this is sufficient.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the operation is a fetch, requires no authentication, returns a persistent artifact rather than a transient ticket, and includes the bibliography. It does not cover failure modes or explicitly state read-only semantics, but 'Fetches' makes the primary behavior clear.

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

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

Two concise sentences with the core operation front-loaded and the additional context about auth and durability earning its place. There is no filler, redundancy, or unnecessary detail.

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

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

For a one-parameter read tool with no output schema, the description adequately identifies the input, the returned artifact (finished answer plus bibliography), and the access/persistence caveats. A brief note on response shape or error behavior would make it fully complete, but it is sufficient for an agent 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?

The input schema already documents the single parameter with a concrete example, and schema description coverage is 100%. The description's 'by handle' merely restates the schema and adds no new semantic detail, so the high-coverage baseline of 3 is appropriate.

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

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

States a specific action ('Fetches'), a precise resource ('finished answer and its bibliography'), and a key selector ('by handle'). The 'unlike a ticket' clause further distinguishes this from transient ticket-based flows, making it clear this is the persistent-answer reader.

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

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

The phrase 'finished answer' communicates when the tool applies, and 'Works without an account and survives a restart... unlike a ticket' gives clear context for preferring this over ticket-based reads. It does not explicitly name an alternative tool such as scibot_check_question, so it stops just short of full routing 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the core state transition (private to public with a URL, or public to private), but it does not mention side effects on an existing URL, error conditions, idempotency, or permission requirements. This is adequate but leaves notable gaps for a mutation tool.

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

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

One sentence, zero filler, and front-loaded with the action and outcome. It communicates the two-state behavior compactly and every word 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?

The schema covers parameter formatting and the description covers the core operation, but with no annotations and no output schema, prerequisites, edge cases, and expected results are left unspecified. The tool is simple enough that this is still minimally viable, but it is not fully complete.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters with their meanings and sources. The description adds only the notion of a public URL and ownership, not parameter-specific formats or constraints, which matches the baseline for fully covered schemas.

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

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

The description uses a specific verb ('Publishes', 'takes it back') and a concrete resource ('an own question' with a public URL or private state). It clearly distinguishes this tool from siblings like scibot_ask_question, scibot_cancel_question, and scibot_delete_question, since none of those handle visibility toggling.

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 makes clear that the tool applies to an existing own question and toggles its visibility between public and private. This gives clear context for when to use it, though it does not explicitly name alternatives or state when not to use it, stopping short of a 5.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the dual-mode nature, the mutating effect ('applies the given keys'), and the return contract ('returns the settings afterwards'). However, it omits failure semantics — the SETTINGS_KEY_UNKNOWN behavior lives only in the schema — along with persistence and partial-application behavior, which are meaningful gaps for a mutating tool with zero annotation coverage.

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 entire description is one dense sentence that front-loads the read mode, then the write mode, then the return value — no filler and nothing redundant with 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 tool with one optional nested parameter and no output schema, the description covers both call modes and the return contract, while the schema documents the patch keys, value constraints, and the SETTINGS_KEY_UNKNOWN error. The remaining gaps — persistence across sessions and error cases beyond unrecognized keys — are minor for a simple settings tool.

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

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

Schema description coverage is 100%: the patch object, citeFormat, minReferences, and answerLanguage all carry descriptions enumerating valid values, ranges, and the unrecognized-key error. The description adds only the read-versus-write framing of patch, which aligns with but does not exceed the schema's own 'omit to read them' note. The baseline of 3 applies because the schema does the heavy lifting.

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 concrete read behavior ('without a patch it reads the account settings') and a concrete write behavior ('with a patch it applies the given keys'), tied explicitly to the presence or absence of the patch parameter. The resource — account settings — is distinct from every sibling, which all deal with questions, conversations, or tokens. An agent can act on this immediately without guessing.

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

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

The description gives clear conditional guidance: omit patch to read, include patch to change, and expect the updated settings as the result. It establishes natural when-to-use logic for both modes, though no alternative is named and no explicit exclusion is stated. Since none of the siblings is a plausible settings alternative, this omission is minor.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It usefully notes that payment details are not exposed and implies a read-only report operation, but it does not describe ordering, time range, or whether the balance is current vs. historical.

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, focused sentences with no filler. The primary behavior is front-loaded, and the second sentence adds an important boundary about payment details.

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 is simple: one optional parameter, clear purpose, and no output schema. The description plus the schema's parameter documentation are enough for an agent to call it correctly, though a bit more detail about the returned entries would round it out.

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% for the single 'limit' parameter, so the schema already documents meaning and default. The description adds no parameter-level detail beyond that, which matches the baseline for full schema coverage.

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

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

The description uses a specific verb ('Reports') and names a clear resource ('token balance and recent balance movements'). It distinguishes this tool from the sibling tools, which are mostly about questions, conversations, and account functions.

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 no guidance on when to use this tool versus alternatives like scibot_account or scibot_settings. It does not state exclusions or conditions; an agent must infer usage solely from the tool name and brief description.

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