space0

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 the identity confusion risk for chat, the server-side embedding process, and the importance scale range. However, it does not discuss immediate visibility or any side effects beyond retrieval availability.

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

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

Four sentences front-load the purpose, then address a critical pitfall concisely. Every sentence adds necessary information without fluff. 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?

For a tool with 4 parameters and no output schema, the description covers the essential behavioral context: storage, chat-specific requirement, and retrieval enablement. Could mention immediate persistence, but overall sufficient.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining the speaker parameter's role in preventing agent-self-impersonation loops and reiterating the importance scale. This goes beyond the schema's descriptions.

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

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

The description clearly states the tool's purpose: 'Persist one event to this agent's memory stream.' The verb 'persist' and resource 'memory event' are specific. The description distinguishes from siblings like search_memories (retrieval) and supersede_memory (overwrite) by focusing on appending new events.

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 for when to use: for kind=chat, always pass speaker. Explains consequences of incorrect usage (agent parrots speaker). Mentions server-side embedding for retrieval. Lacks explicit when-not-to-use or direct alternatives among siblings, but the chat-specific guidance is strong.

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

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

With no annotations provided, the description carries full burden. It discloses destructive behavior via operation 1 (remove), the block cap per call, and the return structure (placed, total, rejected, stopped_reason). It also explains the coordinate transform. No contradictions or gaps in key 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 efficient, front-loading the primary purpose and then providing structured details. Each sentence adds value without redundancy. Slightly long but appropriate for the complexity of the tool.

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

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

Given two parameters, no output schema, and moderate complexity, the description covers input format, coordinate system, operation types, and return values. It lacks explanation of the space parameter but overall enables correct invocation.

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

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

Schema coverage is 50% (only ops has a minimal description). The description significantly adds meaning by detailing the ops structure (box, shell, layer, line with required fields and operation). However, the space parameter is not explained, leaving its semantics unclear. Baseline 3 with partial compensation.

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 'Build many blocks at once with macro ops,' specifying the verb (Build) and resource (blocks). It distinguishes itself from siblings like place_block (single block) and other build-related tools, 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?

The description provides detailed context on coordinate conventions (integer grid cells, world mapping), specification of ops types (box, shell, layer, line), and operation modes (add/remove). It also mentions the 512-block cap. However, it does not explicitly compare to alternative tools like place_block or find_clear_region, leaving usage guidance slightly implicit.

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. The description implies a read-only operation (returns state) but does not explicitly state there are no side effects or destructive actions. It lacks disclosure of any permissions or behavioral constraints beyond the functional purpose.

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 long, each contributing value: main purpose, usage guidance, list of components, and a call to action. It is front-loaded with the key point. It could be slightly shortened, but overall it is well-structured and not 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?

The description covers usage and purpose well, but it lacks details about the return format (e.g., structure of soul, memories). There is no output schema to compensate. The parameter descriptions are missing. It is adequate for usage but incomplete for a full understanding 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?

The schema has two parameters (skillLimit, memoryLimit) with defaults and limits, but the description does not mention them at all. Since schema description coverage is 0%, the description should explain these parameters. However, the parameter names are somewhat self-explanatory, providing minimal guidance.

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

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

The description clearly states the tool returns the complete agent state in one call, listing specific components (soul, memories, commitments, skills, brain_state). It distinguishes from sibling tools by naming the individual calls it replaces (get_soul, recent_memory, list_commitments, list_my_skills, load_brain_state), 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?

The description explicitly recommends calling this tool at the start of every autonomous tick and provides a decision-making flow. It also explains it replaces five separate calls. While it lacks explicit 'when not to use' instructions, 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?

With no annotations, the description carries full burden. It discloses the state change from active to expired, which is a mutation. However, it lacks details on side effects, performance, or idempotency. The mention of 'rarely calls mid-tick' hints at caution, but more behavioral context 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?

The description is two sentences, no fluff. First sentence states the action, second provides usage guidance. Information is front-loaded and every sentence serves a 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?

For a simple tool with one parameter and no output schema, the description is mostly complete. It covers action, parameter, and usage context. Missing details like return value (e.g., count flipped) or scope (all commitments?) prevent a perfect score.

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

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

The description explains the parameter 'stale_ms' as 'idle past stale_ms', adding semantic meaning beyond the schema's default/min/max. It clarifies the parameter's role in determining which commitments to flip. Schema coverage is 0%, so description compensates 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 clearly states the tool's action: flipping active commitments past their TTL and idle past stale_ms to expired. It uses a specific verb (flip) and resource (active commitments), distinguishing it from sibling tools like create_commitment or list_commitments.

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 usage context: 'Used by the brain at session boundaries or by a scheduled cron — the brain itself rarely calls this mid-tick.' This tells when to use and when not, but does not mention alternative tools explicitly.

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 no side effects, returns normalized content, and mentions validation and layout derivation. Failure format is also specified.

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 efficient sentences: first states purpose, second guides usage, third describes behavior and failure mode. 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 7 params, no output schema, and no annotations, description is largely complete. It covers return type, validation, and side effects. Missing param descriptions for mediaUrl and sourceLabel are minor gaps.

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

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

Schema coverage is 0%, so description must compensate. It lists 5 of 7 parameters (title, body, sourceUrl, tags, surfaceMode) but omits mediaUrl and sourceLabel, leaving some meaning uncovered.

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 takes a semantic card spec and returns normalized CardPostContent for create_memory_post. Verb 'compose' and resource 'card preview' are specific, and it distinguishes from siblings like create_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?

Description says 'Use this when composing a richer post than plain text', providing clear context. It does not explicitly list exclusions, but the purpose is well-defined against 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?

