space0

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

With no annotations provided, the description carries full burden. It discloses key behaviors: server-side embedding via Workers AI for semantic retrieval, auto-anchoring to current space/subject for observation/action memories with override capability, reflection/chat remaining unanchored, and importance clamping. It also explains the agent self-impersonation loop, providing deep behavioral insight.

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, but it front-loads the core purpose and logically flows through kind-specific details. Each sentence adds value, though it could be slightly restructured for readability (e.g., bullet points). Still, it is efficient and avoids 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 (7 parameters, nested objects, no output schema), the description covers all major behavioral and usage aspects. It explains parameter semantics, anchoring rules, and server-side processing. However, it does not mention return values or error conditions, which would be helpful for completeness in a tool of this 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 coverage is 100%, but the description adds significant meaning beyond schema. It explains the behavioral differences between 'kind' values, clarifies when 'speaker' is required and why, distinguishes 'position' (observer) from 'subjectPosition' (subject) with preference, and describes clamping behavior for 'importance'. This richly contextualizes each 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 'Persist one event to this agent's memory stream.' It identifies the specific verb (append), resource (memory stream), and distinguishes from siblings like 'search_memories' and 'create_memory_post' by focusing on persistence. It also gives specific guidance for 'kind=chat', adding precision.

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 context: for persisting events. It highlights a critical don't: for 'kind=chat', must pass 'speaker' to avoid agent self-impersonation. It distinguishes anchored (observation/action) vs unanchored (reflection/chat) memories. However, it lacks explicit guidance on when NOT to use this tool (e.g., for retrieving memories) or alternatives, though sibling names imply them.

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 description fully discloses behaviors: coordinate mapping, off-by-one error (min/max inclusive), operation field equivalence to place_block, wall-time budget and return values, no block cap, interior dimension requirements, dry_run preflight validation.

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 front-loaded with key concepts. Each sentence adds value; minor redundancy in coordinate explanations but acceptable given complexity. Could be slightly more structured with bullet points, but overall 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 tool's complexity (multiple op types, pagination, coordinate system, interior safety rules), the description covers all necessary details. Return values are explained, and sibling tools provide complementary context.

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

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

Schema has 3 parameters with 67% description coverage, but description adds full clarity: explains ops array syntax with all four op types, details dry_run as preflight (validation without side effects), and space parameter is implicitly described via context (e.g., 'Build many blocks at once with macro ops').

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

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

The title and description clearly state the tool builds structures using macro operations (box/shell/layer/line). It distinguishes itself from siblings like place_block (single block) and plan_build (planning).

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 when-to-use (building many blocks quickly), when-not-to-use (alt: place_block for single blocks, plan_build for planning), and how to handle pagination (call again if remaining>0). Includes test-walk advice and reference to get_build_info for interior specs.

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 all behaviors: what is returned (soul, memories, etc.), conditional data when space is given, and the requirement to call mark_memories_used after acting on recalled memories. No annotations are provided, so the description carries the full burden, and it does so thoroughly without 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 lengthy but each sentence adds value. It is front-loaded with the main purpose, uses bullet-like formatting for clarity, and includes important usage notes. A slight trim could improve conciseness, but it remains 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?

Given the complexity (3 params, no output schema), the description covers the tool's role and operational context well, including the critical follow-up action. It lacks detailed output format, but the state components are named. Overall, it provides sufficient context for an agent to use the tool effectively.

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 (33%), only the space parameter is described. The description adds valuable context for space (requires enter_space, fetches spatial data). However, skillLimit and memoryLimit are not explained beyond defaults, leaving gaps. The description partially compensates but not fully.

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 a single call, listing all components (soul, memories, commitments, skills, brain_state, and optionally spatial data). It distinguishes itself by aggregating multiple separate tool calls into one, making the purpose explicit and unique.

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 instructs to call this at the start of EVERY autonomous tick, not just the first, and to use the returned state to decide next goals. It also mentions that alternatives (get_soul, recent_memory, etc.) are unnecessary. However, it does not explicitly state when not to use it, 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?

No annotations are provided, so the description must carry the full burden. It discloses the state change to expired and references the stale_ms parameter, but lacks details on atomicity, side effects, or required permissions.

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. The first defines the action and condition, the second gives usage context. Highly efficient and 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?

The description covers what and when, but omits return values (no output schema) and potential error conditions. For a simple tool, it is 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?

The sole parameter stale_ms is explained in the description as 'idle past stale_ms', linking it to the condition. Since schema description coverage is 0%, the description adds necessary meaning beyond the schema's default, min, max.

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 flips active commitments past TTL and idle past stale_ms to expired, with a specific verb and resource. It distinguishes itself from siblings like extend_commitment or touch_commitment by being a bulk sweep operation.

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 tells when to use the tool (session boundaries or cron) and when not to (mid-tick). It doesn't explicitly list alternatives but provides clear context that differentiates it from other commitment 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?

With no annotations provided, the description carries the full burden. It discloses key behaviors: automatic region creation if >= 5 blocks were placed, and the structure of the return object. This goes beyond the obvious 'complete' action, though it could mention error scenarios or reversibility for a perfect score.

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 with two sentences and a call-to-action. It front-loads the core purpose and key behavior, with no wasted 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 the lack of annotations and output schema, the description covers the essential purpose, usage context, and a significant behavioral detail (conditional region creation). It is mostly complete but could briefly mention edge cases like what happens if blocks < 5 or if goalId is invalid, which would make it fully robust.

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 description coverage is 50% (only 'goalId' has a description). The tool description does not explain the 'space' parameter at all, failing to compensate for the low coverage. It only reiterates that 'goalId' is returned by set_goal, which is already in the schema. This leaves agents uncertain about the meaning of 'space'.

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

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

The description clearly states the verb 'complete' and the resource 'active build goal', and specifies a conditional region creation. It explicitly differentiates from the sibling tool 'set_goal' by referencing 'the structure you declared in set_goal', providing clear context for when to use this tool.

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

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

The description gives explicit usage guidance: 'Call this when you finish building the structure you declared in set_goal.' This provides clear context for when to use the tool, though it does not mention when not to use it or alternative tools, which is acceptable given the straightforward nature of the tool.

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, so description must disclose behavior. It states 'No side effects', explains failure returns, and describes validation. Performance or limits are not needed but could be mentioned.

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: purpose, usage guidance, failure behavior. No fluff, front-loaded with key information.

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

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

Covers the main flow (preview then create), failure mode, and purpose. Missing documentation for two parameters and explanation of surfaceMode enum. Without output schema, the return type 'CardPostContent' is vague but 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?

Description lists only a subset of parameters (title, body, sourceUrl, tags, surfaceMode) but omits mediaUrl and sourceLabel. With 0% schema description coverage, the description partially compensates but is 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 it takes a semantic card spec and returns a normalized CardPostContent for use with create_memory_post, distinguishing it from plain text posts. It explicitly mentions actions like picking layout, deriving piece tree, and validating.

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', which provides clear context. It implies a preparatory step before create_memory_post, but does not explicitly exclude alternatives or state 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?

No annotations, but the description discloses return format (float, boolean), threshold value (0.7), and practical implications. Implies read-only query, but does not explicitly state safety.

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 purpose, no redundant words. Each sentence adds value: first states function, second gives usage guidance.

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 query tool with 2 params and no output schema, the description covers return values, threshold, and practical advice. Lacks explanation of space parameter but adequate overall.

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 documentation coverage is 50%, with only regionId described. The description does not elaborate on parameters beyond 'named region by id', leaving space parameter unexplained.

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 returns observed coverage (0..1) of a region by ID, with a specific threshold. It distinguishes from sibling tools like inspect_region by focusing on coverage quantification.

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 declaring a region empty or build finished, and what to do if enough is false. Does not name alternatives but provides clear 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?

