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

No annotations are present, so the description carries the transparency burden. 'Get all registered schemas' implies a read operation, and the tip hints at the output being schema definitions for discovery. But it does not explicitly state read-only behavior, pagination defaults, or return format, leaving some gaps.

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, each purposeful and front-loaded with the verb and resource. The tip adds practical context without padding, making it appropriately concise and well-structured.

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 list tool, the description covers the core action and a use case. It lacks an explicit mention of return type, but the term 'schemas' and the tip make it predictable. The pagination parameters are documented in the schema, so the description is reasonably complete.

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

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

The input schema provides descriptions for all three parameters (100% coverage), and the description only repeats the optional owner filter. No additional meaning or constraints are added beyond what the schema already specifies.

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 ('Get all registered schemas'), specifies the resource scope ('in the subgraph'), and mentions the optional filter by owner. It distinguishes from sibling tools that retrieve individual schemas by name or ID, though it doesn't explicitly name them.

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 tip 'You can use this to see what type of data is available in the network' provides a clear use case for browsing. However, it does not explicitly contrast with alternative tools like get_schema_by_name or get_schema_by_id, so no exclusionary guidance is given.

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

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

With no annotations, the description carries the full burden. It discloses the broad scope ('ALL schemas and manifest states') and return type ('File entities directly'), but does not mention pagination behavior, case sensitivity, performance implications, or whether it searches across all file states. This is a moderate level of transparency for a read-only search tool.

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

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

Two sentences, front-loaded with the agent action, and no unnecessary words. Every clause adds distinct value: scope ('ALL schemas and manifest states') and return type ('File entities directly').

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 no output schema and no annotations, the description does a good job of indicating the return type ('File entities directly') and scope. It is not fully complete—such as not explaining how files are structured or paginated—but it covers the essential context for a search tool with 4 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?

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning to the parameters beyond what the schema already provides; it simply references 'the given file field value' without elaborating on skip, first, or caseSensitive.

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 'Search', the resource 'files', and the scope 'across ALL schemas and manifest states'. It also distinguishes from sibling tools by explicitly noting 'Returns File entities directly', contrasting with tools that return manifests.

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

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

The description implies when to use this tool: when you want File entities (not manifests) searched by a field value across all schemas and manifest states. It does not explicitly name alternatives or exclusions, but the scope and return type provide clear 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?

No annotations are present, so the description carries full responsibility. It states that the tool retrieves a single file and returns the entire file, but it does not disclose behavior for missing ids, error handling, response structure, or whether the operation is read-only. This leaves notable gaps in behavioral 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 two short sentences, directly states the operation, and contains no fluff. It is appropriately sized for a single-parameter retrieval tool and front-loads the core action.

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

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

With no output schema and no annotations, the description's 'Returns the entire file' is vague—it does not specify the file object's structure or behavior when the id is not found. The tool is simple, but key usage context is missing, leaving the description incomplete for a fully informed agent.

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

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

The schema already describes the 'id' parameter with 100% coverage, and the description's 'by its id' adds no new semantic detail. The description does not provide additional context about id format, uniqueness, or error conditions. Baseline of 3 is appropriate given high schema coverage.

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

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

The description uses the specific verb 'Retrieve' and identifies the resource as 'a single file by its id', clearly distinguishing it from sibling tools that fetch files by schema, manifest, or field values. The second sentence clarifies that the entire file is returned, reinforcing scope.

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

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

The description implies usage when a file's id is known, but it does not explicitly state when to use this tool over alternatives like get_file_by_file_field_value or get_files_by_file_fields. No exclusions or conditional guidance is provided beyond the basic id-based lookup.

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?

It discloses the global scope and direct File entity return, which is useful. However, it omits important behavior like what happens when fieldValue is omitted (e.g., returns all files with that field) and does not mention any performance implications. With no annotations, the description carries the burden and only partially fulfills it.

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

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

