Immersive Commons

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

The description goes well beyond the annotations by disclosing that the first call without X-PAYMENT returns a 402 listing tiers in accepts[], that unknown tier labels return error_kind:'validation', and that MCP cannot run the 402 handshake itself. This prevents an agent from incorrectly assuming a donation was executed. No contradiction with the annotations is present.

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

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

The description is long but information-dense; every clause contributes protocol-critical detail, including the manual POST steps that are necessary because the tool cannot complete the handshake. A more structured layout separating the tool's return behavior from the manual donation instructions would improve scannability, but there is no real fluff.

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 fully enumerates the return contents, the 402 flow, error behavior, optional donor body fields, and the donor wall location. It also explains how to complete the donation and what values to sign, so an agent has enough context to invoke the tool and act on the result.

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 only defines a bare optional 'tier' string with 0% description coverage, so the description must carry the full burden. It does so thoroughly: tier is case-insensitive, narrows tiers[] to one tier, adds selected_tier with the exact atomic USDC amount, and unknown labels return validation errors naming valid labels. An agent can validate and construct the argument correctly without any additional 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 states that the tool returns donation tiers, the payTo wallet, asset + network, and a donate URL, so an agent knows the expected output. It is slightly less crisp because the title says 'Donate' while the body clarifies that MCP cannot execute the x402 handshake itself, leaving the tool's exact role somewhat implicit. It is still clearly distinguished from the sibling read/list tools by its donation-specific scope.

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 says no auth is required and gives a manual POST procedure for completing the donation, so an agent understands that the actual payment must happen out-of-band. It does not explicitly compare this tool to siblings such as ic_donations_total, but the context is clear enough to prevent misuse.

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?

Description adds return fields and public nature beyond annotations. No contradictions.

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, efficient, front-loaded with key 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?

Covers all necessary information for a simple read-only endpoint with one optional parameter.

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?

Fully documents limit parameter with range and default, compensating for 0% 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?

Clearly states it returns running total, donor count, and recent donations. Distinct from sibling 'ic_donate' which is for making donations.

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?

Explicitly states no auth required and that it's the public donor wall data. Could improve by contrasting with ic_donate.

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 state readOnlyHint=true. The description adds much more: no auth required, identical not_found responses for unknown vs restricted forms, live accepting_submissions state, and the distinction between can_submit and approval_requires_tier. These are important behavioral disclosures not captured by 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 long but front-loaded with the primary purpose and then uniquely critical notices. It uses formatting like bold and intra-description labels to structure the overloaded usage pitfalls. It is longer than necessary in places, but each section contributes to proper agent behavior.

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 provided, the description supplies the return shape and semantics, including the form contents, can_submit, accepting_submissions, and optional reason fields. It also covers error behavior, runtime state caveat, and usage instructions, making the tool self-contained 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 schema already provides a description for form_id ('From ic_forms_list. Do not invent one.'), so schema coverage is 100%. The description's mention of 'Form: { form_id }' adds no meaningful semantic beyond the schema, so the baseline of 3 stands.

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 title and description state a clear, specific action: reading the full definition of one form, including questions, question types, requiredness, choice options, and per-question 'why' purpose. It is explicitly contrastive with the sibling ic_forms_submit as the read-before-write counterpart, making its purpose distinct.

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 says 'call it before ic_forms_submit' and gives concrete instructions: relay each 'why' to the human, read 'facts' before committing, report both audience and approval_requires_tier, and avoid relying on can_submit alone. This goes beyond implicit context and gives direct when-to-use guidance.

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

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