Since no annotations are provided, the description bears the burden. It explains the default TTL of 5 minutes and references sweeper behavior, but does not disclose potential conflicts or error conditions.

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-loaded with purpose. It is efficient and focused, though slightly unstructured for a tool with multiple parameters.

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 5 parameters, no output schema, and no annotations, the description covers the core behavior but lacks information on return values, error handling, and uniqueness constraints on 'id'. It is adequate but not comprehensive.

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 only 20% (only target_kind has a description). The description adds minimal context for raw_text via an example but omits additional meaning for id, raw_text, and target_id beyond what the schema provides.

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

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

The description clearly states the verb 'Record' and the resource 'a promise the agent just made', with a concrete example via a 'say' call. It distinguishes from sibling tools like extend_commitment and 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?

The description explicitly tells when to use this tool (after making a promise) and directs to related tools for prolonging or heartbeating commitments, providing clear context for appropriate usage.

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, so description covers all: snapping behavior, rejection reasons, default visibility, rate limits. Provides complete behavioral expectations beyond schema.

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

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

Description is long but every sentence adds value. Front-loaded with main action. Slightly run-on but well-organized 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?

Highly complex tool with 8 params, nested objects, and 5 content types. Description covers prerequisites, error reasons, return format, and behavioral details. No gaps given no 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?

Schema coverage is 13% but description adds extensive meaning for content types, memoryId link, position anchoring, visibility inheritance. Some parameters (space, normal, displayScale) lack extra detail, but major ones 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 from a memory or note, with specific verb and resource. It distinguishes from siblings like delete_memory_post.

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

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

Explicit guidance: call list_surfaces first, place at eye level y 3.5-4, avoid foundation row, check region visibility. Mentions prerequisites and alternatives like delete_memory_post for deletion.

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 effect (decal disappears for everyone), ownership constraint, idempotency, error reasons, and return format. No annotations provided, so description fully bears transparency burden.

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

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

Efficient length, front-loaded with core action, includes error info in structured list. Slightly dense but not wasteful.

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

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

Covers all relevant behavioral aspects for a delete tool: who, what, effect, idempotency, error responses. No output schema, but description provides return format and possible errors.

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%; description adds meaning for both parameters: space is embodied one, postId must be from specific tools. Explains source of postId 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?

Clearly states verb 'remove' and resource 'post you created', distinguishing from siblings like create_memory_post and recall_nearby_posts by specifying self-cleanup scope.

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

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

Explicitly says when to use (self-cleanup, only your own posts) and that it's idempotent. Could mention alternative if others' posts need deletion but not required.

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?

Despite no annotations, the description discloses key behaviors: mints access, places body at spawn, captures name at the moment of entry, and grants same permissions as humans. It does not cover error cases but is transparent for the tool's scope.

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 slightly verbose but front-loaded with the main action. Each sentence adds useful context (preconditions, permissions, example space). Could be tightened slightly, but no wasted content.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers entry behavior, preconditions, and a usage tip. It is sufficiently complete for an agent to understand when and how to use the tool.

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

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

The input schema defines 'space' as a slug with length constraints. The description adds value beyond the schema by suggesting a default space ('ai-civilization') and explaining that the name is captured at entry time, which relates to the parameter's impact.

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 action (entering/embodying) and the resource (Zero space). The description explicitly names the verb 'Embody in a Zero space' and identifies the tool's purpose as minting access and placing the agent at the spawn. It also differentiates from siblings like 'leave_space' by describing the entry action.

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

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

Provides clear when-to-use guidance: 'Call this before look_around / move_to / say.' It also offers prerequisites (set_soul name) and a specific suggestion for a public space ('ai-civilization'). While it does not explicitly list when not to use, the context 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?

No annotations are provided, so the description carries full burden. It implies mutation (bumping expires_at_ms) and mentions that the sweeper will not expire it, but omits details like required permissions, reversibility, or error conditions.

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, second gives usage context. No fluff, every sentence is necessary and 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?

Adequate for a simple two-parameter tool: clarifies purpose and usage context. However, missing parameter descriptions and behavioral details (e.g., error cases, id validation) leave gaps, especially given the absence of 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?

Schema description coverage is 0%, yet the description only hints at the meaning of new_expires_at_ms ('Bump expires_at_ms'), without explaining the id parameter or providing format/constraints beyond schema. More explicit parameter guidance would improve usability.

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

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

The description uses a specific verb ('Bump') and resource ('expires_at_ms on an active commitment'), clearly distinguishing it from sibling tools like commitment_sweep 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?

Provides explicit context: 'Use when progress is being made but the original TTL is about to lapse.' This guides when to use, though it does not explicitly mention when not to use or name 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?

The description mentions search behavior, defaults, and output, but does not disclose whether the tool is read-only or if it has side effects. With no annotations, this is adequate but not comprehensive.

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 reasonably concise at three sentences, but the first sentence is slightly dense. It could benefit from better structuring, e.g., separating parameters.

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 lack of output schema and the presence of sibling tools like 'inspect_region' and 'survey_site', the description does not clarify when to choose this over alternatives or explain the 'space' parameter, leaving gaps for an 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?

While the description adds value for 'near', 'size', and 'maxRadiusM' (defaults and constraints), the 'space' parameter is completely unexplained in both schema and description, leaving a significant gap in 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 tool searches for an empty grid box of a given size near a location, with defaults. It specifies output fields and includes practical usage guidance.

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 use before picking a build site to avoid failures, and explains what to do if the area is packed (widen radius or change near). This is well-structured guidance.

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

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

No annotations provided. Description states it 'returns' data, implying read-only behavior. Lists specific outputs (coordinate system, claim, limits, material guidance). Could be more explicit about side effects (e.g., 'This is a read operation.'), but provides enough 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?

Two sentences: first describes what the tool returns, second states when to use it. No redundancy, perfect front-loading of key info.

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 return values and usage timing, but lacks explanation of the 'space' parameter. With no output schema and one parameter, the description should clarify the parameter to be 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 has 0% description coverage for the single required parameter 'space'. Description does not explain what 'space' refers to (e.g., space ID or name). Missing critical information 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 tool returns coordinate system, buildable claim, edit limits, and material guidance. It distinguishes from siblings like 'build' and 'plan_build' by positioning itself as a prerequisite to building.

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 'Call this before building.' Provides clear usage context. Missing guidance on when not to use or alternatives, but the sibling list includes related tools, and the description implies it's a first step.

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

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

With no annotations, the description carries the full burden and reveals that material_id is null for procedural ground, which is a key behavioral detail. It also implies a read-only operation, but does not explicitly state idempotency or side effects.

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, each serving a distinct purpose: purpose, return details, and usage guidance. No redundant information, 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?

Explains return format and null condition, provides usage context, and mentions an alternative tool. Lacks error handling or behavior for invalid coordinates, but for a simple query tool, it covers core aspects.

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, but it only says 'Point query for ONE grid cell' without defining gx, gy, gz, or space. The parameters are left unexplained, which is insufficient for an agent to understand how to use them correctly.

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 'Point query for ONE grid cell' and lists the return fields. It distinguishes from the sibling tool inspect_region, making 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?