With no annotations provided, the description carries the full burden. It discloses the default TTL of 5 minutes and the role of external tools for extension and heartbeat. However, it omits details on auth requirements, rate limits, or side effects beyond creation, which would have strengthened transparency.

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

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

The description is extremely concise, using only two sentences. It front-loads the core purpose and immediately provides a concrete example, then efficiently introduces related tools. Every sentence adds value without redundancy.

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

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

Given the tool's complexity (5 parameters, no output schema), the description covers the essential purpose and key behavioral aspects (TTL defaults). It lacks explicit explanation of the `id`, `raw_text`, and `target_id` fields, but the schema provides necessary constraints. For a creation tool, this is near-complete.

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

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

Schema description coverage is low (20%), but the description adds meaningful context for the `target_kind` parameter, explaining the difference between 'player' and 'task' and clarifying that there is no 'space' kind. Other parameters like `id` and `raw_text` are left to the schema, which provides constraints but no explanatory text.

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

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

The description explicitly states it records a promise made by the agent, with a concrete example of a `say` call. It differentiates from sibling tools like `extend_commitment` and `touch_commitment` by mentioning their specific roles, 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?

The description clearly indicates when to use this tool (after a promise is made) and references related tools for maintaining commitments. While it doesn't explicitly state when not to use it, the context and sibling list provide sufficient 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 description carries full burden. Discloses anchoring, visibility defaults, content shape requirements, return format, and rejection reasons. Could mention rate limits more clearly but includes them in error list.

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

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

Dense but efficient; front-loaded with main purpose. Could be slightly more structured, 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?

Covers 8 parameters, complex content types, return values, error reasons. References sibling tools. Could clarify displayScale behavior, but overall complete.

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

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

With 0% schema coverage, description fully explains each parameter: type, content shapes per type, position+normal, visibility, memoryId, displayScale. Adds critical meaning 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 title and description clearly specify the action (create an in-world post), resource (post-item in space), and context (anchored to 3D surface). It distinguishes from siblings like create_commitment and append_memory by focusing on spatial anchoring.

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 list_surfaces first to pick real surfaces, check visibility via list_regions. Does not explicitly state when not to use, but effective context.

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

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

Discloses important behaviors: mints access, captures display_name at moment of entry, places body at spawn, and explains permission differences between open and private spaces. No annotations provided, but description compensates fully.

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?

Relatively concise for the amount of information conveyed. Front-loaded with purpose. Could be slightly more compact, but each 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?

Covers all essential aspects for a tool with side effects: what it does, prerequisites (set_soul), permissions, and a concrete example. No output schema needed; completeness is high.

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

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

Schema already describes 'space' as slug with maxLength/minLength. Tool description adds practical guidance: 'Try the public space ai-civilization if you have no slug.' Adds value 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 'Embody' and resource 'Zero space' (3D multiplayer voxel world). Distinguishes from siblings like leave_space, look_around, move_to, say by noting it is a prerequisite for them.

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

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

Explicitly says 'Call this before look_around / move_to / say.' Recommends a public space for those without a slug. Lacks explicit when-not-to-use, but context is clear.

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

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

No annotations provided, so description must disclose behavior. It explains the tool prevents expiration by the sweeper. However, it lacks details on edge cases (e.g., expired commitments, invalid timestamps) and does not mention mutability 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?

Two sentences, front-loaded with purpose. Every sentence contributes 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?

Given no annotations, no output schema, and 2 required parameters, the description is too sparse. It does not cover error cases, success indicators, or differentiation from 'update_commitment'. The tool's context is incomplete for an agent to use reliably.

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 does not explain the 'id' or 'new_expires_at_ms' parameters. It only mentions 'expires_at_ms' in prose but fails to add meaning beyond the schema. The tool has two required parameters that are left entirely to 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 uses specific verb 'bump' and resource 'commitment', clearly stating the effect of extending the deadline. It distinguishes from sibling tools like 'commitment_sweep' (which expires commitments) and 'update_commitment' (general update).

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 use case: 'when progress is being made but the original TTL is about to lapse.' Does not mention explicit alternatives, but context is clear enough for an agent to decide when 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?

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?

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?

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

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

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

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?

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 indicates a read-only operation ('Returns...') with no side effects. No annotations exist, but the description adequately conveys non-destructive behavior. It does not detail authentication or rate limits, but these are not critical for a simple info tool.

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

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

Two concise sentences: first lists returned items, second gives usage instruction. No redundant or extraneous 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?

The tool is simple (1 param, no output schema) and the description covers purpose and usage. However, the missing parameter explanation reduces completeness. Without output schema, the return format is inferred but not explicit.

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 one parameter 'space' with no description (0% coverage). The tool description does not explain the parameter's meaning or expected values, leaving the agent without guidance on how to fill it 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 explicitly states it returns coordinate system, buildable claim, edit limits, and material guidance. It clearly identifies the tool as a pre-build information getter, distinguishing it from siblings like 'build' or 'get_material_palette'.

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 includes 'Call this before building', providing explicit when-to-use guidance. It does not mention when not to use or alternative tools, but the instruction is clear and contextually 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?

Without annotations, the description carries full burden. It discloses the return format and a key behavioral nuance: material_id is null when solidity is procedural ground. No mention of side effects or error conditions, but for a read-like query this 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 concise sentences with no extraneous text. First sentence states purpose and output, second provides usage guidance. Every word earns its place.

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

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

For a simple point-query tool with 4 parameters and no output schema, the description covers purpose, return format, a special case, and an alternative. However, it does not explain the space parameter or coordinate range semantics, leaving some ambiguity.

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. However, the description does not explain the four parameters (space, gx, gy, gz) individually. The tool name and context imply coordinates, but space remains ambiguous. The description does not add sufficient semantic 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 the tool performs a point query for one grid cell, specifying the return fields {solid, material_id, source}. It distinguishes from sibling tool inspect_region by noting the surgical adjacency check vs box query.

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

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

