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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the output format (Markdown) and exclusion of metadata, but lacks critical details: whether the conversion is lossy, what happens with malformed JSON, if there are size limits, authentication requirements, or rate limits. For a transformation tool with zero annotation coverage, this leaves significant 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 extremely concise and front-loaded in a single sentence that directly states the tool's function. Every word earns its place by specifying the conversion, input type, output format, and exclusion. There's no redundancy or unnecessary elaboration.

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

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

Given the tool has an output schema (which should document return values) and only one parameter, the description is moderately complete. However, as a transformation tool with no annotations, it should ideally mention more about the conversion process, error handling, or input constraints. The presence of an output schema raises the baseline, but behavioral gaps keep it at an adequate level.

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

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

The description adds minimal parameter semantics beyond the schema. It suggests 'json_file' contains exported/edited JSON, but with 0% schema description coverage and only one parameter, the baseline is 4. However, it doesn't explain the expected JSON structure, file format requirements, or provide examples, so it doesn't fully compensate for the schema gap, warranting a 3.

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

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

The description clearly states the tool's purpose: converting JSON to Markdown format. It specifies the input source ('exported/edited JSON') and clarifies what's excluded ('without metadata'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools, as none appear to be direct alternatives for JSON-to-Markdown conversion.

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 minimal usage guidance. It implies the tool is for converting JSON that has been exported or edited, but offers no explicit when-to-use rules, prerequisites, or alternatives. There's no mention of when to choose this tool over other formatting or conversion methods, or any limitations on the JSON structure.

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

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

With no annotations provided, the description carries full burden. It mentions 'Request cancellation' which implies a mutation operation, but doesn't disclose behavioral traits such as permissions needed, whether cancellation is guaranteed or asynchronous, rate limits, or what happens if the job is already completed. This leaves significant gaps for a mutation 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 a single, efficient sentence that front-loads the key action and resource. Every word earns its place with no redundancy or unnecessary details, making it easy 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 one parameter, no annotations, and an output schema (which handles return values), the description is minimally adequate. However, as a mutation tool with behavioral uncertainties, it should provide more context on outcomes or errors. The presence of an output schema prevents a lower score, but gaps remain.

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

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

Schema description coverage is 0%, so the description must compensate. It doesn't add any meaning beyond the schema's 'job_id' parameter—no explanation of what a job ID is, where to find it, or format examples. With only one parameter, the baseline is 4, but the lack of additional semantic context lowers the score.

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 ('Request cancellation') and target resource ('a long-running MCP job'), with examples of job types (ETCH, NEXUS, etc.). It distinguishes from siblings like 'mcp_job_status' by focusing on cancellation rather than status checking. However, it doesn't explicitly differentiate from all other job-related 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 implies usage for 'long-running' jobs but provides no explicit guidance on when to use this tool versus alternatives, prerequisites, or constraints. No comparison to sibling tools like 'nexus_purge_keystones' or 'workflowy_etch_async' is made, leaving the agent to infer context.

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

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

No annotations are provided, so the description carries the full burden. It mentions the tool retrieves status/results but does not disclose behavioral traits such as whether it requires authentication, has rate limits, what happens if the job is incomplete, or the format of the returned data. This leaves significant gaps for a tool handling potentially complex job states.

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

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

The description is a single, efficient sentence that front-loads the core purpose with no wasted words. It uses examples ('ETCH, NEXUS, etc.') to add context without verbosity, making it appropriately sized for its function.

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

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

Given the tool has an output schema (which reduces the need to describe return values) but no annotations and low parameter coverage, the description is somewhat complete for a basic status-check tool. However, it lacks details on job lifecycle, error handling, or integration with sibling tools, leaving room for improvement in contextual richness.

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 1 parameter with 0% description coverage, and the description does not add any meaning about the 'job_id' parameter. It fails to explain what a job ID is, how to obtain it, or what happens if it's null (the default). With low schema coverage, the description does not compensate for the lack of 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 states the verb ('Get') and resource ('status/result for long-running MCP jobs'), with examples like 'ETCH, NEXUS, etc.' providing specificity. However, it does not explicitly distinguish this tool from sibling tools like 'mcp_cancel_job' or 'nexus_list_exploration_sessions', which might also relate to job 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 usage for checking status/results of long-running jobs, suggesting it should be used after initiating such jobs. However, it lacks explicit guidance on when to use this versus alternatives like 'mcp_cancel_job' or other job-related tools, and does not specify prerequisites or exclusions.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. The description fails to indicate whether this is a read or write operation, what side effects it might have, or what authentication/rate limits apply. Phrases like 'NOTHING CHANGES in the ETHER' and 'untouched witness' vaguely suggest read-only behavior but are too ambiguous to be reliable.

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

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

The description is relatively short (two sentences) but extremely inefficient. Every word contributes to poetic abstraction rather than functional clarity. It's not appropriately sized for its purpose—it's under-specified while using verbose, unhelpful language.

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

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

Given the tool's complexity (inferred from sibling tools in a 'nexus' system), no annotations, and 0% schema coverage, the description is completely inadequate. While an output schema exists, the description fails to explain the tool's purpose, behavior, or parameters, leaving the agent with no meaningful guidance.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented parameter 'nexus_tag'. The description provides no information about what 'nexus_tag' represents, its format, or its purpose. The metaphorical language offers no parameter guidance whatsoever.

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 metaphorical language ('PHANTOM GEM ILLUMINATE', 'TRUE GEMS', 'TERRAIN') without stating what the tool actually does. It doesn't specify a clear verb or resource, and the phrase 'FIRST IMBUE—NOTHING CHANGES in the ETHER' is ambiguous rather than clarifying. This is essentially a tautology that restates the mystical theme without providing functional information.

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

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any context, prerequisites, or relationships to sibling tools like 'nexus_anchor_jewels' or 'nexus_glimpse'. The metaphorical language offers no practical usage information.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that the terrain becomes 'ENCHANTED (SECOND IMBUE)' and 'EMBODIED and REAL as JSON,' suggesting some transformation or creation process. However, it doesn't clarify whether this is a read-only or destructive operation, what permissions are needed, or what happens to existing data. The poetic language obscures rather than clarifies behavioral traits.

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

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

The description is relatively concise at three sentences, but the structure is problematic. It's front-loaded with metaphorical language rather than clear functional statements. While not excessively verbose, the poetic phrasing makes it less efficient at communicating practical information than a more direct description 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 an output schema exists, the description doesn't need to explain return values. However, for a tool with one parameter (completely undocumented) and no annotations, the description provides insufficient context about what the tool actually does. The poetic language creates ambiguity rather than clarity, making it difficult for an agent to understand when and how to use this tool effectively.

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

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

The schema has 0% description coverage for its single parameter (nexus_tag), and the description provides no information about what this parameter represents or how it should be used. The description doesn't mention nexus_tag at all, leaving the parameter completely undocumented. For a tool with one required parameter and zero schema coverage, this is inadequate.

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 metaphorical language ('anchor', 'transmuting', 'impregnation') rather than stating a clear, specific purpose. While it mentions anchoring PHANTOM JEWELS within SHIMMERING TERRAIN and producing JSON, the actual function is obscured by poetic terminology. It doesn't clearly distinguish this from sibling tools like nexus_anchor_gems or nexus_transform_jewel.

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 minimal guidance on when to use this tool. It mentions that 'Workflowy remains untouched until WEAVE,' which hints at a separation between this operation and Workflowy tools, but doesn't specify when to choose this over alternatives like nexus_anchor_gems or nexus_transform_jewel. No explicit when-not or prerequisite information is provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that 'the engine always drives traversal and returns a frontier of leaves,' which adds some context about the tool's behavior, but it lacks details on permissions, side effects, rate limits, or error handling, leaving significant gaps for a tool with four parameters.

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 two sentences that directly state the tool's function and some behavioral context. There is no wasted verbiage, though the technical terms could be clearer.

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

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

Given the tool's complexity (4 parameters, no annotations) and the presence of an output schema, the description is partially complete. It covers the basic action and some behavioral traits but lacks parameter explanations and usage guidelines, making it adequate but with clear gaps for effective agent use.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It does not explain what 'session_id', 'decisions', 'global_frontier_limit', or 'include_history_summary' mean or how to use them, failing to add meaningful semantics beyond 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 states the tool 'Apply exploration decisions to an existing NEXUS session and return the next frontier,' which provides a verb ('apply') and resource ('NEXUS session'), but it's vague about what 'exploration decisions' and 'frontier' mean. It distinguishes from some siblings by mentioning dfs_guided_explicit and dfs_guided_bulk, but these terms are not clearly defined, leaving the purpose somewhat ambiguous.

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 guidance on when to use this tool versus alternatives is provided. The description mentions dfs_guided_explicit and dfs_guided_bulk modes, but it doesn't explain when to choose this tool over other exploration-related siblings like nexus_start_exploration or nexus_resume_exploration, offering no context 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?

With no annotations provided, the description carries full burden but is insufficient. It mentions output files but doesn't disclose critical behavioral traits such as whether this is a read-only or destructive operation, what permissions are required, if it's idempotent, or how errors are handled. The description adds minimal context beyond basic purpose.

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

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

The description is a single, efficient sentence that front-loads the core action and outputs. It avoids unnecessary words, though it could be slightly more structured by separating purpose from context. Every part earns its place, making it appropriately concise.

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

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

Given the tool has an output schema (which should document return values), the description doesn't need to explain outputs. However, with no annotations and 2 parameters (one with an enum), the description is incomplete—it lacks behavioral details and parameter explanations. It's minimally adequate but has clear gaps for a tool that likely performs significant operations.

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

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

Schema description coverage is 0%, so the description must compensate but does not. It provides no information about the session_id or mode parameters beyond what the schema shows (e.g., mode has enum values 'terrain_only' and 'full'). The baseline is 3 because the schema covers parameters structurally, but the description adds no semantic meaning to clarify their roles.

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 ('Finalize an exploration session') and specifies the output files (coarse_terrain.json plus optional phantom_gem.json and shimmering_terrain.json). It distinguishes from siblings like nexus_explore_step or nexus_start_exploration by indicating this is a finalization step, though it doesn't explicitly contrast with all related 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 implies usage context by mentioning 'for use with NEXUS JEWELSTORM and WEAVE,' suggesting when the outputs are needed. However, it lacks explicit guidance on when to choose this tool over alternatives like nexus_resume_exploration or nexus_anchor_gems, and doesn't specify prerequisites or exclusions.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it's a local extraction with no API calls, instant execution, and user control over granularity. However, it lacks details on permissions, error handling, or what happens if files already exist (though 'reset_if_exists' parameter hints at this). It doesn't contradict annotations, but could be more comprehensive for a tool with 4 parameters and output schema.

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

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

The description is appropriately sized and front-loaded, starting with the core action 'GLIMPSE → TERRAIN + PHANTOM GEM' and key details like 'zero API calls'. Each sentence adds value: the first states the purpose, the second explains the mechanism and outputs, and the third covers benefits. There's minimal waste, though some phrasing like 'GLIMPSE → TERRAIN + PHANTOM GEM' could be clearer.

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

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

Given the tool's complexity (4 parameters, output schema exists, no annotations), the description is partially complete. It covers the purpose, mechanism, and benefits well, and the output schema means it doesn't need to explain return values. However, with 0% schema coverage and no parameter explanations, it falls short in fully compensating for the lack of structured data, leaving gaps in how to use the tool effectively.

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

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

Schema description coverage is 0%, so the description must compensate for all 4 parameters. It mentions 'granularity by expanding nodes' which loosely relates to parameters like 'mode' or 'workflowy_root_id', but doesn't explain any parameters explicitly (e.g., what 'nexus_tag' or 'reset_if_exists' do). This leaves significant gaps in understanding parameter meanings beyond what the bare schema provides.

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

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

The description clearly states the tool captures expanded Workflowy content via WebSocket GLIMPSE and creates two JSON files (coarse_terrain.json and phantom_gem.json) from a local extraction. It specifies the verb 'captures' and resources 'coarse_terrain.json and phantom_gem.json', though it doesn't explicitly differentiate from sibling tools like 'workflowy_glimpse' or 'workflowy_export_node' beyond mentioning 'zero API calls'.

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

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

The description provides clear context for when to use this tool: for capturing expanded Workflowy nodes via WebSocket without API calls, with instant results and user-controlled granularity. It implies alternatives by noting 'zero API calls' (suggesting other tools might use APIs) and references sibling tools like 'workflowy_get_node__WARNING__prefer_glimpse', but doesn't explicitly name when-not-to-use scenarios or direct alternatives.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It vaguely suggests the tool reveals 'deeper layers' and produces a 'PHANTOM GEM (S0)', but doesn't explain what this output represents, whether the operation is read-only or mutating, what permissions are required, or any rate limits. The metaphorical language fails to provide concrete behavioral information.

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

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

The description is relatively concise (two sentences) but suffers from poor structure where the poetic language obscures meaning rather than clarifying it. While not verbose, the sentences don't efficiently communicate practical information about the tool's function.

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 5 parameters (2 required), no annotations, and complex sibling relationships, the description is severely inadequate. While an output schema exists, the description doesn't explain what the tool does, when to use it, what the parameters mean, or how it behaves. The metaphorical language fails to provide the necessary context for effective tool selection and use.

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

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

With 0% schema description coverage for all 5 parameters, the description provides absolutely no information about what nexus_tag, root_ids, max_depth, child_limit, or per_root_limits mean or how they should be used. The description doesn't mention any parameters at all, leaving them completely 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 uses metaphorical language ('IGNITE selected SHARDS', 'ETHER glows more deeply', 'PHANTOM GEM') that obscures the actual function. While it mentions revealing 'deeper layers' and 'subtrees', it doesn't clearly state what the tool actually does in concrete terms. The description is more poetic than functional, making it difficult to understand the tool's purpose.

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

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

The description provides no guidance on when to use this tool versus its many siblings (nexus_anchor_gems, nexus_explore_step, nexus_glimpse, nexus_scry, etc.). It doesn't mention prerequisites, alternatives, or specific contexts where this tool is appropriate versus other nexus tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a listing operation, which implies it's likely read-only and non-destructive, but it doesn't explicitly confirm this or describe other traits like pagination, rate limits, authentication needs, or what happens if no sessions exist. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 concise and front-loaded, consisting of a single sentence that directly states the tool's purpose and optional parameter. There is no wasted language or redundancy, making it easy for an agent to parse quickly. Every word earns its place by contributing essential information without unnecessary elaboration.

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 an output schema (which should cover return values), the description doesn't need to explain outputs. However, with no annotations, 0% schema description coverage, and one parameter, the description provides only basic purpose and filtering info. It lacks details on behavioral traits, usage context, and parameter semantics, making it incomplete for a tool in a complex server with many siblings. It's adequate but has clear gaps.

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

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

The description adds some meaning by mentioning that 'nexus_tag' is an optional filter, which clarifies its purpose beyond the schema's basic type definition. However, with 0% schema description coverage and only one parameter, the description doesn't fully compensate—it doesn't explain what a 'nexus_tag' is, its format, or how filtering works. Since there's only one parameter, the baseline is 4, but the lack of detailed semantic context reduces this to 3.

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

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

The description clearly states the action ('List all exploration sessions') and the resource ('exploration sessions'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'nexus_start_exploration' or 'nexus_explore_step' by focusing on listing rather than creating or modifying sessions. However, it doesn't specify what 'exploration sessions' are in this context, which prevents a perfect score.

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 minimal guidance by mentioning optional filtering by 'nexus_tag', but it doesn't explain when to use this tool versus alternatives. For example, it doesn't clarify if this should be used instead of 'nexus_list_keystones' or 'nexus_glimpse' for similar listing purposes, nor does it mention any prerequisites or exclusions. This lack of context leaves the agent guessing about appropriate usage scenarios.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't mention any constraints like pagination, sorting, filtering, or authentication requirements. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, making it easy 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 the tool has 0 parameters and an output schema exists, the description covers the basic purpose adequately. However, without annotations and with sibling tools that suggest complex operations (e.g., 'nexus_purge_keystones'), more context on behavioral traits or usage scenarios would be beneficial for 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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is appropriate here, but doesn't explicitly state 'no parameters needed' to earn a perfect score.

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 ('List') and resource ('NEXUS Keystone backups') with the scope 'all available', making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'nexus_purge_keystones' or 'nexus_restore_keystone', which prevents a perfect score.

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

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

No guidance is provided on when to use this tool versus alternatives. While the name suggests it's for listing backups, there's no mention of prerequisites, timing considerations, or how it relates to other keystone-related tools like 'nexus_purge_keystones' or 'nexus_restore_keystone'.

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. While 'Delete' implies a destructive mutation, the description doesn't specify whether deletions are permanent, reversible, require confirmation, or have side effects (e.g., affecting related resources). It also omits details like rate limits, authentication needs, or error handling, which are critical for a deletion 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 a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration, though this brevity contributes to gaps in other dimensions like guidelines and transparency.

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 this is a destructive tool with no annotations, 0% schema description coverage, and an output schema (which may help with return values), the description is incomplete. It lacks essential context such as safety warnings, behavioral details, parameter explanations, and usage guidance, making it inadequate for reliable agent operation despite its conciseness.

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 1 parameter with 0% description coverage, so the schema provides no semantic context. The description mentions 'one or more' keystones, hinting at the array nature of 'keystone_ids', but doesn't explain what keystone IDs are, their format, or how to obtain them (e.g., from 'nexus_list_keystones'). This leaves significant gaps in parameter understanding.

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

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

The description clearly states the action ('Delete') and resource ('NEXUS Keystone backup files'), making the purpose immediately understandable. It distinguishes from siblings like 'nexus_list_keystones' (list) and 'nexus_restore_keystone' (restore), though it doesn't explicitly name these alternatives. The description is specific but could be slightly more precise about what 'Keystone' represents in context.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as 'nexus_restore_keystone' for recovery or 'nexus_list_keystones' for viewing available backups. It lacks context about prerequisites (e.g., needing to list keystones first) or exclusions, leaving the agent to infer usage from the tool name alone.

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 mentions 'Restore,' implying a mutation operation, but fails to disclose critical behavioral traits like permissions required, whether it overwrites existing data, error handling, or side effects. This leaves significant gaps in understanding the tool's 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 a single, clear sentence that efficiently conveys the core purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to understand 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 the tool has an output schema (which handles return values) and only 1 parameter, the description covers the basic purpose adequately. However, as a mutation tool with no annotations, it lacks details on behavioral context and usage guidelines, making it incomplete for safe and effective use.

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

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

The input schema has 1 parameter with 0% description coverage, and the description does not add any details about 'keystone_id' (e.g., what it is, where to find it, format). Since schema coverage is low, the description should compensate but does not, resulting in a baseline score due to the lack of parameter information.

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 ('Restore') and target ('Workflowy node tree from a NEXUS Keystone backup'), which is specific and actionable. However, it does not explicitly differentiate from sibling tools like 'nexus_purge_keystones' or 'nexus_list_keystones', which reduces it from a perfect score.

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 no guidance on when to use this tool versus alternatives, such as when to restore versus create new nodes or use other backup-related tools. It lacks context about prerequisites or scenarios where restoration is appropriate.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool resumes sessions and provides two identification methods, but doesn't describe what 'resuming' entails, whether it requires specific permissions, what happens to session state, or any rate limits. For a tool with no annotation coverage, this leaves significant 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 perfectly concise and well-structured. It uses just two sentences: the first states the purpose and context, the second explains the parameter options. Every word earns its place with no redundancy or unnecessary information.

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

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

Given the tool has 4 parameters with 0% schema coverage and an output schema exists, the description provides adequate but incomplete context. It covers the core purpose and two key parameters, but doesn't address the other two parameters or behavioral aspects. With an output schema, it doesn't need to explain return values, but should provide more complete parameter documentation.

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

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

The description mentions two parameters (session_id and nexus_tag) and explains their purpose: 'Provide either session_id (exact) or nexus_tag (finds latest session for tag).' With 0% schema description coverage and 4 total parameters, this adds meaningful context for those two parameters. However, it doesn't mention the other two parameters (frontier_size and include_history_summary), leaving them completely 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 clearly states the tool's purpose: 'Resume an exploration session after MCP restart or in new conversation.' It specifies the verb ('resume') and resource ('exploration session'), and provides context about when to use it. However, it doesn't explicitly differentiate from sibling tools like 'nexus_start_exploration' or 'nexus_list_exploration_sessions', which would be needed for a perfect score.

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

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

The description provides clear context for when to use this tool: 'after MCP restart or in new conversation.' It also mentions two alternative ways to identify the session (session_id or nexus_tag). However, it doesn't explicitly state when NOT to use this tool or compare it to alternatives like 'nexus_start_exploration' for new sessions, which prevents a perfect score.

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 must fully disclose behavior. It hints at creating a 'new geography' (likely a session or exploration context) and warns about large-scale operations, but omits critical details: whether this is read-only or mutative, what 'reset_if_exists' does, error conditions, or the output format. The metaphorical language obscures rather than clarifies operational traits.

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

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

The description is front-loaded with metaphorical jargon ('CORINTHIAN NEXUS', 'ETHER', 'TERRAIN') that hinders clarity, followed by practical advice. While not verbose, the structure is inefficient—the first sentence could be simplified to state the tool's function directly, and the second sentence mixes parameter guidance with vague future actions.

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 6 parameters (4 required), 0% schema coverage, no annotations, and an output schema (which relieves some burden), the description is incomplete. It fails to explain the tool's role in the broader 'nexus' workflow, how it differs from similar tools like 'workflowy_scry', or the implications of parameter choices beyond warnings. The metaphorical approach leaves gaps in practical understanding.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'nexus_tag' (names the geography), 'max_depth', 'child_limit', and 'max_nodes' (guard against large SCRYs), but provides no specifics on valid ranges, formats, or the purpose of 'workflowy_root_id' and 'reset_if_exists'. This leaves most parameters inadequately explained beyond their names.

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 metaphorical language ('INITIATE a CORINTHIAN NEXUS on the ETHER', 'COARSE SCRY of Workflowy') but conveys the core action of exploring a Workflowy structure under a root node with depth/child limits. It distinguishes from siblings like 'workflowy_scry' by mentioning 'nexus_tag' and 'TERRAIN' creation, though the distinction is abstract rather than functional.

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

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

The description advises to 'keep [max_depth and child_limit] minimal' and warns about 'accidental 1M-node SCRYs' with max_nodes, but lacks explicit when-to-use guidance versus alternatives like 'workflowy_scry' or 'nexus_glimpse'. It mentions 'Later, you will IGNITE the ETHER more deeply on selected SHARDS' (referencing 'nexus_ignite_shards'), but this is vague and not a clear usage rule.

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 and does so effectively. It explains the engine's control of traversal, the return of frontiers for labeling, the distinction between dfs_guided modes, and the editable parameter's effect on mutation capabilities. It doesn't cover rate limits, error conditions, or session persistence details, but provides substantial operational 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 appropriately sized with three sentences that each add value: first establishes the core purpose, second explains the engine's role and frontier mechanics, third details parameter-driven behaviors. It's front-loaded with the main action and avoids redundancy, though the second sentence is somewhat dense.

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

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

Given the tool's complexity (9 parameters, no annotations, but with output schema), the description provides good coverage of what the tool does, how it behaves, and key parameter effects. The output schema existence means return values don't need explanation. It could benefit from more guidance on parameter interactions or error scenarios, but is largely complete for session initiation.

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

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

With 0% schema description coverage for 9 parameters, the description compensates well by explaining the purpose and effect of key parameters like editable (enables update-and-engulf actions) and implies context for others (root_id for subtree, frontier_size for batch control). It doesn't detail all 9 parameters individually, but provides meaningful semantic context beyond 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 clearly states the tool's purpose with specific verbs ('start a NEXUS exploration session') and resources ('over a Workflowy subtree'), distinguishing it from siblings like nexus_explore_step (which performs steps within a session) or nexus_scry (which appears to be a different operation). It specifies the engine's role in controlling traversal and returning frontiers for labeling.

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

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

The description provides clear context for when to use this tool by explaining the exploration session initiation and contrasting it with other modes (dfs_guided_explicit vs. dfs_guided_bulk). However, it doesn't explicitly state when NOT to use it or name specific alternative tools for different scenarios, such as when to use nexus_resume_exploration 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions operations like DELETE_NODE and SEARCH_REPLACE, which imply mutation and potential data loss, but doesn't explicitly state whether changes are destructive, reversible, or require specific permissions. It also doesn't cover error handling, rate limits, or response format, leaving significant gaps in behavioral understanding for a tool with multiple operations and parameters.

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 that packs in many details (e.g., operation types, file context, text-level features). While it avoids unnecessary words, it's not front-loaded with the core purpose and could benefit from clearer structuring (e.g., separating operation listing from context explanation). Some phrases like 'PHANTOM GEM working copy' are jargon-heavy without explanation, reducing clarity.

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

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

Given the tool's complexity (4 parameters, multiple operations, no annotations, but with an output schema), the description provides a basic overview but lacks completeness. It covers the high-level purpose and operation types but misses key details: parameter meanings, behavioral traits (e.g., mutation effects), and how to use the tool effectively. The output schema may help with return values, but the description doesn't compensate for the gaps in schema coverage and missing 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?

The schema description coverage is 0%, so the schema provides no parameter details. The description mentions 'jewel_file' and 'operations' implicitly by referring to applying operations to a JSON file, but doesn't explain what 'jewel_file' is (e.g., file path or identifier) or the structure of 'operations' (e.g., how to specify MOVE_NODE vs. DELETE_NODE). It also doesn't address 'dry_run' or 'stop_on_error' parameters, leaving most of the 4 parameters inadequately documented.

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

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

The description clearly states the tool's purpose: applying semantic operations to a NEXUS working_gem JSON file. It specifies the verb 'apply' and the resource 'working_gem JSON file', and lists specific operations like MOVE_NODE, DELETE_NODE, etc. However, it doesn't explicitly differentiate from sibling tools like 'nexus_anchor_gems' or 'nexus_weave_enchanted_async', which might also manipulate similar data structures.

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 by stating it's for 'PHANTOM GEM working copy' and 'semantic analogue of edit_file for PHANTOM GEM JSON', suggesting it's for editing JSON files in this specific context. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., 'nexus_anchor_gems' or 'workflowy_etch'), and doesn't mention prerequisites or exclusions, leaving the agent to infer context from the tool name and description alone.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool starts an async job and returns a job_id for polling and cancellation, which adds useful behavioral context. However, it doesn't cover aspects like error handling, rate limits, or authentication needs, leaving gaps in transparency.

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

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

The description is a single, well-structured sentence that front-loads the key action and outcome. It efficiently conveys the purpose and usage without unnecessary words, making it highly concise and clear.

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

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

Given the complexity of an async job tool with 2 parameters, no annotations, and an output schema (which likely covers return values), the description is reasonably complete. It explains the async nature and job_id usage, but could benefit from more detail on parameters or error cases to be fully comprehensive.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'nexus_tag' and 'dry_run' implicitly by referencing the job, but doesn't explain what these parameters mean or how they affect the weave process. This adds minimal semantic value beyond 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 clearly states the action ('Start an async NEXUS ENCHANTED WEAVE job') and the resource (WEAVE T2 back into Workflowy ETHER), providing a specific verb and target. However, it doesn't explicitly differentiate from sibling tools like 'nexus_weave' or 'workflowy_etch_async' that might handle similar async operations, keeping it from a perfect score.

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 starting async jobs and mentions status polling and cancellation, suggesting when to use it (for async operations). However, it lacks explicit guidance on when not to use it or alternatives (e.g., vs. synchronous tools or other nexus tools), leaving some ambiguity.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. While 'Mark as completed' implies a mutation operation, it doesn't specify whether this is reversible, what permissions are required, how completion affects node visibility/behavior, or what happens if applied to already completed nodes. The description lacks crucial behavioral context for a mutation 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 extremely concise at just 5 words, front-loading the core action and resource with zero wasted words. Every element earns its place, making it easy 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 this is a mutation tool with no annotations, 0% schema description coverage, but with an output schema present, the description is minimally adequate. The output schema likely handles return values, but the description should do more to explain the mutation's effects, prerequisites, and relationship to sibling tools for a complete understanding.

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

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

The description mentions no parameters at all. With 0% schema description coverage and 1 required parameter ('node_id'), the description fails to explain what 'node_id' represents, how to obtain it, or its format. However, the baseline is 3 since there's only one parameter, though the description adds no 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 clearly states the action ('Mark as completed') and resource ('a WorkFlowy node'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'workflowy_uncomplete_node' which performs the opposite operation, nor does it mention what 'completed' means in the WorkFlowy context.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing node), when not to use it (e.g., on already completed nodes), or direct alternatives like 'workflowy_uncomplete_node' for reversing this action.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. The description only mentions deprecation status and alternative, but doesn't describe what the tool actually does behaviorally (creates a node? what happens on success/failure? what permissions are needed?). For a tool with 3 parameters and no annotations, this is a significant gap in behavioral transparency.

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

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

The description is maximally concise - a single sentence that communicates the essential information (deprecation status and alternative). There is zero wasted text, and the most critical information (that this tool should not be used) is front-loaded. This is an excellent example of efficient communication.

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 this is a deprecated tool with 3 parameters, no annotations, 0% schema description coverage, but with an output schema, the description is incomplete. While it correctly warns about deprecation, it doesn't explain what the tool does, what the parameters mean, or provide any context for understanding the tool's behavior. The existence of an output schema doesn't compensate for the complete lack of functional explanation.

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%, meaning none of the 3 parameters have descriptions in the schema. The tool description provides absolutely no information about what the parameters mean, their purpose, or how they should be used. The description doesn't mention parameters at all, failing to compensate for the complete lack of schema documentation.

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

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

The description states the tool is deprecated and provides an alternative, but does not explain what the tool actually does. It's not a tautology (doesn't just restate the name), but it's misleading because it focuses entirely on deprecation rather than functionality. The name suggests it creates a single node in WorkFlowy, but the description doesn't confirm or clarify this purpose.

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

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

