CoreModels

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

The annotation destructiveHint is set to true, but the description consistently describes a creation operation ('Create multiple nodes...') with no mention of destructive actions. This is a direct contradiction between the structured annotation and the description, so behavioral transparency is scored 1 and flagged as an annotation contradiction.

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

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

The description is well-structured with a concise opening, bulleted usage criteria, and clear paragraphs for ID sourcing and relation endpoints. Every section adds necessary operational information without fluff.

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

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

Given the complexity of bulk creation (nodes, relations, mixins) and the absence of an output schema, the description covers key contextual aspects: atomic behavior, when to use, ID sourcing, and relation endpoint flexibility. It provides enough for an agent to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It adds crucial semantics by explaining that required IDs come from specific tools, and that relation endpoints can reference either newly created nodes in the same payload or existing project nodes. This goes beyond the raw schema fields, though it does not describe every nested field's meaning.

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 'Create multiple nodes, relations, and mixin values in one atomic operation,' which clearly states the verb and resource. It distinguishes itself from siblings by noting 'For a single node with no relations/mixins, prefer create_node,' directly addressing the primary alternative.

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 'When to use' section explicitly lists conditions for using this tool and points to create_node for simple single-node cases. It also provides concrete guidance on sourcing required IDs from get_mixins_and_relation_groups and get_project_summary or search_nodes, making when-and-how usage explicit.

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

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

Annotations already declare readOnlyHint=true, and the description adds background on mixins as structured metadata. However, it does not disclose output structure, pagination, or error behavior, so the added value beyond annotations is marginal.

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 purpose in the first sentence. The third sentence about get_node documentation is a helpful pointer but is somewhat tangential and could be removed without losing core meaning.

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

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

For a simple, read-only, single-parameter tool, the description is adequate. It misses the opportunity to differentiate from the similarly named 'get_mixins_and_relation_groups' and to specify what 'information about mixins' includes, but it does convey the essential purpose clearly.

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

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

Schema has one required parameter graphProjectId with 0% description coverage. The description never mentions this parameter or how to obtain/fill it, leaving the agent to infer from the tool name. It does state 'in a CoreModels project,' which hints at the project context, but adds no syntax or format details.

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

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

The description opens with 'Get information about all mixins in a CoreModels project' – a specific verb and resource. This clearly distinguishes from sibling tools that focus on relation groups (core_models_get_relation_groups_info) or creating mixins (create_mixin_type, create_mixin_value).

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

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

The description implies the tool is for retrieving mixin info, but it does not contrast with the similar sibling 'get_mixins_and_relation_groups' or state when to use this tool over alternatives. The only guidance is a cross-reference to get_node documentation, which is not a usage guideline.

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

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

The readOnlyHint annotation already marks this as safe; the description aligns with 'Get information' but adds no details on output format or side effects. It doesn't contradict.

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

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

Two sentences, no fluff, front-loaded with purpose.

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

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

No output schema, so description should clarify what 'information' the tool returns. It doesn't specify the response structure, leaving a gap 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 has one parameter (graphProjectId) with zero description coverage; the description doesn't explain the parameter's role or format. However, the name is fairly self-explanatory, but still lacks required clarification.

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 information about relation groups for a CoreModels project. The additional sentence explains its use case (creating relations), which differentiates it from siblings like create_relation_group.

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 when to use it (when you need relation groups to create relations), but doesn't explicitly compare to alternatives like get_mixins_and_relation_groups or state when not to use it.

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

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

Annotations provide destructiveHint=true, and the description adds value by warning to avoid duplicates, implying the operation may fail or create conflicts. It also adds domain context about mixins, but does not detail failure modes or permissions. The annotation covers the mutation aspect, so this 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?

Three concise sentences, front-loaded with the primary action, then practical guidance, then domain context. No filler; every sentence earns its place.

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

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

Clear purpose, good alternative guidance, detailed schema, and annotations flag destructiveness. The main gap is lack of explanation for parameter details and what happens on duplicate. However, for a create operation, this 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?

