Taminyaran Engineering MCP

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds a meaningful behavioral caveat — that results are 'conservative' and no synthetic composite score is fabricated — which shapes interpretation of output. It still omits whether optional sections are skipped or degraded when cultivar/soil inputs are absent, which matters for an orchestrating 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 with no filler, and the aggregation scope is front-loaded. However, the phrasing is dense with undefined internal terms, so brevity comes at the cost of comprehension rather than achieving efficient 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?

A read-only orchestrator with 11 parameters, a nested input object, no output schema, and zero schema descriptions demands far more explanation than is given. The agent cannot tell what soil_assessment accepts, how optional cultivar/rootstock inputs change the result, or what the combined response contains.

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% across 11 parameters, including a nested soil_assessment object, so the description must carry the load and does not. It never maps to a single parameter name (crop_id, lat/lon, cultivar_id, soil_ece, water_ec, soil_texture) or explains what the nested object should contain or what 'limit' caps. Vocabulary like 'environmental fingerprint' and 'cultivar evidence' gestures at inputs without disambiguation.

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 the pieces being combined (environmental fingerprint, variety-fit, knowledge cards, soil assessment), so the aggregate intent is inferable. But it never states plainly what the tool returns or what a 'suitability' result is, leaning on internal jargon like 'canonical variety-fit' and 'reviewed cards'. An agent knows it aggregates several sub-analyses but not precisely what resource it produces.

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 statement of when this orchestrated call should be preferred over calling abiyar_variety_fit, abiyar_soil_assess, and abiyar_location_fingerprint individually, despite those siblings existing. The only guidance is a negative note ('does not invent a new composite score'), which doesn't tell the agent anything about selection.

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

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

Annotations already cover safety properties: read-only, idempotent, non-destructive, and not open-world. The description adds useful behavioral context that the service is 'live' and that forecast values are time-sensitive, but it does not mention authentication, rate limits, caching, or data freshness expectations beyond that single phrase.

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 wasted words. The primary purpose is front-loaded, and the time-sensitivity note follows as useful context.

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

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

For a tool with three required parameters, zero schema descriptions, and no output schema, the description is too thin. It identifies the general concept but omits parameter formats, return value shape, and any guidance about the live service's behavior or freshness.

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% for all three required parameters. The description implies location via 'location-aware' and crop identity via 'crop calendar,' but it does not explain the lat/lon conventions, expected crop_id format, or where crop_id values come from. This leaves parameter semantics substantially under-specified.

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, 'Return,' and names the resources: Abyar crop calendar and weather alerts. It also clarifies the result is location-aware and sourced from the live calendar service. It does not explicitly distinguish itself from sibling tools such as abiyar_chill_profile or abiyar_variety_fit, but its purpose is clear.

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 no guidance on when to use this tool versus alternatives, nor does it state exclusions or prerequisites beyond noting that forecast values are time-sensitive. An agent must infer usage from the tool name and parameters.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered by structured data. The description adds that the profile is 'canonical' and multi-model and that seasonal detail is optional, but omits precedence rules when both fingerprint and coordinates are supplied and says nothing about behavior when neither identifier is given.

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 resource and metrics, with the optional-detail caveat trailing. No redundant restatement of the name 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?

For a 4-parameter read tool with no output schema and only standard annotations, the description covers what is returned and the two lookup modes but leaves the parameter interplay (lat/lon pairing, fingerprint precedence, behavior on missing identifiers) unresolved, which an agent needs to call it 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; it loosely maps all four parameters ('by fingerprint or coordinates' covers fingerprint_key/lat/lon, 'full seasonal detail is optional' covers include_seasons). However it does not state that lat and lon must be supplied together, the format of fingerprint_key, or which input wins when both are provided.

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 ('Read') on a specific resource ('canonical multi-model chill profile') and enumerates the three metrics returned (Chill Hours, Utah Units, Dynamic Chill Portions), which distinguishes it from generic siblings like abiyar_location_profile and abiyar_assess_suitability. The two lookup modes (fingerprint or coordinates) are also named.

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 two ways to call it and that seasonal detail is optional, but never says when to prefer it over abiyar_location_profile or abiyar_assess_suitability, nor when fingerprint should be used instead of coordinates. Usage is only implied, not 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context with 'stateless', but says nothing about what calculations are returned, their ordering ('next relevant'), or how the input combination affects the output.

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

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

One sentence with no filler, and the core action is front-loaded. It is efficient, though the terseness contributes to the semantic gaps noted elsewhere.

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 parameter documentation and no output schema, the description should explain the input combinations and describe what 'next relevant calculations' means. As written, an agent cannot predict the response or understand the interplay of the 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?

Schema description coverage is 0%, so the description must carry the burden, and it only loosely maps to the params via 'crop' and 'location'. It provides no semantics for lat/lon format, units, coordinate pairing requirements, crop_id string format, or behavior when only one input is supplied.

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?

Has a verb ('Build') and a resource ('Abyar context'), but 'Abyar context' is undefined jargon and 'next relevant calculations' is vague about whether it returns data or recommendations. It is distinguishable from siblings like abiyar_get_crop or abiyar_location_profile only by inference, not by explicit differentiation.

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 phrase 'from crop and/or location' implies the parameters are optional, but there is no explicit guidance on when to use this tool instead of abiyar_location_profile or describe_capabilities, and no stated prerequisites or exclusions.

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, idempotentHint, closed-world, and non-destructive, so the safety profile is fully covered. The description adds 'live ... production,' implying current runtime state rather than cached documentation, which is useful context, but it says nothing about response scope or size.

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

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

A single sentence that front-loads the verb and enumerates the covered topics with zero filler. Nothing in it is redundant with the schema or annotations.

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 zero-parameter, read-only, annotation-rich tool with no output schema, the description adequately signals what topics the result covers. The only gap is the missing routing guidance relative to abiyar_context and describe_capabilities.

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 tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The schema is trivially complete and consistent with the description.

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

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

The description uses a specific verb ('Describe') tied to a concrete resource set: live Abyar production architecture, stages, sources, and MCP guardrails. It is clearly differentiated from data tools like abiyar_get_crop, but it does not distinguish itself from the closer siblings abiyar_context or describe_capabilities.

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 explicit guidance on when to call this instead of abiyar_context or describe_capabilities, both of which sound like overlapping orientation tools. The word 'live' hints at a runtime vs. static distinction, but the agent is left to infer it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context by saying the profile is 'live' and comes from 'Matrix and DB,' but it does not describe not-found behavior, permissions, or response characteristics. It does not contradict the annotations.

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

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

