CoreModels

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

Annotations indicate destructiveHint=true, so the agent knows it modifies data. The description adds that the operation is atomic (all-or-nothing) and that relation endpoints can reference new or existing node IDs, but does not detail all behavioral aspects like validation or rollback 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 concise, well-structured with clear sections, and every sentence adds value without redundancy.

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

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

For a complex tool with nested objects and no output schema, the description covers high-level usage and dependencies but omits details like return value or constraints on parameter combinations, making it moderately complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the bulkCreateDto sub-objects (nodes, mixins, relations) and provides context for required IDs, but many parameter details (e.g., node id pattern, nodeType enum) remain only in the schema without textual explanation.

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 mixin values atomically, and explicitly distinguishes from siblings like create_node by advising to prefer it for single nodes without relations or mixins.

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 'When to use' guidance and recommends create_node as an alternative for simpler cases, plus explains required IDs from other tools (e.g., get_mixins_and_relation_groups).

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 include destructiveHint: true, and description confirms creation, failure on duplicate, and private scope. Provides good 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?

Two sentences efficiently cover purpose, return, and constraints. 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 no output schema, description lists exact return values and explains their use in other tools. Covers creation behavior, failure mode, and default setting comprehensively.

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

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

Schema coverage is 100% with descriptions for both parameters. Description adds that defaultSpaceName defaults to 'Main' and that name must be unique. Adequate but not exceptional.

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 creates a CoreModels project with a default space, owned by the calling user. Returns specific IDs and differentiates from sibling tools like create_node or create_mixin_type.

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?

Explains when it succeeds/fails (no duplicate names) and gives usage guidance for returned IDs in other tools (import_jsonschema). Lacks explicit when-not-to-use compared to siblings.

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

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

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 already mark it read-only; the description adds behavioral details about graph-based vs tree-based modes and required boolean flags, but omits potential size limits 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?

Three focused sentences, front-loaded with the main purpose, each sentence adding essential usage guidance 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?

No output schema and missing return value description; for a complex tool with 11 parameters, the description omits how the export output is delivered and what the agent receives.

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 36% schema coverage, the description adds context for key parameters (nodeIds, graphBased, configTypeId) but does not fully compensate for undocumented parameters like includeSpace, useDefaultType.

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 project data') and the specific format ('JSON-LD'), distinguishing it from sibling tools like export_jsonschema 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?

Explicitly instructs to use fetch_json_ld_import_profiles first to discover configTypeId, provides constraints on boolean flags, and explains tree-based vs graph-based mode requirements.

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 already declare readOnlyHint=true, and the description's 'Export' is consistent. No additional behavioral traits disclosed (e.g., return format, performance, or side effects), but the annotation covers the key safety aspect.

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, no wasted words, front-loaded with the core purpose. Highly concise.

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

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

Lacks details about parameter usage, optionality, and scope of export. Given sibling export tools and 4 parameters, the description could better guide the agent on how to tailor the export (e.g., using nodeIds or spaceId).

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% (descriptions for nodeIds and includeCardinality, but not for spaceId and graphProjectId). The description adds no parameter information beyond what's in the schema, failing to compensate for the 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 exports project data as a ShEx schema string, with specific verb and resource, and distinguishes from sibling export tools like export_json_ld and export_jsonschema.

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

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

No explicit guidance on when to use this tool versus alternatives like export_json_ld. The description only states what it does without context for selecting it over other export formats.

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 description need not repeat that. However, it does not add any extra behavioral traits like pagination or caching behavior. For a read-only fetch, this is acceptable 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?

One concise sentence with no redundancy. However, the wording 'import/export profiles' could be clearer to match the title. Overall 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?

The tool is simple (1 param, read-only, no output schema), but the description omits what a profile is or what the return format looks like. Without output schema, this information is necessary for complete understanding.

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

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

With schema description coverage at 0%, the description should compensate but does not. It fails to explain the purpose or format of the graphProjectId parameter beyond what the name implies.

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 'import/export profiles' for a project. However, the title mentions only 'import profiles', causing slight ambiguity about whether both import and export profiles are retrieved. It distinguishes from siblings like fetch_json_schema_import_profiles by specifying 'JSON-LD'.

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 such as export_json_ld or fetch_json_schema_import_profiles. The description lacks context for appropriate 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, 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?

Discloses that the tool saves the summary (destructive behavior) and explains the regeneration logic based on staleness. Also mentions a prerequisite (Claude API key). Annotations already mark destructiveHint=true, and the description adds meaningful behavioral context.

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

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