Description provides no parameter-level details. Schema description coverage is 0%, and the description does not explain graphProjectId or mixinTypeDto fields. The only marginal context is 'Mixins are reusable property sets,' which loosely relates to columns, but it is insufficient given the nested schema with required fields.

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 'Create' and resource 'mixin type', clearly stating the tool's function. It also distinguishes from sibling tools like get_mixins_and_relation_groups by advising to check existing mixins first, and defines mixins as reusable property sets.

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 instructs to check existing mixins with get_mixins_and_relation_groups to avoid duplicates. This provides a clear when-to-use and names the alternative tool, giving the agent actionable operational 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?

Annotations provide destructiveHint:true, indicating a mutating operation. The description adds context that a node can have multiple mixins and each mixin multiple columns, suggesting additive behavior, but does not disclose whether existing mixin values are overwritten or merged, nor mention permissions or side effects. It does not contradict annotations.

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

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

Three short sentences, no redundancy. The description is front-loaded with the action, then provides provenance and cardinality in a compact way.

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 create tool with nested objects and no output schema, the description gives important context about ID sourcing and multiplicity but lacks details on return values, error behavior, or whether values are replaced. This is a moderate gap given the tool's complexity.

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

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

Schema has 0% description coverage at the top level, so the description must compensate. It explains that mixinId and column ids originate from get_mixins_and_relation_groups, providing key provenance. However, it does not explain graphProjectId or targetNodeId, and the value semantics (id=column ID, label=value) are only in the schema, not reinforced.

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

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

Description uses specific verb 'Create' and resource 'mixin value for a node', clearly distinguishing from create_mixin_type and other create tools. Mentions that mixinId and column ids come from get_mixins_and_relation_groups, which further clarifies the tool's role.

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 that IDs are sourced from get_mixins_and_relation_groups, giving a clear precondition. Also notes that a node can have multiple mixins and each mixin can have multiple columns, indicating the data model and when multiple calls may be needed. However, it does not explicitly name alternatives or state when not to use.

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

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

The description says 'Create a new node', which is a non-destructive action, but the annotations mark destructiveHint as true. This is a direct contradiction, so the description fails to convey the tool's actual safety profile. The added behavioral detail about default space and spaceIds constraint is useful but cannot override the contradictory safety signal.

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

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

The description is two sentences long, front-loaded with the core action, and every clause adds value. The constraint about spaceIds is concise and directly relevant, with no wasted words.

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

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

Given the tool's complexity (nested object, 2 required params, no output schema) and the contradictory annotation, the description is too sparse. It does not explain the overall node creation process, the meaning of graphProjectId, or what happens on creation (e.g., whether an existing id gets overwritten). The lack of context could lead an agent to misuse the tool.

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

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

Schema description coverage is 0%, so the description must compensate for the schema's lack of documentation. It adds meaning for spaceIds (empty/default behavior) and nodeType (constraint for Space), but does not explain graphProjectId, label, or the optional id field. The partial coverage is insufficient for a nested-object creation tool.

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

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

The description 'Create a new node' uses a specific verb and resource, clearly distinguishing it from siblings like update_node, remove_node, and bulk_create. It states exactly what the tool does without 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 provides a conditional usage rule about spaceIds being required empty for nodeType 'Space', but does not explicitly mention when to prefer this over alternatives such as bulk_create or create_mixin_type. The intended usage is implied but no exclusions or alternatives are named.

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

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

The description adds significant behavioral context beyond the destructiveHint=true annotation: it states the tool returns { projectId, defaultSpaceId }, creates projects private in the caller's default workspace, and fails rather than silently duplicating if a project with the same name exists. This is valuable transparency on return shape and error behavior.

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

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

The description is three sentences long and front-loaded with the purpose, followed by the return value usage and key behavioral facts. Every sentence provides 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 there is no output schema, the description fully explains the return value format and how to use it. It also covers failure behavior, privacy default, and ownership. No critical information is missing for an agent to correctly invoke and interpret the results.

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

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

All three parameters have schema descriptions (100% coverage), so the baseline is 3. The description does not add new details about parameter semantics, but it does implicitly relate the default space in the description to the defaultSpaceName parameter. No additional compensation is needed.

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

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