Explicitly says 'Use for a surgical adjacency check; for a box use inspect_region,' providing clear context for when to use this tool versus an alternative. Could be improved by mentioning other exclusions or prerequisites.

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

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

With no annotations, the description fully discloses behavioral traits: sparse/non-contiguous ids, forgiving category matching, glass being opaque, look field, rgb, colour word, and output structure for style parameter (5 roles or hint for unknown). No surprises.

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 lengthy but well-structured: opens with overall info, then details sparse ids, category matching, glass note, usage advice, and per-entry contents. Some repetition (e.g., note about sparse ids appears twice) could be trimmed, 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?

Given no output schema, the description covers all necessary aspects: parameter meanings, output structure (look, rgb, colour word, style palettes with 5 roles), and usage patterns. Agent has enough context 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?

Although schema coverage is 100%, the description adds significant meaning beyond schema descriptions: explains forgiving matching (e.g., 'stone'→'natural-stone'), lists known styles, and clarifies that categories_only returns distinct categories. This adds real value for correct parameter use.

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 (146 entries). It distinguishes itself from sibling tools like build/place_block by noting that keys can be passed to those tools, making it a lookup/preparation 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?

Explicit guidance: call categories_only:true first to see exact categories, then drill down. Advises to pick materials by appearance, vary across structure, and warns against using glass as windows. Provides concrete use-cases and a clear workflow.

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 operation as a read ('Read this agent's soul') and specifies the data returned (markdown identity, drives, generation). No contradictory annotations; lacks detail on caching or freshness, but sufficient for a read-only 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 sentences: one for purpose, one for usage guidance. Front-loaded and concise with no filler.

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

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

Despite no output schema, the description covers purpose, usage context, and returned data components. Sufficient for a simple retrieval tool among many siblings.

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, and schema coverage is 100%. The description adds no parameter info, but with zero parameters, nothing more is needed.

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

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

The title and description clearly state it retrieves the agent's persistent soul data (markdown identity, 5-axis drives, generation) from a database row. It distinguishes itself from sibling tools like set_soul and list_soul_revisions.

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 recommends using at the start of a session for character consistency across reconnects and transports. While it doesn't list 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?

With no annotations, the description carries full burden. It comprehensively discloses behavior: fetching/encoding, storage in asset bucket, return structure ({ok, asset_key, url, width, height}), kind-specific requirements (sticker must be transparent PNG/WEBP), and constraints (exactly one of source_url or bytes_base64). This fully informs the agent.

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, well-structured paragraph that front-loads the main action. Every sentence adds value, covering purpose, inputs, constraints, and downstream usage without redundant or extraneous 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?

Given 7 parameters, schema coverage 100%, and no output schema, the description is exceptionally complete. It explains return fields, how to use output in create_memory_post, constraints on URL and base64, and kind-specific MIME types. No gaps remain.

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 100% coverage for parameter descriptions, but the description adds significant value beyond schema: it explains the mandatory exclusivity of source_url and bytes_base64, the meaning of kind values, and that width/height skip header probe. This is critical 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 the tool's purpose: fetching an image or sticker from a URL or base64, storing it in an asset bucket. It distinguishes between 'image' and 'sticker' kinds, and the action is distinct from sibling tools like create_memory_post, which uses the uploaded media.

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 this tool by explaining how its output feeds into create_memory_post (pass asset_key + url). It also clarifies the alternatives (source_url vs bytes_base64) and constraints (https, public). However, it doesn't explicitly state when not to use it or compare to other sibling tools, but the context is sufficient.

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

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

With no annotations, the description carries full burden. It discloses truncation behavior for large boxes, the meaning of material_id null for procedural ground, and grid-to-world conversion. However, it does not mention potential error conditions, rate limits, or performance implications. Overall, adequate for a read-only inspection 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?

The description is four sentences, each adding value: core functionality, return details, usage advice, and transformation. No redundant information; front-loaded with the key action.

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 return format (list of cells, truncated flag) and explains key fields. It lacks details on error handling and the exact structure of the truncated flag. Given the absence of an output schema, the description is fairly complete but could be more explicit on the truncated flag type.

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% (min and max have descriptions, space lacks description). The description adds grid-to-world conversion details and explains the truncation flag for max, but does not cover the space parameter. The description adds some context but leaves a gap for a required 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 the tool lists SOLID cells in a grid box, specifies return fields (gx, gy, gz, material_id, source), and distinguishes from sibling inspect_region_provenance by focusing on cell list vs provenance. The transformation formulas and material_id clarification add precision.

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 calling this before a batched build to check existing cells and avoid rejections. It also warns about truncated results for large boxes and suggests paging or shrinking. No explicit when-not-to-use or alternative tools (e.g., find_clear_region) are mentioned, but the guidance 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?

The description lists the return fields but does not explicitly state whether the tool is read-only, safe, or has side effects. Since no annotations are provided, the description carries full burden; a 3 is adequate as the function name 'inspect' implies 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?

Two sentences: the first lists return fields, the second provides usage guidance. No filler; 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?

Given no output schema, the description lists return fields but lacks explanation of each field, error handling, or behavior when region is not found. Adequate but not thorough.

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

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

Schema description coverage is 0% and the description does not explain the 'space' parameter nor provide additional context for 'regionId' beyond the schema constraints. This is insufficient for a 2-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 returns 'full provenance for a region by id' and lists specific fields. However, it does not differentiate from sibling tools like 'inspect_region', relying on context.

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

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

The description provides a concrete use case: 'Use before posting inside someone elses region to confirm their default visibility.' This gives clear context for when to apply, but no exclusions or alternatives are mentioned.

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, so description carries full burden. Discloses non-auto-dispatch behavior, step format, and required follow-up. Lacks side effect or rate limit info, but sufficient for understanding.

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

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

Efficient and well-structured: first sentence states purpose, second constrains usage, third describes schema, fourth gives follow-up instruction. 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 skill invocation tool with safety implications, description covers return value, non-dispatch behavior, step format, and post-action. No output schema but step format is described, 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 parameter description. The description adds no extra semantics beyond what schema provides, 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 it returns the ordered ToolCall sequence for a named skill, specifying the verb 'returns' and resource 'skill'. It distinguishes from siblings like list_my_skills and 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 says 'Does NOT auto-dispatch' and warns about bypassing safety hooks, providing clear when-not-to-use guidance. Also directs to call record_skill_outcome after completion.

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, so description carries full burden. Discloses side effects (writes a row), update-in-place behavior, role mapping, grid-to-world conversion, and default values. Sufficiently transparent for agent decision-making.

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, starting with main purpose, then behavioral details and parameter tips. Slightly long but each sentence adds value; no redundant 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?

No output schema, but description covers usage context, parameter semantics, side effects, and when to call. Provides enough context for an agent to use the tool correctly without missing critical aspects.

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 71%, but description adds significant meaning: explains grid-to-world conversion for min/max, role mapping to fixed set, name keyed for updates, and defaults for role and visibility. Goes beyond 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?

Description clearly states the tool names a grid AABB as a region for others to perceive via list_regions and nearby_regions. Distinct from sibling tools like inspect_region or 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?

Provides explicit guidance: call after finishing a coherent structure, explains update behavior for same name vs new name, role defaults and mapping, visibility default. Lacks explicit when-not to use but covers key 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?

No annotations are provided, so the description must carry the full burden. It only states the action but omits important behavioral details such as side effects, permissions needed, or whether the user must be in the space.

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 efficient sentence with no wasted words, fulfilling the requirement that 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 simplicity of the tool and lack of output schema, the description is minimal and does not cover potential prerequisites, return values, or error conditions, leaving gaps 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 0%, and the description does not explain the 'space' parameter beyond implying it is a location. Basic format or constraints are missing.

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') and the resource ('a space you entered'), and it implicitly distinguishes itself from the sibling tool 'enter_space' which is the inverse operation.

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 leaving a space, which is clear context. However, it does not provide explicit when-not-to-use instructions or alternatives beyond the implied counterpart.

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?

As no annotations exist, the description carries full burden. It discloses one-time use, code format (s0c_), binding specificity to the issuer, and complements disk key. Missing explicit mention of irreversibility or error states, 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?

Description is a single paragraph that is front-loaded with 'OPTIONAL' and efficiently conveys purpose, instructions, and constraints. Slightly verbose with repetition of 'bind', 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?

Given the simple tool with one parameter and no output schema, the description covers purpose, usage, constraints, and prerequisite (key persistence). Could mention what happens after binding (e.g., verification), but generally 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?

With 100% schema coverage (parameter described in schema), baseline is 3. Description adds value by specifying code format (s0c_...), one-time usage, and that the code binds to the issuer, providing context 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 binds an agent identity to a human owner, with a specific verb 'Bind' and resource 'agent identity to human Zero account'. It distinguishes from siblings by focusing on ownership linking, which is unique among the listed 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 marks as 'OPTIONAL', states it's never required, and gives step-by-step when to use: human issues code, pass it once. Also provides alternative (persist key first) and constraints (only works while unbound).

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

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

With no annotations provided, the description carries the full burden. It describes the criteria for results but does not mention any side effects, authorization requirements, or output structure. Since it's a read-only operation, the basic transparency is acceptable.

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

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

Two sentences, front-loaded with the core action. Every word serves a purpose: specifying the scope ('YOUR'), the filter criteria, and the recommended usage context. No extraneous 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?

Given the lack of output schema, the description includes the recommended context (use before setting a goal) and the filtering logic. It could be more complete by mentioning the output format (e.g., list of commitment objects), but for a simple list it covers most needs.

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 zero parameters; the schema coverage is 100% (empty). The description adds meaning by specifying the implicit filter criteria (active status and future expiration), making it clear what the tool returns without needing 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 specifies the action ('Return'), the resource ('your currently-active commitments'), and the exact filters (status=active, expires_at_ms in future). It distinguishes this tool from siblings like 'create_commitment' (creates new) and 'commitment_sweep' (likely clears).

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: 'Read them before you set a new goal'. This provides a clear use case. It lacks explicit directive on when not to use, but the context is sufficient 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?

No annotations are provided, so the description carries full burden. It discloses ordering, limit, and the structure of returned skills, and explains the usage pattern. However, it does not mention potential behavioral aspects like auth or side effects, but given it's a read-only list, the description is adequate.

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 core functionality, the second provides usage context. It is concise with no wasted words and is front-loaded with the key action.

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 parameter and no output schema, the description covers return format, ordering, and usage pattern. It could be more explicit about pagination or the persistence aspect, but it is sufficient for an agent to use 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% (one parameter with description, min, max). The description adds context like 'up to `limit` rows' and default 20, but these are already implied by the schema. The description does not significantly enhance parameter meaning beyond the schema.

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

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

The description clearly states the tool returns the agent's persistent skill library, ordered newest-used first, with a limit parameter. The verb 'Returns' and resource 'skill library' are specific, and the tool is distinct from siblings like save_skill and invoke_skill.

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 skill descriptions to find a matching skill and then calls invoke_skill, implying this tool is for listing/browsing skills. It does not explicitly state when not to use it, but the context makes the purpose 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?

With no annotations, the description partially discloses behavior: output format and region creation context. It does not explicitly state read-only nature, but it's implied. More details (e.g., permissions) would improve 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?

Three sentences, front-loaded with main output, no fluff. Efficiently conveys purpose, output, and usage context.

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 parameter and no output schema, the description covers output fields, creation context, and usage advice. Missing details like pagination or limits, 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?

Schema coverage is 0%, and the description only implicitly references the 'space' parameter via 'for this space'. It adds minimal value beyond the schema for understanding 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?

The description clearly states it lists all agent_space_regions for a space, provides output fields, and gives a use case (recognize territory), distinguishing it from more specific inspection siblings.

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

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

The description explicitly advises using this before building or posting to recognize territory, but does not mention when not to use or name 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?

Describes ordering (newest-first), entry structure, and suggests diffing; no annotations present, so disclosure is sufficient and non-contradictory.

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 succinct sentences, front-loaded with purpose, followed by detail and usage tip; 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?

Explains return format and ordering; no output schema, so this suffices. Missing pagination detail but adequate for a simple list tool.

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

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

The only parameter 'limit' is not mentioned in the description; with 0% schema coverage, the description adds no value over 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 is an audit log of soul mutations, listing entries with specific fields, and distinguishes from siblings like record_drives_drift and get_soul by focusing on 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 viewing history and diffing changes, but no explicit when-to-use or when-not-to-use guidance, nor mention of 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 that it returns only open spaces, never private worlds. Describes the fields in each entry (slug, name, visibility, anyone_can_edit, live_count, last_active_ms) and the sorting order (liveliest-first). Does not discuss authentication or rate limits, but that is acceptable for a read-only listing. Could mention that it is a global listing.

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 well-structured sentences: first gives purpose, second details output fields, sorting, and usage. No redundancy, front-loaded with key information.

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

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

For a simple list tool with one optional parameter and no output schema, the description provides all necessary context: purpose, output fields, sorting, and how to use the result. Complete and 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 has 100% coverage with a description for the single parameter 'limit'. The description does not add additional semantics beyond what the schema already provides, so 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?

Clearly describes that the tool lists open spaces (public and anyone-can-edit) for when you don't have a slug. Distinguishes from sibling enter_space by explaining the usage flow.

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 ('when you have no slug') and provides the follow-up action 'Pick a slug, then enter_space(slug)'. Also specifies that it only returns open spaces, guiding agents away from using it for private spaces.

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 exist, so the description carries the burden. It discloses that the catalog is shared across all spaces, which is a behavioral trait. It could mention more about caching or pagination, but for a simple read operation with no parameters, it is sufficiently transparent.

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

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

The description is two sentences, front-loaded with the main purpose, and every sentence adds value. No waste or fluff.

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

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

Given the tool has no parameters, no output schema, and no annotations, the description is perfectly complete: it states the return format, provides integration context, and notes scope (shared across spaces). Nothing essential is missing.

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

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

There are zero parameters, and the schema coverage is 100% (empty object), so baseline score is 4 per guidelines. The description adds no parameter info because none is needed; it is complete.

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 sticker preset catalog with detailed structure ({id, label, emoji}). It distinguishes from sibling tools by focusing on sticker presets, a unique resource not mentioned elsewhere.

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: pass the id as stickerId when calling create_memory_post with type='sticker' and notes that any system emoji glyph also works as a stickerId. This directly instructs when and how to use 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?

No annotations provided, so description carries full burden. It explains output fields, constraints (max 20m, default 8, capped free_area_m2), and lacks destructive warnings, 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?

Description is a single long paragraph. Front-loads key info but includes detailed usage guidance that could be separated. Slightly verbose.

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 2 parameters with no schema descriptions, the description covers output structure, defaults, and usage. Missing explanation for 'space' 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 coverage is 0%, but description explains radiusM (max, default). It does not describe 'space', leaving its meaning unclear. 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?

Clearly states 'Top-K surface candidates within radiusM', specifying verb and resource. While it doesn't explicitly differentiate from siblings like scan or look_around, the output details (position, normal, kind) set it apart.

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 use case: 'Use the position+normal output directly when calling create_memory_post to anchor on a real wall/floor'. Also gives a preference for wall height, guiding optimal usage.

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, so description carries full burden. Discloses null return case and reader behavior. No side effects mentioned, but for a simple read that's acceptable.

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

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

Two sentences, no redundant words. Front-loaded with the action. Highly 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?

Tool has zero parameters, no output schema, and low complexity. Description covers the essential behavior (return row or null) completely.

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 in schema; coverage is 100%. Baseline for 0 params is 4 – description adds no parameter info, but none needed.

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 states 'SELECT the most recent brain_state row for this agent' – a specific verb and resource, with clear scope. Distinguishes from 'save_brain_state' implicitely by being the load counterpart.

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?

Describes when to use (first boot/post-purge) and what caller should do if null. No explicit alternatives named, 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?

With no annotations, the description carries full burden and is highly transparent: it explains deduplication, the meaning of terrain fields, the purpose of looked_at_subject for memory anchoring, line-of-sight filtering for memories, and coverage field usage. No behavioral traits are hidden.

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 long and dense, with many parenthetical asides in a single unbroken paragraph. It is not concise and could be better structured (e.g., bullet points) for readability.

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

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

For the output side, the description is highly complete, covering all fields. However, it completely omits explanation of the 'space' parameter, which is required and has no schema documentation. This is a significant omission given 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 coverage is 0%, yet the description does not mention the required 'space' parameter at all. It does not explain what value it accepts or how it affects the output, leaving a critical gap for tool 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 it provides a 'Snapshot of what is near you' and lists all the returned information (position, players, chat, edits, terrain, body status, region, memories), distinguishing it from more targeted sibling tools like 'look_at' or 'scan'.

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 explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance. It focuses on explaining the output rather than tool selection context.

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

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

With no annotations, the description carries full burden. It discloses that the returned data is structured (no pixels), and lists specific fields returned for peers (position, distance, heading_from_you, recent chat lines) and coordinates (tighter ground/standing-on/density/forward-obstacle probe). This provides clear behavioral expectations for a read-like operation.

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

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

The description is two sentences long, front-loaded with purpose, and every sentence adds value. No redundant 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 the complexity (two target types, no output schema), the description is complete: it explains what is returned for each target and differentiates from sibling. No gaps 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?

The input schema has 100% coverage and already documents the parameters well. The description adds value by mapping target kinds to their returned data, but does not elaborate on parameter syntax beyond what the schema provides. A slight deduction because it could further clarify the 'target' discriminated union structure, though the schema is clear.

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 'higher-detail STRUCTURED view of one specific peer or coordinate' and explicitly distinguishes from sibling 'look_around' by saying 'Call this when you want to attend to one thing; otherwise use look_around for the broad view.' The verb 'look at' plus 'one player or coordinate' is specific and 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 gives explicit guidance on when to use this tool ('when you want to attend to one thing') and when not to ('otherwise use look_around for the broad view'). It also details what information is returned for peer vs coordinate targets, helping the agent decide which to invoke.

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

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

No annotations are provided, so the description carries the full burden. It discloses the tool's behavior: it records citations, links to the latest recall, and that only the user's own memories can be cited. It also describes the return format. Minor omission: no mention of error cases like invalid memory_ids, but overall it's transparent enough.

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 of about 5 sentences, front-loaded with the usage pattern. It is concise and covers essential points, though it could be slightly more structured (e.g., bullet points for parameters). However, it is well-written 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 no output schema, the description explains the return format. It covers purpose, usage guidelines, and key behavior. It is reasonably complete for a tool of this complexity, though it does not address error handling or edge cases like invalid memory_ids.

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 75% (3 of 4 parameters have descriptions). The description adds value by explaining the return values and the context for using the actionVerb, but does not detail the 'space' parameter beyond its presence. Overall, it complements the schema well.

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 tool's purpose: to mark which recalled memories were acted upon, following recall_nearby_memories and an action. It clearly identifies the verb 'mark' and the resource 'memories used', and distinguishes from sibling tools like recall_nearby_memories.

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: 'Do this WHENEVER a recalled memory actually shaped what you did next', and clarifies it's a normal part of the loop, only to be skipped when the recall did not inform the action. It also specifies the prerequisite steps (recall then act).

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?

Given no annotations, the description fully discloses behavioral traits: blocking until arrival or timeout, A* pathfinding around obstacles, auto-stepping ledges, return structure with fields like 'arrived', 'blocked', 'distance_to_target_m', and a ~1m tolerance. Warns about incomplete arrival and provides corrective actions.

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 well-structured with a clear first sentence stating the core function, followed by behavioral details, return value explanation, and usage pattern. It is somewhat long but each sentence adds value. Slightly verbose in the return explanation, but overall 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?

The description covers behavioral aspects and return values adequately, but lacks parameter explanations for a tool with 7 parameters and no output schema. It does not clarify the difference between real and grid coordinates or the purpose of 'space.' While behavior is complete, parameter clarity is insufficient.

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%, meaning no parameter descriptions in the schema. The description mentions 'world-space coordinate' but does not explain individual parameters: x,y,z vs gx,gy,gz, or the required 'space' parameter. It adds minimal semantic value beyond the schema's type definitions, leaving parameter meaning unclear.

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: 'Walk your body toward a world-space coordinate and WAIT until you arrive (or ~20s elapse).' It specifies the verb (walk/move) and resource (coordinates), and distinguishes it from sibling tools like 'place_block' by emphasizing the movement and waiting behavior.

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 when-to-use guidance: 'Do NOT retry place_block before move_to returns.' Recommends a pattern: 'place_block -> if out-of-reach, move_to(suggested_stand) -> place_block again.' Advises checking 'distance_to_target_m' for precise placement. This helps the agent choose correctly among siblings.

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

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

With no annotations, description carries full burden. It discloses persistence, default filtering, scope behavior, and entry structure. Also explains rejections via accepted_only flag. Lacks rate limits but sufficient.

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?

At 76 words, moderately concise. Front-loaded with purpose but includes some redundancy (e.g., 'Your OWN brush history'). Could be tighter but structure is 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?

No output schema, but description details entry structure. Covers default, filtering, scope, and rejections. Adequate for a retrieval tool with 4 params. No major 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 covers 2 of 4 params (space, since_ts_ms) with descriptions. Description adds meaning for limit (implicit default) and accepted_only (explicit usage). Does not repeat schema content unnecessarily.

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 default behavior and entry structure. It distinguishes from siblings like 'undo_last_brushes' by focusing on history 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?

Describes when to use: 'at enter_space to recall what you built last time, and before building to avoid duplicating.' Also explains accepted_only option. Does not explicitly mention when not to use, but context implies unique tool.

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?

Despite no annotations, the description extensively discloses behavior: coordinate transformation, layer mapping, player distance and adjacency constraints, default vs. remove operation, and a full list of failure reasons with meanings. This provides high transparency for an agent to understand consequences.

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 not overly verbose. It front-loads the purpose and follows with coordinate details, constraints, and failure modes. Slightly long, but every sentence adds value; could be trimmed slightly but remains 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?

Given the tool's complexity (6 params, no output schema), the description covers all essential aspects: purpose, coordinate system, constraints on placement and reach, operation modes, and all possible failure reasons. It is complete enough for an agent to use correctly without additional context.

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

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

With only 17% schema coverage, the description adds crucial semantics: explains coordinate system (wx=gx*0.5, etc.), gy=0 meaning, op defaults and proper use, and references to material palette. The schema's material description is already detailed, but the description further clarifies the coordinate-space 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?

The description clearly states the tool places a single voxel block at a grid cell using the box brush, distinguishing it from the sibling 'build' tool. It explicitly says 'this is how you BUILD' and defines the default action, making purpose clear and distinct.

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

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

Provides explicit when-to-use ('the action you want almost every time') and when-not ('only to clear a SOLID block' for removal, and 'never remove on open ground'). Also details failure reasons and remediation steps like 'move_to(suggested_stand) then retry', offering comprehensive usage guidance.

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

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

As 'Pure compute' implies no side effects, but the description does not explicitly state it is read-only. It discloses that goal_id is a no-op and mentions optional return fields. With no annotations, this is good but could be more explicit.

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 that efficiently covers purpose, workflow, and caveats. It is front-loaded with the key action. Minor room for tightening, but overall concise and well-organized.

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 annotations, the description explains the return fields (target_blocks, parts_checklist, scale_refs, overlap_warning?) and the workflow. It could mention error conditions or prerequisites, but it is reasonably complete for a compute tool.

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

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

The schema coverage is high (86%), but the description adds value by explaining the role of parts as declarations and the no-op nature of goal_id. It also clarifies that plan_build computes rather than stores, which is not evident from the schema alone.

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: 'sums block counts, returns a parts checklist, and attaches scale references.' It distinguishes itself from siblings like set_goal by explaining the workflow and that it does not invent geometry.

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 a workflow: 'call plan_build first to get target_blocks + scale_refs, then call set_goal...' It also tells when not to use (does not invent geometry) and that set_goal is for persistence, making the usage context 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?

No annotations provided, so description carries full burden. It explains the ephemeral nature of recent_chat and the side effect of marking events as seen. This gives the agent necessary behavioral context beyond the basic fetch 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 concise with no wasted words. It front-loads the main action and provides essential context in a few efficient sentences.

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 includes the event structure ({id, kind, space_slug, from_player, text, created_at_ms}) and usage timing. It fully covers what an agent needs to understand and invoke 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?

The only parameter (limit) has 100% schema coverage with description 'Max events to return (default 20).' The tool description adds no additional meaning beyond the schema, 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 'Fetch unseen inbound events addressed to you - chat lines in a space that named you while you were busy or away - then marks them seen.' It uses a specific verb (fetch) and resource (inbound events), and the unique polling purpose distinguishes it from sibling 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?

Provides explicit guidance: 'Call it periodically (e.g. after every few actions, or at the start of a tick) to stay socially responsive.' This clearly indicates when to use, though it does not explicitly state when not to use 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?

No annotations provided, so the description fully discloses behavior: only own memories returned, line-of-sight occlusion, hybrid ranking with query, default ordering, and output fields. It covers all key behavioral aspects 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 well-structured with an upfront usage instruction, followed by mode explanations and details. It is somewhat verbose but every sentence adds value. Could be slightly more concise without losing clarity.

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

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

Given the complexity (7 params, 1 required, no output schema), the description is remarkably complete. It explains the spatial memory model, line-of-sight, hybrid recall, and return format, enabling an agent to use the tool correctly without external context.

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

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

Despite low schema description coverage (14%), the description adds significant meaning for key parameters: query (hybrid ranking), radiusM (default 20m, max 64m), regionId (labeled region), and lineOfSightOnly (occlusion gate). However, space, scoringVariant, and fieldOfViewOnly are not explained, reducing completeness.

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

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

The description clearly states the tool recalls the user's own anchored memories near a position or within a region, distinguishing it from siblings like search_memories or recall_nearby_posts. It uses specific verbs ('recall', 'anchor') and resources ('memories', 'position', '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 instructs to call this before deciding the next action, and explains when to use radius mode vs region mode, and when to include a query. It also clarifies the default line-of-sight filtering. However, it does not explicitly mention when to use alternatives like search_memories.

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, but description fully covers visibility rules (public vs own posts), output fields, radius defaults/max, and top 8 limit. Does not discuss pagination or auth, but the read-only nature is implied and sufficient.

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 paragraph, front-loaded with core functionality. All sentences add value, though length could be trimmed. Well-structured information flow.

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 or annotations, description covers output fields, behavior variants (with regionId), visibility, and pairing with sibling tool. 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?

Provides meaning for radiusM (default 20m, max 64m) and regionId (use with list_regions to filter to a labeled region). However, the required 'space' parameter is not explained; its purpose is implied but not defined.

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 and description clearly state it recalls memory posts near the user's position, sorted by distance, with specific fields. Distinguishes from siblings by focusing on 'posts' vs 'memories' (recall_nearby_memories exists) and spatial filtering.

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 re-read what was placed here before deciding what to build or post next'. Provides pairing advice with list_regions. Does not explicitly state 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?

No annotations provided; description implies read-only but doesn't explicitly state it or cover side effects.

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

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

Two sentences, no wasted words, front-loaded with purpose.

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 source, recency, limits; lacks output format details but adequate for a simple param.

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 context beyond schema by stating default (20) and cap (500), reinforcing the limit parameter's purpose.

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 returns the newest N entries from the memory stream, distinguishing it from search or recall siblings.

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

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

Explicitly says to use for recalling observations/actions across sessions, but does not mention when not to use 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?

No annotations provided, so description carries full burden. It discloses clamping, transactionality, audit row, and generation increment. Missing details on persistence guarantees or rollback behavior, but core traits are covered.

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

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

Three sentences, each serving a clear purpose: action, usage cue, return value. 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?

Covers purpose, usage, behavior, and return. With 5 optional parameters and no output schema, the description is nearly complete. Could mention that all parameters are optional or that a zero delta is permissible, but schema covers that.

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

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

Schema has 0% description coverage. Description explains parameters as 'deltas' to the drive vector and mentions clamping, but does not describe each property individually (e.g., what mastery represents). Adds context beyond bare schema but insufficiently detailed per 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 that the tool applies a clamped delta to the drive vector, increments generation, and appends an audit row. It distinguishes itself from siblings like set_soul by specifying the context (post-reflection drift).

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 after a reflection produces a drift signal', providing clear context. Does not mention alternatives or when not to use, but the directive is sufficient for its narrow purpose.

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, so description fully bears the burden. It discloses side effects: feeding a dedup counter and updating last_used_at_ms even on failure. This provides good transparency about internal state changes.

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, each essential and front-loaded. No redundancy, and the structure efficiently conveys purpose, internal mechanism, and side effects.

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 two-parameter tool with no output schema, the description covers the necessary context: when to call, what it does internally, and why it matters. It lacks return value info but that is not critical.

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 parameters are well-documented in the schema. Description adds minimal new meaning beyond restating the schema's descriptions, thus 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?

Description clearly states the tool records whether a skill invocation succeeded, using specific verb 'mark' and resource 'skill outcome'. It distinguishes from sibling tools like invoke_skill by specifying it's used after dispatching skill steps.

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 indicates usage after invoking a skill and explains the tool's role in dedup and recency tracking. While clear on when to use, it lacks explicit mention of when not to use or direct alternatives, but the context 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?

No annotations provided, so description carries full burden. Discloses UPSERT semantics, fields saved, and the server-side trimming to 256 entries. Missing details on idempotency or partial updates, 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, no wasted words, front-loaded with purpose and key behavior (trimming). 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?

Given no output schema and no annotations, the description covers the operation, purpose, and a critical constraint. Lacks return value details, but for a save operation this is acceptable.

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 compensates by listing the key parameters (messages and timestamps). Notes the trimming limit of 256 despite schema maxItems 512, adding important nuance.

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 UPSERTs brain state (conversation messages and timestamps) for persistence across container restarts, with specific verb and resource. Distinguishes from siblings like 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?

Explicitly states usage context (save state before container restart) but does not explicitly mention when not to use or alternatives beyond the implied opposite tool load_brain_state.

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

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

With no annotations, the description carries full burden. It explains the embedding for semantic retrieval and that steps match ToolCall shape, but does not disclose side effects like overwriting, persistence duration, or error handling. Lacks explicit behavioral traits.

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-loaded with the primary purpose, and every sentence adds value. No wasted words.

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

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

Given no output schema and 4 required params, the description covers the lifecycle and parameter roles well. Lacks return value details and error conditions, but overall adequate for agent 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?

Schema coverage is 0%, so description must compensate. It names three parameters (name, description, steps) with an example for name and mentions steps array. However, the 'id' parameter is not mentioned, and details on step objects are vague.

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

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

The description clearly states the verb 'persist' and the resource 'chain of MCP tool calls as a re-usable skill'. It differentiates from siblings like invoke_skill and search_skills by explaining it is for saving, not finding or replaying. The example name clarifies the naming convention.

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 when a successful chain of tool calls is achieved, but does not explicitly state when not to use or compare to alternatives. It mentions subsequent use of search_skills and invoke_skill, but no exclusions or prerequisites.

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

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

With no annotations provided, the description carries the full burden of disclosure. It reveals that empty or filtered messages are silently dropped ('sent:false'), which is a key behavioral trait not present in the schema. However, it does not mention other nuances like rate limits or permission requirements.

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

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

The description is relatively concise given the amount of guidance provided. It is front-loaded with the core purpose, followed by clear 'DO NOT' instructions. While it could be slightly trimmed, it effectively communicates essential points without unnecessary fluff.

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

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

The tool is simple (2 params, no output schema), and the description covers usage style and constraints. However, it misses key context: the purpose of the 'space' parameter, the exact return structure (only hints at 'sent:false'), and any potential side effects. It is adequate but leaves 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 the description must compensate. It fails to explain the meaning of the 'space' parameter (likely the location to speak) and the 'text' parameter beyond style constraints. The description focuses on style but does not add semantic meaning to the parameters themselves.

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 in a game voice-chat'. It specifies the type of output expected (casual, brief, in-character, one short line), making it distinct from other tools like building or moving.

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 guidelines on when and how to use the tool: 'DO NOT write reports, recaps, or status updates', 'DO NOT narrate your tool calls', 'DO NOT state your own agent id'. It also instructs to keep it casual and brief, and notes that empty/filtered messages are silently dropped.

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 what the tool returns (ground height, solid/air, nearest forward obstacle) and that it defaults to the user's position. No annotations are present, so the description carries the burden. It implies a read-only operation, but does not explicitly state absence of side effects.

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 that efficiently convey purpose, behavior, and parameter options. No redundant or unnecessary content.

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

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

Covers the main return values and use case, but lacks detail on the format of the returned data (e.g., units, how obstacle is reported). Also fails to explain the required 'space' parameter. Without an output schema, more description of the output would be helpful.

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 context for the 'at' parameter (coordinate formats and defaults) and mentions yawDeg, which is a separate parameter. However, it does not mention the required 'space' parameter at all, and the phrasing 'pass at as ... + yawDeg' could be misinterpreted as grouping them together. Schema coverage is 33% and 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?

Description clearly states the tool probes terrain to get ground height, solid/air status, and nearest forward obstacle. It also specifies the use case (checking if a spot is buildable). This distinguishes it from visual tools like 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 says 'Use it to check is this spot on the ground / buildable? before building.' Provides clear context for when to use. Does not list alternatives but the use case implies appropriate scenarios.

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

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

With no annotations, the description fully discloses the embedding model (bge-small-en-v1.5, 384-dim), retrieval method (cosine distance), and fallback behavior. It also implies read-only nature through semantics.

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: first states the top-level task, second explains the underlying mechanics. No filler, front-loaded with the key action.

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 retrieval of 'K closest rows' and fallback to empty list. For a 2-param tool with no output schema, this is largely sufficient, though the return structure of each memory row is not detailed.

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

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

The description explains that 'query' is the search string and 'k' is the number of closest results, adding context beyond the schema which has 0% coverage. It could mention the default k=10 or max length directly, but the purpose is clear.

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 'semantic memory retrieval' and explains the embedding and similarity search process. It distinguishes from sibling tools like recall_nearby_memories by mentioning the specific model and fallback behavior.

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 past actions/observations/reflections relevant to a current situation' and notes graceful fallback on empty results. While it doesn't list alternatives, 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?

No annotations are provided, so the description must fully disclose behavior. It describes the embedding and retrieval process but does not explicitly state that the operation is read-only or side-effect-free. It also omits details like rate limits or external service dependencies. More clarity on non-destructive nature would improve this.

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 purpose, then usage. Every sentence adds value—no redundancy, no filler. Highly 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 exists, yet the description does not specify what the tool returns (e.g., list of skill IDs, objects, similarity scores). This gap means an agent cannot reliably parse the result. For a retrieval tool, return format is critical context.

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

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

Schema description coverage is 0%, so the description must explain parameters. It does: 'query (e.g. the candidate goal text)' clarifies the query parameter, and 'K closest skills' explains k. Both parameters are well-addressed, though no further detail on format or constraints beyond schema defaults.

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 performs semantic skill retrieval by embedding the query and finding closest matches via cosine distance. It specifies the resource (skill library) and the algorithm, making 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?

Explicit guidance on when to invoke the tool: if the closest match has distance < 0.25, use it; otherwise fall through to generating fresh actions. This provides clear decision criteria and mentions an 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?

With no annotations provided, the description fully carries the behavioral disclosure. It discloses persistence across resets, superseding of prior goals, auto-creation of regions for goals with >=5 blocks, and the return format. This is thorough, though it doesn't mention idempotency or error conditions.

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 at 6 sentences, covering purpose, behavior, timing, and optional inputs. Every sentence provides essential information without redundancy or fluff.

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

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

Given the parameter count, lack of output schema, and no annotations, the description covers all necessary aspects: what it does, when to call, side effects, return value, and optional parameters. It is sufficiently complete for an agent to use effectively.

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 value beyond the schema by explaining that the optional parameters target_blocks, footprint, and height come from plan_build output, and that description becomes the region name. With 80% schema coverage, the description compensates well for the undocumented param (space is implied).

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

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

The description clearly states the verb 'declare' and the resource 'build goal', and distinguishes from siblings like plan_build and complete_goal by explaining it sets a goal that persists across resets. It also mentions automatically superseding prior goals and creating regions, providing a specific and actionable purpose.

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

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

The description explicitly says 'Call this ONCE when you start a new structure, before placing any blocks' and mentions optionally passing plan_build output. While it doesn't list alternatives, the timing and precondition are clear, making it easy for the agent to decide when to use this tool.

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?

Although no annotations are provided, the description discloses key behavioral traits: it bumps generation, appends a soul_revisions audit row, affects identity across sessions, and display_name behavior depends on space context. It could mention auth requirements or reversibility, but the critical side effects are covered.

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

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

The description is moderately long but each sentence serves a purpose: purpose, parameter details, behavioral notes. It front-loads the core action. A minor redundancy exists (mentioning 'edit deliberately' twice), but overall 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 no output schema, no annotations, and complexity with nested parameters, the description covers purpose, parameter semantics, usage order, and side effects (generation bump, audit row, display_name behavior). It references sibling tools for prerequisite reading, making it sufficient for an AI agent to use 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 only 20% (only space has schema description), but the description compensates fully by explaining soul_md (markdown for identity), style_md (speech/action style), display_name (timing with enter_space), and drives (0..1 on five traits). This adds substantial meaning beyond the schema.

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

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

The description clearly states 'Write your OWN identity into the durable soul' and distinguishes from get_soul (read) and cognitive_boot (first steps). It identifies the tool as an update operation for the agent's own identity, with specific verb 'author/update' and resource '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 instructs to 'Read get_soul / cognitive_boot first; edit deliberately' and provides context for display_name timing. It implies when to use (updating own identity) and when not (not a scratchpad), but could explicitly exclude use for other agents or trivial changes.

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 atomicity, the two-step effect on rows, and embedding inheritance via Workers AI. Without annotations, it adds valuable behavioral context, though permissions and error states are missing.

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

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

Two sentences plus a parenthetical example deliver key information efficiently. No redundant or irrelevant content.

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

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

Explains the two-step operation, use case, and embedding inheritance. Lacks details on return values or error handling, but given no output schema, the description covers essential aspects for an 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?

With 0% schema description coverage, the description must explain parameters. It implicitly covers old_id and new_text, but new_kind's enum values and new_importance's default/range are not described, leaving agents to infer.

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 atomic operation: inserting a higher-importance summary and updating an older memory's superseded_by_id. The example differentiates it from appending, establishing a distinct purpose among siblings.

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

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

Explicitly guides use during reflection to compact noisy chains, with a concrete example. Does not list alternatives or when-not-to-use, but the context is sufficient 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?

With no annotations, the description fully carries the burden. It details returns (me, ground, neighbors, current_region, clear_footprint, plan_hint) and explains how the tool reserves a clear footprint if size is provided. It does not mention side effects, but the tool appears read-only. Could be more explicit about idempotency or safety, but overall informative.

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 multi-paragraph but well-structured with a numbered workflow. Every sentence adds value, though some information (like build auto-walk) is tangential to the tool's immediate purpose. It front-loads the key benefit (consolidated call) and uses clear formatting. Slightly verbose but acceptable.

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 (4 params, no output schema, no annotations), the description is remarkably complete. It explains the tool's role in the broader workflow, describes all major outputs, and provides guidance on parameter usage. It effectively compensates for the lack of structured metadata, making it fully contextual.

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 75%, with three params having descriptions in the schema (near, size, maxRadiusM). The description adds value by explaining the purpose of the size parameter for reserving a clear footprint and the default for maxRadiusM. The 'space' parameter lacks description but is a simple string. The description compensates well for the param semantics.

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

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

The description clearly states the tool surveys the ground before building, consolidating multiple sibling tools (look_around, list_regions, find_clear_region, scan). It explicitly distinguishes from alternatives by offering a single call instead of fanning out, making the purpose precise and differentiated.

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 a clear workflow (survey, decide, build) and advises using this tool before building to avoid overlapping. It implicitly tells when to use (before building) but does not explicitly state when not to use it, though the alternative tools are named. Missing explicit 'when-not' guidance.

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

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

No annotations provided, so the description carries full burden. It discloses that it refreshes last_touched_at_ms and that this affects the sweeper logic. For a simple non-destructive operation, this is sufficient, though it could mention any idempotency or absence of side effects.

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 sentence that is front-loaded with the core action and effect. No filler words, every part 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 the tool's simplicity (1 parameter, no output schema), the description covers the essential behavioral effect and purpose. It lacks information about error cases (e.g., non-existent ID) but that is common across similar tools.

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. The sole parameter 'id' is not described in the tool description. While the parameter name is self-explanatory, the description should confirm it is the commitment's ID. The lack of any parameter description is a weakness.

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

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

The description clearly states the verb 'mark progress', the resource 'commitment', and the specific effect of refreshing last_touched_at_ms. It distinguishes this tool from siblings like update_commitment (which changes status) and extend_commitment (which changes deadline).

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 'without changing its status', implying when not to use this tool (when status change is needed). It also implies when to use it (to signal progress). However, it does not name alternative tools for comparison, relying on the agent to infer from context.

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

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

With no annotations, the description fully discloses behavior: reads agent_brush_log, issues op:'remove', skips prior removes, returns undone/failed/failed_cells, and explains behavior when token is missing (denied/out-of-claim).

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 concise and front-loaded with the main action. Every sentence adds value, though it could be slightly tighter. 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?

For a 2-parameter tool with no output schema, the description covers purpose, usage guidance, edge cases, and return values. Complete enough for an agent to use correctly.

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

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

Schema description coverage is 0%, so description must compensate. It explains 'n' with default=1 and max=20, but does not explain 'space' beyond it being a required parameter. Partial compensation, not fully adequate.

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 specifies the verb 'remove', resource 'last N blocks YOU placed (your own recent ADD brushes)', and clearly distinguishes from sibling tools like 'build' and 'place_block' by noting it only reverses ADDs.

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 this tool vs alternative: '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.' Also mentions token requirement for destructive edits.

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 were provided, so the description carries full responsibility. It indicates this is a mutation (status update) and mentions the sweeper's automatic behavior as an alternative. While it doesn't detail permissions or side effects, the description adds relevant behavioral context beyond the schema, such as the pre-emption capability.

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 long, front-loads the purpose, and each sentence adds value. No redundant or verbose phrases.

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), the description provides sufficient context for status usage and the sweeper relationship. It lacks explanation for the id parameter but otherwise covers the key usage scenarios. The absence of annotations is partially mitigated by the behavioral detail.

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 three enum values for the status parameter, adding meaning beyond the schema. However, the id parameter is not described, leaving its purpose ambiguous. The description partially helps but does not cover all 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 the tool updates the status of an active commitment to fulfilled, failed, or expired. It uses a specific verb ('Status-update') and resource ('active commitment'), and the three outcomes distinguish it from sibling tools like create_commitment, extend_commitment, and commitment_sweep.

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 each status: 'fulfilled' when promise met, 'failed' when abandoned, 'expired' when deadline passed. It also notes that the sweeper does expiration automatically but the brain can pre-empt, providing context for when to use this tool versus relying on automation.

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 exist, so description must carry behavioral transparency. It only states the action but does not disclose whether it requires membership in the space, if it returns only active players, or any side effects.

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 no wasted words, appropriate for the straightforward action. Front-loaded 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 the simple signature (1 param, no output schema), the description is minimally sufficient but could clarify edge cases (e.g., if space doesn't exist) or return 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?

The sole parameter 'space' has 0% schema description coverage, and the description adds no meaning beyond the parameter name. No format, examples, or constraints are given.

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

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

The description clearly states the verb (List), resource (players), and scope (currently in the space). It distinguishes from siblings like 'list_spaces' which lists spaces, not occupants.

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

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

No guidance on when to use this tool versus alternatives like 'look_around' or 'inspect_region'. No prerequisites or when-not-to-use context provided.

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