The description is concise with three sentences, each adding valuable information: primary action, return/regeneration logic, and prerequisite. 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 no output schema, the description specifies the return value is the generated markdown summary, which is adequate. It covers regeneration logic and prerequisite, but could elaborate on what the summary contains or its format more explicitly.

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 explains the regenerateIfStale parameter behavior, which adds value beyond the schema. However, the graphProjectId parameter lacks description in both schema and text, leaving its purpose implied. With 50% schema coverage, the description partially compensates but not fully.

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 generates an AI summary of a project from its types, elements, and taxonomies, saves it as markdown, and returns it. It distinguishes from siblings like 'get_project_summary' by specifying generation and potential regeneration behavior.

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

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

Provides clear context on when regeneration occurs (if stale and regenerateIfStale is true) versus when an existing summary is returned unchanged. However, it does not explicitly name alternatives like 'get_project_summary' for when a fresh one is not needed.

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?

Beyond the readOnlyHint annotation, the description discloses the independent pagination per category and the hasMore flag. No contradictions 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?

38 words plus pagination instructions are front-loaded with main purpose. Every sentence adds value; no repetition or 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 no output schema, the description sufficiently states return type (labels and IDs) and pagination mechanics. Could optionally mention the response structure per category, but the pagination details compensate.

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 only adds context for the 'page' parameter (omitting default, re-requesting). It does not explain 'pageSize' maximum or 'graphProjectId' pattern. With schema coverage at 33%, the description could do more to clarify all 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 tool returns 'Labels and IDs of types, elements, and taxonomies in the project' with independent pagination per category. This distinguishes it from siblings like remove_node or search_nodes.

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

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

Provides detailed pagination algorithm: first call omit page, then re-request with page+1 for categories where hasMore is true. However, it does not explicitly contrast with alternative tools or mention when to use this summary over 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?

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?

The description adds behavioral details beyond the readOnlyHint annotation, such as pagination (1-based page), the effect of boolean parameters, and the response format including optional fields. No contradictions 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 concise and front-loaded with the core purpose. Every sentence adds necessary information without redundancy. It packs details into a single efficient paragraph.

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, the description fully covers the response format and all parameter effects, including pagination and the returned fields. It is complete for a read-only list 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 description explains the searchTerm as a case-insensitive substring filter, the includePublicProjects and includeAISummary booleans, and clarifies that page is 1-based and incrementable. Schema coverage is 80%, and the description adds context, especially for pagination 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 clearly states it lists the user's CoreModels projects with specific fields (id, name, accessLevel) and mentions the response format. It distinguishes itself from sibling tools like search_nodes, as there is no other list-projects 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?

The description explains when to use the tool to get projects and how to use returned ids with other tools. It provides pagination instructions (increment page up to totalPages). It does not explicitly state when not to use it, but the context is clear given the sibling set.

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

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

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?

Description adds rich behavioral context beyond annotations: sandboxed environment, no network/filesystem, limits on time/memory/statements/calls, automatic injection of graphProjectId. Annotations only provide readOnlyHint=true, which is consistent.

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?

Description is well-structured with a clear paragraph followed by a bullet list of available functions. Each sentence adds value, though slightly verbose for the bullet details that could be inferred from context.

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

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

Given no output schema, description adequately explains return behavior (result plus captured console.log). Covers constraints, function signatures, and automatic parameter injection, making it complete for an AI agent to use correctly.

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

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

With 50% schema coverage, description provides extra guidance for the 'code' parameter (e.g., 'Use tools.<name>(args), listTools(), getToolDoc(name); end with `return <value>`'). The graphProjectId parameter has only a pattern in schema, but description mentions it's injected automatically.

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 'Execute a JavaScript program that orchestrates this server's tools, and return only its result.' Uses specific verb+resource and distinguishes from sibling tools by emphasizing multi-step orchestration.

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 says 'Prefer this over many individual tool calls when a task needs several steps, looping, filtering, or combining data' and explains why. Also notes limitation that only read-only tools are callable, providing clear 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?

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 already declare readOnlyHint=true, so the tool is read-only. The description adds that the schema is regenerated using configTypeId and rootNodeId, which provides behavioral transparency beyond the 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 two sentences, efficient, and front-loaded with the core purpose. Every sentence adds value without redundancy.

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

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

The description covers the purpose and key parameters but does not explain the return value or validation result (success/failure). Given the tool has no output schema, this omission limits 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?

Schema description coverage is 80%, so baseline is 3. The description adds context by explaining that configTypeId is the export profile id, rootNodeId is used as the root, and jsonString is the serialized JSON. This adds modest value beyond the schema.

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

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

The description clearly states the tool validates a JSON document against a stored JSON Schema, with a specific verb and resource. It is distinct from sibling tools like export_jsonschema or import_jsonschema.

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

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

No guidance is given on when to use this tool versus alternatives, such as when to validate vs export a schema. The description lacks explicit usage context.

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