The description clearly states the specific action: 'Create a new CoreModels project owned by the calling user, including a ready-to-use default space.' It distinguishes this from sibling creation tools by focusing on project-level creation and explicitly mentions the returned IDs that are used as inputs to other 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 clear usage context by explaining that the returned projectId and defaultSpaceId are used as graphProjectId and spaceId in other tools (e.g., import_jsonschema). This implies when this tool is appropriate, though it does not explicitly state when not to use it or name alternatives.

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

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

Annotations already provide destructiveHint=true, signaling a mutating operation. The description adds context about the relation's directed nature and the template requirement, but does not disclose side effects such as whether existing relations are overwritten or if node existence is validated. This is acceptable given annotation coverage, 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?

Two concise sentences, front-loaded with the main action. The second sentence efficiently explains relationGroupId and points to the relevant sibling tool. No wasted words.

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

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

For a create tool with nested object schema and no output schema, the description covers the core action, directionality, and the key template parameter. It lacks explicit mention of return behavior or validation requirements, but the reference to get_mixins_and_relation_groups fills an important knowledge gap. Overall adequate for the tool's complexity.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies fromNodeId and toNodeId as endpoints and relationGroupId as the template (with a reference to list templates). However, the 'id' field's purpose (client-generated 32-hex identifier) is not explained, and graphProjectId's role is only implied. Partial compensation, but gaps remain.

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') and the resource ('directed relation'), with explicit direction 'fromNodeId → toNodeId'. It distinguishes itself from sibling tools like create_node and create_mixin_type by specifying the relation entity.

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

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

The description implies use when creating relations between nodes and provides a practical prerequisite: 'list templates with get_mixins_and_relation_groups.' It does not explicitly exclude alternative creation tools, but the resource type is clear enough to guide 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?

The description adds some behavioral context beyond the annotations: it explains the rejection of duplicate labels and enumerates allowed mappings. However, the annotation destructiveHint: true is never explained or addressed; there is no mention of potential destructive side effects, which is a significant gap for an operation marked as destructive.

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—two sentences—and front-loads the core purpose first. Every sentence provides useful information: the definition of a relation group, the prerequisite call, and the allowed mapping values. No wasted words.

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

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

Given the tool's complexity (nested group object, no output schema, destructiveHint annotation), the description covers the main inputs and prerequisites but misses key contextual details: what the tool returns, why it is marked destructive, and any side effects on existing data. The schema provides some structural details, but the description could be more complete for an agent to use the tool safely.

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 does so by listing the allowed mappings (Type, Element, Name Spaces, etc.), which clarifies the valid values for fromMappings and toMappings. It also indirectly explains the purpose of the group object as a definition of source→target combos. It does not explain graphProjectId, but that is fairly self-explanatory.

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 'Create' and the resource 'relation group', and defines it as 'a class defining valid source→target node-type combinations for relations.' This is specific and distinct from sibling tools like create_relation or create_mixin_type, which are about different entities.

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

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

The description gives explicit prerequisite guidance: 'Always call get_mixins_and_relation_groups first' and warns that duplicate labels are rejected. It also lists allowed mapping values, which is a practical usage constraint. It does not explicitly exclude any alternative tools, but it clearly implies when this tool 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?

Annotations declare readOnlyHint=true, and the description adds valuable behavioral details such as mode-dependent nodeIds requirements and the mandatory flag constraint. It does not contradict annotations and provides context beyond what annotations offer.

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

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

Two sentences with no fluff. The first sentence states the purpose, the second delivers key usage constraints. Front-loaded and efficient.

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

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

For a tool with 11 parameters and no output schema, the description covers the main workflow and critical constraints. It does not describe the output format or all parameters, but the essential usage is adequately specified.

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

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

Schema description coverage is low (36%), so the description must compensate. It clarifies configTypeId, graphBased, nodeIds, and the boolean export flags, but leaves includeSpace and useDefaultType unexplained. This is partial compensation, not full.

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 exports project data in JSON-LD format using a configured export profile. It distinguishes from sibling tools like export_jsonschema and export_shex by specifying JSON-LD and referencing the prerequisite fetch_json_ld_import_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?