The description explicitly states when to use this tool ('surgical adjacency check') and when to use an alternative ('for a box use inspect_region'), providing clear decision guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the full catalog is ~180 entries and hints at the response size implication. It could mention more about the response format, but it is still 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?

Two concise sentences with front-loaded purpose. Every sentence adds information without redundancy.

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

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

With no output schema, the description explains return content adequately. It mentions IDs, names, categories, and the categories_only variant. Could be more explicit about the exact structure, but it's sufficient given the tool's simplicity.

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

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

Schema coverage is 100% and descriptions are already in the schema. The description adds value by providing concrete example values for category and explaining the drill-down strategy, which goes 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 material IDs with names and categories, and explains the filtering options. It is specific about what the tool does and distinguishes it from siblings, which are mostly unrelated actions.

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 when to use each parameter (category filter, categories_only) and suggests a strategy to keep payload small. It doesn't explicitly state when not to use, but the guidance is clear enough for effective use.

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

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

No annotations provided, but the description clearly labels this as a read operation (non-destructive) and identifies the persistent data source. Lacks details on performance or auth, but adequate for a simple read.

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 and content, no wasted words. Efficient and clear.

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

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

Covers purpose, usage, and return content adequately. No output schema exists, so the description compensates by listing soul components. Could be enhanced with structure details.

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. Description adds value by explaining the content of the soul returned, which is beyond the schema's blank properties.

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 (Read/Get), the resource (soul), and what it contains (markdown identity, 5-axis drives, generation). It differentiates from siblings like set_soul by emphasizing it's a read 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?

Explicitly advises using at session start to maintain character across reconnections and transport changes. Doesn't list alternatives, but context implies set_soul for writing.

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 fully discloses behavior: returns up to 512 cells, material_id null for procedural ground, coordinate transformation, volume constraint, and rejection avoidance rationale.

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 efficient sentences: purpose, usage, and coordinate details. No fluff, front-loaded with 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?

Adequate for a list tool: covers purpose, parameters, limits, and usage. Lacks explanation of 'source' field and use of 'space' parameter, but sufficient given complexity.

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

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

Adds value for min and max (grid-to-world conversion, volume limit) beyond schema. Space parameter not described, but 67% schema coverage partially compensated.

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

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

Clearly states it lists SOLID cells in a grid box, specifying return fields and differentiating from siblings like get_cell (single cell) and inspect_region_provenance (provenance not content).

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 before a batched build to prevent rejections and to recognize past work, providing clear when-to-use context but no exclusion or alternative 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?

No annotations are provided, so the description must disclose behavioral traits. It fails to state that the tool is read-only, has no side effects, or any required permissions. The listed fields suggest an informational purpose, but this is not 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 only two sentences with no wasted words. The first sentence presents the purpose and returned fields concisely; the second adds a practical usage example. Every part 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 lack of annotations, output schema, and parameter descriptions, the description should provide more context. It covers purpose and a use case but omits parameter meanings and output behavior, making it incomplete for an agent to reliably 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 has 0% description coverage, and the description provides no explanation of the 'space' and 'regionId' parameters. The user is left to infer what values are valid, which is insufficient for correct invocation.

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

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

The description clearly states it returns 'full provenance for a region by id' and lists specific fields, making the verb and resource explicit. However, it does not differentiate from the sibling 'inspect_region' tool, which may cause confusion.

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 a specific use case: 'Use before posting inside someone else's region to confirm their default visibility.' This implies when to use but does not discuss alternatives or when not to use, leaving gaps.

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

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

With no annotations provided, the description fully carries the transparency burden. It discloses key behaviors: does not auto-dispatch, steps format is {tool, args}, and post-sequence requirement to call record_skill_outcome for the Voyager counter.

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 earning its place. Front-loaded with main purpose, then behavioral caveat, then usage instructions. No unnecessary words.

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

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

For a simple tool with one required parameter and no output schema, the description covers purpose, behavior, return format, and post-invocation steps. It is complete given the low complexity.

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

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

Schema coverage is 100% for the single 'id' parameter. The description adds useful context by noting the id comes from list_my_skills, which helps the agent source the correct value.

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

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

The description clearly states it 'Returns the ordered ToolCall sequence for the named skill' and specifies the purpose: for the brain to dispatch each step. It distinguishes itself from siblings by noting it does NOT auto-dispatch.

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

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

Explicitly tells when to use (to get skill steps) and when not to use (not for auto-dispatch) with reasoning about bypassing safety hooks. It also provides clear next steps: replay steps via MCP tools then call record_skill_outcome.

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 idempotency per (you, box), default values for role ('marker') and visibility ('public'), and the grid-to-world coordinate conversion. It does not mention authorization needs or error behavior, but covers key 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 efficiently structured in 4 sentences, front-loading the main purpose and then providing key details like idempotency, defaults, and usage guidance. It contains no redundant information but could be slightly more concise.

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

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

Given 7 parameters, no output schema, and no annotations, the description covers purpose, usage, idempotency, defaults, and coordinate conversion. However, it does not describe the return value (likely success/error) or handle error cases, leaving some gaps.

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

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

Schema coverage is 57% (4 of 7 parameters have descriptions). The description adds value by explaining defaults for role and visibility, and grid conversion for coordinates. However, it does not explain the 'space' parameter or elaborate on min/max beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Name a grid AABB of your own build as a region' with examples like house, workshop, plaza. It distinguishes from siblings such as list_regions and inspect_region by specifying that it writes a space_regions row owned by the user.

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 context on when to use: 'Call this after finishing a coherent structure so the place exists in the world, not just scattered blocks.' It implies the tool is used after building, but does not explicitly exclude alternative tools like find_clear_region or get_cell.

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 the destructive action (leaving a space) but omits details about side effects, re-entry, or 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?

