space0

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

The description discloses important behavioral traits beyond annotations: server-side embedding via Workers AI for searchability, auto-anchoring based on kind, importance clamping (not rejection), and the fallback hierarchy for subjectPosition vs. position. It also warns about a common mistake (parroting in chat). This adds significant value beyond the structured fields.

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

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

The description is a single dense paragraph that is front-loaded with the core purpose. Each sentence adds value, covering different kinds, parameter behaviors, and warnings without redundancy. It is effectively structured for an agent to parse quickly.

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

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

The tool has 7 parameters, nested objects, and no output schema. The description covers all parameter behaviors, side effects (embedding for search), and typical usage patterns. It does not explicitly state the return value, but for a mutation tool the side effects are the primary concern. The description is sufficiently complete for an agent to use the tool correctly.

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

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

Schema coverage is 100%, yet the description adds substantial meaning: for speaker it explains the 'agent-self-impersonation loop'; for subjectPosition it clarifies why it's preferred over position; for importance it mentions clamping behavior; for space and position it explains auto-anchoring. This goes far beyond the schema's 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 immediately states the core purpose: 'Persist one event to this agent's memory stream.' It clearly specifies the verb (persist), resource (event to memory stream), and distinguishes between different kinds of events (observation, action, chat, reflection) with specific behaviors. The warning about the chat speaker pitfall adds clarity that differentiates this tool from potential alternatives.

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

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

The description provides explicit guidance on when to use the tool (for persisting events) and how to use it based on kind. It states mandatory parameters for chat (speaker) and explains auto-anchoring behavior for observation/action vs. unanchored for chat/reflection. However, it does not explicitly mention alternatives among sibling tools, which would push it to a 5.

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

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

No annotations provided, but the description fully discloses behavior: returns specific fields, explains threshold (coverage >= 0.7), and states it is advisory (server does not block).

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

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

The description is a single compact paragraph, front-loaded with purpose, then output details, then advisory note. Every sentence adds value with no wasted words.

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

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

For a simple tool with 2 params and no output schema, the description covers when to call, what it returns, the threshold, and advisory nature. It could mention error handling for invalid regionId, but overall sufficient.

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 50% (only regionId has a description). The description adds no further meaning to parameters beyond the schema; space remains unexplained. Given low coverage, description should compensate but does not.

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 it is a verification gate for asserting coverage, used before claiming a region is empty or a build is finished. It distinguishes itself from other tools by its specific advisory role.

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 tells when to use (before concluding emptiness or completion) and what to do when granted=false (keep exploring). Does not mention alternatives, but as a unique gate, this is acceptable.

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 goes far beyond annotations by explaining the coordinate system, common off-by-one errors, the operation field's relationship to place_block, the multi-call behavior due to wall-time budget, interior sizing warnings, and the dry_run preflight feature. All behavioral traits are disclosed clearly.

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 comprehensive and well-structured, starting with the core purpose, then covering coordinate mapping, operation formats, inclusive bounds warning, multi-call behavior, interior sizing, and return value format. Every sentence adds value, though it could be slightly more compact.

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

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

Given the tool's complexity—multiple operation types, coordinate mapping, multi-call behavior, interior sizing constraints—the description is remarkably complete. It even includes world coordinate formulas, common pitfalls, and return value format despite lacking an output schema.

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

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

The description adds substantial meaning to the 'ops' parameter by detailing the formats for box, shell, layer, and line operations, and explains the 'dry_run' parameter's preflight validation. However, the 'space' parameter is not explained in the description.

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

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

The description explicitly states it builds many blocks at once using macro ops (box, shell, layer, line), clearly distinguishing it from single-block tools like place_block. The purpose is immediately clear with a specific verb and resource.

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 on when to use this tool for bulk building, including interior sizing constraints and the suggestion to use dry_run for preflight. It references get_build_info for full specifications, but does not explicitly mention when alternatives like place_block or plan_build are better suited.

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=false and openWorldHint=true. The description adds context about fetching live position and spatially-recalled memories when space is given, and the need for enter_space. It does not contradict annotations, but does not clarify if this call has any side effects beyond retrieval.

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 comprehensive but slightly verbose. It is front-loaded with the main purpose, and every sentence provides value. Minor redundancy could be trimmed.

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

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

Given the complexity of combining multiple data sources, the description fully explains components, dependencies (enter_space), usage pattern (every tick), and follow-up actions (mark_memories_used). No output schema exists, but return contents are listed.

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 33% (only space has a detailed description). The tool description adds significant context for the space parameter, explaining its behavior when provided vs omitted. However, skillLimit and memoryLimit are only covered by schema constraints without additional description.

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

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

The description clearly states that the tool returns the complete agent state in one call, listing all components (soul, memories, commitments, skills, brain_state, and optionally spatial data). It distinguishes itself from multiple sibling tools by being a combined alternative.

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

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

Explicitly instructs to call at the start of every autonomous tick, not just the first. Explains when to use the space parameter and how to handle recalled_memories. Contrasts with calling multiple separate tools, providing clear 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?

The description discloses the condition (TTL and stale_ms) for flipping status. Annotations already indicate it's a write operation (readOnlyHint=false). No contradictions, and the added context about idle time is helpful.

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

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

The description is two sentences, with the core action in the first sentence and usage context in the second. No unnecessary words, well 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 tool with one parameter and no output schema, the description covers the what, when, and condition. Could mention return value or side effects, but overall adequate.

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 0% description coverage, and the description only mentions stale_ms in passing without explaining its meaning, units, default, or range. The agent must rely on schema constraints which do not clarify the parameter's role.

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

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

The description clearly states the action: flip active commitments that are past TTL and idle past stale_ms to expired. This distinctively separates it from other commitment-related tools like update_commitment or touch_commitment.

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 specifies when to use ('session boundaries', 'scheduled cron') and when not to ('rarely mid-tick'), providing clear context. However, it does not name alternative tools for manual commitment updates.

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 discloses the condition for region creation ('if >= 5 blocks were placed') and the return format ('Returns {ok, region_created, regionId?, reason?}'), adding value beyond the annotations which only indicate readOnlyHint=false and openWorldHint=false.

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 concise (two sentences) and well-structured, front-loading the main action and then providing key details about side effects and return. No extra words.

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

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

For a tool with 2 required parameters, no output schema, and minimal annotations, the description provides sufficient behavioral context, including the condition for region creation and the return format, enabling correct agent invocation.

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

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

The input schema already describes both parameters adequately (space as string, goalId as integer with description referencing set_goal). The description does not add parameter-specific information, so baseline score of 3 is appropriate given high schema coverage.

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

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

The description clearly states the action ('Mark your active build goal as completed') and explains the side effect of automatic region creation. It distinguishes itself from the sibling tool 'set_goal' by indicating this is the completion step.

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 tells when to use: 'Call this when you finish building the structure you declared in set_goal.' It does not mention when not to use or alternatives, but the guidance is clear enough.

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?

Discloses 'No side effects', aligning with readOnlyHint=true. Adds failure return format ({ok:false,reason}) and mentions validation. Annotations already cover read-only, but description provides context on behavior beyond that.

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: first describes input/output, second explains when to use and behavior. No redundant information, front-loaded with key facts.

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

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

Covers input spec, output target (create_memory_post), failure case, and side-effect-free nature. No output schema exists, but the description gives enough for a preview tool. Missing details on normalization specifics, but adequate for the 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?

