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

With no annotations, the description carries the full behavioral burden, and it delivers: it discloses ascending eigenvalue ordering, the meaning of the second eigenvalue (algebraic connectivity), that connection_type never mixes structural/functional/effective modalities, and that min_weight is not pre-applied when loading data. These are genuine operational traits beyond the schema, though it omits error behavior and output format 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?

Two sentences with minimal filler; the core mathematical purpose is front-loaded and the parameter clarifications are compact. The algebraic-connectivity aside is mildly tangential but adds interpretive value without bloating the text.

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?

An output schema exists to handle return values, and the description covers the mathematical semantics of the tool plus two key parameters. However, atlas_id is unaddressed, no guidance distinguishes this tool from calculate_spectrum, and the absence of annotations leaves the safety/side-effect profile incomplete. For a medium-complexity tool this is adequate but has clear 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 0% and property titles are bare ('Atlas Id', 'Min Weight', 'Connection Type'), so the description must compensate. It adds real semantics for connection_type (never mixes modalities) and min_weight (explicit call-side threshold, not a data-loading filter), but leaves atlas_id 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 identifies a specific artifact: the spectrum of the Laplacian of a real graph of an atlas, with precise mathematical characterization (eigenvalues ascending; second eigenvalue as algebraic connectivity). The verb and resource are clear, but it does not explicitly differentiate itself from the overlapping sibling calculate_spectrum.

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 such as calculate_spectrum, nor any prerequisites, exclusions, or conditions selecting this tool. The remark that min_weight 'decides who calls' hints at caller eligibility but operates only at parameter level and does not constitute 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 provided, the description carries the full burden of behavioral disclosure. It meaningfully discloses an edge case: returns None per region when the graph has fewer than 4 nodes, and emphasizes that it never returns an invented embedding for a too-small graph. This is valuable beyond what the schema conveys, though it does not discuss other behavioral aspects like read-only status or parameter 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 reasonably concise, front-loading the core purpose and then covering the small-graph edge case. The phrase 'nunca un embedding inventado para un grafo demasiado pequeño' is slightly repetitive after the None explanation, but overall every sentence contributes useful 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?

The description explains the output shape and an important null-behavior, and an output schema exists so return values do not need further elaboration. However, it does not explain the two optional parameters or provide explicit selection guidance relative to sibling tools. For a three-parameter tool with 0% schema coverage, this 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 0%, so the description must compensate for the lack of parameter explanations. The description clarifies that the tool works on 'the real graph of an atlas' and that the output relates to graph structure, which helps slightly with atlas_id. However, min_weight and connection_type are completely unexplained, and their roles in constructing the graph are left to 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?

The description clearly identifies the tool's output as a 2D spectral embedding (Laplacian eigenmaps) of an atlas's real graph, with one position per region. It distinguishes this from anatomical-position-based tools by saying it is useful for seeing groupings without depending on anatomical position. It does not state an explicit verb like 'calculates', but the noun phrase 'Embedding espectral 2D' is specific enough to convey the action.

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 the tool: when wanting to see clusters derived from graph structure rather than anatomical position. However, it does not explicitly mention when not to use it or name alternatives such as calculate_laplacian or render_network. The guidance is implied but not fully articulated.

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 full burden of behavioral disclosure. It discloses that the tool throws an error if a species doesn't exist, that it never compares against invented species, and that it never compares topology. It also explains the underlying data limitation (only human has structural connectivity). This is strong behavioral transparency, though it could have mentioned the exact error type or return 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?