It provides clear usage context: instructs to fetch the profile first, states the requirement for at least one export flag, and distinguishes tree-based vs graph-based behavior. However, it does not explicitly mention when not to use this tool versus alternatives.

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

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

The annotation readOnlyHint=true already declares this as a read operation, but the description adds no further behavioral context such as output structure, scoping behavior, or any potential limitations. It only restates the 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, front-loaded sentence with no filler words, making it highly concise and easy to read.

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

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

With 4 parameters, no output schema, and minimal annotations, the description is too sparse to fully inform an agent. It omits what the exported string contains, how parameters like spaceId or configTypeId affect output, and any relationship to sibling export 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 50% (rootNodeId and configTypeId have descriptions), but the description itself adds no information about any parameters. It does not clarify what graphProjectId, spaceId, or configTypeId mean for the export, leaving gaps the description could have filled.

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 'Export project data as a JSON Schema string' clearly states a specific verb (export), resource (project data), and output format (JSON Schema string), distinguishing it from siblings like export_json_ld and export_shex.

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

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

The description implies the tool should be used when a JSON Schema export is needed, but it does not explicitly mention when to choose this over alternative export formats or any exclusion criteria. Sibling names exist but are not referenced.

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?

Annotations provide readOnlyHint=true, which covers the safety profile. The description adds that the output is a 'ShEx schema string', giving a hint about return type, but does not disclose additional behavioral traits such as effects on nodeIds filtering or response size.

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, compact sentence that front-loads the action and format. Every word adds value with no 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 simple export tool with readOnly annotation and schema covering most parameters, the description is sufficient. It states the return format but does not elaborate on scoping behavior, which is mildly incomplete but acceptable given the schema's nodeIds description.

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

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

Schema description coverage is 50%, with descriptions for nodeIds and includeCardinality but not for spaceId or graphProjectId. The tool description does not add parameter-level meaning beyond what the schema provides, but the remaining parameters are self-explanatory IDs.

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', the resource 'project data', and the specific format 'ShEx (Shape Expressions) schema string'. This distinguishes it from sibling export tools like export_json_ld and export_jsonschema, which produce different formats.

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 ShEx output is needed, but does not explicitly state when to use this tool over alternatives or provide exclusions. It lacks guidance on selecting between export_shex, export_json_ld, and export_jsonschema.

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?

Annotations already declare readOnlyHint=true, and the description's verb 'Fetch' is consistent. However, the description adds little beyond the annotation; it does not elaborate on the response format, whether profiles include both import and export variants, or any access constraints. It provides minimal 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 a single, clear sentence with no redundant wording. It conveys the essential purpose without unnecessary detail.

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 relatively simple (one parameter, no output schema), but the description is vague about what the returned profiles look like or how they are structured. The phrase 'import/export profiles' is slightly inconsistent with the tool name 'import profiles', which may confuse. It does not fully address what the agent should expect from the response.

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

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

Schema description coverage is 0%, and the description does not explicitly explain the parameter 'graphProjectId'. While the parameter name and the description's mention of 'for a project' provide some implicit semantics, the description fails to compensate for the lack of schema documentation, such as stating the expected format or behavior.

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

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

The description uses a specific verb ('Fetch') and clearly identifies the resource ('JSON-LD import/export profiles') and scope ('available for a project'). This distinguishes it from sibling tools like 'fetch_json_schema_import_profiles' (which targets JSON Schema) and 'export_json_ld' (which exports rather than fetches).

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 does not mention prerequisites, use cases, or related tools such as 'import_jsonschema' or 'fetch_json_schema_import_profiles'. The usage context is only implied by the tool name and 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?

The description adds no behavioral traits beyond the readOnlyHint annotation. It does not disclose what the profiles contain, how they are structured, or any side effects (though none are expected). No added context such as authentication or rate limits is provided.

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, concise sentence that front-loads the core purpose. No filler or redundant information; every word earns its place.

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

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

