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

No annotations exist, so the description carries the responsibility. It does disclose that the tool writes an annotation to a log ring, but it does not explain ring-buffer retention/overwrite behavior or visibility of annotations. Adequate for a benign logging action, not rich.

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

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

Two sentences front-load the action and include a relevant example. Every word adds value; no filler or repetition.

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

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

For a simple two-parameter logging tool, the description gives the essential usage and example. Some gaps remain around level semantics and ring-buffer behavior, but they are unlikely to block correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies the message field via an example but does not explain the level enum values or any default behavior. Required message is implied; optional level remains undocumented.

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

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

The description states a specific action (write) and resource (log ring), plus an example of what to write. It clearly identifies this as a custom annotation tool, though it does not explicitly contrast with sibling log/notification 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?

It explicitly says to use this for marking phases of an agent run and provides a concrete example. Missing when-not-to-use or alternative routing, but the intended 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?

The description reveals a multi-stage pipeline and an asynchronous apply timing (~2s after world load), which is useful behavioral context. However, with no annotations, it leaves important behavior undisclosed: what happens on validation failure, whether the batch is destructive or reversible, and whether a loaded world or bridge connection is required.

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 tight sentences with no fluff: the first packs the entire verb pipeline and the second adds a crucial timing detail. Every word earns its place, and the core action 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?

For a 5-parameter mutation-like tool with no output schema and no annotations, this is too sparse. It lacks prerequisites (loaded world, bridge availability), failure behavior, what the op batch format should be, and what the tool returns. The timing note is useful, but an agent is left guessing about preconditions and side effects.

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

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

Schema description coverage is only 40% (dryRun and filename are described), so the description must compensate. It does clarify that ops is a 'raw MapDev op batch' and that translation is part of the flow, which indirectly touches autoTranslate. But it leaves name and autoTranslate underspecified and gives no detail about op structure, so compensation is only partial.

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 multi-verb pipeline ('Translate + validate + send') with a clear resource ('raw MapDev op batch') and destination ('to the bridge'). This distinguishes it from siblings like omni_batch_validate (validation-only) and the block/item translate tools, though it does not name alternatives explicitly.

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 sending and applying a batch to the bridge, but gives no explicit when-to-use guidance or exclusions. The timing note ('engine applies it within ~2s of the world being loaded') hints at asynchronous context, but does not state prerequisites or when an agent might prefer a sibling tool like omni_batch_validate.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the critical safety property ('WITHOUT sending it'), specifies return values (cleaned batch + errors/warnings), and gives concrete validation examples. An agent knows exactly what side effects to expect (none) and what the tool will report.

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?

One dense sentence that front-loads the most important safety fact ('WITHOUT sending it') before the return-value summary and examples. Every clause earns its place; no filler.

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

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

Return structure and safety are well covered, and the main parameter is documented in the schema. However, name and autoTranslate semantics are missing and no output schema compensates, so the description is not fully complete for all three parameters.

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

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

Schema description coverage is only 33% — only 'ops' is documented. The description does not explain the meaning of 'name' or 'autoTranslate', and 'Translate' only weakly hints at the autoTranslate parameter. It adds no value for the undocumented parameters, so the low schema coverage is not 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?

States a specific verb+resource: 'Translate and validate a raw MapDev op batch'. The phrase 'WITHOUT sending it' clearly distinguishes this from applying tools like omni_batch_apply and tells an agent exactly what scope the tool operates in.

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 implies a dry-run/pre-validation use case before an actual batch send. It does not explicitly name alternatives or when-not conditions, but the context is unambiguous and sufficient for an agent deciding between validation and application.

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, and it discloses the fuzzy-match behavior, the sources searched, and the exact composition of results (exact matches, aliases, unmapped 1.20 names). It does not explicitly state read-only status or error behavior, but the search framing makes the lack of side effects reasonable to assume.

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 filler. The first sentence establishes action and scope; the second precisely defines output categories. Every clause contributes useful information for invoking or interpreting 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?

The description explains the result categories but omits the output record structure, empty-result behavior, and how 'limit' is applied. With no output schema and no annotations, an agent still lacks some details needed to fully interpret or trust the response.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It hints at the 'kind' parameter by mentioning '198 blocks / 187 items', and 'Fuzzy search' implies the semantics of 'query', but it does not explain 'limit' or the default behavior of 'kind'.

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 begins with a specific verb ('Fuzzy search') and identifies the resource ('1.8 registry... and the alias table'), then enumerates the three result categories. This makes the tool's function unmistakable and clearly distinguishes it from sibling translation tools such as omni_block_translate and omni_item_translate.

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 for discovering block/item names and their 1.8 status, but it never explicitly states when to choose this tool over the translate siblings. It provides no exclusions or alternative routing, so the intended usage context must be inferred.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the operation is a one-to-one translation and returns one of three statuses (translated, passthrough, unresolved), plus the engine-level fact that no alias table exists. This is meaningful, but it does not clarify the exact role of the meta parameter or behavior on invalid input.

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 core action is front-loaded, and the critical usage warning is placed at the end. Every sentence earns its place.

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

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

The description covers the essential call pattern, the return statuses, and a strong usage condition. However, given no output schema and no annotations, it should explain the meaning of 'passthrough' and 'unresolved' and clarify the meta parameter's role. These omissions leave an agent uncertain about edge cases and optional inputs.

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

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

Schema description coverage is only 50% (id is described, meta is not). The description mentions 'with metadata' but does not explain the meta parameter's semantics, whether it is input or output, or when it is needed. This is a real gap because the tool name includes 'block_translate' and the schema leaves meta undocumented.

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

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

The description states a specific action and resource: 'Translate ONE 1.20 block id to its 1.8 form (with metadata)' and distinguishes the tool by emphasizing it is the pre-op translation function with no alias table in the engine. This clearly separates it from siblings like omni_block_search or omni_item_translate.

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

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

The description explicitly says when to use it: 'before any 1.20 block name goes into an op' and gives the reason ('there is NO alias table on the placement path in the engine'). It does not name alternative tools or exclusions, but the usage context is strong and sufficient for this tool.

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

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

With no annotations present, the description carries the behavioral disclosure burden. It discloses the key behaviors: producing a full op list and only applying changes when apply=true, which implies the default is non-destructive. It does not mention error handling or size limits, but it covers the core execution model and output 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?

Two tightly worded sentences: purpose first, then output behavior and the apply flag. Every clause contributes useful selection and invocation information, with no filler.

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

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

The description explains the overall flow and return purpose, which is useful given there is no output schema. However, the steps union is large and the description does not ties step construction to the omni_shape_* tools, does not mention validation behavior, and leaves batchName entirely unexplained. It is adequate but not fully self-sufficient for a complex input schema.

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

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

Schema description coverage is only 33%, so the description needed to compensate for the unocumented steps and batchName parameters. It only vaguely says 'list of named operations' and never explains the step object structure, supported kinds, or the batchName default. Worse, 'named operations' could mislead an agent into adding a 'name' field, since the schema's step items have no such property.

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 an active verb and a clear resource ('Run any sequence of high-level shape calls') and distinguishes itself from the single-shape omni_shape_* tools by emphasizing a single round-trip and a batch-consumable op list. Mention of feeding into omni_batch_apply makes the orchestration role explicit.

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 clearly frames when to use the tool: when multiple shape calls should be composed in one round-trip rather than issued separately, with an explicit path to omni_batch_apply or auto-applying. It does not spell out when-not-to-use cases, but the context is strong enough for an agent to select it appropriately.

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

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

With no annotations, the description carries the behavioral burden. It discloses the core side effect (broadcast), the visual style (blue), and the '[Agent]' prefix, but omits broadcast scope, whether the message persists, and whether any response is returned.

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?

One short sentence with no filler. The core action and output format are front-loaded and immediately understandable.

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 one-parameter tool with no output schema, the description covers the basic purpose and presentation. However, it leaves out who receives the broadcast, whether the chat line is ephemeral, and what the '[Agent]' prefix means, so it is adequate but not 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%, and the description never mentions the 'message' parameter or its constraints. The parameter name is self-explanatory and the schema fully specifies limits, but the description adds no semantic value beyond that.

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?