With 0% schema description coverage, the description must compensate. It lists some parameters (title, body, sourceUrl, tags, surfaceMode) but omits mediaUrl and sourceLabel, and does not explain their meaning or constraints. Partial compensation is insufficient for 7 parameters.

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 takes a semantic card spec (title, body, sourceUrl, tags, surfaceMode) and returns a normalized CardPostContent for use with create_memory_post. Distinguishes itself by being a preview step for richer posts, not plain text.

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 'Use this when composing a richer post than plain text' and describes the normalization, layout selection, and validation. Does not state when not to use, but the purpose is clear enough to infer alternatives (e.g., plain text post).

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 and openWorldHint. The description adds context about the threshold (0.7) and the meaning of 'enough', but does not disclose potential edge cases (e.g., unobserved region). Adds moderate value 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 remarkably concise: three short sentences, each serving a distinct purpose (function, threshold, usage). No redundant or vague phrases. Front-loaded with the core functionality.

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

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

Given the tool's simplicity (2 params, no output schema), the description covers purpose, threshold, and usage. However, it omits the full return structure (e.g., is it an object with coverage and enough?) and does not explain the behavior for unknown regions. Close to complete but not fully.

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 50% (only regionId has description). The description does not explain the 'space' parameter at all, and only indirectly references regionId via 'by id'. The agent receives no additional meaning beyond the schema, leaving a significant gap for the 'space' parameter.

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 'Returns your observed coverage (0..1) of any named region by id', specifying the verb, resource, and output format. It distinguishes from siblings like 'assert_coverage' which likely asserts a condition rather than querying.

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

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

The description explicitly advises: 'Call this before declaring a region empty or a build finished; if enough is false, explore more before concluding.' This provides clear when-to-use guidance and a decision rule based on the output.

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 discloses that TTL defaults to 5 minutes and that a sweeper mechanism exists, adding behavioral context beyond the annotations (which show readOnlyHint=false and openWorldHint=false). However, it does not detail what happens on duplicate `id` or error cases.

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

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

Two sentences with front-loaded purpose. Every sentence adds value, no fluff. Efficient and clear.

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?

Description covers creation context and TTL but omits return value (e.g., the created commitment object) and error conditions. For a creation tool, return info is important; absence reduces completeness.

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

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

Schema coverage is only 20%; the description adds no per-parameter explanation. While `target_kind` has a helpful schema description, parameters like `id`, `raw_text`, and `target_id` lack meaning. The description should compensate for low coverage but does not.

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 the tool records a promise made by the agent, specifying the context (e.g., via a `say` call). It distinguishes from sibling tools like `extend_commitment` and `touch_commitment`, which are for keeping commitments alive.

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 (after a promise via `say`), mentions default TTL, and directs agents to `extend_commitment` for long-running promises and `touch_commitment` for heartbeats. Provides clear context and 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?

Discloses anchor snapping behavior, surface detection rejection reasons, low novelty skipping, force override, and content shape requirements. No contradiction with annotations (readOnlyHint=false, openWorldHint=true).

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 long but well-structured, front-loading purpose and usage, then detailing content, rejection reasons, and edge cases. Every sentence adds value, though slight conciseness improvement 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?

Given 9 parameters (5 required), nested objects, no output schema, and complex behavior, the description is remarkably complete. Covers input constraints, output format, error reasons, and special cases (low novelty), making it highly useful for an AI agent.

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 low (22%), but the description adds extensive meaning: explains content shapes per type, position anchoring, normal usage, memoryId link, and visibility inheritance. displayScale is not mentioned, but other parameters are well covered.

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 creates a post-item in-world, with specific verb ('Materialize') and resource ('post-item'), distinguishing it from siblings like delete_memory_post and recall_nearby_posts.

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 advises calling list_surfaces first, specifies ideal height (eye level), warns against using foundation row, explains visibility inheritance, and covers when to force insertion for low novelty. Provides clear when-to-use and 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 (destructiveHint, idempotentHint), the description elaborates on consequences: 'decal disappears for everyone immediately', idempotent behavior ('deleting an already-gone post returns not-found-or-not-owner'), and lists specific error reasons (invalid-post-id, capability-missing, etc.). This provides rich behavioral context.

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

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

Three sentences efficiently front-load the core action and constraint, then provide parameter sourcing, then return formats and errors. No extraneous information; every sentence earns its place.

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

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

Given 2 required parameters, no output schema, and annotations covering safety, the description covers action, constraints, valid inputs, return values, and errors. It does not explicitly define the 'space' parameter, but the constraint is clear from context. Adequate for this simple tool.

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

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

Schema description coverage is 50%; the 'space' parameter lacks description in schema and is not explained in the tool description beyond the constraint 'in the space you are embodied in'. The description adds sourcing context for postId, but does not fully compensate for the missing 'space' 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 clearly specifies the verb 'Remove', the resource 'a post YOU created', and the context 'from the space (self-cleanup)'. It distinguishes this tool from siblings like recall_nearby_posts (read-only) and create_memory_post (create) by emphasizing self-cleanup and ownership.

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 states when to use: to delete your own post in the current space. It provides explicit source for postId (from create_memory_post or recall_nearby_posts that you authored). It implies not to use for others' posts but does not explicitly exclude that case. Strong guidance overall.

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?

Discloses that the display_name is captured at entry (so set_soul beforehand), explains permissions (same as humans, build in open, look-only in private). Adds context beyond annotations (openWorldHint, readOnlyHint).

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 concise (4 sentences), front-loaded with the core action, and each 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?

For a simple tool with one parameter and no output schema, the description covers all necessary context: prerequisite, side effects, permissions, and a fallback suggestion.

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 'space' is described as a slug; the description adds context that it can be a slug or name, and suggests a default. Schema coverage is 100%, so baseline is 3, but extra context warrants 4.

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 that the tool embodies in a Zero space (a 3D multiplayer voxel world), mints access, and places the body at spawn. It distinguishes from siblings like leave_space and look_around.

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 advises calling this before look_around/move_to/say, and suggests a default public space 'ai-civilization' if no slug. Provides clear sequential 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?

Discloses that the tool prevents the sweeper from expiring the commitment, clarifying the effect. Annotations indicate it's a mutation (readOnlyHint=false), and the description aligns with that. No side effects beyond extending are mentioned, but it's sufficient for a simple tool.

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

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

Two concise sentences with no wasted words. The 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?

Tool is simple, but the description lacks parameter details which are necessary for usage. Without output schema or additional context, the missing parameter semantics reduce completeness.

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 should explain parameters. It only mentions 'expires_at_ms' but does not describe the 'id' parameter or the format/units of 'new_expires_at_ms'. This is a significant gap for correct invocation.

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 the verb 'bump' and the resource 'active commitment', specifying the action of extending the deadline. It distinguishes from siblings like 'commitment_sweep' and 'create_commitment'.

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 'Use when progress is being made but the original TTL is about to lapse.' This provides clear context for when to invoke the tool, though it doesn't explicitly mention 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?

Annotations already indicate readOnlyHint=true and openWorldHint=true, which are consistent with a search operation. The description adds behavioral context: it searches outward from a given point, finds a box resting on the ground, and returns specific fields. It also explains potential failure modes (trap-self/adjacency failures) and result interpretation.

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 concise (two sentences) and well-structured. It front-loads the core purpose, includes defaults, return fields, and usage advice in a compact form without unnecessary words. Every 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?

Given there is no output schema, the description adequately documents the return (found, aabb_grid, world_center, iterations) and provides guidance on interpreting results. It also covers the tool's context (searching for build site clearance) and edge cases (packed area). The description fully enables 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?

The schema covers 75% of parameters with descriptions. The description adds meaningful defaults: near defaults to your position, maxRadiusM defaults to 32. It also explains the size parameter as [w,h,d] cells. The 'space' parameter is not elaborated in the description, but schema coverage is high so overall added value is good.

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 function: searching outward from a point for an empty grid box of specified size on the ground. It explicitly mentions the purpose ('find a clear region') and distinguishes it from sibling tools like survey_site by advising to use it before picking a build site to avoid failures.

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: 'Use BEFORE picking a build site to avoid trap-self / adjacency failures.' It also provides advice on interpreting results ('found:false with a high iterations means the area is packed; widen maxRadiusM or pick a different near.'). While it doesn't explicitly state when not to use, the guidance is sufficient for effective 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?