The description is a single front-loaded sentence with the verb 'Read' and the resource 'Abyar crop/cultivar profile' stated immediately. It contains no filler or redundant phrasing.

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 one-parameter read operation, the annotations cover safety and idempotency, and the description supplies the data-source context. However, it omits meaningful detail about the crop_id parameter and does not explain return or error behavior despite there being no output schema. It is adequate but incomplete.

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 the only parameter, crop_id, has no description beyond a string pattern. The description mentions 'crop/cultivar profile' but does not clarify whether crop_id is an internal Abyar identifier, a cultivar code, or what format it should take. With low schema coverage, the description should compensate but does not.

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: 'Read one live Abyar crop/cultivar profile.' It also identifies the data sources as 'Matrix and DB,' making the operation clear. It does not explicitly distinguish itself from sibling tools such as abiyar_get_taxonomy, so it falls short of a 5.

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 explicit guidance on when to use this tool versus alternatives like abiyar_get_taxonomy or abiyar_describe. The retrieval-by-ID usage is implied by the name and description, but no conditions, exclusions, or alternatives are 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?

Annotations already declare readOnlyHint, idempotentHint, and closed-world behavior, so the safety profile is covered. The description adds useful content-level context (cards are 'reviewed' and carry source references and cautions), but says nothing about volume, pagination, or behavior when no reviewed cards exist for a crop.

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

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

A single front-loaded sentence with no waste, and the resource and returned content lead. It is arguably under-specified rather than over-long, but structurally it is clean.

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?

It tells the agent what the returned cards contain (evidence, sources, cautions), which partly compensates for the absent output schema. However, with five undocumented parameters and no guidance on filter behavior or result limits, it is not complete enough for confident 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 0% across 5 parameters, so the description carries the full burden and largely fails: only crop_id is implied. The limit, topic, status, and audience filters—including the meaning and allowed values of 'status' and 'audience'—are entirely unexplained anywhere.

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 ('read reviewed farmer/engineer knowledge cards for a crop') and names the content returned (evidence/source references, cautions). It does not differentiate itself from siblings like abiyar_search_evidence or abiyar_get_sources, which cover adjacent territory.

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 word 'reviewed' hints that only vetted cards are returned, but there is no explicit when-to-use, when-not-to-use, or named alternative. An agent choosing between this and abiyar_search_evidence gets no routing signal.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the description's only added context is the word 'trace'. It does not explain what an edge is, how deep the trace goes, whether results are paginated, or what an empty result means.

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

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

A single front-loaded sentence with no filler. It is efficient but so terse that meaningful detail was omitted rather than condensed.

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 no output schema and no param documentation, the description should describe what is returned and how to interpret provenance edges. As written, an agent knows only the minimum needed to guess at calling it.

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

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

Schema coverage is 0%, so the description must carry the parameter burden; it does clarify that evidence_id refers to an Abyar evidence ID, which the schema alone does not. It still omits format expectations and where such an ID comes from (e.g., search_evidence).

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 (trace) and resource (provenance edges) tied to an Abyar evidence ID, which distinguishes it from siblings like abiyar_get_sources or abiyar_search_evidence. However, 'provenance edges' is unexplained jargon, so an agent cannot fully picture what it retrieves.

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 no indication of when to use this versus alternatives such as abiyar_get_sources or abiyar_get_knowledge_cards, nor any prerequisite for obtaining the evidence_id. Usage must be inferred entirely from the tool name.

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 readOnly/idempotent/non-destructive, so the safety bar is covered. The description earns credit for disclosing what the payload contains — evidence, open conflicts, coverage, and rootstock-context policy — which is non-obvious and, absent an output schema, genuinely useful. It does not mention pagination or how conflicts are resolved.

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

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

A single dense sentence with the key noun phrase front-loaded and no filler. 'Rootstock-context policy' is jargon that costs a little clarity but the sentence is otherwise 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?

With no output schema and no parameter documentation, the description covers what is returned but leaves the agent guessing about crop_id provenance and limit behavior. Adequate to attempt the call, not complete enough to call it confidently on the first try.

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

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

Schema coverage is 0%, so the description must carry parameter meaning and it does not. Neither crop_id (format/source, e.g. from abiyar_get_crop) nor limit (default, max 50, effect on the returned list) is explained anywhere the agent can see.

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 (List) and resource (canonical rootstocks) scoped to a crop, and enumerates what the response carries (evidence, conflicts, coverage, policy). It is clearly distinct from assess_suitability or variety_fit, though it never names get_varieties, its closest cousin.

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 call this versus abiyar_get_varieties, abiyar_variety_fit, or abiyar_search_evidence. Usage is only inferable from the word 'List' plus the crop_id param.

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, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds only the word 'authoritative' — it says nothing about result ordering, default page size, or what a source entry contains, which would be the value-add beyond the annotations.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though the terseness leaves the parameter gaps noted above unaddressed.

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 0% schema coverage, no output schema, and an unenumerated 'type' parameter, the description should at minimum define the filter values and mention pagination via 'limit'. It does neither, so an agent cannot call it confidently beyond the bare country filter.

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 carry all parameter meaning. It maps 'country' and loosely maps 'type' to 'institution type', but leaves 'limit' (1-100) entirely undocumented and gives no hint about valid 'type' values — the schema has no enum, so an agent has no way to know what strings are accepted.

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?

Names a specific verb ('List') and resource ('authoritative Abyar research/data sources'), which distinguishes it from retrieval siblings like abiyar_get_knowledge_cards or abiyar_get_provenance. It does not explicitly contrast with those siblings, so it stops short of a 5.

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 phrase 'optionally filtered by country or institution type' implies when the filters apply, but there is no statement of when to choose this over sibling lookups (e.g. get_knowledge_cards, search_evidence) or any exclusions. Usage is inferable but not guided.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds that data is "live" from Matrix, implying fresh reads rather than caching, but says nothing about result size, pagination (the limit cap of 200), or what the returned taxonomy looks like, and there is no output 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?

Two compact sentences with the resource and source front-loaded and nothing redundant. It is terse to the point of under-specification, but not padded.

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 two-parameter read tool whose annotations cover safety, the definition is close to sufficient, but with no output schema and zero parameter documentation the agent still doesn't know what a taxonomy record contains or how query matching behaves.

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 carry the load, yet it only offers "optional query filters records" — it never says what field query matches (crop name, code, partial match?) or what limit controls or defaults to. Neither of the two parameters is meaningfully explained.

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

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

The description states a specific verb and resource ("Read ... Abyar crop taxonomy") plus its data source ("Matrix"), which distinguishes it from sibling abiyar_get_crop reasonably well. The term "Matrix" is unexplained jargon, keeping it from a 5.

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?