The description is a single, dense paragraph that front-loads the core purpose and then adds critical constraints. It is somewhat long but every sentence adds value: the combined output, the counting logic, the topology exclusion, and the error behavior. The structure could be improved with bullet points or clearer separation, but it is not bloated.

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 (comparison logic, data limitations, error handling) and the absence of annotations, the description covers the essential behavioral context. It explains what the tool does, what it doesn't do, and when it errors. The output schema exists, so return values are presumably documented elsewhere. The only minor gap is not specifying the exact format of the species IDs or the structure of the homology list, but the description is largely complete for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. The description explains that the two parameters are species IDs and that they must refer to real species, but it doesn't add detail about the format or expected values of the IDs. The description's mention of 'species_a_id' and 'species_b_id' is implicit, not explicit. Baseline 3 is appropriate because the description adds some semantic context (real species, error on non-existent) but doesn't fully elaborate on parameter specifics.

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: comparing two real species by combining a quantitative summary and the complete list of shared homologies. It explicitly names the resource (species) and the specific action (compare), and it distinguishes itself from siblings like compare_species_images and find_homologues by specifying the combined output 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 provides explicit guidance on when to use this tool: it compares real species, never invented ones, and it explicitly states that it does not compare topology between species because only human has real structural connectivity loaded. This directly informs the agent when this tool is appropriate versus when it might need a different tool (e.g., for connectivity comparisons).

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 fully carries the behavioral disclosure burden. It clearly states the output (three PNGs), error conditions (nonexistent species or no homology), and even documents a known bug workaround (structured_output=False). It also specifies that species are never overlaid, which is a critical behavioral trait. This is exceptionally transparent.

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 verbose, especially the extended bug note about pydantic schema generation and structured_output=False, which is tangential to the tool's purpose. While the opening does front-load the main purpose, the overall length and technical digression reduce conciseness. A tighter description would be more effective.

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 output format, error behavior, and a technical caveat, which is substantial. However, it omits explanation of min_weight and connection_type parameters, leaving a gap for those inputs. Given the tool's complexity (four params, image output, error cases), it is fairly complete but not fully 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 0%, so the description must compensate and explain each parameter. It implicitly names species_a_id and species_b_id through 'two species', but does not explain min_weight or connection_type at all. These parameters remain unexplained, leaving agents guessing about their meaning and defaults.

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 specific verb (generate images comparing) and a precise resource (two species), and details the three output images, their content, and color coding. It distinguishes itself from siblings like render_brain or compare_species by emphasizing its non-overlay, image-based comparison approach, making it unmistakably unique.

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 the tool—when visual comparison of two species is needed—but does not explicitly contrast it with alternatives or state conditions when to choose this over compare_species or render_network. It does mention it never overlays species in 3D, which hints at differences, but lacks direct 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 provided, the description carries the full burden of behavioral disclosure. It explicitly states that the tool never invents confidence values or citations, and that the status is 'candidate_homology' with confidence=None. It also explains how the filters affect results (touching either end). This is strong transparency, though it does not mention performance or output 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?

The description is a single paragraph but each sentence adds value: the core purpose, the data source and quality caveats, and parameter explanations. It is somewhat dense but well-structured, with the primary purpose front-loaded. No fluff or redundancy.

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

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

Given that an output schema exists (so return format is already defined), the description covers all essential aspects: what the tool does, the data constraints (54 species, status, confidence), filter semantics, and data integrity guarantees. It is complete enough for an agent to call it correctly without additional clarification.

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 provides detailed semantics for both parameters: region_id filters to homologies touching that region in either end, and species_id filters to those touching that species. This goes far beyond the bare schema (which only lists names and types) and fully compensates for the 0% schema 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 clearly states the tool's function: finding real homologies between already loaded species. It uses a specific verb ('Busca') and a specific resource (homologies), and differentiates from sibling tools like search_region or compare_species by focusing on homology relationships. The mention of 'reales' (real) and 'ya cargadas' (already loaded) adds precision.

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

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

The description gives clear context for when to use the tool (for real homologies among the 54 loaded species) and explains the filtering semantics of both parameters. It does not explicitly name alternative tools or state when not to use it, but the purpose is specific enough to imply when it is appropriate.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly explains the edge-weight semantics: a larger weight is a stronger connection, not a higher cost, and the shortest path tends toward strong connections. It also discloses that path and distance become None when ids are not in the atlas or when no real path exists, and it explicitly guarantees no approximation or invented path.

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 dense sentences that are front-loaded with the core purpose. The parenthetical about weight semantics and the second sentence about None behavior are both essential and add real value; there is no filler or repetition.

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

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

For a pathfinding tool, the description covers the main edge cases well: missing atlas membership, disconnected components, and no approximation. The existence of an output schema reduces the need to explain return values in detail. The main gap is min_weight, which is never described, leaving a meaningful parameter 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?