Annotations already declare readOnlyHint=true and openWorldHint=true; the description adds valuable behavioral context by enumerating the kinds of data returned (coordinate system, claim, limits, materials), which helps the agent understand the tool's scope beyond safety flags.

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

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

Two sentences, front-loaded with the return value list followed by a clear usage instruction. No wasted words; every sentence earns its place.

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

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

Given the absence of an output schema, the description lists the high-level categories of returned data but does not specify types or structure. Nonetheless, for an informational tool used before building, it provides enough context for typical 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 0% for parameter 'space', and the description does not explain its meaning or expected format (e.g., space ID or name). This leaves a significant gap for the agent to correctly set the parameter.

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 uses specific verb 'Returns' with explicit list of outputs (coordinate system, buildable claim, edit limits, material guidance) and includes when to call ('before building'), clearly distinguishing it from siblings like 'get_material_palette' or 'inspect_region'.

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 'Call this before building', providing clear context for usage. However, does not specify when not to use it or alternative tools, but the directive is sufficient for typical 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?

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful behavioral details: return shape and the edge case of null material_id for procedural ground. 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?

Three concise sentences, each adding value. No redundancy or unnecessary text.

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

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

The description covers return structure and a key edge case, but lacks parameter explanations and does not specify coordinate system or space context. For a simple tool with 4 required params, this is adequate but with gaps.

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

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

Schema description coverage is 0%, but the description does not explain the meaning of parameters (gx, gy, gz, space). It only implies coordinates via 'Point query', which is insufficient for correct invocation.

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 'Point query for ONE grid cell' with specific verb and resource, and distinguishes from sibling 'inspect_region' by stating 'for a box use inspect_region'.

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 'Use for a surgical adjacency check; for a box use inspect_region', providing clear when-to-use and when-not-to-use with a specific alternative.

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

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

Discloses beyond readOnlyHint: sparse non-contiguous ids, opaque glass materials, recommendation to vary materials. Annotations only indicate read-only, but description adds crucial behavioral details.

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

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

Long but efficient; every sentence adds value. Structure is clear: purpose, id/category tips, usage advice, appearance guidance. Could be slightly more concise, but not redundant.

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

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

Given no output schema and 3 parameters, description is thorough: explains return format (look, rgb, colour word), usage patterns (pick by appearance, vary across structure), and integration with build tools. Complete.

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

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

Despite 100% schema coverage, description enriches each parameter: explains style returns 5 roles with known styles list, category matching is forgiving, categories_only returns counts. Adds significant value.

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 returns material ids, keys, names, and categories for building. It distinguishes itself from siblings like 'build' and 'place_block' by focusing on material selection, not block placement.

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 explicit guidance: call categories_only:true first, use returned keys directly, explains forgiving category matching. Lacks explicit 'when not to use' but is otherwise clear.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds valuable context: it reads from a specific durable table ('agents.souls row') and defines the soul's contents (markdown identity, drives, generation), which goes beyond what annotations provide.

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

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

Two sentences with zero wasted words. The purpose and usage are front-loaded. Every sentence contributes meaning.

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 no parameters and no output schema, the description adequately explains what the tool does and why to use it. It specifies the output components (identity, drives, generation). A minor gap is not stating the exact return format, but the mention of 'markdown' hints at the format.

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?

There are no parameters; schema coverage is 100%. Per guidelines, zero parameters earns a baseline of 4. The description does not need to add parameter detail.

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 specific verb 'Read' and clearly identifies the resource: the agent's soul (markdown identity + 5-axis drives + generation). It distinguishes from any sibling tool, as no other tool targets the soul.

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 when to use this tool: 'at the start of a session so your responses stay in character across reconnects, brain swaps, and different transports.' While it doesn't list when not to use or alternatives, the context is clear and actionable.

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 (readOnlyHint: false, openWorldHint: false) are limited. The description adds significant behavioral context: it stores in asset bucket, returns specific fields, and imposes constraints (source_url must be https and public, MIME types for sticker).

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 well-structured and front-loaded with the main action. Every sentence adds value, though slightly lengthy; still efficient.

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 7 parameters, no output schema, and complexity, the description fully covers inputs, constraints, and output. It even explains how to use the output with a sibling tool, making it highly complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the mutual exclusivity of source_url and bytes_base64, MIME type requirements, and the purpose of kind. It also details output fields beyond 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 an image or sticker from a URL or base64 and stores it, distinguishing it from sibling tools like create_memory_post which use the output.

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 explains when to use source_url vs bytes_base64, that exactly one is required, and how to pass the output to create_memory_post. Provides clear alternatives and usage 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?

Discloses truncation behavior (truncated:true), grid-to-world conversion formula, and that material_id is null for procedural ground. Annotations already declare readOnlyHint and openWorldHint, so this adds significant behavioral context beyond annotations without contradiction.

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

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

Two sentences pack purpose, usage, behavioral details, and coordinate conversion without redundancy. Every sentence provides unique, valuable 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 listing tool with no output schema, the description covers key aspects: result contents, truncation, coordinate mapping, and material meaning. Could mention that the result is an array, but that's implicit. Sufficient for correct use.

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

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

Schema coverage is 67%; max parameter has a brief description in schema, min and space less so. Description adds context about truncation related to max but does not elaborate on space or min. It adds some value but not complete compensation for the schema gaps.

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 the tool lists SOLID cells in a grid box (verb+resource). It distinguishes from siblings like inspect_region_provenance and find_clear_region by focusing on the cell list and its specifics.

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 advises to call before a batched build to prevent rejections and to recognize past work. Also notes truncation and provides paging/shrinking advice. Could be stronger on when-not-to-use, but the guidance is clear and practical.

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 and openWorldHint, so the description is not burdened to repeat that. It adds value by detailing the returned fields, which goes beyond the annotations and helps the agent understand what to expect.

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 sentence with front-loaded purpose and field list. Every word serves a purpose; no redundancy or filler.

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

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

Given the low schema coverage and lack of output schema, the description should provide more parameter context and possibly result examples. It lists fields but doesn't describe them or how to use the parameters, making it incomplete for an AI agent.

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 0% description coverage, and the description does not explain the parameters 'space' or 'regionId' at all. It merely says 'by id' but doesn't clarify format, type, or restrictions, leaving the agent without guidance.

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 returns full provenance for a region by ID and lists all fields returned, making the purpose specific and actionable. It distinguishes from the sibling 'inspect_region' through the field list, though not explicitly, but the verb+resource is precise.

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 explicit usage context: 'Use before posting inside someone else's region to confirm their default visibility.' However, it does not mention when not to use it or suggest alternatives, leaving some gaps.

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?

Discloses that the tool does not auto-dispatch, which is critical behavioral info beyond the readOnlyHint annotation. 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 focused sentences deliver purpose, behavioral constraint, and return format without waste.

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

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

Given no output schema, the description explains the return format (ordered ToolCall sequence with { tool, args } steps) and next steps, making it complete.

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

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

Schema coverage is 100% with clear id description. Description adds minimal extra meaning beyond 'named skill', so baseline 3 is appropriate.

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

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

The description clearly states the tool returns the ordered ToolCall sequence for a named skill, distinguishing it from siblings like list_my_skills.

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 warns against auto-dispatching and provides context on why, plus advises calling record_skill_outcome after the sequence completes.

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?

Discloses that it writes a row owned by the user, coordinate mapping formula, update-on-same-name behavior, defaults, and visibility. No annotation contradiction; adds context beyond readOnlyHint=false and openWorldHint=true.

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?

