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

With no annotations, the description carries the transparency burden. It discloses what the validation catches (node names, attribute types, hierarchy violations) and the schema version, and provides an example document. It does not detail output behavior, but the presence of an output schema reduces that need.

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

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

The description is well-structured: purpose, use case, error categories, and an Args section with example. It is longer than strictly necessary but every section adds value, especially the sample XML document.

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

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

For a single-parameter validation tool with an output schema, the description covers what the tool does, when to use it, input format requirements, and gives an example. It could add a note about return values, but output schema likely covers that, and it remains complete enough for an agent to invoke correctly.

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

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

Schema coverage is 0%, yet the description fully compensates with an Args section explaining that x3d_xml must be a complete X3D document including XML declaration and root element, plus a minimal working example. This gives the agent everything needed to construct valid input.

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

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

The description opens with a specific verb and resource: 'Validate an X3D XML string against the official X3D 4.0 schema.' It clearly identifies the tool's function and distinguishes it from sibling validate_x3d_file_tool by emphasizing input as a string rather than a file.

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

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

The description explicitly states when to use the tool: 'before presenting it to users or writing it to files.' It gives clear context but does not name alternative tools or define when not to use it, so it stops short of full exclusion guidance.

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

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

With no annotations, the description carries the transparency burden. It discloses supported file type (.x3d XML-encoded) and that it works on files on disk, but does not mention read-only behavior, error handling, or return format. For a validation tool, some traits are implied, so a 3 is appropriate.

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

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

The description is concise and front-loaded with the primary action. The Args section is minimal and clear, with no redundant content.

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

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

For a simple single-parameter tool with an output schema provided, the description covers the essential context: purpose, file type restriction, and parameter definition. It lacks explicit mention of file existence requirements, but that is a minor gap.

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

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

The schema has 0% description coverage, so the description must fully compensate. It defines filepath as 'Absolute path to a .x3d file on disk', adding clear meaning beyond the bare type declaration.

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 validates X3D files on disk against the official X3D 4.0 schema, providing a specific verb (validate) and resource (X3D file on disk). It distinguishes from sibling tools like validate_x3d by explicitly mentioning 'file on disk' and the .x3d extension.

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

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

The description gives a clear use case: 'Use this tool to check existing .x3d files for schema compliance.' It does not mention exclusions or alternative tools, but the context is unambiguous.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It states that the tool parses both the scene and node XML, inserts the node, and returns modified scene XML. This gives a basic process overview but does not mention error handling, validation, or whether the original scene is preserved. It provides some transparency but lacks richer 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 compact and well-structured: a one-sentence summary, a sentence describing the process, and a clear Args list. Every sentence provides necessary information, and the format makes it easy to scan. No redundancy or filler.

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

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

Given the tool has an output schema (though not shown), the description needn't detail return values, but it does mention returning modified scene XML. It covers all parameters and the insertion logic. It lacks mention of edge cases like invalid XML or missing DEF, but for a 3-parameter tool with solid parameter semantics, it is reasonably complete.

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

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

The schema has 0% description coverage and only type/title, so the description fully compensates. The Args section explains scene_xml as the complete document, node_xml as a fragment that can be generated via x3d_generate_node or written manually, and parent_def with its semantics including the empty-string default. This adds substantial meaning beyond the schema.

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

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

The description uses the specific verb 'Insert' and the resource 'an X3D node into an existing scene', which clearly distinguishes it from sibling tools like x3d_remove_node or x3d_modify_node. It states the core function in the first sentence, making the tool's purpose immediately clear.

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

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

The context of use is clear: you provide a scene and a node XML to insert, with optional parent DEF. It references x3d_generate_node as a source for node_xml, providing a related alternative for generating the node. However, it does not explicitly mention when not to use this tool or compare it directly with alternatives like x3d_modify_node, so it stops short of a 5.

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

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

With no annotations provided, the description carries full responsibility for behavioral transparency. It reveals key behaviors: creates a TimeSensor, auto-selects the appropriate Interpolator based on field type, creates ROUTE statements, inserts all nodes, and returns the modified X3D document. It also documents parameter defaults (duration, loop), giving an agent a clear understanding of side effects.

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

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

The description is well-structured: a one-sentence purpose summary, a brief behavioral explanation, and a precise Args list. Every sentence contributes value, with no repetition or filler. The front-loaded summary and organized details make it easy to scan.

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

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

