coremodels

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

Annotations include readOnlyHint=true, and the description aligns by describing an export operation. The description adds meaningful behavioral context beyond annotations: the prerequisite of fetching profiles first, the constraint that at least one export flag must be true, and the differing nodeId requirements for tree vs graph mode. This provides useful operational transparency.

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

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

The description is concise and front-loaded with the primary purpose. The second sentence is information-dense but every clause contributes necessary usage constraints. No redundant or filler content exists, making it efficient and well-structured for an agent.

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

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

For a tool with 11 parameters and no output schema, the description covers the main usage flow (profile discovery, mode selection, flag requirements) but leaves several parameters unexplained and does not describe response behavior. It is reasonably complete for common use cases but not fully comprehensive given the tool's complexity and the lack of output schema.

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

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

Schema description coverage is low (36%), and while the description clarifies key parameters like graphBased, nodeIds, configTypeId, and export flags, it does not explain other parameters such as graphProjectId, includeSpace, or useDefaultType. The description adds value for the core parameters but leaves many optional flags undocumented, so it only partially compensates for the schema 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's function: 'Export project data in JSON-LD format using a configured export profile.' The verb 'export' is specific, the resource 'project data' is defined, and the format 'JSON-LD' distinguishes 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?

The description provides clear usage context: it instructs to call fetch_json_ld_import_profiles first to get the configTypeId, and specifies requirements for export type flags and tree vs graph modes. It does not explicitly mention when not to use this tool relative to alternatives, but the format differentiation is implicit.

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

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

The annotation readOnlyHint=true already conveys that this is a safe read operation. The description adds only that the output is a string (JSON Schema), but does not disclose behaviors such as required parameter significance, error conditions, or any other operational details that would help the agent beyond the annotation.

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

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

The description is a single sentence with no unnecessary words. It is extremely concise and front-loaded, every word contributes to stating the core purpose.

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

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

With 4 parameters, no output schema, and a sparse one-line description, the definition is incomplete. It does not clarify what 'project data' includes, why optional parameters matter, or what the resulting JSON Schema string is used for, leaving significant gaps for an agent.

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

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

The description mentions no parameters and does not compensate for the 50% schema coverage. It leaves unresolved the semantics of spaceId and graphProjectId (aside from patterns) and adds no meaning beyond the partial schema descriptions.

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

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

The description clearly states a specific action ('Export'), subject ('project data'), and output format ('JSON Schema string'), which distinguishes it from sibling export tools like export_shex and export_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?

There is no guidance on when to use this tool versus alternatives, no exclusions, and no context about when it is appropriate. The description merely restates the function without helping the agent choose among the export 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?

The description adds the behavioral detail that the result is a string representation of a ShEx schema, which goes beyond the readOnlyHint annotation. This clarifies the output type without contradicting the annotation, though it does not mention other potential behaviors like formatting options.

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, focused sentence that front-loads the action (Export) and specifies the output. Every word earns its place; it is neither verbose nor under-specified in terms of prose.

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

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

Given the tool has 4 parameters and no output schema, the description is too minimal. It does not explain optional filtering by nodeIds, space scoping, or cardinality flags, leaving the agent without enough context to use the tool effectively for varied scenarios.

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 docs cover only 50% of parameters (nodeIds and includeCardinality), while graphProjectId and spaceId lack descriptions. The description itself mentions no parameters, so it does not compensate for the gap or add meaning beyond the input schema.

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

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

The description clearly states the tool exports project data as a ShEx schema string, specifying both the resource and the output format. It distinguishes from sibling export tools (export_json_ld, export_jsonschema) by naming the specific format.

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

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

The description implies usage when a ShEx schema is needed, but it does not explicitly mention alternatives or provide when-not-to-use guidance. No exclusions or context beyond the format is given, so it is only inferred rather than stated.

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

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

The readOnlyHint annotation already indicates a safe read operation, and the description's 'Fetch' verb aligns with that. The description adds that profiles are 'available for a project' but provides no further behavioral context like output format or pagination; no contradiction exists.

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

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

The description is a single sentence, front-loaded with the verb and resource, and contains no unnecessary words. It is appropriately concise.

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

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

For a simple, single-parameter fetch tool, this is minimally viable, but it lacks important context such as what the return value looks like and what 'import/export profiles' actually contain. Without an output schema, the description should clarify expected results, leaving a gap.

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

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

The schema has one parameter, graphProjectId, with a pattern but no description. The tool description does not mention this parameter at all, leaving the agent to infer meaning from the name. With 0% schema description coverage, the description should compensate but fails to do so.

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

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