The description provides explicit and clear usage guidance: 'DEPRECATED: Use workflowy_etch (ETCH) instead.' This directly tells the agent when NOT to use this tool and provides a specific alternative. This is exactly what strong usage guidelines should do - prevent misuse by directing to the correct tool.

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

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

No annotations are provided, so the description carries the full burden. It mentions 'creates ONE node only,' which implies a write operation, but lacks details on permissions, side effects, error handling, or response format. The warning adds some context but doesn't compensate for the missing behavioral information.

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

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

The description is extremely concise and front-loaded with the warning, followed by the core purpose. Every sentence earns its place, with no wasted words, making it efficient and well-structured for quick comprehension.

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

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

Given the tool's complexity (7 parameters, write operation) and lack of annotations, the description is incomplete—it misses parameter details and behavioral context. However, the presence of an output schema reduces the need to explain return values, and the warning provides some guidance, keeping it from being entirely inadequate.

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 provides no information about any of the 7 parameters (e.g., 'name', 'parent_id', 'note'), failing to add meaning beyond the schema. This leaves parameters semantically unclear.

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

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

The description clearly states the action ('creates ONE node only') and resource ('node'), making the purpose specific and understandable. However, it doesn't distinguish this tool from its sibling 'workflowy_etch' beyond the warning, missing explicit differentiation in functionality.

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

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