For a 7-parameter tool with an output schema, the description covers purpose, mechanism, parameter meanings, and return behavior ('returns the modified X3D document'). It is self-contained and sufficient for correct invocation, even without an explicit description of return values (since an output schema exists).

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

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

Schema description coverage is 0%, but the description's Args section thoroughly explains every parameter with X3D-specific examples (e.g., 'rotation' → OrientationInterpolator, 'from_value' as a space-separated string). This fully compensates for the missing schema descriptions, adding meaning beyond the property 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 opens with a clear verb+resource: 'Generate a complete X3D animation chain and insert it into a scene.' It distinguishes itself from sibling tools like x3d_generate_node and x3d_route by specifying the full chain (TimeSensor, Interpolator, ROUTEs) and the auto-selection behavior.

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

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

The description gives clear context on when to use the tool: to animate a node's field. It explains the automated interpolator selection, implying this is the high-level animation tool rather than manual route creation. However, it does not explicitly name alternatives or provide 'when not to use' guidance, so it stops short of a 5.

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

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

With no annotations, the description conveys that this is a read-only reference operation through words like 'Explain' and 'Provides reference documentation.' It also specifies the behavior for each topic, giving clear expectations of what the tool will return. This fully carries the transparency burden.

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

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

The description is front-loaded with a one-sentence summary, followed by a brief explanation and a compact Args list. There is no filler or repetition; every line adds value.

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

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

Given the tool's simple interface and the presence of an output schema, the description fully covers how to invoke the tool and what to expect. The only minor gap is not describing return value structure, but that's covered by the output schema, so it's complete.

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

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

The schema only defines a generic string parameter with 0% coverage, so the description must provide all meaning. It does so thoroughly by listing the five accepted values ('interpolators', 'timesensor', 'routes', 'examples', '') and what each returns, effectively replacing schema enums.

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 explains X3D animation concepts and lists available interpolators, with a specific reference to event-driven animation. This distinguishes it from sibling tools like x3d_animate (creating animations) and x3d_route (creating routes).

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

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

It provides explicit guidance on what topic strings to use and what each returns, and says 'Call with no topic for a general overview.' However, it doesn't explicitly state when not to use this tool (e.g., when you want to actually create an animation or route), so it lacks explicit exclusions or alternative tool references.

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 disclose behavioral details beyond the core action. It does not mention return value, error handling for invalid node names, or whether this checks against a scene graph or just the specification. The description simply restates the purpose without additional behavioral context.

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

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

The description is concise, front-loaded with the purpose, and uses a clear formatted Args section. No redundant wording.

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?

As a simple check tool with an output schema present, the description needn't detail return values. However, it lacks usage context and behavioral caveats, making it only moderately complete for a user choosing among sibling tools.

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

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

Schema coverage is 0%, so the description compensates with an Args section providing examples for parent_node and child_node. This adds meaningful semantic context beyond the bare string type in the schema, though it could specify valid inputs more precisely.

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

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

The description clearly states the tool's function: 'Check if a parent-child node relationship is valid in X3D' and elaborates that it verifies child placement based on X3D 4.0 type constraints. This specific verb+resource definition distinguishes it from siblings like validate_x3d or x3d_node_info.

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 validate_x3d or x3d_semantic_check. The description only explains what it does, not the appropriate context 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 present, so the description carries the full burden. It discloses that the return value is the full XML subtree, that def_name takes precedence, and that x3d_source can be a file path or XML string. It does not mention error behavior for no-match cases, but otherwise provides meaningful 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 compact and well-organized, with a clear one-sentence purpose statement followed by a structured parameter list. It avoids unnecessary filler and every sentence contributes to understanding the tool.

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

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

For a tool with 4 parameters and 0% schema description coverage, the description provides sufficient context to invoke it correctly: source format, selection modes, precedence, return value, and helpful sibling tools. The presence of an output schema further reduces the need to describe return structure in detail.

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

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

The input schema has no parameter descriptions (0% coverage), but the description's Args section thoroughly explains each parameter: x3d_source, def_name, node_type, and index, including examples, defaults, and how they interact. This fully compensates for the missing schema descriptions.

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

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

The description opens with a specific verb-resource pair: 'Extract a specific node (and its children) from an X3D scene as XML.' It clarifies selection by DEF name or node type + index, which distinguishes it from sibling tools like x3d_node_info or x3d_search_nodes.

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

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