The description uses the specific verb 'Fetch' and identifies the resource as 'JSON-LD import/export profiles available for a project,' which distinguishes it from the sibling fetch_json_schema_import_profiles. However, the tool name focuses on 'import profiles' while the description includes 'export,' and it doesn't explicitly contrast with other 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?

No guidance is given on when to use this tool versus alternatives such as fetch_json_schema_import_profiles or export_json_ld. The description simply states what it does without contextual direction.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is clear. The description adds that it fetches profiles 'available for a project' but does not disclose response shape or potential error conditions.

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

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

The description is a single sentence that starts with the verb and includes only essential information. No filler or redundancy.

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

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

Without an output schema, the description should explain what the 'profiles' are, their format, or any limitations. It also mentions 'import/export' while the tool name says 'import_profiles,' creating ambiguity. Overall, it leaves 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?

Schema description coverage is 0%, so the description must compensate. It says 'for a project,' which implies the role of graphProjectId, but does not explicitly link the parameter or clarify required format.

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

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

The description uses the specific verb 'Fetch' and identifies the resource as 'JSON Schema import/export profiles' scoped to a project. This clearly distinguishes it from siblings like fetch_json_ld_import_profiles by specifying JSON Schema.

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 over alternatives; sibling tools such as fetch_json_ld_import_profiles or export_jsonschema are not mentioned. The description only states what the tool does, not when to choose 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, but the description adds value by noting that it 'Returns compact positional arrays - see the 'format' field for the layout,' and explains that it provides IDs used by other tools. These details go beyond the annotation and inform the agent about the output structure.

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: the first states the primary function, the second provides usage guidance and a hint about the output format. Every sentence earns its place, with no redundancy or filler.

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

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

Given that the tool is a read-only, single-parameter operation, the description adequately covers its purpose, usage timing, and output behavior. The main gap is the unspecified parameter semantics, but the overall context is sufficient for an agent to select and invoke the tool.

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

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

The input schema provides no description for graphProjectId (0% coverage), and the tool description does not explain what this parameter is or how to obtain it. Although the parameter name is self-explanatory, it is not explicitly described, so the description fails to compensate for the schema's lack of documentation.

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

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

The description clearly states 'Get the project schema: all mixin definitions and all relation-group definitions,' which uses a specific verb (Get) and resource (project schema with mixin and relation-group definitions). This distinguishes it from sibling tools like get_project_summary or export tools, which have different purposes.

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 says 'Use this once at the start of a session to discover the IDs needed by other tools (mixinId, columnId, relationGroupId),' giving clear when-to-use context. It does not mention when-not-to-use or alternatives, but this is sufficient for a discovery tool.

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

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

Annotations declare readOnlyHint=true, which sets the safety expectation. The description adds useful behavioral detail about independent pagination per category and how to fetch subsequent pages, going beyond the annotations. It does not discuss auth, rate limits, or error handling, but the read-only nature is already covered.

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

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

The description is compact and well-structured. The first sentence states the purpose, and the pagination section is a clear, actionable list. Every sentence earns its place with no 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?

There is no output schema, so the description carries the burden of explaining return shape. It adequately describes the payload (labels/IDs) and the pagination contract (page, pageSize, hasMore). However, it does not mention whether categories can be empty, the overall response envelope, or error handling, which leaves some gaps.

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

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

Schema description coverage is only 33% (page has a description). The description compensates for the page parameter with concrete pagination semantics and implicitly explains pageSize and hasMore. graphProjectId is not explicitly described, though its name and pattern make its role reasonably clear.

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

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

The description states what the tool returns: labels and IDs of types, elements, and taxonomies in the project. The title 'Get Project Summary' reinforces the purpose. It distinguishes from siblings like list_projects and search_nodes by focusing on the project's structural summary with independent pagination per category, though it lacks an explicit verb.

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

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

The description provides clear pagination usage instructions, but it does not state when to choose this tool over alternatives like get_mixins_and_relation_groups or search_nodes. The pagination guidance is valuable for operating the tool, but the description lacks comparative 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?

The readOnlyHint annotation already indicates a safe read, and the description adds substantial behavioral detail: exact tuple structure, conditional inclusion of public projects and AI summaries, and 1-based pagination with totalPages. This goes beyond the annotation by explaining response shape and pagination mechanics.

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?

Four sentences, each adding unique value: main action, downstream usage, optional flags, and pagination. No redundancy or fluff. Information is front-loaded, and the description respects the reader's time while being complete.

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, the description explains the return format and pagination sufficiently. It might have mentioned pageSize explicitly or error behavior, but the key aspects (tuple structure, totalPages, filter options) are covered. Overall, it's complete for a list operation with 5 optional parameters.

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

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