The description is compact and front-loaded with the primary action. However, the last sentence is somewhat redundant with the first and contains a typo ('precies'), which slightly reduces 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?

Without an output schema or annotations, the description should provide more detail on return values and edge cases. It only says 'Returns File entities directly' without elaborating on structure or behavior when fieldValue is absent, leaving some gaps for an agent to infer.

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 100% for all 5 parameters, so the schema already documents them thoroughly. The description adds no additional meaning beyond referencing fieldName and fieldValue, which are already described in 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 it searches for files by field name and optionally field value across all schemas and manifest states, returning File entities directly. This distinguishes it from sibling tools that return manifests (e.g., get_manifests_by_file_fields).

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

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

The description gives a specific use case: 'use this to be more precise with finding files if you know the field name and field value.' It implies global search, but does not explicitly exclude alternatives or mention 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It notes that file entries contain a tag and fully populated fields, which is useful output context, but it omits any details about pagination semantics, ordering, error behavior, or the read-only nature of the operation beyond the obvious 'Get'.

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 concise, consisting of two sentences that front-load the core purpose and then add a brief note about the output structure. Every sentence serves a clear purpose with no redundancy.

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

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

The description covers the primary function and hints at the return shape, but lacks discussion of pagination behavior (skip/first), sorting, or potential edge cases. Given the tool's moderate complexity and lack of an output schema, the description provides a minimum viable context but leaves 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 100%, so parameters are well-documented in the schema itself, earning a baseline of 3. The description adds no additional semantic meaning beyond what the schema already provides; in fact, the phrase 'Manifest State's ID' is slightly inconsistent with the parameter name 'manifestId'.

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

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

The description clearly states the tool retrieves file entries for a specific manifest by its state ID, using the specific verb 'Get' and specifying the resource. However, it does not explicitly differentiate this from sibling tools like get_file_by_id or get_manifests_by_manifest_state_id, though the name plus description is fairly distinctive.

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, no exclusions, and no mention of prerequisites. It simply states what the tool does without situational context.

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

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

With no annotations, the description carries the full burden. It discloses the scope ('across ALL schemas') and return type ('Manifest entities directly'), but does not mention pagination behavior, optionality of fieldValue, potential performance implications, or auth requirements. It is a search tool, so read-only is implied, but not explicitly stated.

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 sentence serves a purpose: first states what it does, second explains when to use it. There is no redundant information.

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

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

Given the 4-parameter schema with 100% coverage and no output schema or annotations, the description adequately covers the main purpose, scope, return type, and usage context. It does not elaborate on the structure of Manifest entities or explicitly contrast with sibling tools like get_manifests_by_schema_name_and_file_fields, but the provided usage guidance mitigates this 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?

Schema description coverage is 100%, so the schema already documents all four parameters with details like 'Exact, case sensitive' for fieldValue and pagination ranges. The description adds context about schema-agnostic search but does not enrich individual parameter meanings beyond the schema. Baseline 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 states the action ('Search for Manifests') and the resource ('file fields across ALL schemas'), and distinguishes it from schema-specific sibling tools by emphasizing it works across all schemas. It also clarifies the return type ('Returns Manifest entities directly'), making the purpose unambiguous.

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

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

The description provides a clear 'Use this when' clause: 'when you want to find collections of data at a higher level without knowing which schema they belong to.' This implies when to use it over schema-scoped tools, but it does not explicitly name alternatives or provide a 'when not to use' exclusion, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden. It adds some behavioral context ('across ALL schemas', 'Returns Manifest entities directly'), but it does not disclose search behavior such as case-sensitivity defaults, result limits, or whether the operation is read-only. For a search tool, this is minimal but not misleading.

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 concise sentences, front-loaded with the primary action and scope. Every word earns its place with no redundancy 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?