It explains when to use DEF name vs node type + index, states precedence when both are given, and points to x3d_list_defs and x3d_scene_stats for discovery. It does not explicitly contrast with alternative sibling tools, but the usage context is clear enough for selection.

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

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

With no annotations, the description carries the burden, but it only states the tool 'explains' and gives examples of valid inputs. It does not explicitly confirm that the operation is read-only or describe error handling, though the verb 'explain' implies a non-mutating query. The examples of enumeration types add some behavioral context about accepted input formats.

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, front-loaded with the primary purpose, and uses a brief Args section to document the parameter. Every sentence adds value, and the length is appropriate for the tool's simplicity.

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 low complexity (one parameter) and the presence of an output schema, the description fully covers the essential information: what the tool does, what input it expects, and example values. It is self-contained and sufficiently complete for an agent to select and invoke it correctly.

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

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

Schema description coverage is 0%, but the description compensates with a detailed Arg section explaining field_type and providing concrete examples (SFVec3f, MFString, alphaModeChoices). This adds significant meaning beyond the bare string property in the input 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 'Explain an X3D field type or enumeration type,' identifying the specific resource and action. The added sentence 'Use this to understand what values a field accepts' further clarifies the scope and distinguishes it from sibling tools like x3d_node_info or x3d_search_nodes.

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

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

The description provides explicit usage context with 'Use this to understand what values a field accepts,' which tells the agent when to invoke this tool. It does not mention alternatives or exclusions, but for a single-purpose reference tool this is sufficient.

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

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

With no annotations, the description carries the burden for behavioral disclosure. It mentions using the official x3d.py library and ensuring type correctness by construction, and notes that it returns an XML fragment. However, it does not disclose error handling, validation of node names, or whether the operation is side-effect free, leaving some ambiguity.

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

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

The description is well-structured with an Args section and multiple examples. While somewhat long, every part contributes useful information. The examples are particularly valuable and not redundant.

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

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

Given the tool's simplicity, the description covers the essentials: what it does, parameters with examples, and return format. An output schema exists, so return details are not required. However, it does not mention integration with sibling tools or validation behavior, though this is not critical for a basic generator.

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, but the description compensates well by providing concrete examples for both parameters. It explains node_name with valid examples (Box, Material, Transform) and fields with JSON examples (size, diffuseColor, translation). This adds significant meaning beyond the raw schema.

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

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

The description clearly states 'Generate a single X3D node with specified field values' and explicitly says it returns the XML fragment. This differentiates it from sibling tools like x3d_add_node (which likely adds to a scene) and x3d_extract_node (which extracts from a scene).

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 through examples but does not explicitly state when to use this tool versus alternatives. It lacks explicit 'when not to use' or references to sibling tools, so the agent must infer the appropriate context.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains both behaviors (listing all components vs. nodes in a component) and gives examples of valid component names. It does not mention edge cases like invalid component names, but the core behavior is transparent.

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

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

The description is well-structured: a concise opening sentence, clear usage instructions, and an Args block. Every sentence adds value, and the front-loaded first sentence immediately conveys the tool's 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?

The tool is simple (1 optional parameter), and an output schema exists, so return values are not needed in the description. The description covers both invocation modes and parameter semantics, making it complete for an agent to select and use correctly.

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

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

The input schema has zero description coverage, so the description fully compensates. It explains that component_name is optional, what an empty value means, and provides concrete examples (Geometry3D, Lighting, Shape, etc.). This adds significant meaning 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: 'List X3D components, or list all nodes in a specific component.' This gives a specific verb and resource, and distinguishes it from sibling tools like x3d_list_profiles by focusing on components rather than profiles.

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 usage context: call with no arguments to see all components, or with a component name to see its nodes. It does not explicitly exclude alternatives or name sibling tools, but the two invocation modes are clearly explained.

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

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

With no annotations, the description carries the burden. It explains return behavior and input flexibility, but doesn't explicitly state whether the operation is read-only or what error handling looks like. For a list operation, this is adequate but not rich.

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

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

The description is structured with a clear summary, a brief explanation of DEF names, return details, and usage hint. It's a bit wordy with the HTML analogy, but all content is relevant and front-loaded.

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

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