The schema covers 80% of parameters with descriptions, and the description largely reiterates those semantics (searchTerm substring, includePublicProjects, includeAISummary). It adds no meaning for pageSize (the one undocumented param) and only minimally enriches parameter understanding beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly identifies the tool as listing the user's CoreModels projects with a specific resource and output format ([id,name,accessLevel]). The verb 'List' is specific and distinct from sibling tools like get_project_summary, export_*, or search_nodes, making its purpose unmistakable.

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 guidance is provided: use returned ids as graphProjectId for other tools, pass searchTerm for filtering, set includePublicProjects/includeAISummary for optional results, and paginate by incrementing page up to totalPages. While it doesn't name alternatives, the clear context of listing vs. other sibling operations suffices.

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 sandbox limits ('no network or filesystem'), read-only enforcement ('Currently only read-only tools are callable'), the auto-injection of graphProjectId, and the capture of console.log output. These details go well beyond the readOnlyHint annotation, providing essential 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 well-structured with a short intro, a bulleted API list, and environment notes. Every element serves to orient the agent; there is no filler. The format makes it easy to parse and reference.

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 lacking an output schema, the description specifies return behavior ('only what you return reaches the model,' console.log captured) and describes environment constraints. For a tool of this complexity, all necessary context is present.

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 code parameter's purpose is fleshed out with API examples (listTools(), getToolDoc(name), tools.<name>) and the graphProjectId is clarified as auto-injected for internal tool calls, even though it is a required input to run_code. This adds meaning beyond the schema's bare pattern and 50% description coverage.

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

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

The description opens with a specific verb and resource: 'Execute a JavaScript program that orchestrates this server's tools, and return only its result.' This clearly states what the tool does and distinguishes it from sibling tools like export_json_ld or validate_json by focusing on orchestration rather than data transformation or validation.

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

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

It explicitly advises to 'Prefer this over many individual tool calls when a task needs several steps, looping, filtering, or combining data,' giving concrete conditions for use. No alternative tool is named, but the guidance is unambiguous and helps the agent decide when to leverage this tool.

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

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

Beyond the readOnlyHint annotation, the description adds valuable behavioral detail: pagination token lifecycle, compact positional array responses with a format field, exact substring matching with no wildcards, and AND-combined filters. This gives the agent a strong mental model without contradicting annotations.

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

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

The description is well-organized into short labeled sections: main purpose, filters, optional flags, and pagination. It uses bullet-like lines and every sentence carries actionable information without redundant filler.

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

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

For a tool with 11 parameters and no output schema, the description covers return format and pagination well. It could add a bit more detail about what includeRelations and includeMixins return, and explicitly connect to graphProjectId, but it is largely sufficient for correct 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?

Schema description coverage is only 18%, so the description compensates by listing all common filters and flags with purpose. It explains expression semantics (plain text substring, no wildcards) and pagination token usage. However, it doesn't mention the required graphProjectId parameter, although 'in a CoreModels project' implies its role.

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

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

The description opens with a specific verb+resource: 'Search nodes in a CoreModels project.' It also clearly states the return format (compact positional arrays) and is easily distinguishable from sibling tools like export_json_ld or get_project_summary.

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

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

It explicitly says filters are required ('provide at least one') and combine with AND, and explains pagination step-by-step. It doesn't explicitly name alternatives or state when not to use this tool, but the sibling tools are clearly export/utility commands, so the context is clear.

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

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

Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context: the schema is regenerated on the fly from the project using configTypeId and rootNodeId, and the input must be a serialized string. This goes beyond read-only status to explain a dynamic dependency, though it does not disclose return format or error behavior.

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

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

The description is two focused sentences, leading with the tool's purpose and then providing the necessary context about schema regeneration and input format. Every sentence carries information and there is no filler.

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

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

For a read-only validation tool with good schema coverage and annotations, the description is largely complete: it explains the validation target, the dynamic schema generation, and serialized-string requirement. However, it does not mention return behavior (e.g., boolean vs error details) and leaves the configTypeId optionality ambiguous.

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 descriptions already cover 4 of 5 parameters, so the baseline is 3. The description mostly restates schema details (rootNodeId, serialized string) and adds only the 'export profile id' label for configTypeId, but it does not clarify that configTypeId is optional despite being described as 'supplied.' graphProjectId is also left unexplained.

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

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

The description uses the specific verb 'Validate' and names the exact resource ('a JSON document against a project's stored JSON Schema'). It clearly distinguishes validate_json from sibling export tools by focusing on validation rather than exporting or fetching profiles.

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

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

The description implies usage by stating what validation is done and how the schema is generated, but it does not explicitly state when to choose this tool over alternatives or provide any exclusions. It lacks guidance like 'Use this when you need to check JSON conformance' or references to alternative tools.

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