'Broadcast' is a specific verb and 'blue [Agent] chat line' defines the resource and output format, distinguishing it from siblings like omni_command or omni_logs. It does not explain who receives the broadcast or what '[Agent]' refers to, so it stops short of a 5.

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 no guidance on when to use this tool versus alternatives such as omni_notifications, omni_logs, or omni_command. Context is only weakly implied by the 'chat line' wording.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by stating that commands run with full privileges (a meaningful safety signal), are player-anchored, and produce chat feedback. It could still be more explicit about side effects, irreversibility, and failure behavior, but the privilege warning is valuable.

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 with no wasted words. It front-loads the core purpose, then adds the privilege/anchor qualifiers, and finishes with the response behavior. Every clause 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 one-parameter tool, the description covers the essentials: what it runs, the privilege level, anchoring, and a hint about the response. However, 'Response includes chat feedback' is vague, and there is no output schema to clarify the response shape. Given the broad and potentially dangerous nature of a full-privilege command runner, a bit more detail about failure modes or side effects 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?

The schema already documents the single 'command' parameter with 100% coverage, including the important 'without the leading /' detail. The description adds context about privilege and anchoring but no additional parameter-level semantics, so it stays at the baseline.

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

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

Description uses a specific verb ('Run') with a clear resource ('any in-game command') and adds two useful qualifiers: full-privilege and player-anchored. This clearly distinguishes it from the many specialized omni_* siblings, which handle targeted operations like shapes, item translation, or world management.

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 is a generic catch-all for arbitrary in-game commands, but it does not explicitly say when to prefer a dedicated sibling tool over omni_command. There is no guidance about exclusions, such as 'use omni_shape_* for shape operations' or 'use omni_item_translate for item translation', so the usage context is only 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 present, the description carries the full burden of behavioral disclosure. It does disclose a key side effect: 'host/port/token changes affect every subsequent bridge call in this session', which is genuinely useful. However, it does not mention whether updates are validated, require any preconditions, or are reversible per call, so some behavioral context remains implicit.

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 carry all essential information: purpose first, then the persistent-effect warning, then practical use cases. There is no filler or repetition; every clause 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 config tool with multiple parameters, no output schema, and no annotations, the description covers the purpose, the session-scoped impact, and the main invocation scenarios. The schema already documents individual parameters, so the description does not need to enumerate them; it supplies the missing operational context.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that host/port configure a different device and that token typically comes from omni_pair. This links parameters to concrete workflow context rather than just restating their types.

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

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

The description opens with 'View or update the live MCP connection config', a concrete verb+resource pair that states exactly what the tool does. It also distinguishes the tool by specifying that host/port/token changes affect subsequent bridge calls, which sets it apart from sibling tools like omni_ping or omni_state. No ambiguity remains.

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, actionable use cases: 'point at a different device' for host/port and 'set a token obtained by omni_pair' for token. It clearly implies when to call this tool, though it does not name excluded scenarios or direct alternatives beyond omni_pair as a token source.

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

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

With no annotations, the description carries the behavioral burden. It discloses the NO-OP envelope when no devpatch is active, names the three return categories, and 'Compare' implies a read-only operation. It stops short of stating error behavior or explicitly confirming no side effects.

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

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

Three concise sentences, each earning its place: the operation, the return categories, and the no-active-devpatch edge case. It is front-loaded with the primary verb and resource.

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?

Because there is no output schema, the description compensates by naming the return categories and the no-op edge case. It omits error behavior and explicit read-only confirmation, but for a straightforward verify tool the description is largely complete.

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

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

The schema provides no descriptions for `files`, `path`, or `sha256`, and the description only hints that the input is source-file hashes. This is enough to orient an agent, but it does not explain path scope, hash formatting, or the effect of an empty or missing `files` array.

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

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

The description states a specific operation — comparing source-file sha256 values against the active DevPatch inventory — and enumerates the result categories: changed_since_patch, missing, matches. It does not explicitly name a sibling tool, but the DevPatch resource is distinct enough that purpose is clear.

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 intended use case is implied: verify source files against the active DevPatch inventory. The NO-OP envelope also signals that calling without an active devpatch is safe, but there is no explicit guidance about when to prefer this over alternative verification or inspection tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose key behavior: 'min severity hardcoded to WARN' and positions itself as a convenience layer over /omni/logs. However, it does not explain output format, filtering semantics, pagination, or error handling, leaving some behavioral ambiguity for a wrapper tool.

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

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

The description is two short sentences in which every clause earns its place: it defines the wrapper, states the hardcoded severity, and gives a clear usage directive. It is appropriately sized and front-loaded with the most important information. This is exemplary conciseness for a small wrapper 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?

For a tool with four optional parameters, no output schema, and no annotations, the description is incomplete. It explains what the tool is conceptually but leaves the meaning of all four parameters unexplained and does not describe the return structure. The 'use this first' guidance helps, but the overall context for calling it correctly in varied situations is lacking.

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

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

Schema description coverage is 0%, and the description provides no explanations for q, limit, since, or source. These parameters are entirely undocumented in both the schema and the description, so an agent has no basis for knowing how to use them correctly. The description only references severity behavior and does not compensate for the missing parameter 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 identifies this as a convenience wrapper for /omni/logs with a hardcoded minimum severity of WARN, which distinguishes it from the omni_logs sibling. The phrase 'Use this first when something looks wrong' reinforces the intended purpose of retrieving error-level log entries. It is not a tautology and names the specific resource and behavior.

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

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

The description explicitly says 'Use this first when something looks wrong,' giving clear guidance on when to invoke the tool. It also references /omni/logs as the underlying tool, implying that omni_logs is the alternative for more flexible severity filtering. However, it does not explicitly state when to prefer omni_logs over this tool or list exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully reveals that the tool returns the running device's own endpoint list and is self-describing, but it does not describe the output format, potential size, or whether the list includes sibling tools explicitly.

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 short and conveys the essential information in two sentences. The first sentence is slightly awkward and could be more direct, but it contains no waste and the usage guidance is front-loaded at the end.

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 zero-parameter introspection tool with no output schema or annotations, the description provides adequate context: what the tool is, what it returns, and when to use it. It could mention how to interpret the returned catalog, but the core information needed to invoke it correctly is present.

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

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

The tool has zero parameters and 100% schema description coverage, so the schema already fully documents the input surface. Per baseline for parameterless tools, the description does not need to add parameter semantics, and it doesn't.

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

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

The description clearly identifies the tool as a 'self-describing endpoint catalog' and explains that the engine returns its own list. It conveys the resource and action well enough to distinguish it from sibling tools, though the phrasing is somewhat jargon-heavy and lacks a direct verb like 'list'.

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 it: 'Use this to discover platform-specific additions.' This gives clear context for the primary use case, but it does not mention exclusions or contrast with sibling tools that might also relate to platform discovery.

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

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

No annotations are provided, so the description carries the full burden. It discloses the exact composition of returned data (slot id, label, item id, count, meta, damage) and covers the inventory sections, which gives useful context. However, it never explicitly states that the operation is read-only, nor does it describe side effects, error behavior, or performance characteristics.

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 entire description is a single line with no filler words. It front-loads the scope ('Full inventory, hotbar, and armor') and packs the field details into a compact parenthetical, making every word 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?

With no output schema, the description must explain what the tool returns, and it does: the inventory sections and their six fields. It leaves the structural grouping of those sections unspecified, but an agent can reasonably understand the expected data. Minor gaps exist around error cases and whether this requires an active world connection.

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

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

The tool has zero parameters and the schema is empty with 100% coverage, so there is nothing to document. The parenthetical detail in the description is about the return format, not parameters, and it does not need to explain missing parameters. A baseline of 4 is appropriate for a no-parameter tool.

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

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

The description names the resource (inventory, hotbar, armor) and the data fields included, so the agent can infer this is a read operation that returns a snapshot of the player's equipment. However, it lacks an explicit verb like 'get' or 'list' and does not distinguish itself from sibling tools such as omni_player or omni_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?

There is no mention of when to use this tool versus alternatives, no context about prerequisites (e.g., being in a world), and no exclusions. The agent receives no guidance on how this relates to omni_player, omni_state, or other inventory-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?

No annotations are present, so the description carries the behavioral burden. It does disclose the transformation direction and that metadata is involved, and 'translate' implies a pure lookup; however it does not state side-effect behavior, handling of unknown ids, or whether meta is input vs output.

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

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

Two sentences, front-loaded with the operation and scope; the registry-size detail is compact and the sibling reference saves repetition.

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

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