For a simple read-only tool with one parameter, the description is minimally viable but leaves gaps. It does not explain what 'import/export profiles' are, what the return shape looks like, or how this differs from the JSON-LD variant. The lack of output schema makes this more noticeable.

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 associates graphProjectId with 'a project', which adds minimal meaning beyond the bare schema. Since schema_description_coverage is 0%, the description carries the burden, but it only partially compensates by indicating the scope of the parameter without explaining format or constraints.

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

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

The description clearly states the tool fetches JSON Schema import/export profiles for a project, with a specific verb and resource. It distinguishes from the sibling fetch_json_ld_import_profiles by the 'JSON Schema' qualifier, though the inclusion of 'export' is slightly confusing given the tool name only mentions import.

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 sibling list includes fetch_json_ld_import_profiles and export_jsonschema, but the description offers no comparison, prerequisites, or explicit exclusionary 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?

Annotations already indicate destructiveHint=true, and the description adds valuable context: it can overwrite an existing summary when stale, requires a Claude API key, and returns the generated summary. This goes beyond the annotations without contradicting them.

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

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

The description is three sentences and covers all essential aspects: purpose, return value, stale behavior, and prerequisites. It is somewhat dense but each sentence adds value, with no fluff or repetition.

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

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

Given moderate tool complexity, no output schema, and annotations covering destructive behavior, the description provides sufficient context: what is generated, where it is saved, return value, staleness handling, and API key requirement. It could mention error cases, but the core behavior is adequately covered.

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

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

Schema description coverage is 50%, with only 'regenerateIfStale' described in the schema. The description adds meaning for that parameter by explaining the staleness logic, while 'graphProjectId' is self-explanatory from its name and pattern. It compensates for the missing schema description on regenerateIfStale.

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 ('Generate') and clearly identifies the resource ('AI summary of the project') and the output format ('markdown AI summary'). It distinguishes itself from the sibling 'get_project_summary' by focusing on generation and persistence.

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 tool's behavior in detail (when it regenerates vs. returns unchanged) but does not explicitly compare it to alternatives like 'get_project_summary'. The usage context is implied but not stated in terms of when to choose this over a read-only option.

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?

ReadOnlyHint is already provided, and the description adds non-obvious detail about the return format: 'compact positional arrays - see the "format" field for the layout.' This helps the agent understand what to expect without contradicting annotations.

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

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

Two concise sentences, front-loaded with purpose and immediate usage guidance. No redundant wording or padding.

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

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

For a simple read-only tool with one parameter, the description covers the purpose, usage timing, and response format hint via the 'format' field. It lacks a full response structure but points to where it is, which is adequate given no output schema.

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

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

The only parameter graphProjectId is self-explanatory by name, but the description does not explicitly define it or its format. Schema coverage is 0%, so the description shoulders the burden; however, the parameter is obvious from the name and the pattern, earning a baseline 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 'Get the project schema: all mixin definitions and all relation-group definitions,' using a specific verb and resource. It distinguishes from sibling get_project_summary by specifying the full schema content, not a summary.

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 instructs to use 'once at the start of a session to discover the IDs needed by other tools,' providing a clear when and rationale. It implies it is the prerequisite before using other tools that require mixinId, columnId, or relationGroupId.

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?

Annotations declare readOnlyHint=true, and the description adds behavioral detail about independent per-category pagination and the hasMore flag, which is not inferable from the schema. This gives the agent a clear model of how to iterate, though it does not mention response envelope or potential auth requirements, so not 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 and front-loaded: a one-sentence summary followed by a clearly structured pagination guide. Every sentence adds value with no filler or redundancy.

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

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

Given the lack of an output schema, the description reasonably conveys both the content (labels/IDs of types, elements, taxonomies) and the pagination contract (page, pageSize, hasMore). It does not cover error cases or authentication, but for a read-only summary tool with a simple parameter set, the provided detail is largely sufficient.

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

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