Even with readOnlyHint: true in annotations, the description significantly enriches transparency: it discloses auth behavior (no auth needed, token doesn't narrow), visibility filtering (listed vs omitted forms), and explicitly states listings never contain answers. It explains the rationale for hiding omission, which goes well beyond the annotation contract.

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 longer than average but front-loads the core purpose. Each sentence adds information: the purpose, the START HERE directive, the visibility exclusions, the no-answer guarantee, and the return shape. The only slightly verbose part is the 'program nobody outside can discover' rationale, which is still relevant enough to keep.

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

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

For a tool with no parameters and no output schema, the description fully specifies expected return fields (ok, count, forms, and each form's fields) and behavior nuance (what is omitted, what can_submit means). An agent can successfully invoke this tool with no outside knowledge and interpret the result 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 and 100% coverage, so the baseline is 4. The description adds the 'Args: none' line, which is redundant but helpful confirmation. No parameter semantics are lacking.

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

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

The description states a specific verb ('list'), resource ('every form Immersive Commons is currently taking answers to'), and the key scope: filtered by who you are. It also differentiates from siblings by explicitly saying 'START HERE — do not guess a form id,' which signals that this is the entry point for form-related tools and disambiguates from ic_forms_get/submit.

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

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

The description provides clear when-to-use context: 'START HERE — do not guess a form id' tells an agent to call this before any form-specific tool. It also explains when a token matters and when it doesn't. However, it doesn't explicitly name sibling tools or provide exclusions (e.g., 'for a single form use ic_forms_get'), so it falls short of a perfect 5.

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

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

With readOnlyHint already set true, the description adds valuable behavioral context beyond annotations: no token required, no auth required, the two access paths, the id-alone failure mode, the consistent found:false result for any invalid input, and the explicit non-return of stored answers or reviewer notes. No contradiction with 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 front-loaded with the most important fact: 'your own, never anybody else's', and the structural Arg/Return framing at the end helps parseability. It is verbose by strict standards, with a couple of repeated ideas ('No token required' and 'No auth required'; id-alone warnings appear twice), though the repetition is used to reinforce a critical security rule.

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

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

Given there is no output schema, the description adequately explains the return shape and semantics: { ok, found, submission? }, what submission contains (status, dates, failed gates), and what it never contains. The security model and both invocation modes are fully spelled out for a security-sensitive 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?

The schema has 100% description coverage, so baseline value is already met. The description adds meaningful semantic context beyond the schema: the relationship between claim_token and submission_id, the 'id alone never works' constraint, and the security rationale. This elevates it above a bare schema readout.

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 and resource: it reads the status of one submission and 'never anybody else's'. It clearly distinguishes itself from general form/submission tools by emphasizing the own-submission-only behavior and the identity/token mechanisms.

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 when-to-use conditions: signed-in identity resolves the record with no id, or submission_id plus claim_token opens the record. It also gives when-not guidance: an id alone never works, wrong tokens all return found:false, and the tool cannot be used to test which ids exist.

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 provide only four thin booleans (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the description carries the full burden — and it exceeds it: no token required for public forms, live audience-ring checks, one-submission-per-identity semantics, claim_token returned once and only for unattributed submitters, and the explicit warning that this writes a real submission under a real person's name and every answer must be confirmed with the human.

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?

For a high-consequence tool, nearly every sentence earns its place — preceding tokens, audience checks, this-activity semantics, idempotency, claim_token duties, and return shape are all load-bearing. The structure is an information-dense single paragraph, though, and the critical warning to confirm every answer sits mid-stream; paragraph breaks and strict warning-front-loading would tighten it.

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

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

With no output schema and only two parameters, the description must carry return-format and failure-mode disclosures — and it does: it enumerates the exact return (ok, submission_id, status, failed_gates, claim_token?, counts, message), explains the claim_token governance, the audience-ring refusal behavior and its difference from 'no such form', and the semantics of the submission. Nothing an agent needs to call this tool 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 documents both parameters thoroughly, including that answers are keyed by question id exactly as ic_forms_get returns them and that booleans admit multiple string forms. The description's 'Args: { form_id, answers }' restates schema information and names ic_forms_get as the source of the keys, but adds little new meaning, 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?

States a specific verb + resource ('Submit answers to one form'), scoped to a single form, and the ensuing text distinguishes it from its read-side siblings ic_forms_get and ic_forms_list. The purpose is unambiguous without needing to open the schema.

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

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

Explicitly instructs the caller to run ic_forms_get first to obtain question ids and allowed options, and explains when NOT to use the tool — a correction must go to the form's contact address because a resubmit is refused and the first submission is never overwritten. It also frames the real-world semantics of the action (expression of interest, not a final application), telling the agent what to tell the human.

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 directly contradicts the annotations: it explicitly claims idempotency ('Idempotent: a record that was already withdrawn comes back ok with changed: false', 'a retry after a timeout is safe'), while the annotations set idempotentHint to false. Per the scoring rule, a contradiction with annotations forces a score of 1. Otherwise the description is rich with behavioral detail, but this contradiction is disqualifying.

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 long and somewhat repetitive, restating consequences already in the title and over-explaining ownership. However, given the consequential and irreversible nature of the operation, the detail is largely justified and front-loaded with the core purpose. Every major point contributes to safe usage, though tighter editing would improve it.

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?

Even though there is no output schema, the description explains the important return fields ('found', 'changed', 'freed_slot', 'counts', 'message'), covers idempotent retry behavior, addresses ambiguous error semantics for nonexistent ids, and details edge cases like already-withdrawn records and approved submissions. This is complete enough for an agent to invoke the tool safely and interpret the 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 coverage is 100%, so the baseline is 3. The description adds meaningful semantic context beyond the schema: it explains the two valid identity paths (signed-in identity versus submission_id plus one-time claim_token), clarifies that a signed-in submitter needs neither token, and reinforces that submission_id and claim_token must be used together. This helps an agent choose the correct parameter combination for the caller's situation.

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 and resource: it withdraws the human's own submission to a form. It also sharply distinguishes itself from siblings by emphasizing that only the submitter can perform this action, and that operators, reviewers, and admin permissions cannot. This makes the tool's purpose unambiguous even among many form-related siblings.

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 says when to use the tool, when not to use it, and who is allowed to call it. It states that operators/reviewers/admins cannot withdraw on someone's behalf, that withdrawal is not a way to redo an application, that the agent must confirm with the human before calling, and explains the implications for approved submissions. This is strong, actionable usage 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 declare readOnlyHint=true, and the description reinforces this with 'No auth required; this is the rules table, not anybody's progress.' It adds valuable behavioral context beyond the annotation, including the structure of conditions ('Conditions read as either { signal, gte } ... or { minTier }') and the default for items without `requires`. This enriches agent understanding without contradicting the annotation.

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

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

Although the description is multi-sentence, every clause serves a purpose: scope, auth, use cases, condition semantics, sibling pointer, args, and return shape. The main action is front-loaded in the title and first sentence. There is no fluff or repetition, making it appropriately sized for the tool's complexity.

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?

Since there is no output schema, the description compensates by specifying the return structure `{ ok, count, items[{ id, kind, label, blurb?, rarity, requires?, asset? }] }` and explaining the `requires` condition shapes. It also covers auth, use cases, and default granting, making the tool fully understandable in context, even without structured output definitions.

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 `kind` is fully described by the schema with an enum and description: 'Optional filter — return only unlocks of this kind.' The description merely repeats the enum values in the Args line ('kind?: 'clip'|'prop'|'skin'|'stage'|'capability''), adding no new semantic detail. With 100% schema coverage, the 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 clearly states the tool's purpose: 'The full catalog of things a Funko Me figure can earn — animation clips, props, skins, stages — with the condition that unlocks each one.' It uses a specific verb (list) and resource (catalog), and distinguishes itself from the sibling tool ic_funko_progress by explicitly directing progress queries there.

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

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

It explicitly states when to use the tool: 'Use it to explain to a human WHY something is locked, or to show what is worth doing on the floor.' It also names the alternative: 'For one member's actual progress against these, call ic_funko_progress.' This is clear, actionable guidance with explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds that no auth is required and specifies ranking behavior (highest-velocity-first, ties preserve feed order). It stops short of error/rate-limit behavior, but the added context is meaningful.

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

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

Front-loaded with purpose and the sibling distinction, then return fields, then a compact Args block. Dense but nearly every clause carries information; only minor tightening possible.

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 enumerates return fields (url, velocity, summary, dek, beat, date, publishedAt, image, focal) and the ranking order, so an agent knows exactly what to expect. Nothing needed 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 description coverage is 0%, and the description fully compensates: limit (1-25, default 20), min_velocity (>=1, default 1, explained as corroboration by >= N sources), and q (2-80 chars, case-insensitive substring over title + summary). Every parameter's meaning and constraint is documented.

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 ('Returns newagg's velocity-ranked AI news') and explicitly distinguishes itself from the ic_signal_* surface. An agent can route to the correct tool without opening a schema.

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

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

Explicitly names the alternative surface ('a DIFFERENT surface from ic_signal_* which serves THE SIGNAL, the weekly editorial dispatch') and the condition that separates them: raw aggregator firehose vs curated editorial dispatch. Clear when-to-use routing.

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

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

Annotations already declare readOnlyHint=true (safe read). The description adds useful behavioral context: no auth required, returns full record, includes content field as a distillation, error behavior with listing available entries, and ambiguity resolution (newest wins). This goes beyond 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 information-dense but front-loaded with the main purpose. It includes details on return format, error handling, and related tool usage without being overly verbose. Could be slightly tighter but each sentence adds value.

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

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

Despite no output schema, the description fully explains the return object fields, error behavior, and the nature of the content field. It covers all essential aspects for correct invocation and understanding.

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?

Input schema already has 100% coverage with descriptions for both parameters. The description adds semantic context: session_no is VCN-only, series disambiguates across programs, and explains ambiguity resolution. This enhances understanding 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 fetches a single presentation by session number, with optional series disambiguation. It distinguishes from sibling ic_presentations_list, which is for listing and discovering non-VCN talks. The verb 'fetch' and resource 'single presentation' are specific.

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?

Explicitly states when to use this tool (VCN-only talks with session_no) and when to use ic_presentations_list (non-VCN talks like ClawCamp). Also mentions no auth required, which is helpful for selection.

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 indicate readOnlyHint=true, and the description confirms 'No auth required.' It goes beyond annotations by detailing the return structure, explaining the scaffold flag meaning placeholder data, and noting that public_url may be null for unpublished items. No contradictions with 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 richly packed but efficiently structured: purpose first, then differentiation, auth, parameters with examples, and expected return format. Every sentence adds unique value without repetition, making it both comprehensive and easy to parse.

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

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

Despite having no output schema, the description fully documents the return shape and edge cases (scaffold, unpublished presentations). Combined with the thorough parameter and usage details, the tool is completely understandable without further references.

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 description adds context beyond the schema: examples for series values ('VCN'|'ClawCamp'|'Talk'), default/max for limit and its application scope, and an explicit note about case-insensitive filtering. This fully compensates for any lack of deeper semantics.

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

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

The description clearly states 'List the public archive of presentations given at Immersive Commons events...', specifying the verb and resource. It explicitly differentiates from sibling tools ic_resources_list and ic_presentations_get, making the tool's unique purpose 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 provides explicit guidance: when to use (listing public presentations), when not to (not for rooms, not for detail), and alternatives (ic_resources_list, ic_presentations_get). It also notes that no authentication is required and that results are grouped by series.

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/open-world, but the description adds far more: the incomplete-success contract for ok:true/complete:false, coverage.unknown_minutes and unknown_windows[], the rule that unknown windows are omitted rather than assumed free, horizon.effective_to clamping semantics, and explicit 'NO TOKEN REQUIRED' auth disclosure. This is exactly the extra behavioral context annotations cannot carry.

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

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

Front-loaded with the two facts an agent needs first (slots + policy together, then the read-order rule). The return-shape enumeration and the negotiation metaphor add length; the metaphor sentence is stylistic rather than informational, but the rest of the length is earned by genuinely non-obvious semantics.

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

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

No output schema exists, yet the description enumerates the full response shape (ok, complete, member, meeting_type fields, slots, coverage, unknown_windows, horizon, generated_at), explains the empty/incomplete cases, and discloses auth requirements. An agent could call and interpret this correctly without further probing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description reinforces semantics the schema states and adds cross-parameter meaning: start/end are UTC ISO-8601 with trailing Z, member.tz and viewer_tz are IANA zones and wall-clock arithmetic is forbidden without one, and the arg list is restated. Useful but largely overlapping with 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 (open slots for one meeting type) and an unusual scope addition (the member's full booking policy in the same response). It is clearly distinguishable from ic_scheduling_list_meeting_types, which it references as the source of the meeting_type slug, and from ic_scheduling_manage_booking.

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 strong when-to-use guidance: read the policy block before the slots, understand that complete:false is an incomplete success, and that empty slots with complete:true means genuinely booked. It routes to ic_scheduling_list_meeting_types for the slug, but does not explicitly contrast against ic_scheduling_manage_booking or state when not to call this.

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 only readOnly/openWorld, so the description carries the real behavioral load: no token required, visibility filtered in the service's own SQL (members_only/unlisted/deactivated never appear), and what an empty meeting_types means. This is exactly the context an agent needs that annotations cannot express.

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

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

Front-loaded with the core 'what you may book' statement followed by usage, semantics, and the return shape. It is dense and somewhat long, but nearly every sentence carries distinct operational value; only the protocol URL caveat is marginal.

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, yet the description spells out the full return shape (ok, member, meeting_types fields) and the empty-result semantics. For a read-only listing tool, nothing an agent needs to call and interpret it 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% and the single handle param is fully documented with a regex in the schema. The description only restates 'Args: { handle }' and hints at slug correctness, adding no syntax 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 and resource ('list every PUBLIC meeting type' a member publishes) plus the fields returned (duration, location kind, notice window, booking horizon). Clearly distinguishable from the sibling ic_scheduling_get_availability, which it explicitly positions itself as a prerequisite to.

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?

Explicit 'START HERE' directive, warns that guessing a slug causes not_found, and tells the agent to read min_notice_minutes and horizon_days before proposing times. It also explains the meaning of an empty result, ruling out a misuse interpretation.

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?

Goes well past the annotations: token-as-credential model, constant-time comparison, wrong-token and missing-booking both returning not_found (enumeration defense), cancel idempotency so a retry after a dropped response is a success, reschedule atomicity so a refused move leaves the original untouched, and the new booking.id plus superseded payload behavior for stale manage links. This is exactly the behavioral context a mutation tool needs.

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?

Information-dense but front-loaded with rhetorical framing ('an agent that has to ask its human to click a link in an email simply ghosts') before the operational facts. Every paragraph carries real content, yet the prose is long and capitalized emphasis is overused, which slows an agent scanning for the essentials.

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, and the description compensates fully by enumerating the success payload (booking, superseded, member, meeting_type, location_url, ics, calendar) and the full error_kind list. For a 6-param, three-action tool with no output schema, nothing an agent needs to call it or interpret a failure 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 already 100%, but the description adds meaning on top: reschedule's start must come from a fresh availability call because old responses go stale, the service requires idempotency_key on reschedule and mints one if omitted, reason is member-visible, and the full arg list is restated. It doesn't add much beyond the schema on booking_id/cancel_token, which 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 title and body make clear this is read/cancel/reschedule for a single booking keyed by its cancel_token, and the action enum semantics are spelled out, so it is distinguishable from ic_scheduling_get_availability and the other siblings. The opening sentence is metaphor ('The way OUT of a booking') rather than a plain verb+resource statement, so the purpose takes a few lines to land.

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 real routing guidance: cancel/reschedule must be confirmed with the human first, reschedule needs a start from a FRESH ic_scheduling_get_availability call (implying the alternative of re-querying availability), and idempotency_key should be brought and reused on retry. No explicit when-not-to-use case beyond that, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false. Description adds valuable behavioral info: 'No auth required' and explains the return structure (full tree). Does not contradict 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?

Three sentences with no filler. First sentence defines purpose, second lists return fields, third notes auth and parameter format. Efficiently 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 read tool with one parameter and no output schema, the description covers purpose, parameter format, authorization, and return structure. No obvious gaps given the tool's low complexity.

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

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

Schema description coverage is 0%, so the description carries the full burden. It provides an example argument ('issue-05') and clarifies the parameter's role (slug). Adds meaning beyond the schema's type and constraints.

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?

Description clearly states 'Fetch one issue by slug' with specific verb and resource. It lists the return structure (beats, stories, datespan, etc.) and distinguishes from siblings like ic_signal_get_story and ic_signal_list_issues.

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?

Description implies usage context (fetch one issue), but does not explicitly state when to use vs alternatives or when not to use. No exclusions or alternative tool references are provided.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds valuable behavior context: no auth required, include_stories defaults to false, and the stories are inlined as stories[] with id/title/dek. This goes beyond the annotations without contradicting them.

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

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

The description is compact and front-loaded: it states what the tool returns first, then gives shape and behavior details. Every sentence adds useful information, and there is no redundant repetition of the title or 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?

Even without an output schema, the description sufficiently describes the return value by referencing the list_issues element shape and the optional stories fields. It covers auth requirements, the single parameter's behavior, and the relationship to sibling tools, so an agent has enough context 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?

Schema description coverage is 0%, so the description carries the full burden for parameter meaning. It explains exactly what include_stories does, its default value, and the resulting shape of the response. This fully compensates for the empty schema descriptions.

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 and resource: 'returns the most-recent issue summary' and clarifies the exact shape ('same shape as one element of ic_signal_list_issues.issues[]'). It clearly distinguishes itself from siblings by focusing on 'latest' and referencing the related tools it complements.

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

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

The description provides clear context for when to use the tool: it is a 'convenience tool' for the latest issue summary, and it explains how include_stories can save a follow-up ic_signal_get_issue call. It does not explicitly enumerate when not to use it versus list or search, but the intended usage is strongly 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 indicate read-only (readOnlyHint=true). The description adds context: no auth required and the return structure (body paragraphs, feature card, image, source citations). No destructive behavior implied, and no contradictions.

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?

Description is brief (4 sentences) and front-loaded with the main action. Could be slightly tighter, but no extraneous information.

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

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

For a simple get operation with two params and no output schema, the description covers purpose, return content, and auth. Lacks details on errors or pagination, but those are not critical here.

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 has 0% description coverage. Description provides an example and format for story_id ('kebab-case slug') but does not explain the slug parameter beyond 'issue slug'. Minimal added value beyond schema constraints.

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

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

The description clearly states the action (fetch/get), the resource (a single story), and the identification method (issue slug + story id). It distinguishes from siblings like ic_signal_get_issue and ic_signal_search by specifying it retrieves exactly one story by two keys.

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 notes 'No auth required', which is a usage precondition. It implicitly tells when to use this tool (when you have the exact slug and story_id) but lacks explicit negative guidance or alternatives.

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

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

Beyond annotations (readOnlyHint, openWorldHint), it adds ordering behavior, authentication requirements, and the exact return structure, giving full insight into what the tool does.

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?

Efficient two-sentence description plus concise args/returns block, no unnecessary words, and key 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?

Covers purpose, ordering, auth, parameters, and return types. Without an output schema, the explicit return structure ensures the agent knows exactly what to expect.

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

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

With 0% schema description coverage, the description fully compensates by specifying the parameter's optionality, default value, and min/max constraints, adding meaning beyond the raw 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 verb 'list' and the resource 'issue summaries for THE SIGNAL', distinguishing it from sibling tools that get a specific issue, latest, or search.

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 context (newest first, no auth required) but does not explicitly mention when to use this tool versus alternatives like ic_signal_get_issue or ic_signal_search.

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?

Behaviors like case-insensitivity, match fields, returned fields (snippet, slug, story_id), and no auth required are disclosed, adding beyond readOnlyHint annotation.

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?

Single concise paragraph with purpose first, every sentence adds value, 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?

Completeness is high: describes input parameters, match scope, and return fields. Output schema absent but description suffices.

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?

Despite 0% schema coverage, description provides full parameter semantics: q (string, 2-120 chars), limit (number, max 50, default 10), matching schema constraints.

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?

Description clearly states it performs substring search across published SIGNAL issues, distinguishing it from sibling tools like ic_signal_list_issues or ic_signal_get_issue.

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?

Description mentions no auth required and implied usage for searching, but lacks explicit guidance on when to use vs alternatives or when not to use.

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?

Goes far beyond the sparse annotations (readOnlyHint=false, idempotentHint=false) by disclosing real-world stakes: it 'WRITES a real application under a real person's name and commits them to a 5-week in-person NDA-bound program.' It also reveals edge-case behavior (a second application is refused, not merged), the one-time-only claim_token display requirement, and the auth model (no auth required; token only attributes). This is deep behavioral disclosure with no annotation 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?

Dense but every sentence earns its place: the highest-stakes warning (real commitment) is front-loaded, followed by the guardrail, prerequisite, duplicate-handling, and output-token warning. For a high-stakes 14-parameter write operation, the length is fully justified with zero 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?

With no output schema present, the description supplies the exact return shape 'Returns: { ok, application_id, claim_token, status, failed_gates, cohort, message }' and explains how to handle the critical claim_token. It covers prerequisites, consequences, edge cases, and auth behavior, making it complete 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?

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by flagging the nda_ack, commit_5_weeks, and in_person_sf parameters as 'promises they have to keep' that must be confirmed with the human, and by pointing to ic_spatial_beta_program for exact allowed values on enum-backed fields like profile and availability.

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?

Opens with a specific verb+resource: 'Submit an application to the 50-person spatial-computing beta.' The description clearly differentiates this from the sibling ic_spatial_beta_program by instructing the agent to call that tool first for the catalog, and the scope (applying versus status/program info) 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?

Explicitly directs the agent to 'Call ic_spatial_beta_program first for the catalog and the exact allowed values,' giving a named prerequisite and alternative. It does not explicitly spell out when NOT to use ic_spatial_beta_status, though the apply-versus-check distinction is reasonably clear from naming and 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value beyond them by stating 'No auth required' and disclosing the return shape ({ ok, form, cohort: { size, approved, remaining } }), which is meaningful since there is no output schema. It stops short of describing pagination or freshness, hence a 4 rather than 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?

It is front-loaded with the core purpose and every sentence carries information the caller needs (terms, question catalog, gating logic, invocation order). The parenthetical listing of all program terms is dense and slightly long, but each detail is decision-relevant for a prospective applicant, so it earns its place rather than 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?

With no output schema, the description fills the gap by naming the return shape and the key fields (form, cohort size/approved/remaining). It covers what the tool is, what it returns, when to call it, auth requirements, and how to interpret the output for the follow-up apply step. 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The 'Args: none' line states this explicitly, which is a small clarity win.

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 exactly what the tool returns: the beta terms, every application question, and the reason each is asked. It distinguishes itself from its most relevant sibling by explicitly naming ic_spatial_beta_apply and positioning itself as the prerequisite. An agent can tell what this is for without opening anything else.

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 an explicit when-to-use rule ('Call this BEFORE ic_spatial_beta_apply so you answer well instead of guessing') and an actionable decision heuristic via the three `gates` booleans, noting a no to any likely means rejection. This is routing guidance plus eligibility guidance, not vague context.

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

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

With readOnlyHint already covering safety, the description adds substantial non-obvious behavior: the token acts as a credential because ids leak via URLs/chat logs, wrong-or-missing tokens are indistinguishable from unknown ids (no enumeration oracle), and no auth is required. This is exactly the kind of context annotations cannot convey.

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

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

Front-loads the purpose, then the credential requirement, then the security rationale, then args and return shape. Dense but every sentence carries information; the opening 'Where one application stands' is slightly indirect but quickly grounded.

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, yet the description enumerates the return fields (ok, found, application?, cohort), states the auth requirement, and documents the security semantics of failure modes. Nothing an agent needs to call or interpret this tool 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 the baseline is 3, but the description adds real meaning beyond the schema: it explains why both parameters are jointly required and frames claim_token as a credential rather than a plain identifier. It does not add format/syntax detail beyond the sbc_/sb_ prefixes in 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 ('Where one application stands', checked against the spatial-beta application concept) and clearly differs from the sibling write tools ic_spatial_beta_apply and ic_spatial_beta_program by being a read/status lookup. An agent can identify the tool's role without opening the schema.

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

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

Gives clear conditions for use: BOTH application_id and claim_token from submission are required, and it explains that an id alone yields only public slot counts. It stops short of naming siblings explicitly, so routing relies on inference, but the when-to-use context is strong.

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