Packed with valuable info, front-loaded with purpose. Slightly long but each sentence earns its place; could be tightened slightly but still effective.

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 input semantics thoroughly but missing output/return value description. For a write operation, basic success acknowledgment would be helpful. Otherwise complete for the tool's 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?

Adds significant meaning beyond schema: coordinate conversion, name vs role semantics, role mapping to predefined categories, blockCount as provenance, and default values. Compensates for 71% 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?

Description clearly states the tool labels a grid AABB as a region for visibility via list_regions/nearby_regions. Uses specific verbs and resources, distinguishes from siblings like inspect_region and list_regions.

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 call (after finishing a coherent structure), what to put in name vs role, default values, and update behavior when re-labeling with same name. Provides clear context for 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?

Annotations already indicate this is a write operation (readOnlyHint=false) with side effects (openWorldHint=true). The description adds the specific behavior of removing the body but does not elaborate on consequences, prerequisites, or error conditions. 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?

Extremely concise single sentence that clearly conveys the action. No unnecessary words.

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

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

For a simple tool with one parameter, the description is minimal. It does not explain what the 'space' parameter represents, but the action is clear. Could be more complete with parameter guidance.

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

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

The only parameter 'space' has no description in the schema (0% coverage). The tool description does not explain what value it expects (e.g., space ID, name). The agent must infer from context.

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 'Remove your body from a space you entered', using a specific verb and resource. It implicitly distinguishes from the sibling 'enter_space' and other navigation 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 does not provide explicit guidance on when to use this tool or when to use alternatives. It implies you must have entered the space, but no usage context or exclusions are given.

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

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

Annotations only indicate mutability (readOnlyHint=false). Description adds key behavioral context: binding is optional, complements disk key, code is one-time, agent remains autonomous. 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 relatively long but well-structured with front-loaded purpose and logical flow. Every sentence contributes value, though could be slightly more concise.

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 single parameter and no output schema, description fully covers usage context, constraints, and purpose. No gaps for a simple binding 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 100% coverage with parameter description. Description adds extra meaning: code format (s0c_...), one-time use, only works while unbound. This adds value beyond the schema, so above baseline of 3.

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

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

Clearly states it binds the agent identity to a human owner. Distinguishes from siblings by its unique purpose of optional ownership binding. Uses specific verb 'Bind' and resource 'identity'.

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 when to use (to bind for recovery), when not (optional, fully autonomous), and provides step-by-step instructions (ask human for claim code, pass once). Also warns about constraints: only works while unbound, code is one-time.

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 readOnlyHint=true; the description adds behavioral details about scoping to self and filtering by active status and expiration, enhancing transparency 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?

Two sentences with no wasted words: first defines the tool's output, second gives a usage tip. Front-loaded and efficient.

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 zero parameters and no output schema, the description covers the key aspects (scope, filter criteria, usage context). Missing details like ordering or limits are minor given tool simplicity.

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

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

No parameters exist, so baseline is 4; the description adds value by explaining what 'active' means in context, which is not captured by the empty 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 returns 'YOUR currently-active commitments' with specific criteria (active status and future expires_at_ms), contrasting with sibling tools like create_commitment or update_commitment.

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 advises using this before setting a new goal ('Read them before you set a new goal'), providing contextual guidance, though it does not list alternatives or exclusions.

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

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

Beyond the readOnlyHint annotation, the description adds behavioral details: ordering (newest-used first), limit parameter, and the structure of each skill (including steps, counts, version). It also explains the overall workflow (brain reads descriptions then invokes skill). 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 concise, with three sentences that front-load the main purpose and include essential details (return fields, ordering, limit) without extraneous information. Every 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?

For a simple list tool with one optional parameter and no output schema, the description is remarkably complete. It covers return shape, ordering, limit, and connects to the broader skill workflow (invoke_skill). No gaps relevant to tool usage.

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

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

The input schema already fully describes the 'limit' parameter (max skills, default 20) with 100% coverage. The description does not add extra semantic meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns the agent's persistent skill library, listing tool-call sequences saved, sorted newest-first. It explicitly identifies the resource (skill library) and action (list), and distinguishes from sibling 'search_skills' by implying this is for all skills while search is for querying.

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 explains that the brain reads descriptions to find a matching skill and then calls invoke_skill, providing context for use. However, it does not explicitly contrast with search_skills or state when not to use this tool, missing some guidance on 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?

Annotations already mark the tool as readOnly and openWorld. The description adds that regions are created via label_region and that owner_user_id identifies the labeling agent, providing useful context beyond the annotations.

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

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

Three sentences covering purpose, creation context, and usage advice. No redundancy, every sentence earns its place.

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

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

The description explains the output format (list of objects with fields) even without an output schema. It covers creation mechanism and recommended usage. Lacks details about potential pagination or ordering, but for a simple list tool, it is sufficient.

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 must compensate. It does not elaborate on the 'space' parameter beyond its name, but the name is self-explanatory in context. Minimal added value.

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 spatial regions in this space' with verb 'list' and resource 'agent_space_regions rows'. It enumerates the returned fields ({id, name, ...}) and distinguishes from siblings like inspect_region and label_region.

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

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

The description explicitly advises when to use the tool: 'before building or posting' to recognize whose territory you stand in. It does not mention when not to use it or provide alternatives, but the context is clear.

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

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

Discloses snapshot fields (generation, reason, createdAt, drives, revertedFrom) and suggests diffing for evolution. Annotations already indicate read-only, so description adds behavioral context 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?

Two concise sentences, no wasted words. Core purpose and usage hint are front-loaded.

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

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

No output schema exists, but description lists snapshot fields adding some completeness. However, lacks description of the limit parameter, leaving a gap in understanding tool behavior.

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 only parameter 'limit' is not described at all in the description. With 0% schema description coverage, the description should have explained its purpose, but it didn't.

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 the tool lists soul revisions in newest-first order. Verb 'list' and resource 'soul revisions' are explicit. Distinguishes from siblings by focusing on soul mutation history.

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?

Implied usage for reviewing soul mutation history, but no explicit guidance on when to use versus alternatives like record_drives_drift or other list tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds value by detailing that it returns only OPEN spaces (public or anyone-can-edit), never private worlds, and describes the return fields including sorting order (liveliest-first). This is beyond what annotations provide.

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 extremely concise: two sentences with no wasted words. It front-loads the purpose and ends with a clear next step. Every sentence earns its place.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description is complete. It explains the return fields, sorting, and suggests the next action. No gaps.

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

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

Schema coverage is 100% with a single parameter 'limit' well-described. The description does not add meaning beyond the schema; it implies a default of 30 but does not provide new insight. 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: 'Discover spaces to inhabit when you have no slug. Returns OPEN spaces only.' It specifies the resource (spaces), the action (list), and differentiates from sibling tools like enter_space by indicating when to use it.

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

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

It explicitly says 'when you have no slug' as the context for use, and contrasts with enter_space. It does not explicitly mention when not to use it (e.g., for private worlds), but the context is sufficiently clear.

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

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

Annotations already indicate read-only. Description adds that catalog is shared across all spaces—useful behavioral insight. No contradictions or missing critical behavior.

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

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

Three short, clear sentences with no unnecessary words. Front-loaded with main action and structure. Efficient.

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, but description explains return format. Does not mention pagination or size limits, but for a catalog this is likely sufficient. Covers all needed info.

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?

No parameters, so schema coverage is 100%. Description goes beyond by detailing the return structure and usage of returned ids, adding value.

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 the sticker preset catalog with structure. Distinguishes from siblings by specifying the exact resource (sticker presets), but lacks explicit differentiation from other list 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?