The description explicitly provides usage guidance with '⚠️ WARNING: Prefer workflowy_etch (ETCH) instead,' indicating when not to use this tool and naming the alternative. This is a clear, direct instruction for tool 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 are provided, so the description carries the full burden of behavioral disclosure. While it states the tool deletes a node and its children (implying a destructive, irreversible action), it fails to mention critical details like required permissions, error handling (e.g., if the node_id is invalid), or confirmation prompts. For a destructive tool with zero annotation coverage, this is a significant 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 a single, efficient sentence that front-loads the core action ('Delete') and resource. There is no wasted verbiage, making it highly concise and well-structured for quick comprehension.

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 destructive nature, lack of annotations, and an output schema (which may cover return values), the description is minimally adequate but incomplete. It states what the tool does but omits usage context, parameter semantics, and behavioral risks. The presence of an output schema prevents a lower score, but more detail is needed for safe operation.

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

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

The input schema has 1 parameter with 0% description coverage, and the description does not explain what 'node_id' represents (e.g., a unique identifier from WorkFlowy, how to obtain it, or format constraints). Since schema coverage is low (<50%), the description should compensate but adds no parameter details, resulting in a baseline score of 3 due to the single parameter's simplicity.

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 specific action ('Delete') and resource ('a WorkFlowy node and all its children'), distinguishing it from sibling tools like workflowy_update_node or workflowy_move_node. It precisely defines the scope of deletion (node plus children), making the purpose unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., workflowy_uncomplete_node for marking incomplete, workflowy_move_node for relocation, or workflowy_etch for batch operations). It lacks context about prerequisites, such as needing the node_id from a prior operation, or warnings about irreversible deletion.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'ETCH command' but doesn't clarify what that entails (e.g., is it atomic, does it require specific permissions, what happens on failure?). The description lacks details on mutation effects, error handling, or response format, leaving significant gaps for a tool that creates multiple nodes.

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 brief and front-loaded with the core purpose, using two efficient sentences. However, the second sentence is somewhat redundant ('ETCH command for direct node creation' echoes the first), slightly reducing its impact.

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

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