The description gives a clear high-level purpose and scope. While it lacks an output schema and annotations, the parameter schema is fully documented, and the description covers the key differentiator (all schemas). It could be more complete about return structure, but 'Returns Manifest entities directly' suffices for this simple search 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 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides. It does not clarify the relationship between multiple 'file field values' and the single 'fieldValue' parameter, but the schema descriptions are sufficient.

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 'Search' and the resource 'Manifests', with explicit scope 'across ALL schemas'. This distinguishes it from siblings like get_manifests_by_schema_name_and_file_fields that are schema-scoped. The phrase 'Returns Manifest entities directly' also clarifies the return 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?

Usage is implied through the phrase 'across ALL schemas' but there is no explicit guidance on when to use this tool versus alternatives. No alternatives are named, nor are any exclusions or conditions 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?

With no annotations provided, the description carries the transparency burden. It clarifies that a single full manifest is returned, which is useful, but it does not disclose error handling, permissions, or any filtering behavior. The disclosure is partial and leaves some behavioral aspects unaddressed.

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 concise: two sentences that directly state the action and result. It is front-loaded with the verb and leaves out any redundant information, earning full credit for efficiency.

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 simplicity of the tool (one parameter, no output schema, no annotations), the description adequately communicates the purpose and return value ('single manifest', 'full manifest'). It could have added details about error cases or output format, but the current level is sufficient for the tool's straightforward nature.

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 100% coverage for the single parameter, including a description ('The manifest state ID to retrieve'). The tool description does not add any additional semantics beyond what the schema already states, so the 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 states 'Retrieve a single manifest by its manifest state ID' with a specific verb and resource. It distinguishes from siblings like get_files_by_manifest_state_id by explicitly indicating a manifest (not files) and a single result, making the tool's purpose unambiguous.

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

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

The description implies the tool should be used when a manifest state ID is available and the full manifest is needed, but it does not explicitly provide exclusions or alternatives like get_manifests_by_schema_name. This is adequate but lacks explicit comparison to sibling tools.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It discloses that the tool returns the full manifest including file entries and fields, which is useful. However, it does not mention pagination behavior, ordering, or whether historical manifest states are included, though parameters hint at pagination via skip/first.

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 short sentences with no filler. It front-loads the main action and includes relevant return details. Every word contributes to understanding the tool's purpose.

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

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