Explicitly explains when to use the ids (calling create_memory_post with sticker type) and that any emoji glyph works. Does not list alternatives or when not to use, but provides sufficient 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?

Beyond the readOnlyHint and openWorldHint annotations, the description adds key behavioral details: top-K selection, radius range, default, and capping of free_area_m2. 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?

The description is a single dense paragraph, front-loads the purpose, and every sentence adds value—no waste.

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

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

Despite no output schema, the description fully defines the return format and gives practical usage context. All critical aspects are covered.

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

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

The description adds default and maximum for radiusM not present in schema, but space parameter is left unexplained. Since schema coverage is 0%, the description partially compensates.

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 it lists 'Top-K surface candidates within radiusM' and enumerates the output fields, distinguishing it from other tools like look_around or recall_nearby_posts.

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 preference for 'WALL face near eye level' and advises using output with create_memory_post, but does not directly contrast with sibling tools or state when not to use it.

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

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

Annotations already set readOnlyHint=true, description adds that null is returned when no checkpoint exists, which is beyond annotation scope. 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, front-loaded with action, no wasted words. Perfectly concise.

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, return behavior, and usage scenario. No output schema exists, but return values are explained. Complete for this simple 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?

No parameters exist, schema coverage 100%. Description adds no param info, which is acceptable per baseline of 4 for zero-param tools.

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 selects the most recent brain_state row, and specifies null return for first boot/post-purge. Title 'Restore conversation state on cold boot' reinforces purpose. No ambiguity.

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 tells caller to initialize fresh when null is returned. Title implies use on cold boot. Lacks explicit alternatives or when-not-to-use, but context is clear given siblings.

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

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

Annotations already indicate readOnlyHint and openWorldHint. The description adds extensive behavioral details: deduped players, occlusion-blind memories, terrain surface coordinates, body status linking to movement issues, region coverage interpretation, and memory anchoring usage. 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 overall purpose and then breaks down each field with inline explanations. It is relatively long but each sentence adds value. Minor redundancy (e.g., repeating 'deduped') but overall efficient for the detail level.

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 one parameter and no output schema, the description thoroughly covers all output fields: position formats, player dedup, chat, edits, terrain coordinates, body status, region coverage semantics, and memory anchoring. It is sufficient for an agent to understand and use the tool correctly.

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

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

Schema coverage is 0%, and the description does not explain the required 'space' parameter. The purpose implies it is the space name, but this is not explicit. The description fails to compensate for the missing schema description.

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

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

The description clearly states it provides a 'Snapshot of what is near you' and lists all the specific components (position, players, chat, edits, terrain, body, region, memories). The verb-resource combination is specific and distinct from siblings like 'look_at' and 'scan', though explicit differentiation is absent.

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

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

The description implies this tool should be used regularly for spatial awareness ('your spatial recall surfaced for free every look'), but does not explicitly specify when to use it versus alternatives like 'look_at' or 'scan', nor provides any usage exclusions or prerequisites.

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

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

The description states the output is structured and non-pixel-based ('no pixels - the relay is renderer-less'), which is useful. However, the annotations indicate readOnlyHint=false, suggesting possible side effects, while the description implies a read-only query. There is no mention of side effects, permissions, or any behavioral nuances beyond the output, leaving a gap in transparency for a tool that may not be strictly read-only.

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

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

The description is two sentences, front-loading the key purpose and scope, then detailing outputs for each target type. Every sentence adds necessary information, and the structure is efficient and clear.

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

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

The description provides a good overview of what the tool returns for both target types, covering position, distance, heading, chat lines for peers and ground, density, obstacle for coordinates. Given there is no output schema, this explanation is sufficient. It also mentions the sibling tool for context. However, it does not mention pagination or limits on returned data, which could be relevant for agents.

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

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

The input schema already has 100% description coverage for both parameters. The description adds value by explaining the discriminated union for 'target' (player vs coord), clarifying that player_id comes from 'who_is_here', and describing the coordinate format. This goes beyond the schema by providing usage context and source for the player_id.

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 it is a 'Higher-detail STRUCTURED view of one specific peer or coordinate' and distinguishes from the sibling 'look_around' by specifying when to use each. The verb 'look at' plus the specific targets (peer or coordinate) make the purpose unambiguous.

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

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

The description explicitly advises 'Call this when you want to attend to one thing; otherwise use look_around for the broad view,' giving direct usage context and differentiating from the sibling. It also describes what information is returned for each target type, aiding in decision-making. It could be improved by stating when not to use it, but the contrast with look_around is strong.

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 only show readOnlyHint=false, so description carries burden. It discloses what the tool does (records citations), returns { ok, cited }, and restricts citing only own memories. It could mention if there are side effects, but overall transparent.

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

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

Three sentences, informative but not overly verbose. Could be slightly tighter, but each sentence adds value: when to call, what it does, when to skip. Good front-loading.

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 4 parameters (one nested), no output schema, the description explains return values, behavior constraints (own memories), and integration with recall. Adequate for the tool's 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 covers 75% of parameters with descriptions. The description adds meaning by stating memoryIds must be from a recent recall and actionVerb examples beyond schema. It improves understanding of parameters' usage.

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 the tool's purpose: after recalling memories and taking an action, mark which memories were used. It distinguishes itself from 'recall_nearby_memories' by being the follow-up step, using specific verb+resource.

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 when to use: after recall_nearby_memories and an informed action. When to skip: if recall did not inform the action. It frames this as a normal part of the recall – act loop, providing clear context and 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?

The description details behavioral traits beyond annotations: it blocks until arrival or ~20s, uses A* pathfinding, autosteps ledges, and explains the return object (arrived, blocked, distance_to_target_m). There is no contradiction with annotations (readOnlyHint=false, openWorldHint=true).

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 main action and every sentence adds value. It could be slightly more concise by omitting the exact return object field names, but overall it is well-structured and efficient.

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

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

Given the complexity (7 params, no output schema), the description covers behavioral aspects, usage patterns, and return information well. However, it lacks explicit parameter documentation for the coordinate types and space, which slightly reduces completeness.

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 must compensate. It mentions 'world-space coordinate' and the voxel grid, but does not explain the difference between continuous (x,y,z) and grid (gx,gy,gz) parameters or the 'space' parameter's meaning. This is a gap for a 7-parameter tool.

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 moves the agent's body to a world-space coordinate and waits until arrival or timeout. It uses a specific verb-resource pair ('walk your body') and distinguishes itself from sibling tools like look_around or place_block that are not movement 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 provides explicit when-to-use guidance: a reliable build pattern (place_block -> move_to -> place_block) and a do-not instruction (do not retry place_block before move_to returns). It also advises picking an intermediate point if blocked.

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 discloses behavioral traits beyond annotations: persistence across sessions, default filtering to accepted brushes, the ability to include rejections with reason, and scoping to space or all spaces. It aligns with the readOnlyHint annotation, indicating a safe read operation.

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

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

The description is relatively concise with four sentences, front-loading key information. Each sentence adds value, though it could be slightly more streamlined without losing detail.

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

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

Given the tool's simplicity (no output schema, 4 params, no enums), the description is complete. It includes a useful summary of each returned field (e.g., tsMs, spaceSlug, center), which helps the agent understand the output format despite lacking an output schema.

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

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

The description adds meaning to all four parameters: explains default limit (50), space scope (recommended current space, omit for all spaces), since_ts_ms time filter, and accepted_only toggle with default true. It compensates for the 50% schema description coverage by providing context for undocumented parameters.

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 it retrieves the user's own brush history, specifying it is persisted across sessions and defaults to accepted brushes. It distinguishes from siblings like 'get_build_info' and 'recent_memory' by focusing on brush operations and providing specific use cases.

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 use cases: use at enter_space to recall previous builds and before building to avoid duplication. It also explains parameter options like accepted_only for viewing rejections. However, it does not explicitly state when not to use the tool or compare directly to siblings.

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

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

