CoreModels

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

Annotations already indicate destructiveHint=true. The description adds atomicity and prerequisite context (e.g., required IDs from get_mixins_and_relation_groups), going 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?

Front-loaded with core purpose, followed by clear sections for usage, prerequisites, and limitations. No wasted words; 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 complexity (2 params, nested objects, no output schema), the description covers atomic operation, when to use, required IDs, relation endpoint flexibility, and limitations. Sufficient 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%, so description must compensate. It provides high-level guidance (relation endpoints can be same-payload or existing IDs, mixinColumns format) but does not detail the inner structure of bulkCreateDto or each property. Adds some value but incomplete.

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

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

The description clearly states the tool creates multiple nodes, relations, and mixins atomically. It distinguishes from sibling tools like create_node (single node) and create_relation (single relation).

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

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

Explicit 'When to use' section with bullet points: creating more than one node, any creation with relations/mixins, and a preference for create_node otherwise. Also specifies required IDs from other 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?

Beyond annotations (destructiveHint=true), the description adds context that this creates a new type and advises checking for duplicates, but does not detail side effects, permissions, or error handling.

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

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

Three concise sentences front-loaded with the action, no extraneous information—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?

While the description provides pre-check guidance and mixin context, it is insufficient for the complexity: no explanation of the input schema's nested objects or the graphProjectId, and no output schema to describe return values.

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%; the description does not explain the two required parameters (graphProjectId and mixinTypeDto) or their nested fields (label, type, columns), leaving the agent without guidance on what to provide.

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

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

The description clearly states 'Create a new mixin type', defines what mixins are ('reusable property sets applicable to any node'), and distinguishes from sibling tools like create_mixin_value by specifying it's about the type, not values.

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 first with get_mixins_and_relation_groups to avoid duplicates, providing clear when-to-use and precaution.

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

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

The description provides additive context (source of IDs, cardinality) beyond the 'destructiveHint' annotation. However, it does not elaborate on the potential destructive effects (e.g., whether it overwrites or appends values) or any side effects, relying primarily on 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?

Two sentences with no fluff. First sentence states the primary action, second provides context on IDs and cardinality. Efficient 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?

Description covers the source of IDs and the relationship between nodes, mixins, and columns. However, it omits details on the return value, error conditions, and the effect of calling the tool multiple times (e.g., updating vs. adding). Given the complexity of the nested object parameter, more context would be beneficial.

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% at top level, but nested schema has descriptions for mixinId and mixinColumns. Description adds value by explicitly stating that IDs come from 'get_mixins_and_relation_groups', clarifying the source. However, it does not explain the other parameters like graphProjectId or targetNodeId.

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

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

Description clearly states the verb 'Create' and resource 'mixin value for a node'. It distinguishes from sibling tools like 'create_mixin_type' (which creates a template) and 'remove_mixin_value' (which removes).

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

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

Description indicates that mixinId and column ids come from 'get_mixins_and_relation_groups', providing a prerequisite. It also explains the cardinality (multiple mixins per node, multiple columns per mixin). However, it does not explicitly state when not to use this tool or discuss 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 mark destructiveHint=true. The description adds the spaceIds behavior but does not disclose other behaviors like authentication, rate limits, or side effects beyond creation.

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 unnecessary words. The first sentence states the core purpose, the second adds the critical constraint. Highly efficient.

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

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

Given the tool's complexity (nested object, multiple node types, no output schema), the description is too minimal. It fails to explain the id field, label constraints, or the range of nodeType values, leaving the agent with insufficient context.

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

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

With 0% schema coverage, the description should compensate. It only explains spaceIds and indirectly nodeType, while ignoring id, label, and other nodeType enum values. This leaves meaningful gaps.

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

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

The description clearly states the tool creates a node, with a specific verb and resource. It distinguishes from sibling create tools (e.g., bulk_create, create_relation) by adding a constraint about spaceIds when nodeType is Space.

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

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

The description provides explicit guidance on when to omit spaceIds (default space) and when it must be empty (Space nodeType). However, it does not contrast with alternative tools like bulk_create.

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, and the description aligns by stating 'create'. However, the description adds no further behavioral context (e.g., side effects, uniqueness requirements) beyond what annotations imply.

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 action, and every word adds value without redundancy.

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

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

Given no output schema and nested object parameters, the description covers the key action and parameter usage but lacks details on id uniqueness or confirmation behavior, which would improve completeness.

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

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

With 0% schema description coverage, the description explains the relationGroupId parameter as a template and mentions direction, but other parameters like graphProjectId and id are not explained, though fromNodeId and toNodeId are partially inferred from the description.

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

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