Says "Optional query filters records" but never states when to use this tool versus abiyar_get_crop or abiyar_describe, nor whether it should be called with no arguments to enumerate the whole taxonomy. No exclusions or prerequisites are 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds value by disclosing the filtering semantics ('canonical active') and the data source, but says nothing about ordering, pagination, or the shape/size of results.

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

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

A single front-loaded sentence with no filler and the scoping qualifiers ('canonical active') placed early. It is efficient, though the terseness leaves the identified gaps unaddressed.

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

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

The tool is structurally simple (2 params, no output schema, strong read-only annotations), but with zero schema description coverage the description should explain crop_id format and limit semantics. It leaves both undocumented.

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 carries the full burden. 'For a crop' weakly signals that crop_id is a crop identifier, but neither the accepted crop_id format (pattern-constrained slug) nor the purpose of 'limit' (1-100, default behavior) is explained.

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

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

States a specific verb ('List') and a precisely scoped resource ('canonical active cultivars/varieties for a crop'), plus the backing layer (D1-backed Abyar research). An agent can distinguish it from assessment-oriented siblings like abiyar_variety_fit, though no sibling is named explicitly.

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 indication of when to call this versus abiyar_variety_fit, abiyar_get_taxonomy, or abiyar_get_crop. There is no statement of prerequisites (must the crop exist first?) and no exclusions; usage must be inferred from the word 'canonical active'.

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 readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds that the fingerprint is 'rounded' and derived from location plus optional context, which is modest extra context, but it doesn't explain caching, determinism across optional inputs, or what happens when optional soil/water context is omitted.

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

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

A single, front-loaded sentence with no filler. It is efficient, though the terseness comes partly at the cost of clarity given the jargon.

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 6 undocumented parameters, no output schema, and an undefined 'rounded fingerprint' return value, the description leaves too much unknown for an agent to invoke this confidently. It should at least sketch the shape of the fingerprint and the effect of the optional inputs.

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% across 6 parameters, so the burden falls on the description, which only loosely maps 'location' to lat/lon and 'soil/water context' to the EC/texture fields. It says nothing about the units of soil_ece and water_ec, the allowed values of soil_texture, or the role of province.

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?

It states a verb ('Build/read') and a resource ('rounded environmental fingerprint'), and ties it to the variety-fit policy, which hints at its role. However, 'environmental fingerprint' and 'rounded' are internal jargon that don't tell an agent what is actually computed or returned, so purpose is only partially clear.

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 phrase 'used by Abyar variety-fit policy' implies it is a prerequisite step, but there is no explicit when-to-use guidance and no mention of the obvious alternatives such as abiyar_location_profile, abiyar_context, or abiyar_assess_suitability. The agent must infer its place in the workflow.

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 readOnly, idempotent, non-destructive, closed-world. The description adds real value beyond that by stating 'Stateless and not persisted by MCP', which tells the agent no caching or state is created. It does not say how the profile is modeled, its source/version, or what coordinate convention is assumed.

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 short sentences, front-loaded with the purpose before the stateless caveat. No filler. It is arguably too terse rather than verbose, but tight structure is a strength here.

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?

A simple two-parameter read tool with full annotation coverage, so heavy explanation is not required. However, with no output schema, the description should say more about what a 'location/climate-zone profile' contains and what coordinate format is expected; as written an agent must guess both.

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% — the properties are bare numbers with only min/max bounds and no descriptions. The phrase 'supplied coordinates' implies lat/lon but the description does not confirm the coordinate system (WGS84 decimal degrees?), ordering, or handling of invalid/out-of-bound values, so it does not compensate for the coverage 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?

States a specific verb and resource: 'Get Abyar modeled location/climate-zone profile for supplied coordinates.' An agent knows exactly what comes back conceptually. It does not name or distinguish itself from any of the many siblings (abiyar_context, abiyar_describe, abiyar_water_need), so sibling differentiation is absent.

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

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

No guidance on when to call this versus abiyar_context, abiyar_describe, or abiyar_water_need, nor prerequisites such as data availability or upstream steps. The only behavioral framing is statelessness, which is about side effects, not selection.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the description need not repeat that. Beyond annotations, it only adds the word 'preliminary', giving no context about assumptions, limitations, or what kind of capacity verdict is returned.

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 single sentence is front-loaded and has no wasted words. Its brevity crosses into under-specification, though, since it conveys almost no actionable detail.

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

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

With four undocumented required parameters, no output schema, and a domain-specific engineering calculation, the description is far too thin to call the tool correctly. An agent would not know what a 'screen' returns or how the four flow/time inputs relate.

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 four required numeric inputs. It says nothing about peak_daily_m3, irrigation_hours, source_flow_m3h, or hours_available, leaving an agent to guess at their units and interaction from bare schema constraints.

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 sentence names a specific domain object (irrigation network capacity) and an action (preliminary screen), so an agent can infer a quick feasibility check. However, the verb 'screen' is vague and it does not differentiate itself from close siblings like abiyar_water_need, abiyar_pond_design, or run_calculator.

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 rather than abiyar_water_need, abiyar_pond_design, or run_calculator. The word 'preliminary' weakly implies early-stage use, but no exclusions or alternatives are 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. Beyond that the description adds only 'live', with no mention of units handling, geometric assumptions (rectangular section with top/bottom dimensions implies sloped sides), or what a result contains.

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

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

A single front-loaded sentence with no waste, but the brevity reflects under-specification rather than disciplined concision for a six-parameter computational tool.

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?

Six required parameters with zero schema descriptions and no output schema means the description should at minimum state what the calculation returns and what units/constraints apply. It does neither, leaving the agent unable to predict results or validate inputs.

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 carries the burden of explaining the six required numeric parameters, yet it mentions none. Only the parameter names' '_m' suffix implies metres, and nothing explains the relationship between top vs bottom dimensions or the meaning of freeboard.

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?

Names a specific verb ('Run') and a specific resource ('Abyar rectangular pond geometry calculation'), which separates it from spec/listing siblings like get_calculator_spec or list_calculators. However, 'Run live ... calculation' does not say what is actually computed (volume, side slope, liner area?), so the agent knows the domain but not the outcome.

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

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

No guidance on when to use this versus run_calculator, design_project, or explain_design. The word 'live' hints at execution over documentation, but no explicit condition or exclusion is 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: results are filtered to 'active' evidence and it 'does not generate new claims' (i.e., pure retrieval, no synthesis). It omits pagination behavior and what 'active' means in practice.

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 tight sentences, zero filler, with the retrieval scope front-loaded before the output character. Every clause 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?