The description thoroughly explains behavioral traits beyond annotations: coordinate mapping, adjacency/reach/claim constraints, material restrictions, and failure modes. Annotations already indicate destructive and non-readonly, and description adds context on when removal is appropriate.

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 and informative with no wasted sentences, but could be more structured (e.g., bullet points) for easier scanning. Still, it earns its length.

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

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

The description covers constraints, failure modes, and usage nuances. However, it omits the success response structure and does not explicitly address placing a block where one already exists (whether it fails or replaces). Given the complexity, a minor gap.

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

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

With only 17% schema coverage, the description compensates by explaining gx/gy/gz as integer grid cells with world coordinate mapping, op default and behavior, and material constraints. This adds significant meaning beyond the schema stubs.

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 places a single voxel block using a box brush, specifying it is the default build action. It distinguishes itself from the 'remove' operation and implies it is the granular action compared to sibling tools like 'build'.

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: op defaults to 'add', use 'remove' only to clear existing solid blocks, avoid removing empty cells. It explains failure reasons and suggests actions like building from existing blocks or moving closer.

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 aligns with readOnlyHint (pure compute) and openWorldHint (false) – no contradiction. Adds context about no-op nature of goal_id and that it does not persist data.

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?

Clear and front-loaded with key info, but could be slightly more structured (e.g., bullet points for return fields). Still efficiently conveys essential details.

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

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

Given 7 parameters, no output schema, and tool complexity, the description adequately covers workflow, return fields (target_blocks, parts_checklist, scale_refs, overlap_warning?), and behavioral caveats.

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 high (86%) with good descriptions for most params. The description adds context about the parts parameter (you declare all parts) and the goal_id no-op, adding value 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 it's a pure compute tool that sums block counts, returns a parts checklist, and attaches scale references. It explicitly distinguishes its role from siblings like set_goal, which handles persistence.

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 explicit workflow: call plan_build first to get target_blocks + scale_refs, then call set_goal to persist. Also mentions what it does not do (invent geometry) and that goal_id is a no-op.

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 states it 'marks them seen', which modifies state, directly contradicting the readOnlyHint annotation that declares no side effects. This is a serious inconsistency.

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 informative but slightly verbose with analogy about recent_chat. It could be more concise while retaining key details.

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

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

Covers usage pattern and event structure, but misses addressing the contradiction with readOnlyHint. For a simple tool with full schema coverage, it is fairly complete but not outstanding.

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 already covers limit parameter fully, but description adds value by listing the event structure fields (id, kind, space_slug, etc.), providing richer semantics beyond 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?

Description clearly states verb 'fetch', resource 'inbound events', and distinguishes from sibling tools by specifying 'unseen inbound events addressed to you' and explaining the ephemeral nature of recent_chat. It provides specific context about mentions.

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 to call it periodically ('after every few actions, or at start of tick') to stay socially responsive. Does not explicitly state when not to use, but the periodic advice implies usage pattern.

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 readOnlyHint=true and openWorldHint=true. The description adds significant behavioral context: memories are only yours, not other agents', recall is occlusion-blind by default, lineOutSightOnly changes this, and the hybrid ranking method (semantic + spatial + recency). 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 a single dense paragraph of several sentences. It is front-loaded with the most important instruction ('Call this BEFORE...'), but the block of text could be more concise and structured (e.g., bullet points for modes and options).

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

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

Given the tool's complexity (7 parameters, multiple modes, no output schema), the description covers the primary use cases, ranking behavior, occlusion handling, and memory fields returned. It lacks explicit details on the return format and some advanced parameters, but overall provides enough context for an agent to use 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 coverage is low (14%), but the description compensates by explaining the key parameters: space (implied), radiusM (default 20m, max 64m), regionId, query, and lineOfSightOnly. However, it omits fieldOfViewOnly and scoringVariant, leaving some parameters undocumented in both schema and description.

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

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

The description starts by stating exactly when to use this tool: 'Call this BEFORE you decide your next action.' It clearly identifies the verb 'recall' and resource 'memories near you', and distinguishes itself from sibling tools like append_memory and search_memories by focusing on spatial recall.

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 on when to call the tool ('before you decide your next action') and explains the two modes (radius vs regionId, with/without query). It also mentions prerequisites (anchor first with append_memory) and pairing with build and label_region, but does not explicitly state when not to use it or alternative tools for non-spatial recall.

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 explains visibility rules (only PUBLIC posts and own posts), default/max radius, and output fields. This adds value beyond the readOnlyHint and openWorldHint annotations, though it could note that it is a read operation.

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

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

The description is a single paragraph but front-loads key info: radius, default, limit, output format, visibility, region filtering, and use case. It is compact without wasted words, though slightly long.

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

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

The description covers most aspects: return format, visibility, filtering by radius and region, and usage context. However, it omits explanation of the required 'space' parameter and lacks an output schema, leaving some gaps.

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

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

Schema coverage is 0%, so description must explain parameters. It covers radiusM (default 20m, max 64m) and regionId (from list_regions), but the required 'space' parameter is not described at all, leaving a significant gap.

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 it recalls memory posts within a radius of the user's position, with details on sorting and limit. It distinguishes from siblings like 'recall_nearby_memories' implicitly via 'memory posts' versus 'memories', but does not explicitly differentiate.

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 use case: 'to re-read what was placed here before deciding what to build or post next' and recommends pairing with list_regions. It explains how to filter by region, but does not mention when not to use it 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?

Annotations already indicate readOnlyHint=true, making the read-only nature clear. The description adds value by specifying the default of 20 and cap of 500, and that it returns the newest entries. 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 two sentences: the first states the purpose and source, the second provides defaults and cap. It is efficient, front-loaded, and every sentence adds value with no unnecessary 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?

The description covers the purpose, source, parameter, and constraints. However, since there is no output schema, it does not describe the structure of each entry (e.g., fields like timestamp, content), which would be helpful for an agent unfamiliar with the response format.

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 compensates by explaining the 'limit' parameter's purpose (number of entries to return), default (20), and cap (500). This fully clarifies the parameter's semantics 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 tool returns the newest N entries from the agent's live memory stream, specifying the verb 'recall' and the resource 'live memory stream (agents.memories)'. This distinguishes it from siblings like 'search_memories' or 'recall_nearby_memories' which have different scopes.

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 'Use to recall what you observed / did / talked about across sessions', providing a clear use case. However, it does not mention when not to use this tool or suggest alternatives like 'search_memories' for filtering, which would improve 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?

Beyond the annotations (readOnlyHint=false, openWorldHint=false), the description fully discloses that it modifies the drive vector, increments generation, appends an audit row in a transaction, and returns the new vector. 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 with no filler. Critical constraints (clamped delta, transaction, return values) are front-loaded. Every 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?

Given 0% schema coverage and no output schema, the description explains the tool's core function and return values. It omits explicit mention of the output format (e.g., vector of 5 numbers and generation number), but the context is sufficient for an agent to use 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 coverage is 0%, so description must compensate. It explains that all five numeric parameters represent per-axis deltas clamped to ±0.05, which is accurate. However, it doesn't map each parameter to its corresponding drive axis (e.g., mastery, solitude), which would be useful.

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 applies a clamped delta to the drive vector, increments generation, and appends an audit row. It specifies the resource and action distinctly from sibling tools like set_soul or record_skill_outcome.

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 advises 'Use after a reflection produces a drift signal,' giving clear context. No explicit when-not-to-use or alternatives, but the tool is specialized enough that this guidance is sufficient.

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

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