For a relatively simple tool, the description covers purpose, input format, output contents, and usage context. An output schema exists, so return structure isn't needed in the description. Missing edge cases like invalid input, but not essential.

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 only says 'x3d_source' is a string, with no description. The description adds critical detail: it can be a file path or full XML document string, which significantly clarifies usage. This compensates well for the 0% schema coverage.

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

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

The description clearly states the tool's purpose: listing all DEF'd nodes in an X3D scene, with specific mention of returned context (node type, parent, children). This distinguishes it from siblings like x3d_search_nodes or x3d_node_info by focusing on DEF names as identifiers.

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?

Includes explicit usage context: 'Use this to find targets for x3d_extract_node or x3d_add_node', which signals when this tool is appropriate. It doesn't explicitly state when not to use it, but the related tools give some contrast.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds useful context by explaining what profiles are and listing common profile names, but it does not describe return format, ordering, or any edge cases. For a simple read-only list, this level of transparency is adequate but not rich.

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

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

The description is two sentences, front-loaded with the action, and provides only essential context. No wasted words or redundant information.

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

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

For a simple, zero-parameter list tool with an output schema, the description is sufficiently complete. It names the common profiles and explains the domain concept, which is all an agent needs to invoke it correctly. It could mention return behavior, but that's optional here.

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

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

The tool has zero parameters, so the baseline score is 4. The description adds meaningful domain context ('Profiles are capability tiers...') that helps the agent interpret the tool's output, going beyond the empty input 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 'List all X3D profiles with descriptions' using a specific verb and resource, and the mention of 'profiles' distinguishes it from siblings like list_components and list_defs. It unambiguously tells the agent what the tool does.

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

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

The description provides no guidance on when to use this tool versus the many sibling tools (e.g., list_components, list_defs). It does not state any exclusions or alternative scenarios, so the agent is left without 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?

No annotations are provided, so the description carries the burden. It clearly states that the tool finds a DEF node and updates attributes, and returns the full modified XML document. It also notes values are set as XML attribute strings. However, it does not disclose behavior on missing DEF names, duplicate DEFs, or whether a file path input is modified in place, which limits 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 compact, starting with a clear one-line summary, followed by a brief elaboration and a structured Args list. Every sentence adds value without redundancy. It does not repeat schema details unnecessarily.

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 3-parameter tool with a simple output schema, the description covers the core purpose, parameters, and return value. However, the file path ambiguity (whether it reads from and writes back to the file) and lack of edge-case behavior leave some gaps. Overall it is reasonably complete but not exhaustive.

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 zero property descriptions, so the description must compensate. It does so thoroughly: x3d_source is explained as a string or file path, def_name comes with examples, and field_changes includes a JSON example and clarifies that values are set as XML attribute strings. This greatly exceeds the schema's bare parameter 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 opens with 'Modify field values on a DEF'd node in an X3D scene,' which is a specific verb+resource. It further details the mechanism ('Finds the node by its DEF name and updates the specified attributes') and clearly distinguishes from sibling tools like add, remove, move, or animate by focusing on modifying existing node fields.

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 one needs to change field values on an existing named node, but it does not explicitly state when not to use it or name alternative tools. For example, there is no guidance like 'for structural changes use x3d_add_node or x3d_remove_node.' This leaves the selection context only implied.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the node is detached and appended, that cycles are detected and prevented, and that an empty new_parent_def moves the node to be a direct child of <Scene>. This goes beyond a minimal statement. It does not mention error handling or whether the source is mutated in place, but given the output schema, return values are likely covered. Overall, it provides strong behavioral context.

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

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

The description is concise and front-loaded: the first sentence states the core purpose, followed by two sentences of crucial behavioral details, and then a structured Args list. Every sentence adds value; there is no redundant information.

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

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

Given the tool's moderate complexity and the presence of an output schema, the description is quite complete. It covers the operation, special constraints (cycle prevention), and parameter semantics. It does not explicitly list error conditions, but the output schema likely defines the response structure. Overall, the description provides sufficient context for an agent to select and invoke the tool.

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

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

The schema provides zero description coverage for parameters. The description's Args section explicitly explains the meaning and format of each parameter, including the default behavior of new_parent_def. This fully compensates for the missing schema descriptions and gives the agent clear guidance on how to fill in each argument.

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

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