For a simple two-parameter translation tool the description gives the core selection and direction, but with no output schema and no annotations it omits return format, meta handling, and error behavior, leaving the agent to consult omni_block_translate for the contract.

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 only loosely identifies id as the 1.20 item id and mentions metadata; it does not explain the meta parameter's role, default when omitted, or accepted input format. It relies on 'same rules as omni_block_translate' for details.

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

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

States a specific verb ('Translate') and resource ('1.20 item id' to '1.8 form'), scopes to the item registry, and contrasts with omni_block_translate so an agent can distinguish sibling translation tools immediately.

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 first sentence clearly indicates when to call it: when a 1.20 item id needs converting to 1.8. 'Same rules as omni_block_translate' points to an established sibling contract, though it does not spell out conditions when the block variant should be used instead.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does convey that this is a read-only fetch of static content, which is useful. However, it does not mention what the response looks like, whether content is large or paginated, or what happens when topic=all is requested.

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 front-loads the core action and resource, then lists topics efficiently. There is no filler or redundancy, and every clause adds useful context.

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

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

For a simple static knowledge-base lookup, the description covers the main topics and communicates read-only behavior. However, the absence of an output schema and annotations, plus missing enum values and no return-format details, leaves some gaps that an agent may need to discover by calling 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?

Schema description coverage is 50%: pitfallId is documented in the schema but topic is not. The description adds meaning to several enum topics ('recipe shapes', 'staging paths', 'endpoint catalog') beyond the bare labels, but it omits mapdev, repos, and all, and does not explain the pitfallId parameter or its relationship to topic=pitfalls.

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 ('Fetch') and a specific resource ('the static OmniMod knowledge base'), then enumerates the main topic areas it covers. This makes the tool's purpose clear, though it does not explicitly differentiate it from sibling documentation tools like omni_help or omni_map_docs.

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 given for when to use this tool versus alternatives like omni_help, omni_map_docs, or omni_map_guide. The word 'static' implies it is for fixed reference content rather than live state, but there are no explicit conditions, exclusions, or routing hints.

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 of behavioral disclosure. It shares parameter mechanics (sequence cursor, min severity, substrings, tail bytes) but does not disclose whether the operation is read-only, how the ring buffer behaves at the edges, whether output is ordered, or any performance/rate considerations. The 'log ring' phrasing hints at a circular buffer, but little else.

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?

A single dense sentence that front-loads the resource and severity range, then enumerates filter parameters compactly. No filler words or redundant restatements of the tool name.

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

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

For a six-parameter tool with no output schema and no annotations, the description leaves key context unstated: what the return payload looks like, whether results are ordered, default behavior when no arguments are supplied, and ring-buffer retention/capacity semantics. The parameter semantics are well covered, but the overall tool contract is incomplete.

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, so this text is the sole semantic source for parameters. It clarifies all six: 'since' as a sequence cursor, 'level' as minimum severity, 'source' and 'q' as substrings, 'tail' as file-tail bytes, and 'limit' in the context of a log list. This fully compensates for the bare 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 identifies the resource (in-game log ring), the severity spectrum (TRACE..FATAL + AGENT), and lists filtering capabilities, making it clear this is a log retrieval/filtering tool. It stops short of an explicit action verb like 'read' or 'list', and doesn't actively distinguish from omni_agentlog or omni_errors, but the built-in filters and AGENT level hint at its scope.

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

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

No guidance is given on when to use this tool vs the many log/state siblings such as omni_errors, omni_agentlog, or omni_notifications. It implies log access with filtering, but does not state when it is appropriate, when it is not, or which alternatives to prefer.

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 disclosure burden and does it well: it explains that static docs are rewritten only when missing/version-stale, and that MAP_OVERVIEW.md / CHANGE_LOG.md / FILE_MAP.md are seeded only when absent and never overwritten. This gives the agent a clear mental model of what will and won't be mutated on disk.

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 tightly packed sentences: main action, precise overwrite semantics, and usage context. Every sentence earns its place with no filler or repetition.

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

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

Covers the tool's purpose, write behavior, non-destructive seeding rules, and when to apply it. Minor gaps remain, such as what the tool returns and how the optional parameters interact, but these are partly covered by the schema and are not critical for correct invocation. For a mutating bootstrap tool with no annotations or output schema, this is above average.

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 parameters are already fully documented in the schema. The description does not add parameter-specific meaning, so the baseline 3 applies. There is no missing compensation 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?

Uses a specific verb pair ('Create or repair') and a precise resource ('agent context pack inside a map folder'), and clearly distinguishes itself from the many omni_map_* siblings by describing its provisioning/repair role. The description makes its purpose unmistakable even without comparing schemas.

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 the intended use case: 'Use this for map folders the running game has not provisioned' with concrete examples (copies pulled off a device, exported maps, Web-target saves). It lacks an explicit when-not-to-use or named alternative, but the context is clear enough to route an agent correctly.

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 disclosure and does it well: append-only, 'existing history is never rewritten,' and the correct-by-appending workflow. This makes the non-obvious side effects visible without needing initialization or auth details.

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

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

Three sentences, each adding a distinct fact: core action, mandatory usage, and correction/read modes. No repetition, no filler, and the main verb appears first.

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 core behavior, required usage context, and mode switching are all covered, and the schema documents the remaining parameters. It does not state return values or failure behavior, but with no output schema and 93% parameter coverage this is a minor gap.

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

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

Schema coverage is 93%, so the baseline is 3. The description goes beyond the schema by explaining how corrects and read alter the behavior, which is parameter-level semantic guidance the schema does not provide.

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 opens with a specific verb and resource: 'Append an entry to a map's CHANGE_LOG.md.' It distinguishes the write mode from read mode and from correction-by-append, making the tool's 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?

It states 'Required at the end of every task,' giving an explicit trigger. It also explains when to use read:true and how to handle corrections via corrects rather than editing, so an agent knows the three invocation variants.

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

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

With no annotations provided, the description fully carries the behavioral disclosure burden. It explains side effects of PLAY mode (command blocks become invisible/unopenable/unbreakable/untargetable while logic continues), persistence, race-free scheduling, instant rebuild, and the critical caution that hiding never disables logic.

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

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

The description is longer than average but every sentence carries operational value, and the most important behavior is front-loaded. The final sentence about the unified kernel is minor context but not redundant. It is structured well with mode definitions and consequences.

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

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

For a tool with no output schema and no annotations, the description covers invocation, mode semantics, aliasing, persistence, concurrency behavior, post-switch verification, and relationship to other interfaces. An agent has enough information to call the tool correctly and interpret its expected behavior.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining the real-world effect of each mode value, the preview alias, and the no-args query behavior. The 'by' parameter is adequately covered by 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 identifies the tool as a dual-mode switch for the running map, supports both switching and querying, and precisely defines DEV vs PLAY behavior. It distinguishes itself from sibling tools by focusing on mode state and switching semantics rather than status or map file operations.

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

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

It explicitly states that calling with no arguments queries the current mode, and it describes what each mode value does and when to verify after switching. It does not explicitly name sibling alternatives to avoid, but the usage context is clear and actionable.

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

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

There are no annotations, so the description carries the behavioral disclosure burden. It reveals that the tool exposes apply-ledger state and the current map name, implying a read-style status query, but it does not explicitly state read-only behavior, side effects, or error 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?

The description is extremely short and contains no filler, making it easy to scan. It is more of an elied noun phrase than a full sentence, which slightly reduces structural 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?

For a zero-parameter status tool with no output schema, the description names the two main pieces of information returned: MapDev apply-ledger state and current map name. However, 'apply-ledger state' is not explained, and there is no context on how to interpret it or what variants may exist.

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

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

The tool has zero parameters and the input schema covers everything; there is nothing for the description to add. Per the baseline for parameterless tools, a 4 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 identifies a specific resource ('MapDev apply-ledger state') and an additional output field ('current map name'), which is more informative than a tautology. However, it lacks an explicit verb like 'gets' or 'reports', so the action is only implied.

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 given about when to use this tool instead of siblings such as omni_map_status or omni_mapdev_mode. The agent is left to infer the use case from the tool name and the brief description.

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 behavioral burden. It communicates that the operation is a read and that it depends on a prior onboarding step, which is useful. However, it does not disclose failure modes for missing or invalid file paths, whether the tool returns raw file contents versus metadata, or what happens when the map is not yet onboarded.

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 and front-loads the core action ('Read specific documents') before giving usage direction. Every clause earns its place, with no filler or redundant restating of the tool name.

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

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

