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 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 indicate readOnlyHint=true, and description adds details about ranking (highest-velocity-first), default values, and no auth. 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?

Concise single paragraph, front-loaded with main output. Each sentence adds value; no 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?

Despite no output schema, description covers output fields, parameters, authentication, and sibling differentiation. Complete for a read-only 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 has no descriptions (0% coverage), but description explains each parameter: limit range and default, min_velocity threshold, q substring match. Adds meaning beyond schema types.

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 velocity-ranked AI news from newagg, with specific output fields. Differentiates from ic_signal_* tools, which serve editorial dispatch.

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 says it's the raw aggregator feed, distinguishes from ic_signal_* tools, and states no auth required. Provides parameter constraints and defaults.

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 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?

With no meaningful annotations to rely on, the description carries the behavioral burden well: it states there are no arguments, no auth is required, and the return shape is { ok, form, cohort: { size, approved, remaining } }. It also surfaces important context like the three gating booleans. It could go further by noting whether the call has side effects, but for an informational tool this is strong.

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 dense with high-value information: terms, question catalog, rationale, gates, return shape, and auth status. It is a single paragraph, but each clause earns its place. Slight restructuring could front-load the 'call before apply' instruction, but overall it is well-organized for an informational tool.

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 zero-argument informational tool, so the description needs no parameter explanations. It provides the return shape, auth requirement, application terms, the critical gating booleans, and the relationship to ic_spatial_beta_apply. Since there is no output schema, the return-shape disclosure is especially valuable and makes the tool fully self-contained.

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 and 100% coverage, so the schema already communicates there are no arguments. The description adds the explicit 'Args: none' confirmation, which removes any ambiguity. This meets the 0-param baseline and adds marginal clarity.

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

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

The description states a clear purpose: it provides everything needed to apply to the spatial-computing beta, including terms, questions, and rationale. It distinguishes itself from ic_spatial_beta_apply by explicitly telling the agent to call this tool before applying.

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

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

The description gives explicit usage guidance: 'Call this BEFORE ic_spatial_beta_apply so you answer well instead of guessing.' It also explains the gating booleans and advises honesty over applying despite an expected rejection, giving the agent actionable decision criteria.

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?

All annotations are false, so the description carries the transparency burden. It discloses privacy-relevant behavior (id-only returns only public counts, invalid tokens are indistinguishable from unknown ids) and explicitly states no auth is required. It does not explicitly mention side effects or idempotency, but for a status lookup this is a minor gap.

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

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

The description is dense but efficient: the core purpose leads, followed by the critical parameter relationship, the anti-enumeration security behavior, and a compact args/returns/auth summary. Every sentence adds value 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?

With no output schema, the description provides the return shape ({ ok, found, application?, cohort }), explains auth, and covers edge-case behavior. It could elaborate on the meaning of fields like 'found' or 'cohort', but it is still 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?

Schema coverage is 100%, but the description adds significant meaning beyond field names: it explains that both parameters must be supplied together, that claim_token is a secret credential, and that the id alone has a different, less privileged result. This is exactly the kind of contextual nuance an agent needs.

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 states the verb 'Check' and the resource 'spatial-beta application's status', and the description reinforces with 'Where one application stands' and the return shape. It is clearly distinct from the sibling apply/program tools.

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

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

The description explicitly states both required parameters, explains why an id alone is insufficient, and warns that the endpoint cannot be used to test id existence. This gives the agent strong when-to-use and when-not-to-use guidance.

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