The description clearly states the tool's function with a specific verb ('Reparent') and resource ('a node from its current parent to a new parent in the scene graph'). It distinguishes itself from sibling tools like x3d_add_node and x3d_remove_node by focusing on moving an existing node rather than adding or removing. The details about detaching and appending further clarify the operation.

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

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

The description implies use cases by describing the reparenting action, and the special behavior for new_parent_def='' provides context. However, it does not explicitly discuss when to use this tool versus alternatives (e.g., x3d_add_node) or state any exclusions. Sibling tool names offer some differentiation but the description itself lacks explicit guidance.

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

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

No annotations are provided, so the description carries the burden. It clearly conveys this is a read-only lookup by stating it 'returns' information and does not imply any mutation. It details the output components, but does not mention error behavior for invalid node names, which keeps it slightly below a 5.

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

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

The description is compact, front-loaded with the primary purpose, and includes an args section with examples. Every sentence adds value, with no redundancy or filler.

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

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

The tool has a simple one-parameter input and an output schema, so the description doesn't need to detail return structure. It covers purpose, usage, and parameter semantics completely, making it well-suited for an agent to select and invoke correctly.

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

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

With 0% schema description coverage, the description fully compensates by explaining node_name is case-sensitive, requires exact naming, and provides multiple examples. This gives the agent complete parameter understanding beyond the schema.

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

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

The description clearly states the tool retrieves detailed X3D node specification info, listing specific return content (component, inheritance, fields, link). This specific verb+resource distinguishes it from sibling tools like x3d_search_nodes (which searches) and x3d_field_type_info (which focuses on field types).

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

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

The description explicitly advises using this tool before generating X3D content to ensure correct field names/types/values, providing clear usage context. It doesn't explicitly mention when not to use it or name alternative tools, but the guidance is sufficient for a lookup tool.

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

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

With no annotations, the description carries the transparency burden. It explains the tool's handling of two input formats (full X3D document vs raw nodes), extracting the <Scene> content or placing nodes inside <scene>. It also mentions the inclusion of CDN resources and boilderplate. It does not cover error handling, but for a page-generation tool, the provided behavior is adequate.

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

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

The description is well-structured with a clear opening sentence and a bullet-like Args section. The X3DOM background sentence adds useful context but is somewhat redundant. Overall, it is appropriately sized and organized without excessive verbosity.

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

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

The description covers the tool's purpose, input handling, and all parameter semantics. An output schema exists, so the lack of return-value explanation is acceptable. It omits edge-case behavior and doesn't differentiate from closely named siblings, but for a tool with six parameters, it is quite thorough.

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

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

The schema provides only titles and defaults (0% coverage), so the description's Args section is essential. It explains each parameter meaningfully, including the dual-mode behavior of x3d_content and gives concrete examples for width/height (e.g., '800px', '100%'), which goes well beyond the schema.

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

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

The description starts with a specific, action-oriented sentence: 'Wrap X3D scene content in a complete X3DOM HTML page.' It clearly identifies the tool's function and output, distinguishing it from sibling tools that focus on validation, searching, or node manipulation.

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 the tool—when you need to render X3D in a browser with HTML boilerplate and CDN includes. It does not explicitly contrast this with alternatives like x3dom_starter or x3d_scene_template, but the intended use case is evident.

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 transparency burden. It discloses that the tool returns a ready-to-open HTML file, loads X3DOM from CDN, includes a simple 3D scene (red cube, lighting, viewpoint), and clean styling. This is useful behavioral context, though it does not mention caveats like internet/CDN availability.

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

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

The description is two sentences, front-loaded with the core purpose, and every sentence earns its place by explaining what is generated and how to use the output. No filler or redundancy.

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

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

For a zero-parameter generator with an output schema, the description is complete: it states the purpose, the exact contents of the generated file, and the follow-up action ('Save the output as an .html file and open it'). No important context is missing.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter-level details because there are none to describe, and the schema already indicates no arguments are needed.

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

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

The description clearly states a specific verb ('Generate') and resource ('complete starter X3DOM HTML page with an example scene'). It is specific about the output, but it does not explicitly distinguish itself from sibling tools like 'x3dom_page' or 'x3d_scene_template', so it falls slightly short of full sibling differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions saving the output and opening it in a browser, but there is no indication of preferred use cases or exclusions relative to the many sibling tools.

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

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

With no annotations, the description carries the burden of disclosing behavior. It explains the output (indented tree), what is shown (every node, DEF names, key attributes), and auto-detection of input type. This adds meaningful context, though it omits error handling or potential limitations.

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

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