Schema description coverage is only 33% — only page has an inline description. The description compensates by explaining pagination semantics: omit page to default to 0 and use page+1 when hasMore is true. It also mentions pageSize in the response context, but does not explain graphProjectId beyond its name and pattern, leaving some ambiguity.

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 indicates the tool returns 'Labels and IDs of types, elements, and taxonomies in the project' — a specific resource and scope. While it lacks an explicit verb like 'retrieves' or 'lists', the title and noun-phrase description convey its read-only purpose and distinguish it from mutation 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 no guidance on when to use this tool versus alternatives such as list_projects or generate_project_ai_summary. The pagination instructions are useful but do not help an agent decide between this and sibling tools, so usage context is under-specified.

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

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

The annotation destructiveHint=true already indicates this is a destructive operation, but the description adds no further behavioral context—such as whether it overwrites existing data, what gets replaced, or what side effects occur. No additional transparency is provided.

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 (one sentence) with no wasted words, but it is under-specified. It does not sacrifice conciseness for clarity; it simply omits critical details, making it minimally acceptable in structure.

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 (nested objects, required IDs, and destructive behavior), the description is grossly incomplete. It fails to mention any parameter semantics, output behavior, or usage context, and the schema cannot fully compensate due to 0% coverage. The agent cannot reliably invoke this tool from the description alone.

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

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

The description contains no parameter information whatsoever. The input schema has nested structures with 0% coverage in the description, so the agent receives no explanation of what graphProjectId, selectedSpaceId, or jsonDataSources mean or how to fill them correctly.

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

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

The description clearly states the action ('Imports'), the resource ('JSON Schema'), and the destination ('into a space'). It distinguishes from sibling tools like export_jsonschema, though the term 'space' is not precisely defined.

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

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

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites, and no exclusions. The description is a single sentence with no usage context.

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

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

Beyond the readOnlyHint annotation, the description discloses response format, pagination behavior, and the effect of optional parameters (includeAISummary changes row structure, includePublicProjects expands scope). It also notes the 'format' field for response details. No contradiction with annotations.

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 dense but well-organized, front-loading the primary purpose. Each sentence covers a meaningful aspect (core action, id reuse, filtering, public projects, AI summary, pagination). Slightly longer than minimal but 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?

With 5 parameters and no output schema, the description fully compensates by specifying the returned row structure, pagination semantics, and parameter effects. It is complete enough for an agent to invoke the tool and interpret results without further 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?

Schema coverage is 80%, and the description adds extra meaning: it explains how searchTerm filters (case-insensitive substring), what includeAISummary does to the response (4th and 5th elements), and how page relates to totalPages. This goes beyond the 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 lists the user's CoreModels projects with a specific response format. It distinguishes from siblings like create_project (creates) and get_project_summary (gets summary) by focusing on the listing 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?

Provides clear guidance: 'Use a returned id as graphProjectId for other tools' and explains paging ('increment page up to the returned totalPages'). It doesn't explicitly say when not to use this tool or name alternatives, but the context is sufficient for an agent to select it appropriately.

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

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

The annotations already declare destructiveHint, so the agent knows the operation is destructive. The description adds valuable context by clarifying the scope of destruction: only the mixin column values are removed, not the mixin definition itself. This goes beyond the annotation and addresses a common misunderstanding without contradicting it.

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

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

The description is three short sentences, front-loaded with the primary action. The second sentence provides a key sourcing hint, and the third clarifies scope. There is no redundant or filler content—every sentence adds value.

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

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

Given the nested mixinRemoveDto and the destructive annotation, the description sufficiently covers the action, the source of IDs, and the limitation that the mixin definition remains intact. It does not mention possible side effects or return values, but with no output schema and the schema detailing parameter structure, the description covers the most critical contextual points.

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 a hint that mixinId and column ids come from get_mixins_and_relation_groups, which aids in finding the correct values. However, with schema description coverage at 0%, the description should compensate more for parameters like graphProjectId and targetNodeId, which are not explained. The schema provides some structure, but a bit more textual guidance would be beneficial.

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 ('Remove') and clearly identifies the resource ('one or more mixin column values from a node'). It also explicitly distinguishes the tool's scope by stating it does not delete the mixin definition, which helps differentiate it from sibling tools like remove_node and create_mixin_value.

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

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