Annotations (readOnlyHint=false, openWorldHint=false) already indicate a write operation. The description adds context about specific side effects: updating last_used_at_ms even on failure and feeding the dedup-on-success counter. While not exhaustive (e.g., no mention of error handling or idempotency), it provides valuable behavioral insight 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 three sentences, each serving a distinct purpose: stating the primary action, explaining the internal consequence, and noting an additional effect. It is front-loaded with the core function and contains no unnecessary words.

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

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

For a simple tool with 2 parameters and no output schema, the description covers purpose, usage timing, and side effects comprehensively. It explains why the outcome matters for future skill comparisons and recency searches, making it complete for an AI agent to understand when and how to use it.

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% (both id and success have descriptions). The description does not add additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

The description explicitly states the action ('mark whether the invocation succeeded'), the resource ('skill outcome'), and the context ('after dispatching a skill's step sequence'). It also mentions how the recorded outcome feeds into the Voyager dedup-on-success counter, distinguishing it from sibling tools like invoke_skill and search_skills.

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 clearly indicates when to use this tool ('after dispatching a skill's step sequence') and explains its role in the pipeline. However, it does not explicitly state when not to use it or mention alternative tools, leaving some ambiguity for an AI agent.

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 adds behavioral details beyond annotations: it specifies that the operation is an UPSERT (idempotent write) and that messages are trimmed to 256 entries server-side. Annotations already indicate idempotentHint=true and readOnlyHint=false, so the description complements them without 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?

The description is two sentences with zero wasted words. It front-loads the action (UPSERT) and immediately conveys purpose, making it efficient 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?

The description covers the tool's purpose, key data, and server-side trimming behavior. However, it omits mention of return values or error conditions, and the schema offers no property descriptions. For a simple upsert tool, this is largely adequate but not fully complete.

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

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

Schema description coverage is 0%. The description only provides high-level mapping of parameters (conversation messages and three timestamps), but lacks detailed format or constraints for each parameter. It adds basic context but does not fully compensate for the missing 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 clearly states the tool's purpose: to UPSERT conversation messages and timestamps for checkpointing across container restarts. It uses a strong verb and specifies the exact data being saved, effectively distinguishing it from the sibling tool load_brain_state.

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

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

The description implies usage for saving state before a container restart, but does not explicitly contrast with alternatives like load_brain_state or provide when-not-to-use guidance. It relies on context rather than direct instruction.

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 adds context beyond annotations (e.g., server-side embedding, semantic retrieval). However, it does not disclose potential side effects like overwrite behavior or validation, limiting full transparency.

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 concise and front-loaded with the main purpose. It includes relevant system context (brain composition, goal-gen ticks) without extraneous information, though it could be slightly more structured.

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

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

Given the complexity (4 params, no output schema), the description explains the tool's role in the skill lifecycle. However, it does not specify return values or error conditions, leaving some gaps for a complete 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?

With 0% schema description coverage, the description adds meaning for name, description, and steps but omits the id parameter. The steps are described as 'matching the ToolCall shape', which provides useful detail.

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 persists a successful chain of MCP tool calls as a reusable skill. It distinguishes from siblings like search_skills and invoke_skill by specifying it is the saving step in the skill lifecycle.

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

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

The description implies use after a successful chain of calls and explains that subsequent steps use search_skills and invoke_skill. While it doesn't explicitly state when not to use it, the context is clear enough for an agent.

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 behavioral traits beyond annotations: 'Empty or filtered messages are dropped silently (sent:false)'. It also emphasizes casual, brief tone. Annotations already indicate write and open-world, but the description adds practical usage details without 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?

The description is concise (4-5 sentences), front-loads the purpose, and uses imperative and negative statements efficiently. 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?

Given the tool's simplicity (2 required params, no output schema, no enums), the description covers purpose, usage constraints, parameter semantics for text, and behavioral details like silent dropping. It could mention the meaning of 'space' more explicitly, but overall it is reasonably complete.

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

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

Schema coverage is 0%, so description must compensate. It effectively explains the 'text' parameter (one short line, casual, no formatting) but does not explicitly describe the 'space' parameter beyond its existence. This provides moderate added meaning.

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: 'Talk in the world like a real person' and specifies it outputs 'ONE short line' as a 'quick callout'. This distinguishes it from sibling tools which perform different actions like building, moving, or memory operations.

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 'DO NOT' instructions excluding reports, recaps, status updates, narration, and agent IDs. While it doesn't explicitly list when to use (it's obvious for speaking), the exclusions are clear and helpful.

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 the description adds behavioral context: probing is non-destructive, defaults to user's position and facing, and returns specific obstacle info. No contradictions; adds value 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?

Two sentences: first states the action and outputs, second provides parameter guidance and usage. Front-loaded with key information, no filler, every word earns its place.

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

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

Covers purpose, usage, parameters, and default behavior. With no output schema, the description implies return fields (ground height, solid/air, obstacle) but does not state the return structure explicitly. Adequate for the tool's 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?

The description explains the 'at' and 'yawDeg' parameters with format and defaults, compensating for low schema coverage (33%). However, the required 'space' parameter is not explained at all, leaving an important gap.

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 uses specific verb 'probe' with clear resource 'terrain' and explicitly lists what it returns: ground height, solid/air status, and nearest forward obstacle. This distinguishes it from sibling tools like 'look_around' or 'survey_site' by focusing on ground-level assessment.

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 'Use it to check "is this spot on the ground / buildable?" before building', providing clear when-to-use guidance. It also explains optional parameters and defaults. Lacks explicit exclusions or alternatives, but context is strong.

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?

Describes the embedding process (Cloudflare Workers AI, bge-small-en-v1.5, 384-dim), RPC call with cosine distance, and graceful fallback. Annotations already declare readOnlyHint=true, so no contradiction; description adds useful implementation details 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?

Two sentences front-load the core purpose and method. Every sentence adds value: first sentence defines operation and mechanism, second sentence gives usage context and fallback behavior. 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?

No output schema is provided, and the description only indirectly indicates return of 'rows' without specifying fields (e.g., content, score). For a retrieval tool, this leaves ambiguity about what the agent receives. However, for a search tool with low complexity, it is minimally adequate.

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 description must compensate. It mentions 'query' (text to embed) and 'K' (number of results, default 10) implicitly through 'Top-K' and 'asks for the K closest rows'. However, it does not explicitly explain constraints like maxLength or the min/max for k, which are in schema but lack 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?

Clearly states 'Top-K semantic memory retrieval' with specific verb and resource (search memories via semantic embedding). Distinguishes itself from siblings like recall_nearby_memories and recent_memory by specifying semantic similarity rather than spatial or temporal retrieval.

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 'Use to recall past actions/observations/reflections relevant to a current situation' and notes graceful fallback (empty list). Does not explicitly name alternative tools or when not to use, but context implies when semantic recall is appropriate.

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?

Discloses embedding via Cloudflare Workers AI, cosine distance retrieval, and threshold logic. Annotations already indicate readOnlyHint=true, so the description adds algorithmic context without 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?

Three sentences: purpose, mechanism, usage. Front-loaded and efficient, 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?

Covers purpose and algorithm, but missing return format (e.g., list of skill objects with distances) and error handling. Given no output schema, the description should at least mention what the tool returns.

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 must add parameter meaning. It explains 'query' as candidate goal text and 'k' as number of closest skills, but lacks format guidance or examples, leaving semantic gaps.

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 retrieves skills by description similarity using Voyager. It uses specific verbs like 'retrieval', 'embeds', and 'closest', and distinguishes from siblings like list_my_skills (listing all) and invoke_skill (execution).

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 explicit decision rule: invoke first match if distance < 0.25, else generate new actions. This guides when to use the tool's output, though it doesn't compare directly to alternatives like list_my_skills or invoke_skill.

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 discloses important behavioral traits: persistence across resets, auto-supersede of prior goal, auto-region creation condition (>=5 blocks), and return format. Annotations (readOnlyHint=false, openWorldHint=false) are consistent, and the description adds context beyond 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?

Four sentences, each adding essential information. No redundant text. Front-loaded with main purpose, then details. Efficient and well-structured.

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

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

The description covers behavior, return, and parameter guidance adequately for a 5-parameter tool with no output schema. It could mention what happens if <5 blocks, but the agent can infer from the condition. Overall complete.

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

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

The schema covers 80% of parameters with descriptions. The description adds value by linking optional parameters (target_blocks, footprint, height) to plan_build output and explaining that 'description' becomes the region name if auto-created. This clarifies usage 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 declares a build intention, with specifics like persisting across resets and auto-creating regions. It distinguishes from siblings like plan_build and complete_goal by specifying when to call it (once at start, before placing blocks).

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 to call it once before placing blocks and optionally pass plan_build output. However, it does not explicitly state when not to use it or list alternatives, though the context with sibling tools makes it clear.

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

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

Annotations indicate mutation (readOnlyHint false). Description adds behavior: bumps generation, appends audit row, and details on display_name timing. Provides caution about editing carefully, adding value 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?

Description is dense but well-structured: starts with purpose, then details per parameter, then side effects and usage advice. Slightly verbose but every 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?

No output schema, but description explains side effects (generation bump, audit row). Covers all parameters and usage nuances. Adequate for a mutation-focused tool.

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

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

Schema description coverage is low (20%). Description compensates by explaining the purpose of each parameter: soul_md (who you are), style_md (how you speak/act), display_name (in-world name with timing caveat), drives (curiosity/sociality/aesthetic/mastery/solitude). This adds significant meaning.

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?

Title 'Author/update your own soul' and description clearly state the tool writes one's own identity. It distinguishes from siblings like get_soul and cognitive_boot by emphasizing it's for editing self, not reading.

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

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

Advises to read get_soul/cognitive_boot first and to edit deliberately, implying usage after initial check. Explains when display_name takes effect relative to enter_space. Lacks explicit when-not-to-use but context is clear.

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

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

Annotations show readOnlyHint=false and openWorldHint=false. The description adds atomicity, inheritance of embedding, and the effect on the old row. No contradictions. Could mention that it modifies existing data, but overall good.

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, each adding value. Front-loaded with the core action and purpose. No filler or repetition.

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

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

Provides a concrete example and explains atomicity, inheritance, and use case. No output schema, but the action is straightforward. Slightly lacking on param details, but otherwise complete.

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

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

Schema has 4 params with 0% description coverage. The description explains the overall operation but does not detail each parameter's meaning, format, or constraints. new_importance default is implied but not stated. Validates baseline 3.

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

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

The description uses specific verbs and resources: 'Atomically INSERT a higher-importance summary AND mark an older memory row's superseded_by_id'. It includes a concrete use case for compacting noisy chains, clearly distinguishing it from sibling tools like append_memory.

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?

States when to use: 'during reflection to compact noisy chains'. Provides a concrete example. Does not explicitly mention when not to use or alternatives, but the context is clear enough.

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 discloses that the tool is a read-only survey (consistent with readOnlyHint annotation) and returns comprehensive site data. It does not contradict annotations. However, it could mention that it does not modify the world, but the annotation already covers that.

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 clear and front-loaded with purpose, but it is somewhat long with workflow details. It could be slightly more concise without losing essential 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?

Given no output schema, the description fully enumerates the expected return fields (me, ground, neighbors, etc.) and provides a workflow sequence. It covers all necessary context for an agent to invoke the tool appropriately.

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

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

The description explains the 'size' parameter's role in reserving a clear footprint and notes it can be omitted. However, the 'space' parameter is not explained (schema also lacks description). The description adds context beyond the schema for some parameters but not all.

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 surveys a build site, distinguishes it from slower alternatives (look_around + list_regions + find_clear_region + scan), and lists the returned data (me, ground, neighbors, etc.).

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 tells when to use the tool ('Survey the ground before you build') and contrasts with slower, heavier alternatives. It also provides a step-by-step workflow (1 survey, 2 decide form/materials, 3 build), guiding the agent on how to use the tool in sequence.

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 idempotent=true and not read-only. Description adds value by specifying the exact field updated (last_touched_at_ms) and the behavioral effect on the sweeper. No contradiction with annotations; consistent with mutation and safe repetition.

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 sentence front-loads the action, purpose, side effect, and rationale. No wasted words; every part is informative.

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

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

For a simple one-parameter heartbeat tool with no output schema and good annotations, the description covers purpose, effect, and why it exists. No gaps.

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

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

Schema coverage is 0% (no parameter description in schema). Description does not define the parameter 'id', but given the tool's purpose, it is obviously the commitment ID. This is minimally adequate but relies on inference.

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 the action: 'Mark progress on a commitment without changing its status' and specifies the exact effect (refreshes last_touched_at_ms). It distinguishes from siblings like update_commitment (which changes status) and commitment_sweep (which cleans up abandoned ones).

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 provides clear context: used for heartbeat/active progress tracking, explicitly says 'without changing its status' (exclusion), and explains why (sweeper distinguishes progressing from abandoned). However, it does not explicitly name alternative tools for status changes, though context implies update_commitment.

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 destructiveHint=true. The description adds crucial behavioral details: it requires a token for destructive edits, otherwise cells return denial reasons. It also notes that only ADD brushes are reversed (remove operations are skipped). 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 a single paragraph but each sentence earns its place: function, constraints, scope, auth requirement, alternative, and return values. It is front-loaded with the key action and well-structured 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?

Given the tool's complexity (2 parameters, no output schema, no nested objects), the description covers all necessary aspects: return format, error scenarios, prerequisite token, and the alternative approach. It feels complete and self-sufficient for an agent to invoke correctly.

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

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

Schema description coverage is 0%. The description adds meaning for the 'n' parameter (default 1, max 20) but does not describe the 'space' parameter, which is required. This leaves a gap; the agent may need to infer that 'space' refers to the current space. Partial compensation for 'n' but incomplete.

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 removes the last N blocks placed by the user, specifying the source (agent_brush_log) and operation (op:'remove'). The title 'Undo your last placements' aligns well. It distinguishes from sibling 'build' by positioning this as a recovery tool after a bad build.

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 provides when to use this tool vs. alternatives: 'The cleaner fix for a bad build is build({dry_run:true}) BEFORE committing; undo_last_brushes is the recovery when you already placed something wrong.' It also clarifies that it only reverses ADDs and discusses token requirements.

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 explains that this tool modifies commitment status and details the meaning of each status. It also mentions the sweeper's automatic behavior, providing context beyond the annotations (which only indicate readOnlyHint=false and destructiveHint=false). 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, each earning its place. The first sentence states the core purpose. The second provides specific usage guidelines for each status. 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?

The tool has 2 required parameters and no output schema. The description covers the status parameter well and mentions the sweeper for automatic expiration. It does not explicitly state the return value, but given the simplicity of the tool, the description is sufficiently complete 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 description coverage is 0%, so the description must compensate. It explains the status parameter's enum values thoroughly (fulfilled, failed, expired) with usage guidance. The id parameter is not described, but as a required identifier it is self-explanatory. The description adds meaning beyond the schema.

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

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

The description starts with 'Status-update an active commitment', clearly stating the verb (update) and resource (commitment). It then lists the three possible status values and their meanings, distinguishing it from sibling tools like commitment_sweep and extend_commitment.

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 on when to use each status: 'fulfilled' for met promises, 'failed' for abandoned, 'expired' for deadlines passed. It also notes that the sweeper handles expiration automatically but the brain can pre-empt, clearly stating when to use an alternative tool.

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