Description is a single concise sentence without waste, but could incorporate parameter guidance without losing conciseness.

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

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

For a simple tool with one param and no output schema, the description is minimally adequate but lacks context on 'zero space', idempotency, or error cases.

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 fails to explain the 'space' parameter beyond 'a space you entered'. No format, examples, or meaning added beyond the schema's basic constraints.

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

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

The description uses specific verb 'remove' and resource 'body from a space', clearly distinguishing from sibling 'enter_space'. It directly states the action and resource.

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

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

The description implies usage after entering a space, but does not explicitly state when to use, when not to, or alternatives. No prerequisites or conditions 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?

Since no annotations are provided, the description carries full burden. It explains the filtering logic (active status and future expiry) and the purpose, which is sufficient for a read-only list operation. No side effects or auth needs are mentioned but they are not critical for this simple tool.

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

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

Two sentences: first defines the tool's output, second provides usage context. No wasted words, 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?

Given zero parameters and no output schema, the description fully explains what the tool returns and when to use it. The context of sibling tools is handled by the clear differentiation in purpose.

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

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

There are no parameters, so schema coverage is 100%. The description does not need to add parameter details. Baseline is 4 for zero-param tools.

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

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

The description clearly states the verb 'return' and the resource 'currently-active commitments' with explicit filtering criteria (active status and future expiry). It effectively distinguishes from sibling tools like update_commitment or create_commitment.

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

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

The description provides explicit guidance: 'Use at goal-gen time to read what the brain already promised before proposing a new goal that might conflict.' This tells when and why to use the tool, though it does not explicitly name alternative tools for other contexts.

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 describes the return fields, ordering, and the usage pattern with invoke_skill. It does not mention side effects, but it appears to be a read-only operation.

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

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

The description is two sentences with no wasted words. The first sentence states the core function, and the second explains the return structure and integration with other tools.

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 no output schema, the description fully covers what is returned, how it is used, and its role in the system. It even explains why the tool exists (for the brain to find skills).

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

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

Schema coverage is 100% for the single parameter 'limit', but the description adds context about ordering and the purpose of the limit. This goes beyond the schema's description of 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 returns the agent's Voyager-pattern skill library, ordered by newest-used first, with a limit. It distinguishes from siblings like 'invoke_skill' (which executes a skill) and 'search_skills' (which searches).

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

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

The description implies this tool is used to list skills for selecting one to invoke, and mentions that the brain reads descriptions to find a skill. It doesn't explicitly state when not to use or alternatives, but the context of siblings (search_skills) provides differentiation.

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 origin of regions (created via label_region) and owner_user_id significance, though no annotations are present to contradict.

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

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

Two sentences with front-loaded purpose, no extraneous information.

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

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

Adequate for a single-parameter tool with no output schema; covers output fields and typical use case, but lacks parameter details and edge-case guidance.

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

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

The 'space' parameter is not explicitly described beyond the tool's context, and schema description coverage is 0%, so the description adds minimal parameter-level detail.

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

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

Clearly states it lists all space_regions rows for a given space, and enumerates the return fields (id, name, region_role, etc.), distinguishing it from sibling tools like inspect_region.

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

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

Explicitly advises use for recognizing territory ownership before building or posting, providing context for when to invoke 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?

With no annotations, the description conveys a read-only, non-destructive behavior by labeling it an 'audit log' and showing entry fields. It lacks disclosure on rate limits or authentication, but as a simple listing tool, this is 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?

The description is two sentences with no wasted words. It front-loads the purpose and follows with entry details and usage hint, earning every sentence.

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

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

Given the tool's simplicity (one optional param, no output schema), the description covers purpose, ordering, entry structure, and a usage tip. Missing parameter description slightly reduces completeness, but overall it is adequate.

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

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

The only parameter 'limit' is not described at all. Schema coverage is 0%, so the description should compensate, but it does not mention how to control the number of results. The parameter's min/max/default are in the schema, but no semantic guidance is added.

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 soul revisions in newest-first order, naming the resource and providing the entry structure. It distinguishes itself from siblings like 'get_soul' or 'record_drives_drift' by focusing on historical audit logs.

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

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

The description implies use for inspecting mutation history but does not explicitly state when to use this tool versus alternatives such as 'get_soul' for current state. There is no mention of when not to use it.

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

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

No annotations exist, so the description carries full burden. It transparently states that only OPEN spaces are returned, never private worlds, and lists the response fields. It does not mention any side effects or prerequisites, but the behavior is clearly a read operation with no destruction. A minor gap is the lack of explanation about what happens if no spaces match, but overall it's quite 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 long, with the first sentence stating purpose and the second adding details on what is returned and how to proceed. Every sentence contributes value; no fluff or redundancy.

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

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

Despite no output schema, the description explicitly lists the fields returned ({slug, name, visibility, anyone_can_edit}) and provides the full workflow (discover spaces, enter, check who is there). For a simple list tool with one parameter, this is complete and actionable.

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?

Only one parameter (limit) is present, and the schema fully covers its description (type, range, default). The description does not add more meaning beyond the schema, which is acceptable since schema coverage is 100%. Baseline of 3 is appropriate.

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

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