Adequate for a simple read-only search: it says what is searched and roughly what comes back. But with no output schema and three undocumented parameters, it should have specified result shape (row fields, ordering) and the effect of limit; those gaps matter 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 0%, so the description must carry the full burden. It meaningfully maps 'subject and/or agronomic domain' to subject_id and domain and signals they are optional and combinable, but leaves 'limit' entirely unexplained and gives no format or valid values for subject_id or domain.

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 ('Search') and resource ('active Abyar evidence') plus the filter axes (subject and/or agronomic domain). It also clarifies the output nature ('source-linked evidence rows') which distinguishes it from the many abiyar_get_* retrieval siblings, though it never names an alternative directly.

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 explicit when-to-use guidance and no alternatives named, despite a crowded sibling set (abiyar_get_sources, abiyar_get_knowledge_cards, abiyar_get_provenance, workspace_add_evidence) that an agent could easily confuse with evidence retrieval. Only the implied 'search = find evidence' framing is present.

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, idempotentHint and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: the output is deliberately conservative and the fertilizer dose is withheld absent calibrated local evidence, which tells the agent to expect an incomplete result. It does not quantify that limitation or say what evidence would unlock the dose.

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 tightly written sentences, front-loaded with the action and immediately followed by the key caveat. No filler and no repetition of the tool name.

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

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

For a tool taking a free-form nested object with no output schema and no property documentation, the description does not explain how to build the assessment payload or what the screening result contains. The behavioral caveat is helpful but leaves the invocation guidance materially incomplete.

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 single required parameter 'assessment' is a nested object with zero schema description coverage, and the description says nothing about its expected shape or fields. With one opaque nested parameter, the agent has no guidance for constructing the call beyond guessing.

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: run Abyar conservative soil/lab/water screening. That is materially more specific than the sibling abiyar_water_need or abiyar_assess_suitability, but the description never explicitly names which sibling covers adjacent needs, so the boundary is inferred rather than stated.

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 explicit when-to-use clause, no prerequisite, and no named alternative such as abiyar_water_need or abiyar_assess_suitability. The agent must guess the screening context in which this tool applies.

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, idempotentHint, destructiveHint=false and closed-world, so safety is covered. The description contributes one genuinely useful behavioral fact — that MCP preserves the upstream score and decision without alteration — but says nothing about permissions, latency, or what a failure/empty result looks like.

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 tight sentences with the primary inputs front-loaded and the narrowing options immediately after. The only waste is the undefined in-group term 'Abyar', which costs clarity without adding 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?

With no output schema, no parameter descriptions, and five parameters, the definition leaves the agent guessing about the return shape (scores? decisions? a variety list?), the meaning of limit, and how to obtain a valid fingerprint_key. For a domain-specific policy tool this is a substantial shortfall.

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% across 5 parameters, so the description must carry the burden and does not. It names crop, fingerprint, cultivar and rootstock in prose but never explains that fingerprint_key is a 64-hex-character environmental fingerprint (nor which sibling produces it), and 'limit' (1-50) is never mentioned at all.

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

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

The verb is clear ('Run ... policy') and the resource is named ('variety-fit'), plus the inputs are sketched (crop, environmental fingerprint, optional cultivar/rootstock). But 'canonical Abyar variety-fit policy' is jargon that never says what the tool actually returns — a score, a ranking of varieties, a pass/fail — and it is not distinguished from the sibling abiyar_assess_suitability, which sounds like the same job.

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 of when to use this versus abiyar_assess_suitability, abiyar_get_varieties, or abiyar_context, and no prerequisites or exclusions. The only conditional in the text ('optional cultivar/rootstock narrows context') describes parameter behavior rather than tool selection.

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

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

Annotations already establish that this is a safe, read-only, idempotent, non-destructive computation. The description adds a genuinely useful behavioral detail beyond annotations: missing inputs are returned rather than guessed. It still omits output shape, units, and error semantics, but the added missing-input behavior is meaningful.

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 short sentences, front-loaded with the tool's purpose and followed by the key caveat. 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?

This is a complex tool with nine parameters, nested monthly climate objects, and no output schema. The description gives only purpose and one behavioral note, leaving critical invocation details such as units, expected monthly data format, optional parameter effects, and output shape unexplained.

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 the description does not explain any of the nine parameters, their units, or how they interact. The phrase '12-month' hints at the monthly arrays already enforced by the schema, but no parameter meaning is added beyond structured fields.

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 gives a clear verb and resource: 'Run Abyar 12-month irrigation water-need logic.' That is specific enough for an agent to understand this is a computation tool for monthly irrigation demand. It does not, however, distinguish this from siblings such as run_calculator or get_calculator_spec.

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 states no when-to-use or when-not-to-use guidance and names no alternatives. It only describes a behavioral trait about missing inputs, leaving the agent to infer whether this should be used instead of run_calculator or other calculation tools.

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

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive behavior, so the safety profile is covered. The description adds value beyond that by enumerating what the response actually contains (domains, limits, data version), which is important given there is no output 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?

One short sentence with the resource and the returned content front-loaded; no filler, no restatement of the name.

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

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

For a parameterless, read-only introspection tool with no output schema, the description tells the agent what categories of information come back. It could say more about the shape or freshness of that data, but nothing an agent needs in order to call it correctly is missing.

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 tool takes zero parameters, so the baseline is 4 and there is nothing for the description to clarify beyond what the empty schema already shows.

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?

Specific verb 'describe' plus the concrete content it returns: supported engineering domains, limits, and data version. This clearly marks it as a meta/discovery tool, distinct from the design, material, and quote siblings, though it never explicitly contrasts itself with 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 content listed implies usage ('find out what this service supports before doing domain work'), but there is no explicit statement of when to call it versus the sibling tools, nor any noted prerequisites or exclusions.

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, idempotentHint=true, destructiveHint=false and closed-world, so the safety profile is covered. The description adds genuine context beyond that: which CAL modules are actually executable (guarded) and that high-risk results are gated to human review, which tells the agent to expect partial automation. It does not disclose what 'versioned' means operationally (does a version get persisted?), which sits in tension with readOnlyHint and would matter to a caller.

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

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