For a simple read tool with fully documented optional parameters, this description gives enough context for an agent to choose and invoke it: the prerequisite, the use case, and parameter examples are all present. There is no output schema, so a bit more detail about the return shape would improve completeness, but it is not a blocker for correct invocation.

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

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

Schema description coverage is 100%, so the parameters are already well documented in the input schema. The description adds a useful example for the `files` parameter and echoes the omit-to-list behavior, but it does not materially expand on the schema's semantics beyond that.

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 specific documents') and the resource ('a map's agent context pack'), and it distinguishes this tool from omni_map_onboard by framing it as a follow-up lookup tool. However, it does not explicitly differentiate from closely named siblings like omni_map_filemap or omni_map_changelog, which leaves some ambiguity about which tool handles file listing or change-log-specific reads.

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 sequencing: 'Use omni_map_onboard first; use this for targeted lookups afterwards.' It also provides concrete examples of when to invoke it (troubleshooting file, change log). It stops short of listing when not to use it versus sibling map tools, so it is clear but lacks explicit exclusions.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It explains the source of truth ('real folder contents'), what files are included, that unparseable batches are flagged, and that world data files are marked off-limits. It does not explicitly say the existing FILE_MAP.md is overwritten or require permissions, but 'Regenerate' strongly implies replacing the file.

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

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

The description is a single dense sentence with the action front-loaded, followed by the output contents and a clear trigger. Every clause contributes useful information, though the long enumeration makes it slightly harder to parse quickly.

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

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

Given no annotations and no output schema, the description covers the key contextual needs: what gets regenerated, what data is included, which files are marked off-limits, and when to run the tool. It does not describe the tool's return value or errors, but the purpose is essentially to rewrite a file, so the outcome is clear enough for selection and invocation.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. The description references 'a map' generically but does not add extra meaning about map vs mapDir vs worldsDir precedence or the agent parameter beyond what the schema already documents. This is acceptable because the schema fully covers parameter 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 opens with a specific verb and object: 'Regenerate FILE_MAP.md'. It then enumerates the exact contents that will be regenerated, including files under _dev/ with owner/size/mtime, world data marked off-limits, batches with op counts, verification reports, and sibling mod-staging folders. This clearly distinguishes it from map_status and map_overview, which are likely read-only reporting tools.

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

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

The description explicitly states when to run the tool: 'after creating, renaming or deleting ANY file in the map.' This is strong usage guidance for an agent deciding whether to invoke it. It does not mention when not to use it or name an alternative tool, but no sibling directly performs the same regeneration task.

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?

There are no annotations, so the description carries the behavioral disclosure burden. It clearly conveys this is a read-only reference guide, states that it mirrors the omnimod resource, and gives session cadence. It does not explicitly state the return format, but for a zero-parameter knowledge tool the content and usage are sufficiently transparent.

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

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

Two sentences with no filler. The first sentence front-loads the tool's identity and content, and the second provides usage timing plus the alternative tool. 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?

For a no-parameter, no-output-schema knowledge tool, the description is complete: it explains what the guide covers, when to read it, and which sibling offers the condensed version. An agent can select and invoke this tool correctly without additional context.

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

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

The tool has zero parameters and schema coverage is 100%, so the baseline for parameter semantics is 4. No parameter documentation is needed because there is nothing to pass, and the description adds no parameter details without needing to.

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

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

The description states a specific purpose: a complete professional map-development master guide, and enumerates its content areas (8-phase workflow, command surface, functions, testing, verification, handoff). It also differentiates itself from the compact summary provided by omni_knowledge, so an agent can tell what this tool offers.

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 the agent when to use the tool ('Read this once per session before building a map') and names the alternative for a lighter summary ('use omni_knowledge(topic="mapdev")'). This is direct and actionable selection 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?

With no annotations, the description carries the full burden of behavioral disclosure. It implies a read/verify operation by saying it 'verifies' and 'reports missing/outdated/unwritten documents,' but the autoBootstrap parameter defaults to true and 'Create or repair the pack when documents are missing or version-stale.' The description does not disclose this potential side effect, making the tool seem safer/more read-only than it actually is.

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 strong front-loading: 'START HERE for any map task.' It packs purpose, action, output, and usage timing without wasted words. Every clause 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?

The description covers when to run it, what it returns, and how it relates to the bridge/knowledge base. However, it omits the autoBootstrap side-effect behavior and does not describe error or missing-folder behavior. Given there is no output schema and no annotations, this is a meaningful gap, though the schema compensates for some parameter-level detail.

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

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

Schema description coverage is 100%, so the schema already documents map, full, autoBootstrap, and the boolean flag with defaults. The description adds some context by linking 'map folder' to the map parameter, but it does not meaningfully extend the schema's parameter explanations. 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 is explicit: 'Locates the map folder, verifies the per-map agent context pack, and returns the mandatory documents...' It names a specific verb, resource, and concrete output, and anchors itself as 'START HERE for any map task.' This clearly distinguishes it from sibling map tools by establishing it as the onboarding entry point.

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 timing: 'Run this before your first batch on a map, even when connected to the bridge.' It also contrasts itself with the MCP knowledge base, explaining why the pack matters for the specific map. It does not explicitly name alternatives or when-not-to-use cases, but the guidance is strong enough for an agent to know when to invoke 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 carries the behavioral burden. It discloses that the tool can both read and replace, that the file is persistent shared state containing the goal and specification, and that correcting previous agents' errors is expected behavior. It could add a warning that replace overwrites existing content, but 'replace' already communicates mutation.

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

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

The description is compact and front-loaded: the first sentence states the operation, the second gives timing/context, and the third enumerates sections. Every sentence earns its place and there is no redundant filler.

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

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

For a tool with no output schema and an explicit input schema, the description sufficiently covers the artifact, the action modes, when to use it, and the section semantics. It does not explicitly describe reading a single section versus the whole file, but the schema already covers the whole-file read behavior and section replacement semantics, so this is not a blocking gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real value by mapping each section number to its intended content (Identity, user goal, build specification, coordinate conventions, etc.), which helps an agent choose the correct section. It also explains why the file matters by naming the goal and coordinate conventions that live there.

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 names the exact artifact (MAP_OVERVIEW.md) and states both modes of operation: read the whole file or replace a numbered section. This is a specific verb+resource pairing that clearly sets it apart from generic sibling tools like omni_map_docs or omni_map_guide.

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

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

It gives explicit guidance on when to write (BEFORE building) and when to correct (whenever a previous agent recorded the goal wrongly), which tells an agent when this tool is the right memory-maintenance tool. It does not enumerate when not to use it or name alternatives, but the situational guidance 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 means the description carries full disclosure burden. It reveals the key behavioral trait — writing to `worlds/<map>/_dev/state/verification/` and the template mode that avoids writing — but does not disclose whether existing reports are overwritten, what the tool returns after a write, or what happens when required content is absent. Adequate but with notable gaps.

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. The core action and destination are front-loaded in the first sentence, and the second sentence adds the critical workflow variant. 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?

The description fully covers the two modes (write vs template) and the target directory, which is the core flow. However, with no output schema and no annotations, it leaves return behavior, overwrite semantics, and the interplay of `map` vs `mapDir`/`worldsDir` undisclosed. For a mutating 6-param tool this is a gap, though the schema covers parameter meaning.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine value beyond the schema: the path template `worlds/<map>/_dev/state/verification/` explains how `map` is interpolated into the filesystem location, and the `template: true` example reinforces the `template` parameter's purpose. These tie schema fields to real usage meaningfully.

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

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

The description states a specific verb (Write), a specific resource (verification report), and the destination path (worlds/<map>/_dev/state/verification/), making the core function immediately clear. It does not explicitly name a sibling it differs from, though among tools like omni_devpatch_verify the report-writing role is clear enough that an agent can tell them apart without opening the schema.

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

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

"Every task owens one" gives clear situational context: this tool is mandatory per task, not optional. The instruction to pass `template: true` to get the blank skeleton also lays out the intended workflow (template first, then fill in). It lacks explicit when-not-to-use guidance or alternatives, but the context is strong enough for selection.

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

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

No annotations exist, so the description carries the full behavioral burden. It explicitly promises no mutation and details exactly what aspects of the map/workspace state will be surfaced: document existence, staleness, unwritten living documents, batch presence, ledger op/placed/failed counts, and verification reports. This gives an agent a realistic picture of the tool's read-only behavior and output coverage.

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

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