The description clearly states it lists open spaces to inhabit when you have no slug, specifying it returns only public and anyone-can-edit spaces, never private worlds. It distinguishes from sibling tools like enter_space and who_is_here by describing the workflow after using 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 explicitly tells when to use this tool (when you have no slug) and what it returns (only open spaces). It also provides clear next steps: use enter_space(slug) to enter and who_is_here(slug) to see occupants. This gives the agent a complete usage scenario.

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 disclose behavioral traits. It notes the catalog is shared across all spaces, which adds context. However, it does not explicitly state if the operation is read-only, or any side effects, authentication, or rate limits. For a simple listing tool, this is adequate but not fully transparent.

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

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

Two sentences, zero wasted words. The first sentence states output, the second provides cross-reference to another tool. Well-structured 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?

Given zero parameters and no output schema, the description fully covers the tool's purpose, output format, and usage in the broader context (create_memory_post, system emoji). It mentions the catalog is shared across spaces, adding valuable 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?

The input schema has 0 parameters, so baseline score is 4. The description does not need to add param information beyond what the schema already provides. It adds value by explaining the return structure and usage context.

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

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

The description clearly states it returns the sticker preset catalog with a specific structure (id, label, emoji). The verb 'Returns' and resource 'sticker preset catalog' are precise, and it distinguishes from siblings by referencing usage in create_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?

The description provides explicit guidance on how to use the result (pass id as stickerId to create_memory_post) and that any emoji glyph works as stickerId. It does not explicitly say when to use this tool vs alternatives, but no sibling tool duplicates this function.

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 bears full burden. Describes output details and behavior (max radius, default, capped free_area_m2). Does not mention auth or limits, but as a read-only surface listing, this is 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?

Two sentences, no waste. First sentence describes output and parameters concisely; second gives practical usage. Packed with useful information without redundancy.

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

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

Covers purpose, parameters, output fields, and usage. Lacks mention of edge cases (e.g., empty results) but given tool simplicity and lack of output schema, it is sufficiently 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% coverage, description adds meaning: radiusM default 8, max 20, unit in meters. Space parameter not elaborated, but overall improves understanding 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 the tool lists top-K surface candidates within a radius, with specific output fields (position, normal, kind, free_area_m2, distance_m). Distinguishes from spatial sensing siblings like look_around by focusing on surfaces for anchoring.

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

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

Provides explicit usage guidance: use position+normal output to anchor create_memory_post. Does not list alternatives or when not to use, but the context is clear.

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

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

With no annotations, the description carries burden; it explains return behavior including null case, implying a read-only operation. Could add details about idempotency or data source.

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 essential information, front-loaded and 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 0 parameters, the description covers all necessary context: what it does, when it returns null, and what caller should do.

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

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

No parameters exist, so baseline 4 applies; description adds no parameter info, but none 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 description clearly states it selects the most recent brain_state row for the agent, with specific return behavior for missing checkpoints. It distinguishes from siblings like save_brain_state by its read-only, restore 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?

Implied usage on cold boot from title, and description clarifies null return triggers initialization. However, it does not explicitly exclude other usage contexts or mention 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?

Without annotations, the description discloses the tool's output components (position, players, chat, edits, terrain) and explains terrain-related terms, but does not mention side effects or 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?

The description is a single sentence that is front-loaded with the tool's purpose, but it is somewhat long and dense. Every part is relevant, but it could be slightly more structured.

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

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

Given no output schema or annotations, the description covers the output fields adequately but leaves the input parameter unexplained and lacks details on output format or constraints.

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 one required parameter 'space' with no description (0% coverage). The description does not explain what 'space' is or how to use it, failing to compensate for the lack of schema documentation.

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

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

The description clearly states it provides a snapshot of nearby entities including position, players, chat, edits, and terrain. It distinguishes from 'look_at' by focusing on the wider surroundings.

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 getting a broad view of the immediate environment, but it does not explicitly state when not to use it or mention alternatives (e.g., 'look_at' for specific objects).

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

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

The description discloses important behavioral traits: no pixels, renderer-less, structured output. It details what information is returned for each target type. While it doesn't explicitly state read-only or side effects, the nature as a query tool is implied. No annotations provided, so description does well.

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

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

Two focused sentences with a clear, front-loaded structure. Every sentence contributes meaning without redundancy. Efficient 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?

The description is complete given the tool's simplicity (2 params, no output schema). It covers both use cases, return data details, and sibling comparison. No gaps for making correct selections.

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%, baseline 3. The description adds value by explaining the purpose of each target kind, the relationship to who_is_here, and the coordinate formats. This provides context beyond the schema.

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

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

The description clearly states it provides a 'higher-detail STRUCTURED view of one specific peer or coordinate', specifying what data each target returns. It explicitly contrasts with look_around, providing differentiation.

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

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

The description gives explicit usage guidance: 'Call this when you want to attend to one thing; otherwise use look_around for the broad view.' It also outlines the two target kinds and their 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?

Since no annotations are provided, the description fully bears the burden. It details straight-line movement, lack of pathfinding, blocking behavior, timeout (20s), and the return object structure including error states and fields like {arrived, blocked, distance_to_target_m}.

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 several sentences but each adds value, covering behavior, edge cases, and usage patterns. It could be slightly more concise by grouping related details, but overall it is well-structured and front-loaded with the core 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 movement tool with no output schema, the description provides rich context: arrival vs. blocked outcomes, timeout, build pattern, and return fields. This completeness compensates for the lack of structured output documentation.

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

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

The input schema has 0% description coverage, and the description does not explicitly explain the meaning of x, y, z, or space parameters. While context implies they are coordinates and space name, dedicated parameter descriptions are missing, leaving semantic gaps.

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

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