The description clearly states 'Create a directed relation fromNodeId → toNodeId', using a specific verb and resource, and distinguishes from siblings by mentioning the direction and referencing get_mixins_and_relation_groups for templates.

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 guidance on how to use relationGroupId by referencing a sibling tool to list templates, but does not explicitly state when to use this tool versus alternatives or when not to use it.

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

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

Annotations provide readOnlyHint=true, and the description confirms a read operation without side effects. Additional behavioral context (profile requirement, boolean constraint, mode behaviors) is disclosed. No contradictions.

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

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

Three sentences with clear front-loading: purpose, prerequisite/constraint, mode explanation. Every sentence adds necessary 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 11 parameters, low schema coverage, and no output schema, the description covers the essential usage decisions (profile prerequisite, boolean constraint, mode). Minor omission of other booleans like includeSpace and useDefaultType is acceptable for brevity.

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 low (36%), but the description adds critical semantics: the prerequisite for configTypeId, the boolean group constraint, and mode-specific nodeIds rules. It does not cover all 11 parameters but focuses on the most important ones.

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

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

The description clearly specifies the tool exports project data in JSON-LD format using a configured export profile. It distinguishes from siblings like export_jsonschema and fetch_json_ld_import_profiles by naming the specific format and profile requirement.

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

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

Explicitly states the prerequisite to call fetch_json_ld_import_profiles first for configTypeId. Also details the constraint that at least one of the four boolean flags must be true and explains when to use tree-based vs graph-based mode based on graphBased and nodeIds.

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, so the agent knows it's a safe read operation. The description adds no additional behavioral context, such as whether the export is synchronous, what is included in 'project data', or any 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 a single short sentence, which is efficient but lacks sufficient detail. It conveys the basic purpose but could be more informative without being verbose. It is front-loaded but incomplete.

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 moderate complexity, the description is too brief. It does not explain the output format, error conditions, or behavior differences when parameters are omitted, making it insufficient for correct tool invocation.

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

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

The input schema has 50% parameter description coverage (only rootNodeId and configTypeId have descriptions). The tool description does not supplement any parameter meanings, leaving spaceId and graphProjectId underdocumented.

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 (Export) and resource (project data) and result (JSON Schema string). However, it does not distinguish this tool from siblings like export_json_ld or import_jsonschema, which also export data in 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 provides no guidance on when to use this tool versus alternatives such as bulk_create or export_json_ld. No context on prerequisites or when not to use it.

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

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

Annotations declare readOnlyHint=true, which aligns with the fetch action. The description adds minimal context ('available for a project') but no additional behavioral traits like authentication or rate limits.

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

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

Single sentence with front-loaded information. Concise but might benefit from a bit more 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?

With no output schema and a single undocumented parameter, the description is insufficient for an agent to understand what profiles are returned and how the parameter works.

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

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

The input schema has 0% description coverage for the only parameter graphProjectId, and the description does not explain what this parameter is or how to use it.

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

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

The description clearly states it fetches JSON-LD import/export profiles for a project, but it does not differentiate from the sibling fetch_json_schema_import_profiles tool.

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

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

No guidance on when to use this tool versus alternatives like fetch_json_schema_import_profiles or export_json_ld. The description lacks 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?

Annotations already declare readOnlyHint=true, so description aligns but adds no extra behavioral context beyond the fetch action. No mention of error cases, rate limits, or what happens if the project ID is invalid.

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

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

A single sentence with no extraneous words, efficiently conveying the action. However, it could be slightly expanded to include parameter context without losing conciseness.

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

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

Given a simple tool with one parameter and no output schema, the description is minimal but sufficient to understand the basic action. Lacks detail on return format or behavior, but for a straightforward fetch, it is adequate.

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

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

Schema description coverage is 0%, meaning the 'graphProjectId' parameter is not explained in the description. The parameter's type and required status are only in the schema, and the description adds no meaning beyond that.

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

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

The description clearly states the verb 'Fetch' and the resource 'JSON Schema import/export profiles available for a project', distinguishing it from sibling tools like 'import_jsonschema' and 'export_jsonschema' which perform the actual import/export actions.

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

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

No guidance is provided on when to use this tool versus alternatives, such as when to fetch profiles vs. directly using import or export tools. No exclusions or prerequisites are mentioned.

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

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

Annotations already mark the tool as readOnlyHint=true. The description adds that it returns compact positional arrays and references the 'format' field for layout, providing useful output structure details 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?

Three short sentences with the core action first, followed by usage guidance and a key output hint. No unnecessary words; each 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 simple read-only tool with one parameter and no output schema, the description covers purpose, usage timing, and output format hint. It lacks detail on how to interpret the 'format' field but remains adequate.

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

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