The description is front-loaded with the core purpose and then uses a colon-led enumeration to pack a lot of useful specificity into a single sentence. It is dense but not wasteful, though the long run-on structure is slightly harder to scan than clearly separated sentences would be.

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 that there is no output schema and no annotations, the description compensates well by naming the categories of status information an agent can expect. It does not explicitly address behavior when no parameter is supplied or the meaning of parameter precedence, but the schema already documents each parameter, and the overall description is sufficient for a read-only status query.

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?

All three parameters are fully described in the schema at 100% coverage, so the schema does the heavy lifting. The description adds broad workspace/map context but provides no additional parameter-level details such as precedence, defaults, or accepted formats, so it neither earns above baseline nor loses credit.

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 opens with a specific verb and resource, 'Verify a map's context pack and workspace without changing anything,' and then enumerates concrete status checks: documents, stale versions, unwritten living documents, batches, the apply ledger, and verification reports. This makes the tool's purpose unmistakable and distinguishes it from the many sibling map/status tools that are about mutation, scanning, or reports.

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 conveys a clear read-only verification context by saying 'without changing anything' and labels the operation as 'Level 1 verification without the HTTP bridge,' which helps an agent understand when to call it. It does not explicitly name sibling alternatives or list when-not conditions, so some routing decisions are still left to inference.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It honestly states that the mod is only staged and will not be active until the next world load, and even explains how to force activation on a running world. It does not cover potential overwrite/conflict behavior or error states, so it stops short of 5.

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

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

Two packed sentences: the main action is front-loaded, and the activation consequence is explained immediately. 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 the moderate complexity and the absence of annotations/output schema, the description covers the essential lifecycle: staging, deferred pickup on next load, and reload instructions. The main gap is that it does not explain what happens when 'world' is omitted or what result/output the agent should expect, but the core calling behavior is clear.

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

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

Schema description coverage is only 33%, so the description must compensate. It explains that dataB64 holds the base64-encoded JAR bytes and that the operation targets a world, but it does not clarify the meaning of the required 'filename' parameter or the behavior of the optional 'world' field. It adds meaningful context beyond the schema but does not fully compensate for the coverage 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 uses a specific verb ('Stage') with a clear resource ('a mod JAR') and target ('a world'), then explains the activation model. This distinguishes it from sibling tools like omni_mod_scaffold (creating mods) and omni_mod_inspect (examining mods).

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 clearly states the tool is for staging a mod JAR and gives explicit activation guidance: the next world load picks it up, and if a world is running, reload via omni_world_quit + omni_world_enter. It does not explicitly exclude alternatives or state when not to use it, but there is little ambiguity about the intended 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?

With no annotations, the description carries the full transparency burden. It does disclose that the tool parses and returns models/recipes/GUIs and a problem list with engine-code citations, which gives useful expectations. However, it never explicitly states whether the operation is read-only or has side effects, and it omits failure/performance behaviors for large or malformed mods.

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 tight, front-loaded sentences: the first identifies the target and accepted input; the second summarizes output categories and problem-list content. There is no filler or repetition of schema details.

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

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

For a tool with one well-covered parameter, the description is largely adequate for invocation. However, with no output schema and no annotations, the broad terms 'metadata', 'file counts', 'parsed models/recipes/GUIs', and 'problem list' leave the return structure underspecified, which could hurt downstream result interpretation.

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

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

The input schema already fully documents the single required 'path' parameter as an absolute path to a mod JAR or folder (100% coverage), so baseline is 3. The description only restates this as 'JAR or unzipped folder,' adding negligible semantic value beyond the schema.

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

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

The description states a specific verb ('Inspect'), a clear resource ('a Forge mod (JAR or unzipped folder)'), and enumerates the outputs (metadata, file counts, parsed models/recipes/GUIs, problem list). This makes the tool's role clear and it is naturally distinct from sibling mod tools like omni_mod_add or omni_mod_scaffold, though it does not explicitly name those alternatives.

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

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

The description gives no guidance about when to prefer this over the many mod-related siblings (e.g., omni_batch_validate, omni_mod_add, omni_recipe_validate) or what conditions make it the right choice. The only usage signal is the generic 'Inspect' verb, which is implicit rather than explicit exclusion/inclusion 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?

With no annotations provided, the description carries the full burden and does disclose key behavioral traits: output is a folder rather than a ZIP, zipping is the caller's responsibility before omni_mod_add, and a folder-staging alternative exists. The statement that every JSON key written is one the engine reads also sets expectations about the scaffold's fidelity. It could mention error behavior or overwrite semantics, but the core behavior is clearly communicated.

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 with no filler. It front-loads the main action, then gives the critical output-format caveat and workflow context, and closes with a useful guarantee about JSON keys.

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 complex, with a large nested spec schema, no output schema, and no annotations. The description covers the essential workflow and output format, but it does not address the supported mod loaders implied by the schema, potential validation failures, or how to construct the spec correctly beyond the schema itself. The mention of scaffold.ts comments is not directly actionable from the description alone.

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

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

Schema description coverage is 50%: outDir has a description, but the large nested spec object has none. The description does not explain the individual spec fields, though the schema's property names and types are mostly self-descriptive. The note that every JSON key written is read by the engine adds confidence but does not compensate for the lack of guidance on complex nested structures like guis, recipes, or extraAssets.

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

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

The description explicitly states the tool writes a mod folder to disk and identifies the specific output type (folder, not ZIP). It also differentiates from omni_mod_add by describing the required workflow: zip it yourself before omni_mod_add or stage via the folder mod path.

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 clear usage context by explaining what happens after scaffolding: zip it before omni_mod_add or use the folder mod path on the engine side. It does not enumerate exclusions or alternative tools beyond omni_mod_add, but the guidance is sufficient for an agent to sequence the tool correctly.

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 behavioral disclosure burden. It does disclose grouping behavior, severity selection, and output shape (count + sample per source), which is useful. It does not mention read-only behavior, time-window defaults, ordering, or any side effects, leaving material gaps.

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 short, information-dense sentences with the core grouping behavior front-loaded. Every clause earns its place: severity categories, grouping key, row format, and compactness are all communicated without filler.

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

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

The description conveys the essential output shape and aggregation behavior for a simple one-parameter tool. It is incomplete because it fails to explain the 'since' parameter, lacks any guidance about when to prefer this over omni_errors/omni_logs, and provides no safety or side-effect information in the absence of annotations.

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

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

Schema description coverage is 0%, and the description does not mention the 'since' parameter at all. With one optional integer parameter present, the agent receives no guidance about its units, meaning, temporal reference, or default behavior, so parameter semantics are effectively absent.

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 identifies the resource as a grouped feed of WARN/ERROR/FATAL issues, one row per source with count and sample, which conveys the tool's purpose. It stops short of a full 5 because it lacks an explicit verb such as 'list' or 'retrieve' and does not name sibling tools for contrast.

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 phrase 'compact issue feed' implies this is an aggregated summary view rather than a full log or raw error dump, which gives some usage context. However, it does not explicitly state when to choose this over omni_errors, omni_logs, or other siblings, nor does it mention any exclusions.

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

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

With no annotations, the description carries the full burden and does well: it discloses that no authentication is required, that the call returns a token, and that the token is persisted into the MCP's live config so future calls work without re-pairing. It does not describe all error or invalidation cases, but the key side effect is clearly stated.

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 filler. The purpose and code source are front-loaded, followed by the crucial auth and persistence notes. 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?