For a tool with 4 parameters (0% schema coverage), no annotations, and sibling tools, the description is inadequate. It doesn't explain parameter roles, behavioral traits, or usage context. While an output schema exists, the description lacks crucial details for safe and effective use, especially given the tool's mutation nature.

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

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

The schema description coverage is 0%, so the description must compensate for undocumented parameters. It only vaguely references 'JSON structure' and 'direct node creation', without explaining the purpose of 'parent_id', 'nodes', 'replace_all', or 'nodes_file'. This fails to add meaningful context beyond what the bare schema provides.

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

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

The description clearly states the action ('Create multiple nodes') and the resource ('from JSON structure'), and distinguishes it from file-based approaches ('no file intermediary'). However, it doesn't explicitly differentiate from sibling tools like 'workflowy_create_single_node' beyond mentioning it's an 'ETCH command'.

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 minimal guidance, only noting it's for 'direct node creation' without a file. It doesn't explain when to use this tool versus alternatives like 'workflowy_create_single_node' or 'workflowy_etch_async', nor does it mention prerequisites or constraints.

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

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

With no annotations provided, the description carries full burden. It discloses the asynchronous nature and job_id return for polling, which is valuable. However, it doesn't cover important behavioral aspects like required permissions, rate limits, error handling, what 'ETCH' specifically entails, or whether the operation is destructive (though 'node creation' suggests additive).

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

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