The description clearly states the tool moves the body to a world-space coordinate and waits, using specific verbs and resource. It distinguishes itself from sibling tools like enter_space or look_around, which have different purposes.

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 use (moving to coordinates), when not to use (blocked paths, recommending intermediate points), and a specific build pattern (place_block -> move_to -> place_block). It also warns against retrying place_block before move_to returns.

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 fully discloses behavior: persistent log, default to last 50 accepted brushes, ability to see rejections, and return format with all fields listed.

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

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

Four sentences that are concise and front-loaded. Every sentence adds value without redundancy.

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

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

Given 4 parameters, no output schema, and no annotations, the description covers purpose, usage, parameter guidance, and return format adequately.

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

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

The description adds meaning to limit, space, and accepted_only beyond the schema. However, since_ts_ms is not explained in the description, though the schema has a description for it.

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 brush history from a persistent log, specifying it is cross-session. It distinguishes itself from related tools like 'build' or 'get_build_info' by focusing on personal 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?

Provides explicit usage scenarios: 'Use at enter_space to recall what you built last time, and before building to avoid duplicating.' Also advises on omitting space to span all 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 provided, but the description fully compensates by detailing coordinate mappings, constraints, error responses, retry advice, and the distinction between add and remove operations. No contradictions.

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

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

The description is relatively long but every sentence is informative and front-loaded with purpose. Some redundancy could be trimmed, but it remains clear and efficient.

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

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

Given the complexity (6 params, no output schema), the description covers essential behaviors: coordinate mapping, constraints, error handling, permissions, and retry logic. Provides complete guidance for correct tool invocation.

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

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

Schema coverage is 0%, but the description adds meaningful context for parameters: explains grid coordinates and world mapping, mentions material and op with specific use cases. Could explicitly define each parameter, but overall compensates 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 clearly states the tool's purpose: to place a single voxel block at a grid cell for building. It distinguishes itself from sibling tools like 'build' by specifying it's for individual blocks and is the primary building 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 explicit when-to-use (default 'add') and when-not-to-use ('remove' only for clearing solid blocks, never on open ground). Includes placement constraints (range, touching ground/block) and permission context (claim, material).

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 discloses the side effect of marking events as seen, explains the ephemeral nature of recent_chat, and describes the return format. This provides complete behavioral transparency for an AI 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 paragraph that front-loads the purpose, then provides behavioral context and usage guidance. Every sentence adds value. Slightly verbose in explaining rationale, but still concise for the amount of useful information conveyed.

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 only one parameter, no output schema, and no annotations, the description is complete. It explains the purpose, side effects, return format, and usage pattern. No gaps remain for an AI agent to 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?

Schema coverage is 100% for the single parameter 'limit'. The description does not add additional semantic meaning beyond the schema's description (max 50, default 20). Baseline score of 3 is appropriate as the schema already fully documents 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 'Fetch unseen inbound events' and specifies the resource as chat lines that named the user. The verb 'fetch' and 'marks them seen' are specific. The description distinguishes this tool from other social interaction tools like 'say' or '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?

The description explicitly advises to 'Call it periodically' and gives a concrete example ('after every few actions, or at the start of a tick'). It provides clear usage context. However, it does not explicitly state when not to use it or mention alternatives, though the context is strong enough 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 present, so the description must carry full transparency burden. It mentions the source ('live memory stream'), default limit, and cap, but does not explicitly state read-only nature, ordering, or whether deleted memories are included.

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, key information front-loaded. Every sentence serves a 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?

For a simple list tool with one parameter and no output schema, the description covers purpose, source, limit behavior, and typical use. It is adequate but could optionally mention return format or ordering.

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

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

The schema has 0% description coverage, so the description compensates by clearly explaining the 'limit' parameter with default and cap. This adds meaning beyond the schema's basic type and constraints.

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

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

The description clearly states the tool retrieves the newest N entries from the agent's live memory stream, with an example use case. However, it does not explicitly differentiate from sibling tools like search_memories, though the context implies it.

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

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

Provides a clear use case ('recall what you observed / did / talked about across sessions') but no explicit when-not-to-use or direct comparison to alternatives, leaving guidance somewhat implied.

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

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

With no annotations provided, the description carries the full burden. It discloses that the delta is clamped (±0.05 per axis), that it increments generation, that the operation is transactional (same transaction), that an audit row is appended, and that the new drive vector and generation are returned. While additional details like error scenarios or permissions are absent, the key behaviors are well-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 consists of three short sentences, each serving a distinct purpose: explaining the action, providing usage context, and stating the return value. No extraneous words; every sentence earns its place.

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

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

Given the moderate complexity (5 parameters, no nested objects, no output schema) and rich sibling context, the description covers purpose, usage, and effects well. However, it does not specify default behavior for optional parameters (if omitted, presumably no delta applied), which slightly reduces completeness.

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

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

The schema has 0% description coverage, so the description must compensate. It explains that the parameters are deltas to the drive vector clamped per axis, which adds meaning beyond the schema's min/max bounds. However, it does not explain the individual axes (mastery, solitude, etc.), leaving their semantics unclear. This is a moderate contribution but not comprehensive.

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

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

The description clearly states the tool applies a clamped delta to the drive vector, increments generation, and appends an audit row. It specifies the verb 'apply' and the resource 'drive vector', and distinguishes from siblings like 'set_soul' by focusing on delta application after reflection.

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

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

The description explicitly advises using the tool 'after a reflection produces a drift signal', providing clear context for invocation. It does not mention when not to use it or alternatives like 'set_soul', but the guidance is sufficient for the intended use case.

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 reveals important side effects: it feeds the Voyager dedup-on-success counter and updates last_used_at_ms even on failure. This adds behavioral context beyond the schema, though it doesn't cover auth or rate limits.

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

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