For a single-required-parameter tool with no output schema and no annotations, this is sufficiently complete: clear purpose, exact input source/format, auth status, and post-call behavior. An agent can confidently decide to call it and know what happens afterward.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining where the code comes from (the user's device screen) and restating the 8-character format, which helps an agent know what to ask the user for and how to interpret the 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 names a specific action ('Quick-pair with the device'), specifies the exact input (8-character code), and tells the user exactly where to find it (Options -> Agent Link Info -> Quick Pair Computer). This is clear and complete, and no sibling tool appears to overlap with pairing.

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 implies when to use this tool: when the user provides an 8-character quick-pair code from the Agent Link Info screen. It does not explicitly discuss alternatives or exclusions, but none of the sibling tools obviously compete with this pairing 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?

With no annotations, the description carries the behavioral disclosure burden. It discloses that the call requires no authentication and returns service info, protocol version, and auth requirements. This is sufficient for a liveness probe, though it does not mention side-effect-free behavior explicitly.

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 short sentences with no wasted words. The purpose is stated first, followed by a critical behavioral note about auth and the expected return contents.

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 zero-parameter liveness probe with no output schema, the description provides enough context: what it probes, that auth is not needed, and what it returns. It lacks an explicit statement about when to use it in agent workflows, but the simple nature of the tool makes this a minor gap.

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

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

The tool has zero parameters, so parameter semantics are not applicable. The schema is effectively empty, and the description correctly avoids inventing parameter details. Baseline for 0 parameters is 4.

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

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

The description names a specific verb and resource: 'Liveness probe for the OmniMod Agent Dev Link bridge.' It clearly identifies this as a health-check endpoint and distinguishes it from sibling tools by specifying the bridge as the target.

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 as a liveness check and explicitly notes 'NO AUTH,' but it does not state when an agent should prefer this over sibling tools like omni_pair or omni_state. The context is implied rather than explicit.

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 bears full responsibility for disclosing behavior. It lists action names and notes that per-action fields vary, but does not explain side effects (e.g., attack causing damage, give transferring items), permissions, reversibility, or output behavior. The disclosure is minimal.

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

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

The description is concise and front-loaded with the action list. Every word earns its place; there is no redundancy. However, the second sentence references constraints that are not actually included in the description, slightly reducing its structural utility.

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

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

This is a complex tool with 15 parameters, 13 action variants, no annotations, and no output schema. The description is far too sparse: it lacks per-action parameter requirements, behavior descriptions, and return/result information. An agent would need significant external knowledge to invoke this 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 description coverage is 0%, and the description does not compensate. It only says that per-action fields vary without mapping any of the 15 parameters (x, y, z, all, yaw, item, meta, slot, count, pitch, enable, entity, player, message) to specific actions. An agent cannot determine which parameters are valid or required for a chosen action.

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

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

The description states the resource (player) and enumerates 13 concrete action verbs, giving a clear operational scope. It is distinguishable from sibling tools like omni_world_scan or omni_inventory, though it could be more explicit about 'controlling the player character'.

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 about when to use this tool versus alternatives, no exclusions, and no when-not scenarios. The phrase 'see the per-action constraints' suggests further documentation but none is present in the description, leaving the agent with no decision support.

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

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

With no annotations, the description carries the transparency burden. 'Static linter' strongly signals a read-only analysis and the check list delimitates scope. However, it never says what the tool returns on success/failure or whether invalid recipes produce errors vs warnings, a significant gap for a validation 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?

A single front-loaded sentence contains a clear subject, verb, object, and a tight list of behaviors. There is no filler, and every clause adds useful information.

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

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

For a tool with no output schema and no annotations, the description is incomplete: it omits the return/output contract, the meaning of 'name', and any example of a valid recipe shape. It covers what is checked, but not what the caller should expect back or how to supply the recipe fully.

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

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

Schema description coverage is 0%, so the description must explain parameters. It gives context for the recipe object via validation rules but never mentions the 'name' parameter or what it means. The recipe parameter itself is only referred to generically as 'recipe JSON object' rather than connected to the schema property.

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 ('linter') and a specific resource ('recipe JSON object'), so an agent immediately knows what to invoke it for. It enumerates distinct checks (engine keys, 3x3 pattern, 1.8 registry, 1.20 result form), which differentiates it from siblings like omni_batch_validate.

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 clearly implies the use case: statically validate a recipe JSON object before the engine consumes it. It does not name alternatives or state when not to use it, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions structural components and optional foundation, but it does not state that the tool places/blocks the world, whether it replaces existing blocks, what happens with door positioning relative to doorSide, or any side effects of the one-call operation. This leaves an agent guessing about mutative consequences.

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

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

The description is two short sentences, front-loaded with the core concept and then reinforced with concrete example user intents. There is no repetition, filler, or unnecessary detail; every sentence contributes to tool selection.

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 highly complex (24 parameters, 4 required), has no output schema, and no annotations, yet the description only captures the high-level purpose and use cases. It omits operational details like how width/depth/height map to the structure, how roof styles behave, how the centered door relates to doorSide, and what window band parameters control. An agent could select the tool from this description, but it would not be confident about correct invocation.

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

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

Schema description coverage is only 8% for 24 parameters, so the description would need to compensate heavily. It does add some semantic context by listing house components (foundation, floor, walls, roof, door, windows), and it clarifies the foundation is optional, but it does not map these components to the many parameters or explain key options such as roofStyle, doorSide, or windowsEnabled. This is insufficient for a tool with this many undecumented parameters.

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

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

The description clearly identifies the tool as a one-call generator for a complete house-like structure, listing the concrete components it creates (foundation, floor, walls, roof, centered door, window band). It also gives explicit natural-language triggers ('build me a house', 'build me a tower', 'build me a small castle'), which distinguishes it from the sibling individual-shape tools such as omni_shape_solid_box or omni_shape_gable_roof). It lacks a direct verb like 'builds', but the intent is unmistakable.

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

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

The description gives explicit when-to-use guidance by naming the exact user requests it answers, which is strong signal for an agent deciding between this and the more granular shape primitives. It does not name explicit alternatives or exclusion conditions, so it misses the 'when not to use' half of ideal usage guidance.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It does add useful detail: 'Solid by default' and 'Each y-layer is one or two fill_area runs' reveal fill behavior and implementation. However, it does not state world-modifying side effects, permissions, or reversibility.

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

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

Three short sentences, each carrying distinct information with no filler. The phrasing is very compact, though almost telegraphic, which slightly limits how much guidance it can convey.

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 world-modifying shape tool with six parameters, no annotations, and no output schema, the description is too sparse. It omits coordinate interpretation, how block and meta work, return behavior, and whether the shape is applied immediately.

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

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

Schema description coverage is 0%, and the description never names center, radius, height, block, or meta. The only semantic contribution is 'vertical,' which hints that height maps to the Y axis, but this does not compensate for the missing parameter 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 identifies a vertical cylinder and states it is solid by default, which distinguishes it from other shape tools. The phrase 'fill_area runs' implies the tool generates fill operations, though no explicit verb like 'create' or 'fill' is present.

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?

There is no guidance on when to use this tool versus sibling shape tools such as omni_shape_sphere or omni_shape_pyramid. No exclusions, alternatives, or conditions are mentioned beyond 'solid by default.'

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 provides useful geometry behavior—'Ridge runs along the given axis' and 'Each course is two fills (both slopes)'—beyond the input schema. Yet with no annotations, the burden is on the description to disclose operational behavior; it never says that the tool modifies the world, how existing blocks are affected, how overhang behaves, or what output/return to expect. This is a significant gap for a mutation-style 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?

Three short sentences with no filler; each sentence delivers a distinct fact: the shape type, the ridge axis behavior, and the course structure. The wording is a bit jargon-heavy but concise 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 six parameters, no output schema, no annotations, and a sibling family with many shape variants, the description is too sparse to be complete. It omits overhang semantics, meta usage, block behavior, and footprint coordinate requirements, leaving an agent without enough context for reliable invocation.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It hints at ridgeAxis via 'given axis' and at from/to via 'footprint', but provides no explanation of block, meta, overhang, or coordinate ordering and interpretation. An agent cannot correctly set all six parameters from this description alone.

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

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

The description identifies the tool as generating a gable roof over a footprint, which clearly distinguishes it from sibling shape tools like omni_shape_hip_roof. The phrase 'Ridge runs along the given axis' adds specific geometric scope. A verb such as 'creates' is missing, but the shape-tool family context makes the purpose clear.

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?

Usage context is implied rather than explicit: if you need a gable roof, this is the tool, and the sibling name omni_shape_hip_roof hints at the alternative. However, there is no direct statement of when to use this versus other roof or shape tools, and no exclusions or routing 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?

With no annotations, the description carries the burden and does disclose the construction algorithm: layer-by-layer inset of 1 and apex fill. However, it does not state that this is a world-editing operation or whether existing blocks are overwritten, which is important for a shape tool with no readOnlyHint.

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

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

Three terse sentences with no filler; the main purpose is front-loaded and the algorithm is kept brief. The parenthetical '1 fill at apex' is cryptic, but the overall description is economical.

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 5-parameter shape operation with no annotations and no output schema, this description is incomplete. An agent cannot determine how to map from/to onto the footprint, how overhang affects the result, or what side effects the operation has.

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

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