The description is a single, well-structured sentence that efficiently conveys the core purpose and key behavioral aspect (async with job_id). Every word earns its place with no redundancy or unnecessary elaboration.

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 an async creation tool with 4 parameters (0% documented) and no annotations, the description is incomplete. While it correctly indicates the output will be a job_id (aligned with having an output schema), it lacks parameter explanations, permission requirements, and detailed behavioral context. The presence of an output schema reduces but doesn't eliminate the need for more completeness.

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

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

With 0% schema description coverage for 4 parameters, the description provides no information about parameters beyond what's implied by 'Workflowy node creation'. It doesn't explain what 'parent_id', 'nodes', 'replace_all', or 'nodes_file' mean, their relationships, or how they affect the ETCH job. The description fails to compensate for the schema's lack of documentation.

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

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

The description clearly states the action ('Start an async ETCH job') and resource ('Workflowy node creation'), with 'async' and 'return a job_id for status polling' providing important context. It distinguishes from immediate creation tools like 'workflowy_create_single_node' by emphasizing the asynchronous nature and job tracking, though it doesn't explicitly name 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 implies usage when asynchronous node creation with status polling is needed, rather than immediate creation. However, it doesn't explicitly state when to use this vs. alternatives like 'workflowy_etch' (synchronous version) or 'workflowy_create_single_node', nor does it mention prerequisites or exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Export' but doesn't specify the output format (e.g., JSON, text), whether it's a read-only operation, any rate limits, or authentication needs. This leaves significant gaps in understanding how the tool behaves beyond its basic function.

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

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

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, making it highly concise and well-structured.

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

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