Three short sentences with no filler, and the artifact statement is front-loaded. However, the second sentence is dense internal jargon (CAL-060/061, CAL-065/066/067) that consumes the middle of a very short description without explaining what those modules accept or produce. Efficient in length, but the space is spent on identifiers rather than on actionable meaning.

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 18 parameters, deep nested objects, no output schema, and 0% schema description coverage, this is a high-complexity tool whose description is far too thin. It never says what a successful call returns (a versioned design document? a module result set?) or what the required project_type values are, and no output schema exists to backfill that. The module and human-review notes are helpful but nowhere near 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 0% across 18 parameters, so the description carries the full burden and largely fails it. The module list loosely maps to a few property names (tunnel, groundwater, drainage, structure, pump), but the required project_type, calculator_id, required_output, design_life_years, fluid_or_medium, and the eleven nested objects are given no meaning at all. An agent cannot tell what shape to send for geometry, constraints, or qa_qc from either the schema or the description.

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

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

The first sentence ('Versioned preliminary engineering design') names the artifact produced but never uses a clear verb — it is unclear whether the call computes, stores, or versions a design. The second sentence enumerates which calculator modules are executable, which is useful domain detail but not a statement of what invoking the tool does for the caller. An agent can infer it is the design-generation entry point, but only by guessing against siblings like explain_design and project_intake.

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 explicit when-to-use guidance and no alternative is named, even though siblings (explain_design, project_intake, prepare_quote_request) plausibly overlap. The only usage-adjacent statement is the constraint that 'High-risk engineering remains human-review,' which indicates a boundary but not a selection rule. The agent is left to infer routing from the tool name alone.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only "Stateless", which is a genuine extra (nothing is persisted), but it says nothing about what the explanation contains, whether malformed payloads produce errors or diagnostics, or how opaque/unknown design shapes are handled.

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 short, front-loaded sentences with no filler or repetition. It is efficient, though the brevity is partly the cause of the missing detail rather than purely a virtue.

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

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

No output schema exists, so the description is the only place the response shape could be described, and it says nothing about it. Combined with an opaque nested input object at 0% coverage and no annotation-independent behavioral detail, the definition is not complete enough for reliable 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 0% and the single required parameter is an unconstrained nested object, so the description carries the full burden. "design_project payload" hints at the expected shape, but it never enumerates fields, required keys, or the expected structure of the nested object, leaving an agent with no way to construct a valid `design` value from the definition.

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?

"Explain" + "design_project payload" gives a verb and a resource, but "explain" is ambiguous: it doesn't say whether the output is a validation report, a human-readable summary, a field-by-field walkthrough, or an error diagnosis. It also doesn't distinguish itself from the sibling design_project tool, so an agent cannot tell which to pick from the description alone.

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 says the payload is "supplied by the client" and that the tool is stateless, which hints at the input's origin but never states when to call this instead of design_project or project_intake. There are no exclusions and no conditions that select this tool over its siblings.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety behavior is covered. The description adds one genuinely extra behavioral fact — the spec is 'live', i.e. resolved at call time rather than cached — plus what the response contains. It does not say what happens if the calculator_id is stale or unknown.

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

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

A single front-loaded sentence with no filler; the resource and its three returned facets appear immediately.

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 correctly names the three things returned, which is the main completeness win. But the returned concepts are undefined and the identifier's origin is unstated, so an agent still has to guess before its first successful call.

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

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

Schema coverage is 0%, so the single parameter is documented only by its name. The phrase 'for one ... site calculator' does convey that calculator_id selects exactly one calculator, but nothing says its format or that identifiers come from list_calculators, leaving a real discovery 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?

Specific verb 'Get' plus a clearly scoped resource: the spec (field contract, source, risk class) of a single site calculator. That distinguishes it from list_calculators (enumeration) and run_calculator (execution). The only shortfall is domain jargon ('field contract', 'risk class') that an unfamiliar agent cannot fully decode.

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 statement of when to call this versus list_calculators or run_calculator, and no prerequisite guidance. A reader must infer that this is an inspection step performed before running or configuring a calculator.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds only the word 'curated', which hints at a filtered/approved catalog but does not explain what that means or what happens if the asset_id is not eligible or not found.

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

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

A single short sentence with zero filler and the resource plus selector front-loaded. It is efficient, though its brevity borders on under-specification rather than tight phrasing.

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

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

The tool is simple and annotations carry the safety profile, but with no output schema the description says nothing about what a 'curated material' record contains or how errors are surfaced, which an agent would want before calling.

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 the single parameter asset_id has no format, source, or example documented anywhere. The description merely restates the parameter name ('by asset_id') without adding meaning, leaving the agent to guess the identifier 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?

States a specific verb ('Get') and resource ('curated material') with the key selector ('by asset_id'), which is enough to distinguish it from the sibling search_materials (singular retrieval vs. search). It does not explicitly name that sibling, but the scope is clear.

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 word 'one' implies this is for fetching a single known material rather than browsing, which implicitly routes against search_materials, but no alternative is named and no preconditions (e.g., where asset_id comes from) are 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 annotations already declare that this is a safe, read-only, idempotent, non-destructive, closed-world operation. The description adds useful scope context—32 live canonical calculators and no falsely executable planned items—but does not explain filtering, pagination, or return behavior despite the limit and query parameters.

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 and front-loads the primary purpose. The second sentence is somewhat defensive but still earns its place by clarifying scope.

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 listing tool, the description could be sufficient, but the two parameters have 0% schema description coverage and there is no output schema. The description therefore leaves important operational details—filtering and limiting—unexplained.

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 the description does not explain either parameter. It says 'List all 32' without clarifying how limit or query affect the result, leaving both optional parameters entirely undocumented.

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: listing all 32 live canonical calculators from Taminyaran Calculation Center. This clearly separates it from action-oriented siblings such as run_calculator or get_calculator_spec, though it does not explicitly name those 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?

It does not say when to choose this tool over get_calculator_spec, run_calculator, or other siblings. The note about planned Master Map items clarifies scope, but not usage context or exclusions.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description reinforces this with the strong 'NEVER submits' guarantee and adds a non-obvious behavioral requirement (surface the summary and get explicit user confirmation). What is missing is any hint about what the preview contains or whether validation errors can occur.

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 short sentences, front-loaded with the purpose and followed by the critical constraint. Every clause carries operational weight – nothing is redundant.

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 preview tool with no output schema, the description mentions that a 'returned summary' exists and must be shown to the user, which partially compensates. But with 12 undocumented parameters and no output schema, an agent still lacks guidance on how to populate the boq structure or when to supply design_id/calculator_id, so the definition is only minimally sufficient.

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?

There are 12 parameters at 0% schema description coverage, yet the description says nothing about any of them. The phrase 'from an engineering design/BOQ' loosely hints at the boq parameter, but required fields like customer_name, phone, city, product, quantity, and the optionals design_id, calculator_id, assumptions and warnings are entirely undocumented.

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 ('Prepare a Taminyaran RFQ preview') plus the input source ('from an engineering design/BOQ'). It is immediately differentiable from the sibling submit_quote_request, which the description names as the follow-on step.

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

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