The description is well-structured with a clear opening sentence, a usage hint, and an Args section. It is slightly verbose but each sentence adds value. No redundant filler, though it could be tightened without losing clarity.

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

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

For a single-parameter parse tool, the description fully covers what it does, when to use it, and what to expect. The output schema likely handles return-value details, so the description can focus on purpose and parameter semantics. It is complete for the tool's simplicity.

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

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

The input schema only defines the parameter name and type with no description. The tool description fully compensates by explaining that x3d_source can be a file path or XML document string and that the tool auto-detects which. This is complete and adds significant 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 that the tool parses X3D content and displays the scene graph as an indented tree, mentioning every node with DEF names and key attributes. This specific verb and resource distinguish it from sibling tools like search or validation.

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 guidance on when to use it: to understand the structure of an existing X3D scene before modifying or analyzing it. It does not explicitly name alternative tools or state when not to use it, but the context is strong enough for correct 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 responsibility for behavioral disclosure. It clearly states that the node and its children are removed, that DEF name takes precedence over node_type, and that the modified XML document is returned. This is vital destructive/transformational context beyond the tool name. Minor gaps like error handling or validation are not addressed.

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

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

The description is well-structured: a brief summary paragraph followed by a clear Args list. Every sentence adds value, with no redundancy or irrelevant detail. It is concise yet comprehensive for the tool's complexity.

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

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

Given the lack of annotations and the presence of four parameters, the description covers target selection, destructive scope, and return value. It also provides a helpful pointer to a related tool. The only gaps are details about error conditions (e.g., node not found, invalid x3d_source), which are not critical for understanding the tool's primary 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 input schema has no parameter descriptions (0% coverage), so the description fully compensates by documenting every parameter: x3d_source (string or file path), def_name (with precedence), node_type (with example types), and index (0-based, default 0). It explains how they interact, which is essential for correct invocation.

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

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

The description begins with a clear, specific verb 'Remove' and identifies the resource ('a node (and its children) from an X3D scene'). It explicitly distinguishes this removal tool from siblings like x3d_modify_node or x3d_move_node by stating the action and scope.

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

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

The description provides context on when to use the tool (when a node needs removal) and explains how to select the target via DEF name or node_type+index. It also directs users to x3d_list_defs for available names, but does not explicitly contrast with alternative tools like modify or extract. The removal purpose is clear enough from context.

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

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

Since no annotations are provided, the description carries the full burden. It discloses the validation steps (checking DEF existence, field validity, access type compatibility, and type matching) and specifies field access constraints. However, it does not state whether the input source is mutated or a new scene is returned, though the presence of an output schema mitigates this 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 well-structured and front-loaded with a clear purpose. It uses a concise overview, contextual explanation, and a clear Args list without redundancy. Every sentence contributes value.

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

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

For a tool with five required parameters and no annotations, the description covers the tool's purpose, validation behavior, and parameter constraints thoroughly. It also mentions the input format (XML or file path). The presence of an output schema means return values need not be described, so the description is contextually complete.

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

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

The description adds significant meaning beyond the raw schema by explaining each parameter: x3d_source is a full XML string or file path, from_node is a DEF name, from_field must be an outputOnly or inputOutput field, etc. This is essential given the schema provides only names and types.

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

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

The description clearly states the tool's specific action: "Validate and insert a ROUTE statement into an X3D scene." It names a specific resource (X3D scene) and a distinct task (ROUTE insertion) that separates it from sibling tools like x3d_add_node or x3d_animate.

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

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