Given the tool has an output schema, the description doesn't need to explain return values, but with no annotations and incomplete parameter coverage, it should provide more context on behavior and usage. The description is minimal and doesn't fully address the complexity of an export operation, leaving room for improvement in 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 input schema has 1 parameter with 0% description coverage, and the tool description doesn't add any details about the 'node_id' parameter, such as its format, what 'null' means, or examples. Since there's only one parameter, the baseline is 4, but the lack of any parameter explanation in the description reduces it to 3, as it fails to compensate for the schema gap.

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

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

The description clearly states the verb ('Export') and resource ('a WorkFlowy node with all its children'), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'workflowy_get_node' or 'workflowy_glimpse', which might also retrieve node data but in different formats or contexts, so it misses full sibling distinction.

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

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

No guidance is provided on when to use this tool versus alternatives such as 'workflowy_get_node' or 'workflowy_glimpse', nor are there any prerequisites or exclusions mentioned. The description lacks context for tool selection, leaving usage ambiguous.

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

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

No annotations are provided, so the description carries full burden. The description doesn't disclose any behavioral traits - it doesn't explain what the tool actually does, what permissions are needed, what data is returned, or any side effects. The deprecation warning is useful but doesn't describe the tool's 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 concise - just one sentence that delivers the essential information (deprecation and alternative). Every word earns its place with no wasted text. It's perfectly front-loaded with the most critical 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?

While there's an output schema, the description is incomplete for understanding the tool. It doesn't explain what the tool does, what the parameter means, or what behavior to expect. For a deprecated tool, this might be intentional, but from an agent's perspective, it lacks the context needed to understand the tool's function.

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

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

The description provides no information about the 'node_id' parameter. With 0% schema description coverage and no parameter information in the description, there's complete lack of parameter semantics. The description doesn't explain what node_id represents or how to obtain 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 provides no information about what the tool does. It only states that it's deprecated and to use another tool instead. There's no verb, resource, or functional explanation, making it tautological with the name and title.

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 NOT to use this tool ('DEPRECATED') and provides a clear alternative ('Use workflowy_glimpse (GLIMPSE) instead'). This is a perfect example of explicit usage guidance with alternatives.

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

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

No annotations are provided, so the description carries the full burden. It mentions 'Retrieve' (implying a read operation) but lacks details on permissions, rate limits, error handling, or what 'retrieve' entails (e.g., full node data vs. metadata). The warning adds some context, but behavioral traits are under-specified for a tool with no annotation 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 extremely concise and front-loaded with a warning, followed by the core purpose. Every sentence earns its place: the warning is critical for usage, and the retrieval statement defines the action. 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 that an output schema exists, the description doesn't need to explain return values. However, with no annotations, 0% schema coverage, and 2 parameters, the description is incomplete—it lacks parameter explanations and behavioral details. The warning and purpose are helpful, but gaps remain for a tool with this complexity.

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

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