Explicitly defines the workflow boundary: 'This tool NEVER submits. Show the returned summary to the user and obtain explicit confirmation before calling submit_quote_request.' This tells the agent when to use this tool, when to stop, and which alternative to use next.

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 readOnly/idempotent/non-destructive, so the bar is lower, yet the description still adds real behavioral facts: stateless, nothing is persisted, missing values stay null and yield HOLD. These are non-obvious response-behavior traits not present in the annotations. It stops short of describing the actual returned payload shape.

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 dense, front-loaded sentences with no filler; the core purpose leads and the CAL screen routing and HOLD rule follow. Domain codes are unexplained but are likely load-bearing for the target audience.

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 12-parameter tool with nested objects, no output schema, and zero schema description coverage, the description is thin: an agent cannot tell what belongs in pump/groundwater/evidence/geometry or what the HOLD output looks like beyond a status keyword.

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% across 12 parameters including nine nested objects (pump, drainage, groundwater, geometry, structure, evidence, constraints, investigation), and the description explains only the null/HOLD convention — no meaning is given for any domain-specific field, so it does not compensate for the schema 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?

Specific verb+resource: 'Normalize a project brief into a stateless machine-readable engineering intake' clearly states the transformation and its stateless nature. It implicitly separates this from design/explain siblings (intake vs. design), but never names them, so the sibling differentiation is left to inference.

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 useful routing context — excavation/foundation groundwater projects map to CAL-065/066/067 screens — and states the HOLD rule for missing values. But there is no explicit when-to-use-this-vs-design_project guidance and no stated prerequisites or exclusions; usage is implied rather than directed.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only the 'canonical engine / Calculation Center Page 16700' claim, which is not actionable, and says nothing about validation failures for an unknown calculator_id or malformed inputs.

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

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

A single front-loaded sentence with no padding. The 'same canonical engine as Calculation Center Page 16700' clause is the only questionable content, since it consumes space without helping the agent act.

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 an untyped nested inputs object, no output schema, and no guidance on input shape or prerequisite discovery, the description is seriously incomplete. An agent could not construct a correct call from this definition alone.

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% with two required parameters, one of which is a free-form nested object. The description implies calculator_id is one of 32 choices but does not enumerate them or name the tool that does, and gives no hint about the structure of the inputs object, which is the parameter most likely to cause a failed call.

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: run one of 32 site calculators on the canonical engine. The purpose is clear, but it does not distinguish itself from siblings like list_calculators or get_calculator_spec, which an agent would need to call first, and the 'Page 16700' reference is opaque internal jargon.

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 when-to-use guidance and no stated prerequisites, even though the tool requires a valid calculator_id and a calculator-specific inputs object. It never points to list_calculators (to discover the 32 IDs) or get_calculator_spec (to learn the required input shape), which are present as siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds a useful trust caveat that matches are candidates, not engineering approvals, but does not cover ranking, pagination, or authorization 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 two sentences, front-loaded with purpose and followed by a concise caveat. 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 search tool with four undocumented parameters and no output schema, the description is too sparse. It does not explain return shape, pagination, ranking, or how family/project_type/limit affect results, leaving the agent under-informed.

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 0% description coverage for four parameters: query, family, project_type, and limit. The description does not explain any of these parameters or their expected formats.

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: 'Search curated Taminyaran local materials.' It distinguishes discovery from retrieval by sibling get_material, though it does not explicitly name that alternative. The second sentence adds a clarifying caveat about result interpretation.

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 explicit guidance on when to use this tool versus alternatives such as get_material or design_project. The caveat 'Matches are candidates, not engineering approvals' clarifies result meaning but not tool selection or prerequisites.

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

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

Annotations already mark this as destructive, open-world, and non-idempotent, but the description adds critical operational context beyond them: human confirmation is mandatory before submission, the recipient is constrained, and automatic retries are forbidden when status is unknown. Those are important safety behaviors for an external write operation.

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 three tight sentences, front-loaded with the action and immediately followed by the most important gating condition. Every sentence adds operational value, especially the confirmation requirement and unknown-status warning.

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

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

For a complex, destructive external submission tool with no output schema, the description covers the main workflow gate and retry hazard well. However, it leaves the agent without enough explanation of how to populate or validate the many submission fields, which is a substantial completeness gap even if prepare_quote_request supplies much of the payload.

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% for 14 parameters, and the description does not explain individual fields such as boq, warnings, assumptions, design_id, calculator_id, or confirmation_code. It implies the payload should match the prepare_quote_request summary and that confirmed confirmation is required, but that is far too thin for a 14-parameter tool with no 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 states a specific verb and resource: submitting a previously prepared RFQ through Taminyaran's official quote form. It clearly distinguishes this from preparation by referencing prepare_quote_request and requiring its exact summary, so an agent can tell it is the submission step, not the drafting step.

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 explicit gating conditions: call only after the user explicitly confirms the exact prepare_quote_request summary. It also states exclusions and failure handling: no arbitrary recipient, and no automatic retry when submission status is unknown. This is unusually clear when-to-use 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?

Beyond the annotations, it discloses two important behaviors: file bytes are not stored (only a reference/hash/metadata), and human verification is a separate step. That materially clarifies what this non-read-only mutation actually commits. It still omits duplicate handling for a non-idempotent write and the purpose of confirm_store.

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

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

Three short sentences with zero filler; the primary action is front-loaded and the two key caveats (no file bytes, separate human verification) follow immediately.

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 behavioral side is reasonably covered for a mutation tool with no output schema, but with 0% schema coverage on 8 params and a required confirm_store gate, an agent still lacks the guidance needed to construct a valid call confidently.

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% across 8 parameters, including nested metadata, the sha256 pattern, project_key length bounds, and the required confirm_store flag. The description adds no parameter-level meaning at all, leaving the agent to infer everything from field names and enums.

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: 'Append a ... evidence reference/status/hash/metadata record to Project Workspace.' It clearly distinguishes a write-side evidence record from read-side siblings like abiyar_search_evidence or workspace_get_project, though it never names those siblings explicitly.

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?

'Human verification is separate' implies this tool should not be used to record human sign-off, but the description never says when to call this versus workspace_review_readiness or the quote-handoff tools. No prerequisites (e.g., the confirm_store requirement) are stated, so usage 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?