The description explains the purpose of ROUTEs and when this tool is relevant (connecting event outputs to inputs). It does not explicitly mention alternative tools or when not to use it, but the context is clear enough for an agent to select it for ROUTE creation.

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 explicitly lists the computed statistics (total node count, DEF'd vs anonymous, type breakdown, component grouping), which conveys the tool's behavior beyond a mere 'get stats' declaration. It does not mention side effects, but for a read-only stats tool this is sufficient.

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

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

The description is concise and well-structured: a one-line summary, a return-value overview, a usage recommendation, and an Args section. Every sentence adds value without redundancy.

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

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

Despite the existence of an output schema, the description enriches context by summarizing the return values. Combined with a single, well-explained parameter and a clear usage hint, the tool is fully specified for the agent.

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

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

The schema only defines x3d_source as a required string with no description (0% coverage). The description compensates fully by explaining that it can be an absolute file path or a complete X3D XML document string, which is critical for correct invocation.

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

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

The description uses a specific verb+resource ('Get statistics about an X3D scene') and enumerates concrete outputs (node counts by type, DEF'd vs anonymous, component grouping). This clearly distinguishes it from sibling tools like x3d_node_info or x3d_search_nodes.

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

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

The phrase 'Use this for a quick overview before diving deeper' provides a clear usage context. It implies the tool is a starting point, but it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.

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

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

With no annotations, the description carries the burden. It discloses that the tool returns a complete, valid X3D XML document with boilerplate already set up, and explains the effect of each parameter on the output. It doesn't mention error handling or side effects, but the non-destructive template generation nature is clear. This is strong transparency for a generation 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 well-structured, front-loaded with the core purpose and return value, followed by a clear Args section. Every sentence adds value—no fluff. It's appropriately sized for a tool with four parameters.

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

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

The tool is simple, and the description covers what it does, what it returns, and how to use the parameters. An output schema exists, so the return format is further specified. The description is complete enough for an agent to invoke confidently without ambiguity.

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

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

Schema description coverage is 0%, so the description alone explains the parameters. It provides meaningful semantics for 'profile' including common choices (Interchange, Interactive, Immersive, Full) with brief descriptions, and clarifies 'title', 'include_viewpoint', and 'include_light' with their roles. This fully compensates for the lack of schema descriptions.

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

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

The description clearly states the tool's purpose: 'Generate a minimal valid X3D scene template' with a specific verb and resource. It distinguishes itself from siblings like x3d_generate_node and x3d_add_node by focusing on a full-scene template rather than a single node or modification.

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: 'Use this as a starting point and modify the scene content as needed.' It also explains profile choices and their use cases, helping the agent select the right profile. However, it doesn't explicitly mention when not to use it or alternatives like x3d_generate_node, so it stops short of full exclusion guidance.

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

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

No annotations are provided, so the description must carry the full burden. It mentions searching both node names and descriptions in the X3D 4.0 spec, which adds useful behavioral context. However, it does not disclose any additional behaviors such as result limits, sorting, or side effects, leaving it at a basic acceptable level.

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 well-structured: a clear purpose sentence, a usage guideline, and a compact parameter explanation. Every sentence serves a purpose with no filler.

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

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

This is a simple single-parameter tool with an output schema present, so the description does not need to explain return values. It adequately covers what the tool does and when to use it, leaving little ambiguity. A 5 would require more behavioral detail, but the context is sufficiently complete.

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

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

The input schema has no description for the 'query' parameter (0% coverage). The description compensates with an Args section that provides a definition and multiple examples ('light', 'texture', 'animation', etc.), adding significant 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 'Search for X3D nodes by name or description' with a specific verb and resource. It also differentiates from siblings by indicating this is for when the exact node name is unknown, which distinguishes it from x3d_node_info.

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 provides a condition for use: 'Use this when you don't know the exact node name.' This gives clear context but does not name specific alternative tools or exclusion scenarios, so it falls slightly short of a 5.

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

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

No annotations are provided, so the description carries full responsibility. It details the checks performed and return value (structured report of errors, warnings, informational notes), which are key behavioral traits. It does not explicitly state whether the operation is read-only, but the nature of a semantic check strongly implies no mutation.

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

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

The description is compact, front-loaded with the purpose, and uses a bulleted list for readability. Every sentence contributes value, with no redundant information.

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

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

For a single-parameter tool with an output schema, the description covers the input format, the scope of checks, and the report structure. It is sufficient for an agent to invoke the tool confidently.

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

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

Schema coverage is 0%, so the description's definition of x3d_source as a 'Complete X3D XML document string or file path' is the only guidance. This adds meaningful semantics beyond the bare schema, clarifying the accepted input formats.

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

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

The description opens with a specific verb ('Run semantic checks') and clearly defines the resource ('X3D scene'). It differentiates from siblings by explicitly stating 'beyond XSD schema validation' and enumerating the types of issues detected.

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

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

It implies use after XSD validation by saying 'beyond XSD schema validation,' but does not explicitly name alternative tools like validate_x3d or state when not to use it. Context is clear enough for an agent to select it for semantic authoring issues.

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