Schema description coverage is 0%, and the description does not explain the parameters at all. It mentions 'by ID' but doesn't clarify what node_id represents or what secret_code is for. With 2 parameters and no schema descriptions, the description fails to add any semantic value beyond 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 clearly states the specific action ('Retrieve a specific WorkFlowy node') and resource ('by ID'), distinguishing it from siblings like workflowy_glimpse, workflowy_list_nodes, and workflowy_export_node. It explicitly warns to prefer another tool for reading trees, which helps differentiate its purpose.

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

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

The description provides explicit guidance on when to use this tool vs. alternatives: it warns to 'Prefer workflowy_glimpse (GLIMPSE) for reading trees,' indicating a clear alternative and context for usage. This helps the agent understand the tool's specific role among siblings.

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

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

No annotations are provided, so the description carries full burden. It mentions loading into context 'no file intermediary' and optional file export with 'TERRAIN export (WebSocket+API merge with full NEXUS semantics)', which adds some behavioral context like direct access and export capabilities. However, it lacks details on permissions, rate limits, side effects (e.g., if it modifies data), or response format, leaving significant gaps for a tool with mutation potential (implied by 'export').

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 brief (three sentences) but front-loaded with the main purpose. However, it includes jargon like 'GLIMPSE command', 'TERRAIN export', and 'NEXUS semantics' without explanation, reducing clarity. The structure is somewhat efficient but could be more straightforward, with sentences that don't fully earn their place due to unclear terminology.

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 complexity (tool with potential read/write operations, 2 parameters, 0% schema coverage, no annotations, but has output schema), the description is incomplete. It hints at behavior but lacks details on inputs, outputs (though output schema exists, the description doesn't bridge to it), error handling, or sibling differentiation. For a tool in a rich sibling set with cryptic terms, more context is needed to be adequately helpful.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'node_id' implicitly via 'node tree' and describes 'output_file' as writing 'TERRAIN export', adding some meaning beyond the schema (e.g., export format and semantics). However, it doesn't explain what 'node_id' is, its format, or constraints, and the export details are cryptic ('WebSocket+API merge with full NEXUS semantics'), failing to fully clarify the two 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 the tool loads a node tree into context, which is a specific verb+resource ('Load entire node tree into context'). However, it doesn't clearly distinguish from siblings like 'workflowy_get_node' or 'workflowy_export_node' beyond mentioning 'GLIMPSE command for direct context loading' and a sibling warning hinting at preference. The purpose is somewhat vague regarding what 'context' means and how this differs from other retrieval 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 minimal guidance: it mentions 'GLIMPSE command for direct context loading' and implies an alternative use with 'output_file' for export, but doesn't explicitly state when to use this tool versus siblings like 'workflowy_get_node' (which has a warning to prefer glimpse) or 'workflowy_export_node'. No context on prerequisites, exclusions, or comparisons is given, leaving usage unclear.

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

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

No annotations are provided, so the description carries full burden. It only states the tool is deprecated, offering no behavioral details like what the tool originally did, its read/write nature, permissions needed, or output format. For a tool with 1 parameter and output schema, this is insufficient disclosure.

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 perfectly concise with zero wasted words—a single sentence front-loading the critical deprecation information. Every word earns its place by clearly communicating the tool's status and alternative.

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 deprecated tool, the description adequately communicates its status and alternative, which is the primary need. However, given it has 1 parameter and an output schema, more context about its original function would help agents understand legacy usage or migration needs, though not strictly required for deprecation.

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 provides no information about the 'parent_id' parameter—not its purpose, format, or effect. The deprecation notice doesn't add any parameter semantics, leaving the parameter completely 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 is a tautology that restates the tool name ('workflowy_list_nodes') without explaining what it does. It provides no specific verb or resource details, only indicating it's deprecated. This fails to clarify the tool's actual function beyond its name.

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 'DEPRECATED: Use workflowy_glimpse (GLIMPSE) instead', providing clear when-not-to-use guidance and naming the specific alternative. This is ideal for deprecated tools, leaving no ambiguity about usage.

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

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

No annotations are provided, so the description carries full burden. It mentions a warning/preference but doesn't explain why glimpse is preferred, what 'list' actually returns (structure, format, limitations), or any behavioral traits like pagination, rate limits, or permissions needed. The warning adds some context but insufficient for a mutation/read operation.

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

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

Extremely concise with two sentences: a warning/preference statement and the core functionality. Every word earns its place, and it's front-loaded with the most critical information (the warning).

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

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

Given 2 parameters with 0% schema coverage and no annotations, the description is incomplete—it lacks parameter explanations and behavioral details. However, an output schema exists (not shown), which may cover return values, and the warning provides some usage context, making it minimally adequate but with clear gaps.

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

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

Schema description coverage is 0% (no parameter descriptions in schema), and the description only mentions 'parent_id' briefly ('omit parent_id for root'). It doesn't explain what 'parent_id' or 'secret_code' parameters do, their formats, or provide any semantic meaning beyond the schema's basic structure.

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

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

The description clearly states the verb ('List') and resource ('WorkFlowy nodes'), making the purpose specific and understandable. It distinguishes from sibling 'workflowy_glimpse' by indicating a preference hierarchy, though it doesn't fully explain functional differences between listing and glimpsing.

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 'Prefer workflowy_glimpse (GLIMPSE) for reading trees' and provides a usage tip ('omit parent_id for root'), giving clear when-to-use guidance and an alternative tool. This directly addresses sibling tool 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 are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Move') but lacks details on permissions required, whether the move is reversible, effects on child nodes, rate limits, or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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

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

The description is a single, efficient sentence with no wasted words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential information without redundancy.

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

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

Given the tool's moderate complexity (3 parameters, mutation operation) and the presence of an output schema, the description is minimally adequate. However, with no annotations and low schema coverage, it lacks details on behavioral traits, parameter meanings, and usage context. The output schema may cover return values, but the description does not address critical aspects like error handling or dependencies.

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 mentions 'node_id' and 'parent_id' implicitly but does not explain their formats, what 'null' parent_id means (e.g., moving to root), or the 'position' parameter's purpose and allowed values. The description adds minimal semantic value beyond the schema's structure.

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 ('Move') and resource ('a WorkFlowy node'), specifying the destination ('to a new parent'). It distinguishes from siblings like 'workflowy_create_single_node' or 'workflowy_delete_node' by focusing on relocation rather than creation or deletion. However, it doesn't explicitly differentiate from similar tools like 'workflowy_update_node' which might also affect node positioning.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites (e.g., node existence), exclusions (e.g., moving to invalid parents), or comparisons with sibling tools like 'workflowy_update_node' that might handle node modifications. This leaves the agent without context for tool 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?

With no annotations, the description carries full burden. It discloses the tool forces a snapshot and updates a cache, implying a write/mutation operation with potential performance impact. However, it lacks details on permissions, rate limits, or what 'force' entails (e.g., overwriting, triggering background jobs).

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

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

The description is a single, efficient sentence that front-loads the core action ('Force a fresh snapshot') and purpose ('update the local cache'). Every word adds value without redundancy, making it highly concise and well-structured.

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

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

Given 0 parameters, no annotations, and an output schema (which handles return values), the description is reasonably complete. It explains what the tool does and its purpose for cache-dependent systems. However, as a mutation tool with no annotations, it could benefit from more behavioral context (e.g., side effects, idempotency).

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 with 100% schema description coverage. The description doesn't need to explain parameters, so it appropriately focuses on behavior. Baseline is 4 for zero-param tools, as no parameter semantics are required.

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 ('Force a fresh /nodes-export snapshot and update the local cache') and specifies the resource (cache used by NEXUS and UUID Navigator). It distinguishes from siblings like 'workflowy_export_node' by focusing on cache refresh rather than data export, though it doesn't explicitly name 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 implies usage when a fresh snapshot is needed for cache-dependent tools (NEXUS/UUID Navigator), but doesn't specify when to use this vs. other cache-related or export tools. No explicit when-not or alternative guidance is provided, leaving context somewhat open.

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 mentions 'bypass WebSocket' and loading 'complete tree regardless of expansion state,' which adds useful context about the tool's approach and scope. However, it lacks details on permissions, rate limits, error handling, or what 'load' entails (e.g., data format, performance implications). For a tool with no annotations, this leaves gaps in behavioral understanding.

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

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

The description is highly concise and well-structured, consisting of two sentences that efficiently convey purpose and usage guidelines. Every word earns its place, with no redundancy or fluff, making it easy to parse and understand 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 the tool's complexity (loading entire trees with 4 parameters) and the presence of an output schema (which mitigates the need to describe return values), the description is partially complete. It covers purpose and usage well but lacks parameter explanations and detailed behavioral context, especially critical since no annotations are provided. This results in a moderate level of completeness for effective agent use.

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

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

Schema description coverage is 0%, meaning none of the 4 parameters (node_id, depth, size_limit, output_file) are documented in the schema. The description does not mention any parameters or their semantics, failing to compensate for the schema gap. This leaves the agent with no guidance on what inputs are needed or how they affect the tool's behavior, beyond the required 'node_id' inferred from the schema.

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

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

The description clearly states the tool's purpose: 'Load entire node tree via API (bypass WebSocket).' It specifies the verb ('load'), resource ('entire node tree'), and mechanism ('via API, bypass WebSocket'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'workflowy_glimpse' or 'workflowy_get_node' beyond mentioning 'ETCH' and 'complete tree regardless of expansion state,' which are somewhat indirect comparisons.

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 scenarios: 'Use when Key Files doesn't have parent UUID for ETCH, or when Dan wants complete tree regardless of expansion state.' This gives clear context for when to use this tool, including specific conditions and user preferences. However, it doesn't explicitly state when not to use it or name alternatives beyond implied references to 'ETCH' and other tools, missing full sibling differentiation.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. While 'Mark as not completed' implies a state mutation, it doesn't disclose whether this requires authentication, what happens if the node doesn't exist or isn't completed, whether the change is reversible, or any rate limits. The description provides minimal behavioral context beyond the basic action.

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

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

The description is a single, efficient sentence that states the core functionality without any wasted words. It's appropriately sized for a simple tool and gets straight to the point. Every word earns its place in conveying the essential action.

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

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

Given the tool's simplicity (single parameter, no annotations, but has output schema), the description is minimally adequate. The output schema existence means the description doesn't need to explain return values. However, for a state mutation tool with no annotations, the description should provide more behavioral context about what 'marking as not completed' entails in the WorkFlowy system and any constraints.

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

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

The input schema has 0% description coverage, so the description must compensate. However, it provides no information about the 'node_id' parameter - what format it should be, where to find it, or what constitutes a valid ID. The description adds no parameter semantics beyond what's implied by the tool name, leaving the single required parameter completely undocumented in both schema and description.

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

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

The description clearly states the action ('Mark as not completed') and resource ('a WorkFlowy node'), making the purpose immediately understandable. It distinguishes from sibling 'workflowy_complete_node' by specifying the opposite state change. However, it doesn't specify what 'not completed' means in the WorkFlowy context, leaving some ambiguity.

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

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

The description implies usage when a previously completed node needs to be marked incomplete, but doesn't explicitly state when to use this tool versus alternatives. No guidance is provided about prerequisites (e.g., the node must exist and be currently marked as completed) or when not to use it. The existence of 'workflowy_complete_node' as a sibling suggests a clear alternative, but this isn't mentioned in the 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 full burden for behavioral disclosure. While 'Update' implies mutation, it doesn't disclose whether this requires specific permissions, whether changes are reversible, what happens when only some fields are provided (partial updates), or what the response contains. For a mutation tool with 5 parameters and no annotation coverage, this is a significant gap in 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 extremely concise at just 5 words, with no wasted language. It's front-loaded with the core action and target. While this conciseness comes at the cost of completeness, the structure itself is efficient with every word serving a purpose.

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

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

Given this is a mutation tool with 5 parameters, 0% schema description coverage, no annotations, but with an output schema, the description is incomplete. While the output schema may document return values, the description fails to provide essential context about what can be updated, how updates work, when to use this versus sibling tools, or behavioral implications. For a tool with this complexity, the description should do significantly more.

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%, meaning none of the 5 parameters have descriptions in the schema. The tool description provides zero information about what the parameters mean, their purposes, or how they interact. It doesn't even mention that parameters exist beyond node_id, leaving the agent to guess what can be updated based on parameter names alone.

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

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

The description clearly states the action ('Update') and target ('an existing WorkFlowy node'), providing specific verb+resource. However, it doesn't distinguish this tool from sibling update tools like 'workflowy_complete_node' or 'workflowy_uncomplete_node' which also modify nodes, nor does it mention what aspects can be updated (name, note, layout_mode, completion status).

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over 'workflowy_complete_node' for marking completion, or 'workflowy_move_node' for structural changes, nor does it specify prerequisites like needing an existing node_id. There's no explicit when/when-not context provided.

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