With 0% schema description coverage, the description must compensate. It does add meaning for connection_type by explaining the weight interpretation, but it says nothing about min_weight, which has a default of 0 and is not self-explanatory. atlas_id, source_id, and target_id are understandable from their names but their expected formats are not clarified.

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 specific verb and resource: 'Camino más corto real entre dos regiones del mismo atlas' — a real shortest path between two regions of the same atlas, over a specific connectivity graph. It also distinguishes itself by emphasizing 'real' vs approximate paths and by restricting to the same atlas, which helps separate it from sibling tools like find_homologues or get_connectivity.

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 the tool: when an exact, non-approximate shortest path is needed between two regions of the same atlas. It also explains that path and distance return None when no path exists. However, it never explicitly names alternatives or says 'use X instead of Y', so the guidance is implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly reveals the empty-return fallback and clarifies that the result contains real connections, named tracts, and citations, not a reinterpreted query. It does not explicitly confirm read-only behavior, but the 'get' naming and query semantics make that reasonably clear.

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

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

Two concise sentences with no filler. The core behavior is front-loaded, and the edge-case behavior is added as a second sentence that 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 tool with one required parameter and an output schema, the description covers the input semantics, the minimum input size, the output content, and the fallback behavior. It does not address invalid IDs or alternative tools, but neither is essential for a simple getter.

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 that region_ids identifies the set of regions being queried and adds the important minimum-cardinality rule that fewer than two IDs yields an empty result. It does not define the exact ID format, but this is sufficient for a single simple parameter.

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 what the tool computes: real connectivity between a given set of regions, including existing connections and named tracts touching them, with citations. This is specific and differentiates it from sibling search, rendering, and path-finding tools.

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

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

It gives clear context: the tool should be used when you have a set of regions and want actual inter-region connectivity. It also warns that fewer than two region_ids returns empty rather than reinterpreting the request, providing an explicit usage constraint.

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 excels: it explicitly states the tool NEVER touches the real database or its connection, only generates idempotent SQL (ON CONFLICT DO UPDATE), requires human review before application (decision 17), and that dataset_dir must be local, never remote. This is rich, safety-relevant 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 verbose (three paragraphs) but front-loaded with the core purpose in the first sentence, and every sentence carries substantive information about constraints or behavior. It could be tightened, but there is no wasted or filler content; the density justifies the length.

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 output schema exists (so return values are covered) and the tool is complex (7 params, 0% schema coverage), the description is largely complete: it covers the SQL generation mechanics, idempotency, human-review requirement, format preconditions, and study pairing. The main gap is the four undocumented study metadata parameters, which prevents a 5.

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

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

Schema description coverage is 0%, so the description must compensate. It does well for dataset_dir (local path semantics) and the study_id/study_name pairing rule, but says nothing about study_doi, study_year, study_authors, or study_journal. Four of seven parameters remain undocumented in both schema and description, so the compensation is only 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 states a specific verb and resource: 'Propone el SQL de alta de un dataset real' (proposes the registration SQL for a real dataset). It is clearly differentiated from the sibling tools, which are all analysis/rendering tools (render_brain, search_region, get_connectivity), making this the only ingestion/registration tool in the set.

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 specifies clear preconditions for use: the manifest format must already be one of the four labels in SUPPORTED_FORMATS (never unsupported_pending_adapter), and the files map must cover all required roles. It also states the study_id/study_name pairing constraint and that dataset_dir must be a local path. It does not name explicit alternative tools, but the siblings are all unrelated analysis tools, so no true alternative exists.

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 behavioral disclosure burden and does it well: it reveals output format (PNG), coordinate system details (axial view, Z axis discarded), legend inclusion, connection threshold behavior, and the error case. It does not mention side effects, but as a rendering tool this is a minor gap.

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 one dense sentence with no filler, front-loading 'Imagen PNG real' and then specifying projection, coloring, connections, and error behavior. The repeated use of 'real' is slightly heavy but serves to emphasize the contrast with synthetic/network views.

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 3-parameter tool with no annotations and no output schema, it covers output format, coordinate handling, coloring, thresholding, and error behavior. It is less complete because it omits connection_type semantics and does not explicitly guide selection relative to render_network.

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, but only min_weight is explained ('connections above min_weight as thin lines'). atlas_id is inferable from the tool's purpose, while connection_type receives no explanation of its allowed values or effect, leaving a significant parameter gap.

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 'Imagen PNG real' and specifies a 2D axial atlas projection with real X/Y coordinates, coloring by functional network, and thresholded connection lines. This gives a clear verb+resource+output and distinguishes it from siblings like render_network by focusing on atlas projection, though it does not explicitly name alternatives.

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: call this to get a real PNG image of an atlas projection. However, it does not explicitly state when to use this tool over render_network or other visualization siblings, and the only selection-related hint is the error condition when no real region is loaded.

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 and does disclose key runtime behavior: real PNG output, included legend, gray chord per connection above min_weight, and an error when no real regions are loaded. It stops short of stating side effects or permissions, but for a render-style operation the provided behavior is unusually specific.

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 core sentence is dense and informative, and details are front-loaded. However, the second sentence repeats 'real image' and adds a user-request date that does not help an agent invoke the tool, so not 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?