Annotations already declare the mutation profile (readOnly=false, idempotent=false, non-destructive, closed-world), so the description is not carrying the safety burden alone. It adds genuinely new facts beyond the annotations: the return payload (project_id + a one-time project_key), the PII-free constraint, and a security rule about not putting the key in a URL. It does not say what happens to pre-existing projects or whether the intake payload is mutated.

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

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

Three short sentences, zero filler, and the core action is front-loaded before the precondition and the security caveat. Each sentence carries distinct information (what it does, when to use it, a security rule).

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 state-creating mutation that returns a one-time secret, the description covers the important operational facts (persistence precondition, key handling). However, given 0% schema coverage on a deeply nested intake object and a required confirmation flag, the description leaves the agent guessing about how to populate the payload - a significant gap for this complexity level. No output schema exists, and the return values are at least summarized.

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% across 4 parameters, including a required nested `intake` object with ten sub-properties and a required `confirm_persist` boolean. The description explains none of them - it never says that confirm_persist gates the write, nor what the intake fields (goal, geometry, groundwater, etc.) mean or whether they must be PII-free. The 'PII-free' phrasing is the only indirect hint at parameter content.

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 specific verb and resource ('Create a persistent PII-free Project Workspace') plus what it returns, which is far more than the bare tool name conveys. It implicitly separates itself from intake-only siblings like project_intake and workspace_run_intake by requiring persistence intent, though it never names an alternative explicitly.

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?

'Use only after the user explicitly asks to persist project state' is a concrete precondition that tells the agent when to call it and, by implication, when not to (i.e., for exploratory intake). It stops short of naming which sibling to use instead when the user has not asked for persistence.

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?

Adds genuine context beyond the annotations: the link is temporary and PII-free, contact details are collected in the external form, and crucially 'this creates NO RFQ/inbox record by itself' — a non-obvious side-effect disclaimer that matters because annotations only say readOnlyHint=false, destructiveHint=false, idempotentHint=false. Minor gap: no TTL or reuse/idempotency behavior for the short link is described.

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

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

Three short sentences, front-loaded with the precondition and the action, and every sentence carries information the agent needs (trigger, artifact produced, side-effect disclaimer). 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 small, no-output-schema tool the description covers what is produced and what is not created, which is the key decision-relevant context. It stops short of describing the return value (presumably the /q/ URL) and how long the temporary link lives, so an agent still has minor unanswered questions.

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 all four parameters are required with no schema descriptions at all. The description only indirectly implies 'confirmed'/'confirmation_code' via the confirmation prerequisite; it never explains project_id vs project_key (the latter with a 40-120 char constraint) or the confirmation_code format. This is a meaningful gap the description should have covered.

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 ('create') and precisely scoped resource ('a temporary PII-free /q/ short link that opens the existing official Taminyaran quotation form'). This clearly distinguishes it from the sibling workspace_prepare_quote_handoff, which it explicitly names as the prerequisite.

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 gating condition is stated explicitly: only after 'explicit user confirmation of workspace_prepare_quote_handoff'. That gives a clear when-to-use rule and sequencing. It does not name alternatives or say when NOT to use it (e.g. when a full RFQ is wanted), which keeps it below 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so 'Read-only' is largely redundant. The added claim that 'MCP itself remains stateless' is genuine extra context about side effects, but the description never says what the 'bridge safety contract' entails or what a caller learns from 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?

Two short sentences with no filler; the read-only constraint is stated up front. The brevity comes at the cost of unexpanded jargon rather than verbosity.

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 parameters, the description is the only place a caller could learn what this returns, and it does not — 'state plane' and 'bridge safety contract' are never explained. An agent cannot predict the response shape or decide whether the call is worth making.

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 tool takes zero parameters and the schema is closed (additionalProperties: false), so there is nothing for the description to disambiguate. Baseline 4 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 verb 'Describe' plus the named resource 'Taminyaran Project Workspace' gives a rough idea, but 'state plane' and 'bridge safety contract' are internal jargon that never resolve into a concrete object. It also fails to differentiate itself from sibling describe-style tools (describe_capabilities, abiyar_describe).

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 of when an agent should call this versus describe_capabilities, abiyar_describe, or the workspace_* tools that actually read project state. The word 'read-only' hints at a safe inspection call but gives no triggering condition.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description. The description does add useful value by enumerating the returned sections, but says nothing about behavior such as error cases when no handoff exists, key rotation effects, or size/pagination.

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

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

A single front-loaded sentence that leads with the verb and resource before enumerating contents. There is no filler, hedging, 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?

With no output schema, the description is the only place return contents are explained, and the enumerated sections partially satisfy that. However, for a tool requiring two opaque identifiers, the description is silent on parameter meaning and on failure behavior, leaving meaningful gaps for an agent to close by trial and error.

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 carries the burden for two required parameters, yet it mentions neither project_id nor project_key. It gives no clue why both identifiers are required or what the 40-120 character project_key represents (a secret-like key?), which is exactly the kind of ambiguity the description should resolve.

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 ('Read') with a clearly named resource ('the structured project handoff') and enumerates what that artifact contains (intake run, evidence matrix, reviewer decisions, memo seed, checklist). This makes the purpose concrete. It falls short of a 5 because it never distinguishes this read from the adjacent workspace_get_project or workspace_review_readiness 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?

There is no statement of when to use this tool versus workspace_get_project, workspace_review_readiness, or workspace_prepare_quote_handoff, all of which live in the same workspace family. The description also gives no precondition (e.g., whether an intake run must exist first), leaving the agent to infer usage entirely.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds two genuinely new facts: the state is PII-free, and project_key functions as a capability handle (an access credential). It does not disclose failure behavior for an invalid or rotated key, which is the key remaining 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?

A single front-loaded sentence with the verb first and zero filler. It is arguably too terse for the amount of undocumented parameter surface, but nothing in it is wasted.

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 should hint at what 'project state' contains, and it does not. Annotations cover the read/idempotent profile, but an agent still lacks guidance on return shape and on what happens when the capability handle is rejected.

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 carry the semantics. It correctly frames project_key as a 'capability handle' rather than a plain lookup key, which is meaningful, but says nothing about the format or source of project_id, nor how the 40-120 character key is obtained.

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 ('Read persistent PII-free project state'), which clearly separates it from write-oriented siblings like workspace_create_project or workspace_update_intake. It does not explicitly name a sibling it is not, and 'state' remains somewhat abstract, so it stops short of a 5.

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 of when to use this versus workspace_describe, workspace_review_readiness, or workspace_get_handoff. The only usage signal is the implicit prerequisite of supplying both project_id and project_key; no exclusions or alternative routing are 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?