Schema description coverage is 0% and the description does not compensate: it never explains that from/to are the footprint coordinates, that overhang controls the inset, or what meta and block accept. The phrase 'Inset by 1 each layer' describes the default behavior but fails to mention the overhang parameter that can change 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 identifies a hip roof over a footprint, distinguishing it from sibling shape tools like omni_shape_gable_roof by shape type, and the algorithm sentences make the intended output concrete. It lacks an imperative verb such as 'creates/builds', relying on the tool name to supply the 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?

No guidance is given for when to choose this tool over alternatives such as omni_shape_gable_roof or omni_shape_pyramid. The only usage signal is the implicit 'use when you want a hip roof', with no exclusions or fallback conditions.

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 at all, the description carries the full behavioral burden. It meaningfully discloses that the tool expands into up to 6 fill_area operations, which informs the agent about world-modifying side effects and scale. However, it does not state whether existing blocs are overwritten, what happens when toggles are off, or any preconditions and permissions—gaps that matter for a mutating shape 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 short sentences with zero filler: the core purpose and mechanism are front-loaded in sentence one, and the distinctive togggable-face behavior is in sentence two. Every word earns its place without repetition of schema property names or types.

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 7-parameter tool with no annotations, no output schema, and no schema parameter descriptions, a two-sentence description is insufficient. An agent cannot fully resolve the meaning of block and meta, is not told the tool overwrites world state, and gets no guidance on edge cases (e.g., from == to or all faces disabled). The core shape concept is covered, but the operational essentials are not.

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 compsensate. It adds real meaning to three booleans (floor/ceiling/walls = independently togggable faces), which maps directly to the schema. But it says nothing about the required from/to coordinates beyond what the name implies, and block and meta (an unexplained 0-15 integer) are completely undocumented anywhere—a serious gap at 0% schema coverage.

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

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

The description identifies a specific resource ('Hollow cuboid shell') and a concrete mechanism ('as up to 6 fill_area ops'), clearly distinguishing this from the sibling omni_shape_solid_box. The verb is only implicit rather than explicitly stated (e.g., 'creates')—hence not a 5—but there is no ambiguity about what this tools does.

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 togglable floor/ceiling/walls strongly imply this tool is intended for hollow structures where faces can be selectively enabled, but no explicit when-to-use vs alternatives is given. The description never names omni_shape_solid_box or any sibling as the alternative for filled cuboids. Usage must be inferred from the name and wording rather than being stated directly.

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

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

With no annotations, the description carries the behavior burden. It discloses the core behavioral trait: a Bresenham algorithm placing blocks along a line. However, it omits what happens with existing blocks, error/return behavior, or any permissions/limitations, leaving meaningful gaps.

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 short sentences front-load the core mechanism and follow with practical use cases. Every word earns its place; there is no filler 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?

Given no annotations, no output schema, and a 0% schema description coverage, the description is too thin. An agent can guess from/to are coordinates but lacks clarification of the coordinate system, what meta means, how the block default interacts, and what a successful invocation returns.

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

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

Schema description coverage is 0%, and the description does not meaningfully explain from, to, meta, or block. The '3D' mention implies from/to are coordinates and the examples hint at block use, but meta is completely unexplained and no parameter-specific guidance is given.

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

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

The description states the resource and operation clearly: it creates a 3D Bresenham line via place_block operations, and gives concrete use cases (paths, fences, wires). It is clearly a line-drawing shape tool and understandable against sibling shape tools, though it does not explicitly name a sibling to distinguish itself from.

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 phrase 'Use for paths, fences, wires' gives explicit, practical guidance on when to select this tool. It does not provide when-not-to-use guidance or name alternative shape tools, so it is clear context without exclusions.

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

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

With no annotations, the description carries the behavioral burden and does add meaningful behavior: 'hollow=true skips the interior of each layer' and '1 fill per layer' explain construction details. However, it omits other behavioral context such as whether the tool overwrites existing blocks, how layer heights are determined, or what errors or results are returned.

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 short sentences with no filler. It front-loads the core shape and layer behavior, then immediately addresses the hollow option. Every phrase 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 5-parameter shape-generation tool with no annotations and no output schema, the description is too sparse. It does not explain how the pyramid's stepped layers are derived from `baseRadius`, what coordinate frame `center` uses, whether the operation modifies the world destructively, or what a successful invocation returns.

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

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

Schema description coverage is 0%, and the description only clarifies the `hollow` parameter. Parameters like `baseRadius`, `center`, `block`, and especially `meta` are left to inference from their names and schema defaults, which is insufficient given the low coverage.

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

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

The description clearly identifies the tool as generating a 'stepped square pyramid' with '1 fill per layer', which is a specific shape resource and distinguishes it from sibling cylinder, sphere, box, and roof tools. It lacks an explicit verb like 'create' or 'build', but the intended purpose is still 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?

There is no guidance about when to use this tool versus alternatives such as omni_shape_solid_box or omni_shape_sphere. The shape name implies its use case, but the description does not state conditions, exclusions, or preferences that would help an agent route between the shape 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?

There are no annotations, so the description carries the full burden. It discloses that coordinates are inclusive and that it is one fill_area operation, but it does not disclose effects on existing blocks, whether the operation replaces blocks or only fills air, block default behavior, or whether it is synchronous. This is a mutation tool with minimal behavioral context.

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

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

The description is concise and front-loaded with the core behavior. The inclusive-coordinates note is a high-value detail in minimal space. It earns its place, though it could add a little more context without becoming bloated.

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 mutation tool with no annotations, no output schema, and 0% schema documentation coverage, this description is too sparse. An agent cannot tell what 'from'/'to' coordinates mean precisely, whether the operation is destructive, how blocks are placed, or what the fill_area op implies. Sibling shape tools likely share patterns, but the description alone is under-specified.

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 schema itself provides only types and defaults. The description says 'Coordinates are inclusive', which clarifies the semantic meaning of from/to beyond raw schema. However, it does not explain block or meta parameters, or what the coordinates represent in the world (e.g., absolute vs relative positions). Baseline adjustment: description does add some value, but the gap remains for half the parameters.

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

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

The description states a specific verb and resource ('Solid cuboid (1 fill_area op)') and adds a key detail that it is a solid box, which distinguishes it from hollow-box and other shape siblings. It does not explicitly contrast with siblings, but the resource is clear.

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: it creates a solid cuboid between two coordinates. It does not explicitly state when to choose this over omni_shape_hollow_box or other shape tools, but the distinction is reasonably inferable from the name and 'solid' qualifier. No exclusions or alternatives are mentioned.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It reveals a concrete algorithmic trait—rasterization as x-runs per (y,z) row—which is useful. However, it does not state that this is a world-modifying operation, how hollow affects the shape, or any side-effects, leaving several behavioral gaps.

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 short sentences with zero filler. The first sentence states the shape and variant, the second adds a precise technical detail. Every word earns its place and the structure is easy to scan.

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

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

Despite having no output schema, no annotations, and five parameters with zero schema descriptions, the description offers only a brief shape label and a rasterization hint. It does not explain return behavior, how center or radius are used together, or what the hollow flag does. An agent would need additional context to invoke this correctly beyond guessing common shape-tool conventions.

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 for five parameters. It usefully explains that radius can be an integer or a 3-element array (ellipsoid), but center, block, hollow, and meta are left undescribed. The 'x-runs per (y,z) row' hint implies a mapping but doesn't concretely bind params to behavior, so the compensation is incomplete.

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

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

The description clearly identifies the resource: a sphere, with an ellipsoid variant via a 3-element radius, and the sibling tool set makes its purpose distinctive. However, it lacks an explicit verb such as 'creates' or 'generates', so it is just short of the top standard.

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 choose this tool over other shape tools like omni_shape_solid_box or omni_shape_cylindr. The ellipsoid detail is a parameter semantics point, not a usage criterion. An agent must infer selection solely from the tool name and sibling context.

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

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

No annotations are present, so the description carries the full burden. It discloses that this is a non-mutating snapshot and enumerates the data fields returned, which tells an agent what to expect. It could go further on failure modes or side effects, but 'snapshot' suggests pure read and the field list is good.

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

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

Two sentences with zero filler. The first sentence states the output contents; the second gives the exact invocation timing. Both earn their place and key guidance 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?