The definition covers output type and one error condition but leaves out the return delivery format (PNG bytes, URL, etc.), valid connection_type semantics, and guidance for choosing this tool over render_brain. Given no output schema and no annotations, this is minimally acceptable but not 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?

Since schema descriptions cover 0% of parameters, the tool description must explain them. It clarifies min_weight as the connection threshold and indirectly identifies atlas_id as the atlas source, but connection_type is never explained, and with no enums listed the agent cannot know valid values or how it affects the connectogram.

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 names a concrete deliverable: a real PNG circular connectogram of an atlas, with node coloring and thresholded chords. It also stresses that it is not a scene descriptor, which gives some differentiation, but it never names a sibling like render_brain, so the distinction is not explicit.

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 statement about when to prefer render_network over render_brain or other siblings. The 'never a scene descriptor' remark is an output guarantee, not a routing rule, and no alternative tool is suggested or excluded.

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 and clearly discloses behavior: results are restricted to atlases actually loaded, coordinates are real, and functional networks are only reported if already computed, otherwise returned as unclassified and never invented. This is a strong provenance guarantee that goes beyond the bare schema.

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 purpose is front-loaded and every sentence adds value for parameter behavior or result guarantees. It is slightly dense and the internal reference 'decision 73' contributes little, but the overall length is appropriate for the two parameters and output semantics.

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 two-optional-parameter search tool with an output schema, the description is complete: all parameters are explained and the semantics of coordinate, reference space, and network classification are stated. Minor gaps are the lack of explicit exclusions/alternatives and any mention of response size or pagination, but these are not critical for this simple lookup.

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% and the schema provides only names and nullable string types. The description compensates fully by explaining atlas_id as an atlas filter with a concrete example and default behavior, and network_source as selecting from named classifications with its own default 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?

States a specific verb and resource: searches real regions loaded in NeuroGraph. The scope is unambiguous and distinct from siblings like search_tract and rendering/connectivity tools, and the description clarifies what each returned region contains.

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 for the operation (searching loaded regions and their network metadata) and explains the effect of omitting atlas_id. However, it never states when to prefer this tool over an alternative or when not to use it, so the agent must infer selection from the resource type.

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 and does well: it discloses that results include ALL touched regions, include the real citation, and exclude tracts with no verified connections. This is meaningful behavioral context beyond the raw schema.

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

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

Three sentences with no filler. The search criteria are front-loaded, followed by output behavior and exclusion semantics. Every sentence adds useful 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?

The description covers the essential semantics for a search tool: criteria, result contents, and exclusion behavior. The main gap is the ambiguous 'y/o' combination of name and region_id, and there is no mention of pagination or error behavior, though an output schema exists.

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 explain the parameters itself. It does: 'name' is a substring match on name/abbreviation, and 'region_id' specifies a region the tract must touch. It also clarifies how region_id affects the output.

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 specific action ('Busca tractos reales') and the search criteria (name/abbreviation substring and/or region). It clearly identifies the resource and what the tool does, though it does not explicitly contrast itself with sibling tools like search_region.

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 the tool: when searching for real tracts by name, abbreviation, or region. However, it offers no explicit guidance about when not to use it or how it compares to alternatives such as search_region or find_path.

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