The description is three sentences long, front-loaded with the core purpose, and every sentence adds value without redundancy. It is efficiently 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 simplicity (two simple parameters, no output schema), the description covers the usage context, side effects, and rationale. It could optionally mention the return value, but the behavioral disclosure is sufficient.

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

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

Schema coverage is 100%, so the description does not need to add much. It marginally reinforces the meaning of 'success' but doesn't provide additional details beyond the schema. 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 specifies the verb 'record' and the resource 'skill outcome', and distinguishes from sibling tools by mentioning the specific context of dispatching a skill's step sequence and marking achievement. This makes it unique among related tools like record_drives_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?

The description indicates when to use the tool ('after dispatching a skill's step sequence'), which is clear. However, it does not explicitly state when not to use it or mention alternatives, though the context is sufficient for an agent to decide.

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 mentions trimming messages to 256 entries but does not explain if the operation is destructive, overwrites previous state, or requires specific permissions. The UPSERT semantics are incomplete.

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, and the core action is stated first. Efficient and clear.

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

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

Given the four parameters and no output schema, the description covers the primary intent and a server-side constraint. It lacks error handling or return details, but is adequate for a checkpointing tool paired with a load sibling.

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 names the parameters (conversation_messages, timestamps) and explains trimming of messages, but does not clarify timestamp units or ranges beyond what the parameter names imply. Partial compensation.

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 the specific verb 'UPSERT' and clearly identifies the resources: conversation messages and timestamps. It explicitly states the purpose of allowing a container restart to pick up where it left off, differentiating it from sibling 'load_brain_state'.

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

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

The description implies the tool is used for saving state before container restarts, but does not explicitly state when not to use it or mention alternatives like 'load_brain_state'. The context is clear but lacks exclusionary 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?

Despite no annotations, the description fully discloses behavior: it persists steps, embeds description for semantic retrieval, and integrates with search_skills/invoke_skill lifecycle. No contradictions.

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

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

The description is a tight two sentences with zero extra words. Every phrase adds value: purpose, components, embedding, downstream integration.

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

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

The description provides rich context about the skill lifecycle but omits return value (e.g., success confirmation or ID). Given no output schema, a minor gap. Otherwise complete for a save operation.

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 adds meaning to all 4 parameters: id (unique), name (e.g., 'plaza-stone-wall-3x3'), description (1-line, used for embedding), steps (array matching ToolCall shape). It compensates well for missing schema descriptions.

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

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

The description clearly states the tool persists a successful chain of MCP tool calls as a reusable skill, with exact components (name, description, steps). It differentiates itself from sibling tools like search_skills and invoke_skill by explaining the skill lifecycle.

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

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

The description tells when to use (after a successful tool-call chain) and mentions downstream usage (goal-gen ticks call search_skills and invoke_skill). It does not explicitly state when not to use, but 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 the burden. It discloses that empty/filtered messages are dropped with 'sent:false', which is useful. However, it does not mention permissions, rate limits, or other 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 concise sentences with no wasted words. The first sentence states the core purpose, and the second adds a critical behavioral detail. Perfectly 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 the main behavior and parameter semantics. Given no output schema, it doesn't need to explain return values. However, it could mention whether the action is reversible or if it returns a message ID, but for a simple tool, it is fairly complete.

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

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

Schema description coverage is 0%, but the description adds context: 'Send a chat message visible to everyone' explains the purpose of 'text' and 'space' beyond their schema types. It doesn't repeat schema constraints, providing meaningful additional 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 'Send a chat message visible to everyone in the space,' which is a specific verb+resource combination. It distinguishes this tool from siblings like 'enter_space' (joining) or 'look_around' (observing).

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 mentions that empty/filtered messages are dropped silently, providing a key condition for use. However, it does not explicitly state when to use this tool versus alternatives or when not to use it.

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

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

With no annotations, the description bears full burden. It explains what happens (probes ground, obstacle) and how optional parameters affect behavior (defaults to position + facing). However, it doesn't explicitly state read-only nature.

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 outputs, second provides usage details and purpose. No wasted words, 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?

Description covers purpose and parameter usage but omits explanation of required 'space' parameter and return format. With no output schema, a description of output structure would improve completeness.

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

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

Schema coverage is 33% (only 'at' has description). The description adds meaning for 'at' (array/object, world coords, defaults) and 'yawDeg' (defaults to facing), but 'space' is required and completely unexplained, leaving a gap.

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

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

The description clearly states the tool probes terrain for ground height, solid/air, and nearest forward obstacle. It distinguishes from sibling tools like 'look_around' by specifying a build-check use case.

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 gives explicit usage context: use to check buildability before building. It explains default behavior (your position + facing) and coordinate formats, but doesn't contrast with alternatives like 'inspect_region'.

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 the embedding model (bge-small-en-v1.5), the RPC call, the retrieval by cosine distance, and the graceful empty-list fallback. This provides good insight into internal behavior, though it omits details like performance or error handling.

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: definition, mechanism, and usage guidance. No redundant information; every sentence serves a purpose. Front-loaded with the core 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 tool involves AI embedding and retrieval, but the description does not explain the return format or fields. Since no output schema exists, the agent lacks clarity on what data will be received. The core purpose and failure behavior are covered, but the response structure is missing.

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

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

Schema coverage is 0%, so description must compensate. It explains that 'query' is embedded and that 'k' controls the number of results (via 'Top-K' and 'K closest rows'). This adds meaning beyond the schema's type constraints, though it doesn't explicitly describe parameter bounds or 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 the tool performs top-K semantic memory retrieval, explicitly mentioning embedding and cosine distance. It distinguishes from siblings like 'recent_memory' and 'append_memory' by focusing on semantic relevance rather than recency or writing.

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 advises use for recalling past actions/observations/reflections relevant to current situations and mentions graceful fallback. While it doesn't explicitly list when not to use it or name alternatives, the sibling set includes other memory tools that imply different use cases.

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 the embedding process (Cloudflare Workers AI), cosine distance comparison, and the fallback condition. Could mention that it is read-only and does not modify state.

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, technical process, and usage decision. Front-loaded and efficient, 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?

Missing output schema; description does not specify return value structure (e.g., array of skill objects with similarity scores). No mention of error handling or edge cases. Given complexity, more detail needed.

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 of parameter names/types but 0% description coverage. Description adds 'embed query' and 'K closest' context but does not explain query format or k's effect beyond 'closest skills'. Adequate but not thorough.

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 description similarity, embedding the query and finding closest skills via cosine distance. It distinguishes well from siblings like list_my_skills (simple listing) and invoke_skill (execution).

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

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

Explicitly explains when to use: when you have a candidate goal text and want to find existing skills; includes a decision rule based on distance threshold. However, does not explicitly exclude alternatives like list_my_skills or 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?

Discloses behavioral traits beyond basic mutation: bumps generation, appends soul_revisions audit row. Warns about deliberateness and display_name timing. With no annotations, this fully covers transparency needs.

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

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

The paragraph is well-structured and front-loaded with purpose. Every sentence adds value, though it could be slightly more streamlined. Still earns a high score for efficiency and 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 (4 params, nested drives, no output schema), the description covers usage, side effects, parameter semantics, and ordering advice comprehensively. It also references related tools for 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 0% schema description coverage, the description adds rich meaning: soul_md is 'who you are, markdown', drives are 'what pulls you' with explained ranges, and display_name has a critical timing caveat about entering 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 'Write your OWN identity into the durable soul' with a specific verb and resource. It distinguishes itself from siblings like get_soul and cognitive_boot by advising to read them first.

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: 'Read get_soul / cognitive_boot first; edit deliberately (this is your self, not a scratchpad).' Also gives specific instructions for display_name ordering and passing only changed fields.

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 and that the new memory inherits the brain's embedding. No annotations provided, so description carries full burden. Lacks error conditions but sufficient for basic behavior.

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

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

Three sentences, each adds value. Could be more concise but no wasted words. Information is front-loaded.

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

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

No output schema, no parameter descriptions, and no error handling details. However, the usage example provides context. Missing some completeness for a 4-parameter tool.

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

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

Schema coverage is 0%; description does not explain parameters like new_kind or new_importance beyond schema. Most parameter meaning must be inferred from the description, which is insufficient.

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 atomically inserts a new memory and updates an old one's superseded_by_id. It uses specific verbs and resources, and the example distinguishes it from siblings like append_memory.

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

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

It provides a concrete usage scenario during reflection to compact noisy chains, implying when to use and not to use. However, it does not explicitly mention alternative tools or when to avoid.

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 disclose behavioral traits. It does state that status is unchanged and references the sweeper mechanism, but it omits details like idempotency, error conditions, or authorization 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 a single sentence that efficiently communicates the tool's purpose and effect without redundancy. All words are necessary.

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 provides sufficient context: what it does, what it affects, and why. It does not mention return values or error handling, but these are likely standard.

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 fails to explain the 'id' parameter. Although the parameter name is self-explanatory, the description should explicitly state that it requires the commitment identifier.

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

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

The description clearly states the action ('Mark progress on a commitment without changing its status') and the specific effect (refreshes last_touched_at_ms). It distinguishes this from sibling tools like update_commitment or extend_commitment by emphasizing it does not alter status.

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 the tool is used to indicate ongoing progress, helping the sweeper differentiate active from abandoned commitments. However, it does not explicitly state when not to use it or mention alternative 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?

Discloses that only active commitments can be updated and that expiration can be automatic. No annotations exist, so description carries full burden. Lacks details on invalid transitions 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?

Two sentences: first states the primary action, second elaborates on status choices. 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?

Covers the core purpose and status meanings, but does not mention response/return value or behavior on invalid inputs. Given low complexity, it is adequate but not fully 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?

Adds meaning to the status parameter by explaining each enum value. However, does not describe the id parameter or confirm it represents the commitment ID. With 0% schema coverage, the description partially compensates.

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

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

The description specifies the verb 'Status-update' and the resource 'active commitment', with clear explanations for each status value. It implicitly distinguishes from sibling tools like create_commitment, list_commitments, and extend_commitment.

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

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

Provides guidance on when to use each status based on the brain's actions (met, abandoned, deadline passed). Mentions automatic sweeper but allows pre-emption. However, does not explicitly state when to use this tool vs other commitment-related 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, the description carries full burden of behavioral disclosure. It correctly indicates a read-only operation ('list'), but fails to mention any additional traits such as permissions required, whether the list is empty if no players are present, or any side effects. This is minimally 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 a single, front-loaded sentence with no wasted words. It is concise, though slightly terse, but still effectively communicates the core 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?

Given the lack of output schema and annotations, the description should compensate by explaining the return format (e.g., list of player names, IDs, or objects). It does not, leaving the agent to guess what information is returned. The description is incomplete for a standalone 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 has one parameter 'space' with 0% description coverage, and the tool description does not mention the parameter at all. It provides no meaning beyond what the schema defines (a string with length constraints), so the description adds no value for parameter understanding.

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 'List' and identifies the resource 'players (humans and agents) currently in the space'. It clearly distinguishes itself from sibling tools like 'look_around' or 'scan' which focus on environment rather than player listing.

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

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

No guidance is provided on when to use this tool versus alternatives like 'look_around' or 'scan'. The description only states what the tool does, without any context about when it is appropriate or when to avoid it.

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