The description provides a clear usage hint: mixinId and column ids come from get_mixins_and_relation_groups, directing the agent on how to acquire necessary IDs. It also clarifies what this tool does not do (delete the mixin definition), which helps decide when to use this tool versus removing the entire mixin. However, it does not explicitly mention alternative tools or conditions for when to avoid this operation.

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?

While annotations include destructiveHint=true, the description adds no behavioral context. The word 'suspend' is ambiguous and could imply a non-destructive reversible action, potentially conflicting with the destructive hint. No additional details about side effects, permissions, or outcome are provided, so the agent gets no clarity beyond the annotation.

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 short sentence, which is concise in length, but it sacrifices clarity. The sentence 'Suspend a node.' is under-specified and misleading. It does not earn its place because it introduces confusion (suspend vs. remove) rather than clarifying 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?

This is a simple tool with only two parameters and no output schema, but the description is too sparse. It does not specify the effect of the action (e.g., whether it deletes the node permanently, what happens to connected edges, or whether the project ID is needed for scoping). The description leaves a large gap in understanding for such a straightforward 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 two required parameters (graphProjectId, nodeId) with no descriptions, and schema description coverage is 0%. The description does not explain the role of either parameter. An agent cannot determine which ID corresponds to what or how they are used, leaving parameter semantics completely ambiguous.

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 verb 'Suspend' which conflicts with the tool name 'remove_node' and title 'Remove Node'. This creates ambiguity about whether the action is temporary suspension or permanent removal. It also does not clearly distinguish from sibling tools like update_node or create_node, as the term 'suspend' has no clear relation to graph node 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 provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or alternative tools. The intended usage must be inferred from the tool name alone, which is insufficient.

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?

Annotations already include destructiveHint: true, and the description reinforces this with 'Remove' but adds no additional behavioral context. It does not disclose whether removal is permanent, whether it cascades to other entities, or any permission requirements. The description adds no transparency beyond what the annotation already signals.

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

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

The description is a single sentence, extremely concise and front-loaded. It wastes no words and is directly to the point.

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 operation with a nested relation object and no output schema, the description is sparse. It does not explain the structure of the relation, the meaning of graphProjectId, the permanent nature of the deletion, or any side effects. The description is too minimal to fully support an agent in invoking 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%, so the description must compensate for parameter meaning. It vaguely refers to 'a relation between two nodes,' hinting at fromNodeId and toNodeId, but it gives no detail about the relation object structure, graphProjectId, or how to identify the specific relation. This is insufficient for an agent to correctly construct the parameters.

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

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

The description clearly states the action: 'Remove a relation between two nodes.' It uses a specific verb ('Remove') and resource ('relation'), and it distinguishes itself from sibling tools like create_relation and remove_node by specifying the removal of a relation rather than a node or creation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or scenarios where another tool (e.g., remove_node) might be more appropriate. The usage context is only implied by the action itself, offering no explicit direction.

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

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

Despite the readOnlyHint annotation, the description goes further by detailing sandbox limitations (no network, no filesystem, time/memory/statement limits), how console.log is captured, how `return` values are serialized, and the automatic injection of graphProjectId in internal calls. This is rich behavioral context beyond annotations.

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

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

The description is longer than average but well-structured into usage context, script API, and environment. Every sentence contributes value, though some details (such as the full API listing) could be condensed without losing critical meaning.

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

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

The description is complete for a tool with no output schema and complex behavior. It explains what the tool returns, how side effects (console.log) are handled, the execution environment, and the available inline API. No major 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?