Beyond annotations that already declare readOnlyHint, idempotentHint, and destructiveHint=false, the description adds useful specifics: no link is created, nothing is submitted, PII is excluded, and HOLD/RED FLAG context is preserved. It also states the deterministic confirmation_code, though it does not cover auth, error behavior, or full response shape.

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 three tight sentences with the core action front-loaded, followed by the read-only guarantee and return behavior. Every sentence adds distinct information without 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 two-parameter tool with no output schema, the description does well to describe the return value and safety properties, but it leaves the parameter semantics unexplained. Given the 0% schema description coverage, that gap prevents the definition from being fully self-contained.

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 0% description coverage, so the description must compensate, but it gives no meaning for project_id or project_key. The phrase 'current Project Workspace state' hints that project identity is involved, yet the specific roles and constraints of the two required parameters are left entirely to their bare schema types.

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 specific verb and resource: preparing a PII-free quotation handoff from the Project Workspace state. The sentence 'Read-only: creates no link and submits nothing' clearly distinguishes this tool from the sibling create/submit handoff and quote 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?

The read-only and no-submission behavior implies this is a preparatory step rather than the final handoff action, but the description does not explicitly state when to use this tool versus workspace_create_quote_handoff or submit_quote_request. Usage context is implied rather than spelled out.

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 establish that this is a safe, idempotent, non-destructive read. The description adds useful context by naming the categories of readiness information returned and, importantly, warning that completeness is not human engineering approval. It stops short of richer behavioral detail such as output shape or scope.

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 definition is two sentences, front-loaded with the operation and its outputs. The second sentence is a meaningful caveat rather than filler, so 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 description lists the readiness categories and includes an important approval caveat, which is adequate for a read-only tool whose annotations cover safety. However, with no output schema and no parameter descriptions, it should clarify the project scope and what the two required identifiers represent.

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?

There are two required parameters, project_id and project_key, and schema description coverage is 0%. The description never mentions either parameter, their formats, or their relationship to the project, so it does not compensate for the schema's missing parameter 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 gives a specific read operation and enumerates what it returns: design-review blockers, evidence gates, red flags, and commissioning readiness. That is much clearer than a generic 'get readiness', but it does not explicitly differentiate this tool from siblings such as workspace_get_project or workspace_describe.

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 states what the tool reads but gives no explicit guidance on when to call it versus alternatives, nor any prerequisites or exclusions. The second sentence is a caution about interpretation, not usage routing.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, meaning the safety profile is covered structurally. The description adds genuinely new behavioral facts beyond that: the old key is destroyed, the new key is displayed exactly once, and MCP never stores it — critical details that shape how the agent must handle the response. It stops short of stating auth/permission requirements or what happens to existing sessions using the old key.

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

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

Three short sentences, front-loaded with the action, then the destructive warning, then the irreversibility of the returned secret. No filler and nothing important buried.

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?

It covers the destructive and one-time-display semantics well, which is the hardest part of this tool, and no output schema exists so return values need not be described. But for a 3-parameter destructive mutation with zero schema coverage, leaving all parameter meanings unexplained and omitting permission/prerequisite details leaves the agent guessing at call construction.

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 carries the full burden, and it explains none of the three required parameters. Most importantly it never clarifies whether 'project_key' is the current key being authorized for rotation or a caller-supplied replacement, nor what 'confirm_rotate' must be set to — the phrase 'require explicit confirmation' only obliquely hints at the boolean.

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 ('Rotate the Project Workspace capability key'), which is unambiguous and unique among the siblings — no other workspace_* tool performs rotation or touches the capability key. An agent can tell immediately what this does and that it is not the same as workspace_create_project or workspace_describe.

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 states a precondition ('require explicit confirmation') and flags the destructive outcome, which implies when the tool is appropriate. However, it gives no guidance on when rotation should be performed versus other remediation paths, and no exclusions or alternatives are named.

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?

Goes beyond the annotations by disclosing that it delegates to another MCP tool (project_intake), that it writes a new run/version, and that confirmation is required — none of which the annotations convey. This is consistent with readOnlyHint=false, destructiveHint=false and idempotentHint=false (a new run is created each call), with no contradiction.

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 short sentences, front-loaded with the primary action and followed by the confirmation constraint. Minimal waste, though the phrase 'canonical MCP project_intake' is jargon-heavy for the amount of information conveyed.

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 should say what is returned or what the persisted run/version means; it does not. For a mutation tool with 3 fully-required, undocumented parameters, it also omits failure behavior and prerequisite project state, though the cross-tool delegation and confirmation requirement are usefully covered.

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 carry parameter meaning, but it only implicitly gestures at confirm_store_run via 'Requires confirmation'. project_id and project_key — where project_key has a notable 40–120 char constraint — are never explained, nor is the relationship between them, leaving the caller to guess.

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 two-step action: invoke the canonical project_intake MCP tool for the stored intake, then persist the returned run/version into Project Workspace. This distinguishes it from the sibling project_intake (which only computes intake) and from workspace_update_intake, though it does not name either sibling explicitly.

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 rather than stated: the agent can infer it should be used when an intake must be executed and its run persisted. There is no explicit guidance on when to prefer workspace_update_intake, no stated prerequisites (e.g., whether a project must already exist), and no exclusions.

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 flag destructiveHint=true and idempotentHint=false, so the safety bar is lower; the description nonetheless adds real value by disclosing the version increment, the explicit-confirmation requirement, and the PII-free constraint on payload content. It stops short of saying whether the previous intake is recoverable or what a rejected replace returns.

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 short sentences, mutation and version-bump effect front-loaded ahead of the confirmation caveat. No filler and nothing restated from the schema.

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 destructive full-replacement mutation the mutation semantics are covered adequately, but the payload itself — a large nested intake object with an unstated required shape — is the bulk of what the agent must get right, and neither description nor schema descriptions explain it. No output schema exists, so the absence of any mention of the resulting intake_version is a further 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 0% across four required parameters, and the description compensates almost not at all: only confirm_replace is obliquely referenced via "explicit confirmation." project_id, project_key, and the 11-property nested intake object are undocumented in prose, leaving the agent dependent on a bare 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?

States a specific verb (Replace) and a specific resource (the canonical PII-free project intake in Project Workspace), plus a side effect (intake_version increments). It does not distinguish itself from near neighbors like workspace_run_intake or project_intake, so an agent must still infer which of the intake tools applies.

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?

"require explicit confirmation" gives an actionable precondition for the confirm_replace flag, and "Replace" implies this is for updating an existing intake rather than creating one. However, it never names when to pick this over workspace_run_intake or project_intake, and offers no exclusions.

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