Despite 0% schema description coverage, the description does not explicitly explain the graphProjectId parameter or its format. The parameter meaning is only implied by context (e.g., 'project schema'), leaving the agent to infer.

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

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

Clearly states the tool retrieves the project schema including all mixin and relation-group definitions. The explanation that it discovers IDs needed by other tools further clarifies its specific role, distinguishing it from sibling tools like create_node or remove_node.

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

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

Explicitly advises using this tool once at the start of a session to obtain necessary IDs. While it doesn't mention when not to use or compare directly to alternatives, the guidance is actionable and contextually 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?

The description discloses that categories with >1000 nodes are omitted and recommends using 'search_nodes' instead. This adds context beyond the readOnlyHint annotation, though it could further explain the exact structure of the returned data.

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-loaded with the core purpose, followed by important behavioral notes. No unnecessary words.

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

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

The description covers the main output type and key limitation. Without an output schema, it gives a basic idea of returns. It could be more detailed about the exact fields, but it is complete enough for a summary 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 only parameter 'graphProjectId' is not described in the description or schema. Schema coverage is 0%, so the description should explain its meaning. While the name implies a project ID, the lack of any detail reduces the agent's ability to provide correct 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 clearly states the tool returns 'Labels and IDs of types, elements, and taxonomies', which is a specific and identifiable output. It also distinguishes from sibling tools like 'search_nodes' by mentioning the 1000-node limit and providing an 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 description explicitly tells the agent when to use this tool versus 'search_nodes': when a category has more than 1000 nodes. This is clear guidance on tool selection.

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

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

Annotations already declare destructiveHint=true, but description adds no additional behavioral details (e.g., whether it overwrites, side effects, required permissions). Wastes opportunity to elaborate 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?

Single sentence is concise but fails to convey necessary information. It does not earn its place as it adds minimal value beyond the tool name.

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

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

Given the complex nested input schema, destructive hint, and lack of output schema, the description is wholly insufficient. Agent needs to know return behavior, prerequisites, and import semantics.

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 description provides zero information about parameters. Agent gets no help understanding 'graphProjectId', 'selectedSpaceId', or 'jsonDataSources'.

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

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

Description clearly states verb 'imports' and resources 'JSON Schema' and target 'into a space'. It distinguishes from sibling 'export_jsonschema' but lacks specifics on what the import entails.

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 on when to use this tool versus alternatives like 'validate_json' or 'create_node'. No when-not-to-use instructions.

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 confirm read-only; description adds pagination details, filtering, and inclusion of public projects, fully disclosing behavior.

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

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

Three compact sentences, no redundancy, front-loaded with core purpose, and each 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?

Despite no output schema, description specifies output format, pagination, and parameter usage. Fully sufficient for an AI 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 covers 75% of parameters; description enriches with 'case-insensitive substring', '1-based page', and meaning of includePublicProjects. Slight gap for pageSize not explained.

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

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

Clearly states it lists the user's CoreModels projects with specific output fields ([id,name,accessLevel]), distinguishing it from mutation tools among siblings.

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

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

Explicitly explains how to use the returned id for other tools, pagination mechanism, and optional parameter behaviors (searchTerm, includePublicProjects).

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 destructiveHint: true, and the description confirms the removal action, reinforcing that it modifies data. It adds the context that the mixin definition itself remains untouched. No additional behavioral traits (e.g., reversibility, permissions) are disclosed, but the coverage is adequate given 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 concise with two sentences, front-loading the action. It efficiently conveys the key points without extraneous text. A slightly more structured breakdown could improve readability.

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 parameter object and no output schema, the description covers the main operation and ID sourcing but omits details about parameters like targetNodeId and the response. It is adequate for a straightforward mutation tool but could be more complete.

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

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

Schema description coverage is 0%, but the description adds value by specifying that mixinId and column ids come from get_mixins_and_relation_groups. However, it does not explain other parameters like graphProjectId or targetNodeId, leaving gaps. The contribution is partial.

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

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

The description clearly states 'Remove one or more mixin column values from a node,' providing a specific verb and resource. It also distinguishes from sibling tools like create_mixin_value and create_mixin_type by noting that it does not delete the mixin definition itself.

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

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

The description indicates that mixinId and column ids come from get_mixins_and_relation_groups, implying a prerequisite. It also clarifies that the tool does not delete the mixin definition, which helps differentiate from deletion operations. However, it lacks explicit exclusions or alternative tool recommendations.

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 uses 'suspend,' which contradicts the 'destructiveHint: true' annotation. If the tool is destructive, describing it as suspension is misleading and provides poor transparency about its behavioral impact beyond what annotations indicate.

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

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