With only 50% schema coverage, the description compensates by explaining the code parameter's usage and the graphProjectId's role in inner tool calls. However, the phrasing 'do NOT pass it' could be misread as instructing not to supply graphProjectId to run_code itself, which the schema requires. Slight ambiguity prevents 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 verb ('Execute') and resource ('a JavaScript program that orchestrates this server's tools'). It distinguishes from sibling tools by framing it as a code execution and orchestration layer rather than a direct data operation.

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

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

Explicitly recommends using this tool over many individual calls for multi-step tasks, and explains why (intermediate results stay in the sandbox). Also provides an exclusion: only read-only tools are callable from code, guiding against unsafe 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?

Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral detail: it discloses the response format strategy (compact arrays with a format field), filter combination semantics (AND), and pagination behavior (token-based). It does not contradict the read-only hint. However, the pagination section introduces a pagingToken that is not part of the input schema, which is a transparency issue, but the description itself is rich beyond the annotation.

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 sections for filters, optional flags, and pagination. It is concise but informative, using about 150 words for 11 parameters. Every section earns its place, and the phrasing is efficient. It does not ramble or repeat schema information 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?

The description covers key aspects: filters, flags, and pagination. But the pagination instructions conflict with the schema, leaving the agent unsure whether to use page or pagingToken. Additionally, there is no output schema, and the description only vaguely references a 'format' field for the response. While it does not need to detail every return field, the pagination conflict and missing clarification about the 'page' parameter create a notable gap 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 description adds meaning for nodeIds, nodeType, expression, spaceIds, and optional flags, which is necessary because schema description coverage is only 18%. However, it introduces a problematic pagination mechanism: the description instructs to use a pagingToken, but the schema does not define this parameter and has additionalProperties:false, so it would be rejected. The schema instead has a 'page' parameter, and the description's token-based pagination conflicts with the schema's page-number-based approach. This inconsistency undermines the parameter guidance.

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

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

The description clearly states the tool's purpose: 'Search nodes in a CoreModels project' with a specific verb and resource. It adds distinctiveness by mentioning it returns compact positional arrays with a format field, and the filter list separates it from other node-related tools. The phrase 'Search nodes' is unambiguous and distinct from siblings like create_node, update_node, or export functions.

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 for when to use the tool, outlining required filters and optional flags, and explains that filters combine with AND. It does not explicitly compare to alternatives or state when not to use it, but the specific filter options and pagination guidance make the usage context clear. A score of 4 aligns with 'clear context, no 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?

Beyond the destructiveHint annotation, the description discloses that spaceIds replaces (not merges) existing assignments, that an empty array resets to the default space, and that omitted fields remain unchanged. This is critical behavioral information that helps the agent understand the tool's impact.

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

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

The description is three concise sentences, each adding necessary information: the action, the update semantics, and the input requirement. It is front-loaded with the main verb and contains no 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?

The description covers the core behavior, edge cases (empty array, omitted fields), and constraints. It does not describe return values or error conditions, but there is no output schema and this is likely sufficient for an agent to invoke the tool correctly.

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

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

With 0% schema description coverage, the description compensates by explaining the meaning of label and spaceIds, the replacement semantics, the default space behavior, and the requirement that at least one of the two be provided. This adds meaningful guidance 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 identifies the action (updating a node), the target (existing node), and the specific fields (label and/or space assignments). It is distinct from sibling tools like create_node and remove_node, making its 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 states exactly what can be changed and the constraints (at least one of label or spaceIds must be provided), giving clear context for when this tool is appropriate. However, it does not explicitly mention alternatives or exclusions relative to sibling tools, 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?

Annotations declare readOnlyHint=true, and the description adds context about schema regeneration and the requirement for a serialized JSON string. This goes beyond annotations and helps the agent understand the underlying behavior and constraints.

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

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

The description is two sentences, front-loaded with the main purpose, and contains no redundant information. Every sentence contributes to understanding the tool's function and special requirements.

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

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

The description explains the schema regeneration process, which is essential context. However, it does not mention the return format or error behavior for invalid JSON, and with no output schema this leaves some ambiguity. The read-only annotation and simple purpose keep the gap modest.

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 80%, so the schema already documents most parameters. The description adds a parenthetical 'export profile id' for configTypeId and repeats the serialized string requirement for jsonString, but these are marginal additions over the schema.

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

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

The description clearly states the tool validates a JSON document against a stored JSON Schema, using a specific verb and resource. This distinguishes it from sibling tools like export_jsonschema and import_jsonschema, which focus on schema export/import.

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

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

The description explains that the schema is regenerated using configTypeId and rootNodeId, giving clear context on when to use this tool for validation. It doesn't explicitly mention alternatives or exclusions, but the purpose is well-defined enough for a validation use case.

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