The tool has 4 parameters and no output schema. The description covers the primary purpose and return content but does not mention pagination or how to handle large result sets. Given the schema fully documents parameters, the description is adequate but not rich, and it leaves the agent to infer usage context from the sibling list.

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 100%, so the baseline is 3. The description itself does not add any parameter-specific semantics beyond what the schema already provides. It does not explain how 'owner' or pagination parameters affect results, nor does it detail the schemaName format beyond the example in 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 states a clear action ('Get all manifests') with a specific resource and scope ('under a given schema by the schema's name'). It also mentions return content ('full manifest including its file entries, and fields'). However, it does not explicitly compare against sibling tools like get_manifests_by_schema_name_and_file_fields, so it doesn't fully differentiate despite the name being self-explanatory.

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

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

The description implies the primary use case — retrieve all manifests when you know the schema name. It does not mention when to prefer alternative tools (e.g., when filtering by file fields), nor does it provide exclusions or prerequisites. The sibling list exists but is not referenced in the description, so guidance is only implied.

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

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

No annotations are provided, so the description carries the disclosure burden. It does state that the tool 'Returns manifests directly' and adds a useful case-sensitivity tip, but it does not explicitly confirm read-only behavior, permissions, pagination behavior, or any potential side effects. Some behavioral context is added, but gaps remain.

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 just two sentences: one clear purpose statement and one practical tip. It is front-loaded and contains no filler or repetition of schema details.

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 7 parameters, no output schema, and no annotations, the description is brief. It delivers the core purpose and a useful tip, but it lacks when-to-use guidance and richer behavioral context. The schema makes up for parameter-related details, so overall it is minimally adequate but not comprehensive.

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 100%, so the baseline is 3. The description's additional tip about caseSensitive adds a small layer of meaning beyond the schema, but it does not substantially enhance parameter understanding since the schema already documents all parameters clearly.

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

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

The description uses a specific verb ('Search') and identifies both the resource ('manifests') and the scoping ('using a specific schema' plus file field name/value). This distinguishes it from sibling tools like get_manifests_by_schema_name (no field filtering) and get_manifests_by_file_fields (no schema requirement).

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

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

The description provides no guidance on when to use this tool versus alternatives. It only gives a tip about caseSensitive for better results, which is parameter-level advice, not tool-selection guidance.

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

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

With no annotations, the description carries the full burden. It discloses that the entire schema is returned and highlights a use case, but does not mention potential errors, edge cases, or the read-only nature. This is adequate but lacks depth for a tool with zero annotation support.

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 action, followed by a value-add use case and a practical tip. Minor formatting issue (missing space after period) slightly detracts, but the content earns its place.

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

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

For a simple single-parameter getter with no output schema, the description covers the purpose, return value, and a use case. It is complete enough for the agent to effectively select and invoke the tool, though it could mention error behavior.

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 already documents the single parameter with 100% coverage. The description adds 'unique' to emphasize the ID's role but does not provide significant extra meaning beyond the schema.

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

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

The description clearly states the tool retrieves a single schema by its unique ID, which distinguishes it from siblings like get_all_schemas and get_schema_by_name. It also specifies that the entire schema is returned, making the purpose unambiguous.

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

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

The description provides useful context, noting the tool can be used to discover field names in manifests and includes a tip to prefer searching by ID to avoid mistakes. It does not explicitly mention alternatives but implies the advantage over name-based lookup.

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

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

With no annotations, the description carries the transparency burden. It discloses that the tool 'Returns the entire schema', which is a key behavioral trait, and clarifies a practical use case. The read-only nature is implied by 'Retrieve'. No contradictions or unexpected side effects are hidden.

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 quite concise, with only two sentences that convey the primary action and a use case. However, it suffers from a minor formatting issue ('schema.This' lacks a space), and the second sentence could be more integrated. Still, it is well-structured and efficient.

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

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

For a simple tool with one parameter and no output schema, the description is complete. It states what is returned (the entire schema), how to identify the schema (fully-qualified name), and why it might be used (discovering field names). No additional context is needed 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?

The input schema already provides 100% coverage for the single 'name' parameter, including an example. The description adds only the phrase 'fully-qualified name', which essentially restates the schema's own description. Thus, the description provides no additional semantic 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 retrieves a single schema by fully-qualified name, which distinguishes it from siblings like get_schema_by_id (by ID) and get_all_schemas (all schemas). The verb 'Retrieve' is specific and the resource 'schema' is unambiguous.

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

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

The description provides a clear use case by explaining that it can be used to discover field names for files in manifests using the schema. It implies when to use this tool (when you have the fully-qualified name) but does not explicitly mention 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?

No annotations are provided, so the description carries full burden for behavioral disclosure. It does not explicitly state whether this is a read-only query, what the response format is, or any risks such as expensive queries. The mention of advanced capabilities implies power but lacks concrete behavioral details.

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 purpose, then usage, then a clear preference directive. No filler, well-structured, and every sentence earns its place.

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

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

Given the tool's simplicity (single parameter, no output schema), the description covers the essential purpose, usage, and alternatives. It lacks examples or explicit return-value mention, but GraphQL queries conventionally return results, making this largely 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 100% with a single 'query' parameter already described clearly. The description does not add extra parameter-level semantics beyond reinforcing it is a raw GraphQL query, so the baseline 3 applies.

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 executes a raw GraphQL query against the subgraph for advanced use cases not covered by other tools. It distinguishes itself from sibling high-level tools by emphasizing custom filters, nested relations, ordering, and aggregations.

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 states when to use the tool—when needing custom filters, nested relations, ordering, or aggregations not exposed by higher-level tools—and when not to use it by directing users to prefer higher-level tools when they cover the use case.

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