The description is extremely short but lacks essential information, making it underspecified rather than concise. It fails to earn its place by providing 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 simple tool with 2 parameters and no output schema, the description should clarify the action's nature (temporary vs permanent) and parameter roles. It does not, leaving the agent with incomplete understanding.

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

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

The input schema has 2 required parameters with patterns, but the description adds no explanation. Since schema coverage is 0%, the description should compensate, but it does not mention parameters at all.

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 says 'Suspend a node,' but the tool name is 'remove_node.' The term 'suspend' implies a temporary action, while 'remove' suggests permanent deletion, creating confusion about the actual operation. The description does not clearly state what the tool does in relation to its name.

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

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

No guidance is provided on when to use this tool versus alternatives like 'delete_node' or 'disable_node.' There is no mention of prerequisites, context, or when not to use it.

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

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

The description is consistent with destructiveHint: true, but adds no extra behavioral details like cascading effects, permissions, or irreversibility. Adequate but minimal.

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

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

Single sentence, front-loaded, no fluff. However, it is too brief to be fully informative; conciseness sacrifices completeness.

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 nested parameters, no output schema, and a destructive nature, the description lacks context on prerequisites, side effects, and return behavior. Incomplete for the 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?

0% schema description coverage; the description provides no explanation of the required nested relation object or graphProjectId. Completely inadequate for the agent to understand 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 'Remove a relation between two nodes' clearly states verb and resource, distinguishing it from siblings like create_relation and remove_node.

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 on when to use this tool versus alternatives (e.g., remove_node or create_relation). No context on prerequisites or typical use cases.

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

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

Annotations provide readOnlyHint: true, and the description adds substantial behavioral context: the response contains compact positional arrays, pagination details, filter combination logic, and that expression is a partial substring match without wildcards. All behaviors align with the read-only 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 clear sections: purpose, response format, filters, optional flags, and pagination. It is front-loaded with the core purpose. While it is somewhat lengthy, every part adds value. A slight trim could improve conciseness, but it remains efficient.

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

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

Given 11 parameters and no output schema, the description covers filters, pagination, and optional flags thoroughly. It lacks details on what includeMixins and includeRelations do exactly, and the response layout beyond 'compact positional arrays' could be expanded. Overall, it provides sufficient context for an agent to use 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 only 18% schema coverage, the description compensates by explaining all key parameters: nodeIds, nodeType, expression, spaceIds, optional flags, and pagination token. It adds meaning beyond the schema, such as that expression uses plain text substring match and that filters combine with AND.

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 nodes in a CoreModels project' with a specific verb and resource. It distinguishes from sibling tools like create_node or remove_node by focusing on search and retrieval. The mention of 'compact positional arrays' and response format further clarifies the purpose.

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

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

The description explains when to use the tool: when searching nodes with filters. It specifies that filters combine with AND and that at least one filter is required. Pagination procedure is detailed. However, it does not explicitly mention when not to use or compare to alternatives like get_project_summary or export_json_ld, so it loses one point.

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. Description adds important behavioral detail that spaceIds replaces rather than merges assignments, which clarifies potential destructive 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?

Three sentences, front-loaded with core action, no fluff. Each 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?

No output schema, but description covers input constraints well. Lacks return value details, but acceptable for an update 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%, but the description explains label and spaceIds semantics (replace, omitted unchanged). Does not explain id or graphProjectId beyond schema.

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

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

The description clearly states the verb 'Update' and the resource 'existing node', specifying the fields label and spaceIds. It distinguishes from sibling tools like create_node and remove_node.

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

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

Provides explicit usage rules: omitted fields unchanged, spaceIds replace behavior, empty array default space, and requirement that at least one of label or spaceIds must be provided.

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

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

Annotations declare readOnlyHint true, and description aligns with read-only behavior. Description adds value by disclosing that the schema is regenerated each time using configTypeId and rootNodeId, which implies potential performance costs. However, it does not describe error handling or response format.

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 redundancy. First sentence gives purpose, second explains schema generation mechanism. 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?

While the purpose is clear and key parameters are explained, the description omits any details about the output (validation result, errors) and does not mention the optional spaceId parameter. Given no output schema, this leaves 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?

Schema coverage is 80% with good individual parameter descriptions. The description supplements by explaining that configTypeId and rootNodeId are used to regenerate the schema and that jsonString should be serialized, adding context beyond the schema. It could mention spaceId's role but not necessary.

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

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

Description clearly states 'Validate a JSON document against a project's stored JSON Schema', providing a specific verb, resource, and context. It distinguishes from sibling tools like import_jsonschema and export_jsonschema by specifying 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?

Description implicitly indicates usage when a project has a stored schema and validation is needed, but lacks explicit guidance on when not to use it or alternatives (e.g., using import_jsonschema for schema import). No exclusion criteria are given.

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