For a zero-parameter, no-output-schema state query, the description tells the agent exactly when to call it and what fields it will see. It doesn't detail error cases or connection assumptions, but those aren't critical for this simple read-only snapshot 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?

With zero parameters, the schema is trivially 100% covered and the baseline is 4. The description doesn't need to explain parameters; it adds context about what the snapshot contains, which is the relevant semantic guidance here.

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

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

Description states a specific verb ('Snapshot') and resource ('running game'), enumerating exactly the contents (status state, screen, mode, player position/health/food, world, devpatch status). This clearly distinguishes it from siblings that perform specific actions like world entry, scanning, or shape creation.

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 call: 'before EVERY interaction' and why: to confirm the loaded world matches expectations. This provides strong timing guidance, though it doesn't name alternative tools or explicitly state when-not-to-use, so one point is withheld.

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 carries the full behavioral disclosure burden. It does reveal useful behavior (mods are staged before launch, template meanings are concrete), but it does not say whether creation also launches/enters the world, whether an existing world is overwritten, what side effects occur, or what the return value looks like. For a mutating tool this is a material gap.

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

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

The description is compact, front-loaded with the core action, and every sentence adds useful information. The template list is especially efficient because it compresses four enum meanings into a single readable clause, though there is a minor grammar issue in 'mods stages them before launch.'

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 six parameters, no output schema, and no annotations, the description is not complete enough for an agent to predict the tool's full behavior. It covers the happy path and template selection but omits post-create behavior, return value, and semantics for several parameters, leaving meaningful uncertainty before invocation.

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

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

Schema description coverage is only 17%, so the description must compensate for weak schema docs. It adds real meaning to mods ('stages them before launch') and to the template parameter (each enum value described: void_single, void_platform_7x7, flat, default). However, seed, cheats, gametype, and folder/name semantics are left mostly to inference from property names and the enum values.

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

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

The description states a specific verb and resource ('Create a new world') and immediately distinguishes the action from sibling tools like omni_world_enter or omni_world_scan. The explicit template ids with their physical meanings further pin down exactly what the tool does.

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 intended use case is implied clearly ('Create a new world'), and the note about mods being staged before launch hints at a common use pattern. However, it does not state when to prefer this tool over omni_world_enter, omni_world_scan, or omni_worlds, nor does it give any exclusions or alternative routing.

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

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

No annotations are provided, so the description must disclose behavioral consequences. It states that the tool loads a saved world and that the name comes from a prior omni_worlds call, but it does not describe what happens to the current world, whether the operation is destructive, whether there are open-world constraints, or what happens on failure.

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?

A single sentence carries the purpose, the key parameter semantic, and the prerequisite. It is front-loaded with the primary operation and contains 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 the tool's simplicity — one string parameter, no output schema, and no annotations — the description covers the input and prerequisite well. However, it omits expected return behavior and side effects on the current world session. Since no annotations exist, those omissions leave an invocation- and postcondition gap.

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

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

The input schema only says 'name' is a required string, giving the agent no semantic clue. The description compensates well by clarifying that the value is a folder name and directs the agent to obtain it from omni_worlds. For a single parameter, this is meaningfully more useful than the schema alone.

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

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

The description uses a specific verb ('Load') with a specific resource ('a saved world') and identifies the key input ('folder name'). This clearly separates it from sibling tools like omni_world_create, omni_world_scan, and omni_world_quit, 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?

The description explicitly instructs the agent to call omni_worlds first to obtain the name, which is a clear prerequisite for correct use. It does not explicitly discuss when not to use the tool or compare it to alternatives, but the practical guidance is sufficient for most invocation scenarios.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the main effect (returning to the main menu) and the prerequisite relationship to omni_world_create. However, it does not clarify side effects, whether the operation is safe/idempotent when no world is active, or what happens to the current world 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?

The description is two short sentences with no filler. The core behavior is stated first, and the crucial scheduling constraint is added in the second sentence. Every word contributes useful information.

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

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

For a zero-parameter lifecycle tool with no output schema, the description is largely complete: it explains the effect and when it is required. The only notable omission is confirming behavior when no world is running, which would make it fully robust for an agent's decision-making.

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

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

The tool has zero parameters, so there is nothing for the description to clarify beyond the schema. The baseline of 4 applies: parameter semantics are trivially complete and the description does not need to compensate for any schema gaps.

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

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

The description clearly states the action ('quit' / back to the main menu) and the resource context (the running world), and it distinguishes the tool from the sibling omni_world_create by noting it is required before creation. This is specific enough for an agent to understand what the tool does and how it differs from related lifecycle tools.

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

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

The description provides explicit usage context: it should be called before omni_world_create when a world is already running. It names the relevant sibling and gives the condition for use. However, it does not explicitly state when not to use it, such as behavior when no world is running.

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 disclosure burden. It usefully reveals the origin fallback ('or player eye') and the return contract, but it omits no-hit behavior, whether the ray stops at the first block, coordinate space, and what counts as an entity — material edge cases for reliable invocation.

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 tigh sentences, with the core action in the first and the return contract in the second. No fluff; every phrase carries information.

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

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

For a four-parameter tool with no output schema and no annotations, the description covers the happy-path call adequately but leaves edge/failure behavior and parameter formatting to inference. It is minimally viable, not 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%, so the description must add meaning. It clarifies origin ('or player eye' implies an optional/default origin), direction ('along direction'), and distance (ray length), and implicitly ties entity hits to includeEntities; however, it leaves units, coordinate format, and direction normalization unstated.

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 names a specific action — 'Raycast from origin (or player eye) along direction' — and enumerates the return payload: block hit, face, distance, and entity hit. This is a distinctive, resource-bound description that an agent can separate from sibling tools like omni_world_scan, though it never names alternatives.

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

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

There is no statement of when to use this tool versus omni_world_scan, omni_block_search, or the other world tools, and no exclusions or prerequisites are given. An agent must infer that the tool is meant for line-of-sight probing, which is risky given the large sibling set.

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 disclosure burden, and it does reveal the key non-obvious trait: the output depends on runtime state (full list vs. running world with a note). This is exactly the kind of behavior an agent needs to know in advance. It falls short of a 5 only because it doesn't describe what the note contains or the shape of the returned 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?

Two short sentences with zero filler. The core action ('List saved worlds') is front-loaded, and the second sentence efficiently states the qualifying behavioral condition. 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 0-parameter read-only listing tool with no output schema and no annotations, the description covers the essential gotcha — the conditional output depending on whether a world is running. The only real gaps are the unspecified content of the 'note' and the output format, both minor given the tool's low complexity.

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

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

The tool has 0 parameters and an empty input schema, so there is nothing for the description to add about parameter meaning. Per the rubric, the 0-parameter baseline of 4 applies.

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

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

The description names a specific verb ('List') and a concrete resource ('saved worlds'), and the conditional clause adds a distinctive behavioral detail that separates it from world-management siblings like omni_world_enter, omni_world_scan, and omni_world_create. It is clear and unambiguous, but it doesn't explicitly name or contrast any sibling, which keeps it at a 4 rather than a 5.

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 conditional statement gives useful operational context — the full list is available only when no world is running, otherwise the result is limited to the running world — which helps an agent know what to expect. However, it doesn't explicitly state when to prefer this tool over alternatives like omni_orld_scan or omni_state, nor does it give any 'when not to use' guidance.

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

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

With no annotations, the description carries the full burden and it discloses two crucial behaviors: the 262,144-block hard cap and truncation to maxBlocks/maxEntities. It doesn't cover error cases or filter interplay but is fairly transparent for a read-only snapshot.

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

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

Three short sentences with purpose first; every phrase earns its place. Slight redundancy between 64^3 and 262,144 does not hurt.

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 and no annotations mean the description should cover return value shape and invocation semantics. It leaves coordinate conventions and filter syntax unexplained, so an agent cannot reliably invoke it correctly.

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

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

Schema has 0% parameter descriptions, so the description must explain them. It only relates maxBlocks/maxEntities to truncation and implies from/to define the box; blockFilter, includeBlocks, and includeEntities are left unexplained.

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

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

The description names a concrete operation — capturing a block/entity snapshot in a bounded 64^3 box — and adds hard limits. It doesn't explicitly distinguish siblings like omni_world_raycast, but the boxed-snapshot scope is clear.

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 explicit when-to-use or alternative exclusions; the only guidance is the implied use case of snapshotting a bounded volume. Given related sibling tools, an agent gets no explicit route to choose this over a raycast or block search.

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