rb209-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation2/5
The set has many near-identical lookup families—e.g., at least four soil nutrient-index-by-value variants and multiple organic-material-type filters—so an agent must parse subtle parameter differences to avoid misselection. Singular/plural pairs and a deprecated endpoint duplicated by a country-aware version further blur boundaries.
Naming Consistency3/5
All tools share a uniform `rb209_<area>_<resource>` snake_case pattern, which is predictable. However, naming is inconsistent at the resource level: `soil_nutrient_indices` vs `soil_nutrient_indexes` are both present, singular and plural forms are mixed, and some names are awkwardly long (`rb209_grass_growth_class_by_soil_type_rainfall_altitude_chalk`).
Tool Count1/5
94 tools is an extreme tool count for an MCP server, far beyond the point where an agent can reliably choose. Many endpoints are trivial singular/plural pairs or filter variants that could be collapsed into parameterized tools, so this feels like a direct API surface dump rather than a curated tool set.
Completeness5/5
For the RB209 nutrient-recommendation domain, the tool surface is remarkably complete: it includes the main recommendation calculator plus lookups for crops, grass, soil, organic materials, rainfall, measurements, previous cropping, and fertiliser prices. There are no obvious dead-end workflows; even caveats around no-soil-analysis and country-specific paths are covered.
Average 3.4/5 across 94 of 94 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 40 commits in the last 12 weeks
- Last stable release on August 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden for behavior. It indicates a GET-style read and an 'individual id' result, but it does not disclose return format, error behavior, or any additional operational detail beyond the endpoint line.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with the endpoint shown first and no filler. It is efficient, though slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and many sibling tools, the description should clarify the exact return value and the role of countryId. It only offers a terse noun phrase and omits a required filter, leaving the tool incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all four parameters at 100% coverage, so the description adds no new meaning. It also omits countryId from the list of filters despite countryId being required and present in the endpoint path, creating a misleading gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific endpoint, the resource ('nutrient index id'), and the filtering criteria, so the lookup intent is clear. It does not explicitly differentiate from closely named siblings such as rb209_soil_nutrient_index_by_value_methodology_country, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of the many related soil nutrient index tools. The phrase 'filtered by' only restates the input-driven nature of the call, which the schema already conveys.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only implies a read-only GET operation and does not describe response contents, error behavior, authorization needs, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the endpoint, but the clause after the dash is redundant and tautological. A clearer phrasing such as 'Retrieve a grass history by its ID' would be more effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter GET endpoint this is minimally usable, but with no annotations and no output schema, more context is needed. The description does not explain what a grass history is, what the response contains, or how this endpoint relates to sibling tools like rb209_grass_histories.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single required parameter, describing it as 'The Grass History ID.' The description adds no additional meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly includes the HTTP verb and endpoint template, making it clear this tool retrieves a single grass history by ID. However, it does not explicitly contrast with sibling tools like rb209_grass_histories, and the phrase 'Grass history of grass history id provided' is somewhat circular.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. It does not mention that rb209_grass_histories lists all grass histories, nor does it describe any conditions or prerequisites for selecting this endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the calculation operation and gives no detail on side effects, authorization needs, return behavior, or whether this is a pure read operation. It does not mislead, but it reveals very little beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short line with no filler, and the endpoint is front-loaded. However, it is ungrammatical and compresses what could be a clear statement into a fragment, so the brevity comes at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a nested-body POST with no output schema and no annotations, yet the description does not mention the response shape, required field semantics, or how this calculation relates to the many lookup sibling tools. An agent can construct the request from the schema but cannot predict the result or confidently know when this tool is the right choice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions, so the baseline is 3 even though the description adds no parameter-level detail. The schema's generic 'The X Id for the crop' wording is sufficient for identifying the fields but does not explain how the IDs relate to each other or where to obtain them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the endpoint and the operation: calculating the crop nutrient offtake value. This is specific enough to distinguish it from the sibling calculate_nutrient_deficiency tool, though the phrasing 'The calculate crop nutrient offtake value' is grammatically awkward.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as rb209_recommendation_calculate_nutrient_deficiency or rb209_recommendation_recommendations. The intended selection context is left entirely to the agent to infer from the name and endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It only states that the result is a filtered list; it does not mention response format, ordering, pagination, errors, or any access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the endpoint and filtering behavior without filler. It is concise rather than padded, though it does little beyond restating the endpoint's obvious purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter GET list endpoint with no output schema, and the description gives the essential function and input meaning. It is minimally adequate, but it leaves return fields and invalid-input behavior to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter with a meaningful description ('The crop group id to filter on'), so the baseline is 3. The tool description repeats the filtering idea but adds no format, constraints, or additional semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource and action: it returns a filtered list of crop types, filtered by crop group id. It does not explicitly contrast with sibling tools like rb209_arable_crop_types, but the by-group scope is evident from the endpoint and wording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this endpoint versus the many related crop type or crop group tools. The phrase 'filtered by crop group id' implies a use case, but no alternatives or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure, but it only states the HTTP verb and resource path. It doesn't mention possible errors for invalid/missing nutrientId, whether the text could be localized or formatted, or any additional context about what 'nutrient text' means. The description is essentially a restatement of the endpoint signature with minimal added behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the HTTP verb and path, which orients the agent quickly. Its second clause is somewhat needlessly verbose ('filtered from the supplied corresponding nutrient id') but still one concise sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter lookup tool, this is nearly complete, but there is no output schema and no annotation, so the description should clarify what 'nutrient text' is expected to be (e.g., a string label, a text block, localized names). Also, there is no mention of how to find the nutrientId or what distinguishes this from rb209_field_nutrients beyond singular vs plural. Slightly better than a tautology but leaves meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents nutrientId as 'The nutrient id to filter on'. The description adds only a slightly redundant relational phrase ('filtered from the supplied corresponding nutrient id') that echoes the schema. Baseline 3 applies because the schema does the heavy lifting and the description adds minimal new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (GET) and resource (individual nutrient text filtered by nutrientId), clearly indicating what the tool returns. It distinguishes itself from the plural sibling rb209_field_nutrients, though it doesn't explicitly name the sibling. The phrase 'filtered from the supplied corresponding nutrient id' is slightly awkward but understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like rb209_field_nutrients. The description implies it is for a single nutrient lookup by ID, but it never states exclusions or names alternatives. An agent must infer usage from the singular/plural contrast in sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the HTTP method and resource but gives no detail about response shape, side effects, error behavior, required permissions, or what a 'site class' means. The GET verb implies read-only behavior, but the description does not explicitly confirm it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It is appropriately short for a simple parameterized GET endpoint, though the phrase 'Site class list' is terse and could be slightly more descriptive without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain what the response contains and any operational context. It only says 'Site class list', leaving the agent without information about the return format or how site classes relate to countries. For a one-parameter lookup this is borderline but below minimum viability because it lacks any behavioral detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the countryId parameter described as 'The Country id'. The tool description adds only the path-template context that countryId is substituted into the URL, which is marginal. The schema already documents the parameter adequately, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific HTTP verb (GET) and resource (Site classes filtered by countryId), making it clear this is a list retrieval operation. It does not explicitly distinguish itself from sibling tools like rb209_field_site_class or rb209_field_site_class_item, but the word 'list' and the path structure provide reasonable clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as rb209_field_site_class or rb209_field_countries. The description only states what the endpoint is, not the scenarios in which an agent should prefer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining behavior. It only restates the GET endpoint and the general concept of a site class, without disclosing whether a single item is returned, what fields it contains, how errors behave, or whether any side effects occur. 'Site class of field' is too thin to be fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise line with no filler and places the endpoint first. It is efficient, but the brevity comes at the cost of missing useful behavioral and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple scalar-parameter GET lookup, the schema covers all required inputs. However, there is no output schema and no description of what the returned site class item contains, nor any clarification against the closely named sibling tools, leaving the description less complete than it could be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all four parameters (altitude, postcode, countryId, soilTypeId), so the schema covers 100% of the parameter semantics. The description adds no additional parameter detail, which keeps this at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the HTTP verb and resource ('GET /api/Field/SiteClassItem/...') and states the outcome ('Site class of field'), making it clear this is a lookup operation. However, it does not explain what a 'site class item' actually is or how it differs from the similarly named sibling tools rb209_field_site_class and rb209_field_site_classes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus its siblings, no mention of prerequisites, and no indication of what scenarios call for this specific endpoint. An agent must infer that the path parameters define the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does indicate a non-mutating GET/list operation, but it does not clarify that results are filtered by country despite the tool name, nor does it disclose the response shape, ordering, pagination, or any failure modes. This is minimal behavioral context for a tool with five required inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. The URL placeholder listing is somewhat redundant with the input schema, but it does not hurt clarity. It is appropriately front-loaded with the endpoint and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The five parameters are fully described in the schema, and the tool's purpose as a lookup for defoliation sequences is stated. However, with no output schema and no annotations, the agent is left without guidance on how the return list is structured or how this endpoint differs from the generic rb209_grass_defoliation_sequences tool. Adequate for a simple filterable list, but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters. The tool description adds no new parameter-level meaning beyond restating them in the URL path. This matches the baseline of 3 for a well-covered schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: a list of defoliation sequences for grass fields, and the verb 'list' matches the tool's lookup nature. However, it does not explicitly distinguish this 'by_country' variant from its close siblings rb209_grass_defoliation_sequences and rb209_grass_defoliation_sequence, relying on the name and URL rather than the prose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus the other defoliation sequence tools or how to source the five required IDs. The description simply states what the endpoint returns, with no context about preferred use cases, exclusions, or related lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It does indicate a GET request and a returned list, but it does not disclose output format, whether IDs must already exist, error behavior, or any constraints on the returned values. For a tool with no annotations and no output schema, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence and front-loads the HTTP method and endpoint. It contains no filler, though it is terse enough that the meaning of 'different number of cuts' could be slightly clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema and no output schema, the description gives the core purpose and both required inputs are already documented. However, it does not explain what a 'cut' represents, what the returned list items look like, or how this fits into the broader RB209 workflow, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both parameters as the sward type id and sward management id. The description adds no extra meaning beyond echoing the path template, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource ('PotentialCuts') and an action ('list'), and identifies the target as 'the field' and 'different number of cuts'. It is clear enough to distinguish this from sibling grass tools like yield ranges or sward management lists, though it does not explicitly contrast itself with any particular sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many related RB209 grass tools, nor does it state prerequisites or contexts such as 'use when selecting cutting regimes'. The path and wording imply a lookup, but there is no explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the burden of behavioral disclosure. It only states 'GET' and that the endpoint 'returns' a grass season, adding little behavioral context beyond the operation itself. It does not mention response format, potential errors, or any lookup semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the HTTP method and path, which is useful for an agent. It contains minimal filler, though the phrase 'is used to return' is slightly roundabout and could be tightened to 'Returns the grass season for seasonId.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity single-parameter lookup, the description is minimally adequate: it identifies the endpoint and its purpose. However, with no output schema and no mention of the response contents, an agent cannot fully predict what data will come back or how this lookup differs from the plural rb209_grass_seasons endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter seasonId is already documented as 'The season id' in the schema. The description adds no additional parameter detail, so the baseline of 3 applies because the schema carries the explanatory load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('return'), resource ('grass season'), and exposes the exact endpoint path with the seasonId placeholder. It is clear enough on its own, but it does not distinguish this singular lookup from the sibling rb209_grass_seasons tool, which likely lists multiple seasons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. Given the existence of rb209_grass_seasons and many other grass-related endpoints, the description leaves the selection decision entirely to inference. It provides no context, exclusions, or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says the endpoint returns grass seasons; it does not mention output format, whether the countryId filters results, or any edge cases. The GET method implies read-only, but the description adds almost no behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the HTTP method and path. It is not bloated, but 'This endpoint is used to return grass seasons' could be tightened to 'Returns grass seasons for the given country' without losing anything.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter GET with full schema coverage, the description is barely adequate. However, with no output schema and no annotations, it should clarify that the response is a list of grass seasons and that the countryId is used to scope them; the current description leaves that implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the countryId parameter already documented as 'The country id'. The description adds no additional meaning beyond the schema, but since the schema fully covers the parameter, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb 'return' with a specific resource 'grass seasons', and the endpoint path makes the operation concrete. However, it does not distinguish between this plural endpoint and the sibling rb209_grass_season, nor from measurement_seasons, so the agent gets little help separating it from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this endpoint versus alternatives such as rb209_grass_season or rb209_measurement_seasons. The context is not stated, and no exclusions or alternative conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses a GET operation and the unit conversion, but it does not clearly state whether the response is the converted value, a conversion method, or an error message. This ambiguity matters because 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no unnecessary padding. However, 'The get smn value' is grammatically awkward and slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 annotations, the description leaves the return value ambiguous and omits any example or output format. It is barely adequate for a simple two-parameter endpoint but 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are already documented in the schema with 100% coverage, so the baseline is 3. The description adds the relationship between smnValue and soilLayer through the N/kg-to-kg/ha conversion, but it does not explain how soilLayer is used in the calculation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States an HTTP GET on a specific resource and the unit transformation from N/kg to kg/ha, so the core purpose is recognizable. However, the phrasing is awkward and it does not explicitly distinguish this from related measurement/soil tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus any alternative. The agent must infer the use case from the endpoint name and the unit-conversion hint, with no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden, but it only says the endpoint 'is used to return' an item and exposes the GET verb. It does not disclose whether the result is a single item or list, what the dryMatterSplit true/false difference produces, or any error or edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with the endpoint prefix front-loaded. It avoids fluff, though 'This endpoint is used to return' could be tightened to 'Returns'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read endpoint with no output schema, the description plus schema is minimally sufficient to construct a call. However, it omits the return shape and the significance of the dry-matter split in the response, and it does not route the agent among the many sibling variants.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains both parameters. The description adds no new meaning for organicMaterialTypeId or dryMatterSplit beyond naming them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('return'), resource ('organic material type item'), and input identifiers (organicMaterialTypeId and dryMatterSplit). It is clear enough to know the basic operation, but it does not differentiate this endpoint from closely named siblings such as rb209_organic_material_type_item or rb209_organic_material_types_by_dry_matter_split.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 endpoint versus the closely related sibling tools. The text simply restates the endpoint and its parameters, leaving the agent to infer selection criteria 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it only says the tool 'gets' a result. The GET verb in the path implies read-only behavior, yet there is no mention of output format, error conditions, required context, or limitations—leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. The endpoint path is included, which is useful for invocation, and the purpose statement is brief. It could be phrased more naturally, but it is efficiently compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description should explain what the nutrient deficiency result looks like and under what conditions it is meaningful. It does not, leaving an agent unable to anticipate the response shape or handle likely edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes three of four parameters (nutrientId, nutrientContent, leafSamplingPosition), and the description adds little beyond restating their names in the URL path. cropTypeId lacks a schema description and is not elaborated in the description either, but the parameter names are largely self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('get'), a specific resource ('nutrient deficiency result'), and the basis ('leaf analysis'). It is distinguishable from the sibling calculate_nutrient_offtake tool by the resource it targets, though it does not explicitly call out that difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as rb209_recommendation_calculate_nutrient_offtake or the many lookup tools. The phrase 'based on leaf analysis' implies a context, but no when-to-use/when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It reveals only that this is a GET (read-only) returning a single item; it does not disclose valid value domains for nutrientId or indexId (RB209 indices are a bounded scale), error/not-found behavior, or response shape. Beyond the HTTP method embedded in the endpoint, an agent learns almost nothing about runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with the endpoint front-loaded followed by the scoping clause; there is no filler. The endpoint path redundantly restates parameter names already in the schema, which is mildly redundant but does not detract from readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read endpoint with full schema coverage, the description is nearly viable: an agent can identify the resource and the required keys. However, with no annotations and no output schema, the description leaves the response format, the valid ID value domains, and sibling disambiguation (notably rb209_soil_nutrient_index_id_from_value and rb209_soil_nutrient_indices) unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both parameters have descriptions ('The index id to filter on', 'The nutrient id to filter on') — so the baseline is 3. The description's phrase 'filtered by nutrient id and index id' merely restates the schema; it adds no new meaning about valid ranges or domain semantics (e.g., which nutrientId values map to N/P/K).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource ('Individual nutrient index item') and the two filter keys (nutrient id, index id), with the GET verb implied by the endpoint. The word 'Individual' distinguishes it from the plural list siblings like rb209_soil_nutrient_indices and rb209_soil_nutrient_indexes. However, it does not explicitly disambiguate from rb209_soil_nutrient_index_id_from_value, which also returns a single index item via a different lookup path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description implies the call pattern ('filtered by nutrient id and index id') but never states when this endpoint should be preferred over lookalike siblings such as rb209_soil_nutrient_index_id_from_value or rb209_soil_nutrient_target_index. Given the large sibling group, an agent has no basis for choosing between the alternative single-item lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only restates that this is a GET operation, which implies read-only behavior, but it does not disclose response shape, error behavior, authentication needs, or any other runtime characteristics. With no annotations provided, the description carries the full burden and does not meet it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the exact endpoint, making it easy to parse. The human-readable gloss adds a little clarity, though it is somewhat redundant with the word 'GET' already present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup with three required IDs, the description gives the essential purpose but nothing else. There is no output schema to clarify the return value, and the description does not explain what a nutrient target index is, what values the result can take, or how it differs from related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three ID parameters, so the baseline is 3. The description adds no further meaning about how these IDs relate to the target index or what values are valid, but the schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the HTTP method and resource path, and states that the tool returns the nutrient target index for the given IDs. It is specific enough to know what operation is performed, but it does not explicitly differentiate this from the many similar soil_nutrient_index sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the numerous sibling tools such as rb209_soil_nutrient_indices or rb209_soil_nutrient_index_by_index. There is no mention of intended context, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It reveals the endpoint is a GET and returns categories, but it does not state whether it returns all categories, the response format, or any other behavioral details. This is a significant gap for a tool with 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one clear sentence with the endpoint and purpose. It has a small amount of filler ('This endpoint is used to'), but it is appropriately sized and front-loaded for a simple no-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple, it has no output schema and no annotations, so the description should at least indicate what the response contains and how this call differs from related category/item endpoints. The current description only restates the endpoint purpose without those details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is 100%, so there is nothing for the description to add about parameter semantics. The baseline of 4 applies because no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the HTTP GET method and the resource being returned: organic material categories. It is a specific verb+resource pairing, but it does not explicitly distinguish itself from siblings like rg209_organic_material_category_item or rg209_organic_material_types, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this endpoint versus the many related organic material tools, nor any mention of when not to use it. The caller is left to infer that it lists categories, with no explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It only says 'Calculate' and includes 'GET', which hints at read-only behavior, but it does not describe the response format, units, edge cases, or any restrictions such as the chalk parameter applying only to shallow soils.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the endpoint and immediately states the tool's purpose. There is no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally viable for a simple calculator with fully documented parameters, but it lacks output format details, usage guidance, and behavioral context. Without annotations or an output schema, an agent may know what to call but not fully what to expect in return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a meaningful description. The tool description adds no parameter semantics beyond echoing the parameter names in the URL, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Calculate') and resource ('grass growth class') and names the four input dimensions in the endpoint path. It is clear and distinguishable by name from siblings like rb209_grass_growth_class_by_class, but it does not explicitly call out the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as rb209_grass_growth_class_by_class or rb209_grass_growth_classes. The phrase 'for a grassland field' implies context but does not explain selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys only that this is a GET operation; it does not state read-only behavior explicitly, nor mention authentication, error cases, or what happens for invalid/nonexistent IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, dense line conveys endpoint, operation, and resource meaning with no filler. The important id-based lookup behavior is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter fetch-by-ID tool, the description is minimally viable: it identifies the resource and lookup key. But with no annotations and no output schema, it leaves gaps around expected response shape, error behavior, and the source of valid incorporationMethodId values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate, but it mostly restates the parameter name: 'based on incorporation method id.' It adds no guidance on where to obtain the ID, allowed values, or relationships to other incorporation-method endpoints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the HTTP verb, the resource path, and explicitly says it returns a single 'item based on incorporation method id.' The singular 'item' distinguishes it from related plural/list sibling tools, though it does not name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: this is a GET-by-id endpoint and should be used when an incorporationMethodId is already known. However, it offers no explicit guidance about when not to use it, no reference to sibling list/by-type endpoints, and no source for obtaining valid IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral context. It reveals only that the endpoint 'return[s]' types; it does not state whether the endpoint is deprecated, read-only, paginated, or subject to access requirements. The unusual phrasing 'used to return' introduces uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with the endpoint path front-loaded. Every word contributes; there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an endpoint with no output schema and no annotations, the description should explain what the returned data represents and whether this is the full list or a subset. It does not clarify the ambiguity of 'used to return' or distinguish this from closely related sibling tools, leaving an agent uncertain about its current usefulness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema is empty, so the baseline is high. The description clarifies the output resource (organic material types) even though no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('return') and resource ('organic material types'), and identifies the endpoint path. It does not distinguish this from the many sibling organic material type endpoints, but the core purpose is understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this endpoint versus alternatives such as rb209_organic_material_types_by_category or rb209_organic_material_types_by_dry_matter_split. The phrase 'used to return' is ambiguous and does not clarify current availability or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the HTTP verb and filter semantics. It does not mention auth requirements, response shape, error behavior, rate limits, or any caveats about how the nutrient index item is computed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence containing the endpoint path and the essential filtering behavior. There is no filler or redundant elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The endpoint is simple and all parameters are documented, but the description omits how this endpoint differs from its close sibling, what a successful response contains, and any behavioral caveats. With no output schema or annotations, the agent is left with only the bare mechanics of the request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no new meaning beyond restating the filter names and does not clarify relationships, allowed values, or units beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb (GET) and a specific resource ('Individual nutrient index item') and lists the three filters used to select it. It does not explicitly differentiate itself from the very similar sibling rb209_soil_nutrient_index_by_value_methodology_country, so it falls just 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this endpoint versus near-identical siblings such as rb209_soil_nutrient_index_by_value_methodology_country or rb209_soil_nutrient_index_by_index. There are no use cases, exclusions, or alternative-selection hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It reveals that this is a GET-style operation returning all advice notes, but it does not disclose response shape, ordering, pagination, authentication requirements, or any side effects. This is thin coverage for a tool with 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact line, front-loads the endpoint, and adds a plain-language gloss. Every part earns its place; there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list endpoint, the description is minimally viable: it names the resource and the fact that it returns the full list. However, there is no output schema and no guidance on how the returned items relate to sibling tools, so an agent does not know what fields or identifiers to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is trivially 100% and the description cannot add parameter-level meaning. Per the baseline for no-parameter tools, this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource ('AdviceNote/AdviceNotes') and states that it returns 'the full list of available advice notes,' so the core purpose is clear. It does not explicitly differentiate itself from sibling collection tools, but 'full list' and the endpoint resource make it distinguishable from singular/detail tools like rb209_advice_note or rb209_advice_note_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, and no mention of related tools such as rb209_advice_note or rb209_advice_note_text for retrieving details. 'The full list' implies selection for enumeration, but that is left to inference rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full behavioral burden. It only restates the GET endpoint and the ID filter; it does not disclose response shape, cardinality beyond 'Individual', error behavior, or any side effects. The GET method is implicit but never explained as read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the endpoint and purpose. It is efficient, though 'potato variety' is repeated and the parenthetical is slightly awkward.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter GET look-up, the description is mostly adequate, but with no output schema it should say more about what the response contains. The crop-context note is useful, yet the absence of annotations and return-value information leaves an agent with limited guidance beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents potatoVarietyId with 100% coverage, and the description adds no new parameter detail beyond identifying it as the filter. The 'only required for arable potato crops' note is contextual rather than parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as fetching an individual potato variety filtered by potatoVarietyId, and the singular wording distinguishes it from the plural listing siblings in the tool set. It does not explicitly name the sibling alternatives, but the resource and filter are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives one contextual condition — this look-up is only required for arable potato crops — but does not explain when to choose this tool over rb209_arable_potato_varieties or rb209_arable_potato_varieties_by_group, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It conveys that this is a read-only GET operation returning the site class for the given ID, which is minimal but adequate for a simple lookup. It does not mention error behavior or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with the HTTP method and resource path front-loaded. It is appropriately sized, though the phrasing 'Site class of site class id provided' is slightly redundant with the endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter GET lookup with no output schema, the description is nearly sufficient. However, it leaves undefined what a site class represents, what a successful response looks like, and how invalid IDs are handled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter is self-evidently the ID used to fetch the site class. The description adds no semantic detail beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: GET a site class by siteClassId. This differentiates it from list-style siblings like rb209_field_site_classes, though it does not explicitly distinguish itself from rb209_field_site_class_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many related sibling tools, such as rb209_field_site_classes or rb209_field_site_class_item. The description provides no context about the domain or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does convey that the tool is deprecated and returns a list, which implies a read-only operation. However, it does not explain response format, error behavior, or consequences of invalid parameter combinations, which could matter for an API endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence containing the endpoint, deprecated status, and a concise explanation of the return value. It is compact and readable, though the full URL template is somewhat redundant with the schema parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple listing endpoint but leaves gaps. It does not define what a defoliation sequence is, what the response structure looks like, or which alternative tool should be used given the deprecation. The presence of similar sibling tools makes this lack of context more impactful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all four parameters. The description adds no extra meaning about the parameters beyond embedding them in the URL, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (defoliation sequences for grass fields) and the operation (GET/list). The endpoint pattern and 'Deprecated' marker add specificity, though it does not explicitly distinguish itself from the similar sibling rb209_grass_defoliation_sequence or rb209_grass_defoliation_sequences_by_country.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. The word 'Deprecated' signals the tool may be outdated, but no alternative is offered, leaving the agent to guess whether to use rb209_grass_defoliation_sequence or rb209_grass_defoliation_sequences_by_country instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does convey a read-only GET/list operation, which is useful, but it omits details such as return shape, pagination, authentication, or not-found behavior. The read-only nature is somewhat transparent due to 'GET' and 'list'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the HTTP method and resource. It wastes little space, though 'Grass history list of grass fields' is slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list endpoint this is minimally adequate, but the description does not clarify what a grass history contains, whether results are complete/paginated, or how it differs from rb209_grass_history. The absence of an output schema makes this a noticeable but not critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'countryId' parameter is already described as a filter. The description repeats the path parameter but adds no semantic value beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('GET') and resource ('Grass history list of grass fields') and encodes the filtering endpoint. It is clear enough about what the tool lists, though it doesn't explicitly differentiate itself from the singular rb209_grass_history sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over the many grass-related siblings, and no alternatives or exclusion criteria are mentioned. The endpoint path implies a country filter, but the description leaves selection context entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses a GET operation that returns an item, implying read-only behavior, but it does not describe response shape, error behavior for invalid IDs, or whether additional fields are included. This is acceptable for a simple lookup but leaves edge cases undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the HTTP method and endpoint path before stating the purpose. There is no redundant elaboration, and every element serves a clear function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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, the description does not clarify what a 'category item' contains or how it differs from the plural 'categories' sibling. It is too terse to fully support correct invocation and result interpretation, especially given the large sibling tool list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter with 100% coverage, so the description adds no new meaning beyond the schema. The endpoint URL repeats the placeholder but does not add format, constraints, or usage nuance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('return') and resource ('organic material category item'), and the endpoint path makes clear this is a GET for a single item by ID. However, it does not explicitly contrast with sibling tools like rb209_organic_material_categories, so differentiation relies on the singular 'item' wording rather than explicit naming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the endpoint does but provides no guidance on when to choose it over alternatives. It does not mention conditions, prerequisites, or related siblings such as rb209_organic_material_categories or rb209_organic_material_type_item, leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does disclose the HTTP method GET, implying a read-only operation, and says the list is filtered to 'available' methodologies. However, it does not describe response structure, error behavior, or how IDs are resolved, so transparency is only partially covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with the endpoint path front-loaded. It is easy to scan, though the word 'filtered' appears twice in a slightly redundant way. Overall it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup endpoint, the description names the result type and the two required parameters. However, there is no output schema, and the description does not explain what fields a methodology object contains or how this list relates to the many sibling soil tools. The absence of output schema raises the burden, so the description is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters as filters. The description repeats that filtering is by nutrient id and country id but adds no additional meaning beyond the schema, which earnse a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a GET operation returning a filtered list of soil methodologies, filtered by nutrient and country id. It states the specific verb, resource, and scope. It does not explicitly contrast with the singular rb209_soil_methodology sibling, but the plural 'methodologies' and endpoint path make the distinction reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but gives no guidance about when to choose it over alternatives such as rb209_soil_methodology or the various soil nutrient index tools. There are no when-to-use or when-not-to-use cues, and the many sibling tools make this omission more significant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does communicate that this is a GET (read-only) operation returning an 'Individual' methodology, which is useful. However, it does not mention possible error conditions, authentication needs, output shape, or how the selected methodology relates to other soil data, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that immediately surfaces the HTTP method and endpoint path. The filtering clause is slightly redundant with the schema, but the overall structure is efficient and front-loaded with the most identifying information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter GET endpoint, the description is minimally viable and the schema covers all parameters. However, there is no output schema, no mention of return format, and no context about where methodology IDs come from or what distinguishes this from rb209_soil_methodologies. Given the low complexity, a score of 3 reflects that it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both nutrientId and methodologyId described as filter ids. The description largely repeats this information ('filtered by nutrient id and methodology id') without adding extra meaning such as value sources, valid ranges, or relationships. Baseline 3 is appropriate because the schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair: 'GET /api/Soil/Methodology/{nutrientId}/{methodologyId}' and identifies it as an 'Individual soil methodology' endpoint. It also signals filtering by two IDs. However, it does not explicitly distinguish itself from the sibling rb209_soil_methodologies tool or define what a methodology is, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool instead of alternatives such as rb209_soil_methodologies. The description merely restates the endpoint and filtering behavior, leaving the agent to infer usage context from the name and path. No exclusions, prerequisites, or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The 'GET' prefix and 'Get the list' wording signal a read-only lookup, which is useful because no annotations are provided. However, the description does not disclose response format, pagination, error behavior, or any domain-specific caveats about available PSC values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with the endpoint front-loaded and no filler. It is concise and immediately communicates the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list lookup, the description is mostly adequate, and the endpoint plus schema cover the basic invocation. However, the unexplained 'PSC' acronym and the absence of any output schema or return-value description leave an agent uncertain about the exact shape and meaning of the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are at least present in the schema, but their descriptions are tautological ('The value of pIndexId', 'The value of crop group id'). The tool description adds minimal contextual meaning by tying PSC to a crop group and pIndex, but it does not enrich parameter semantics beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get the list'), the resource ('PSC'), and the selection context ('selected crop group'). It is distinguished from obvious lookup tools by its specific resource name, though 'PSC' is never expanded and no explicit sibling differentiation is given.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no exclusions, and no stated prerequisites. The need for cropGroupId and pIndexId is implied by the endpoint and schema, but the description itself does not explain the decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a GET operation and a full list result, but does not mention whether the response is paginated, the structure of the returned soil type objects, or any other side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the endpoint and immediately conveys the core purpose. There is no redundant or extraneous wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list endpoint, the description adequately names what is returned, but it does not describe the return value structure since no output schema exists. The missing guidance on when to use this vs. the singular soil_type tool also leaves a small completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing for the description to add about parameter meaning. The baseline score of 4 for a zero-parameter tool is appropriate, and the description does not need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning the full list of available soil types, with the resource named explicitly. It distinguishes itself from the singular sibling rb209_soil_type by stating 'full list', though it does not name the alternative directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as rb209_soil_type or other soil-related endpoints. The description only states what the tool returns, leaving the agent to infer when it should be selected based on the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It does reveal a read-only GET that returns 'text' for a specific note, but it says nothing about response format, errors, or what happens when no note matches.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence front-loads the exact endpoint and then states the scoping parameters. There is no filler or duplication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-parameter GET with no output schema, so the description's mention of 'advice note text' partially covers the return. It still leaves the exact response shape and lookup failure behavior unspecified, and the lack of output schema increases the need for those details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains countryId and adviceNoteCode. The description only paraphrases that pairing, adding no extra constraints, formats, or default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete operation ('GET ... AdviceNoteText') and identifies the resource as 'individual advice note text' filtered by country ID and advice note code. It does not explicitly differentiate from siblings like rb209_advice_note or rb209_advice_note_advice_notes, though 'individual' hints at a single-text lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 rather than the sibling advice-note tools, and no workflow context such as needing to look up an advice note code first. The only implied usage is that two identifiers are required, which is also visible in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it is a GET operation but adds little behavioral context beyond that — no mention of return structure, units, error behavior, or what 'default yield data' contains. This is thin for a tool with no annotation safety net.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the endpoint and purpose with no filler. Every word contributes to identifying the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter GET tool, and the description plus schema cover the basics needed to invoke it. However, with no output schema, the description could have clarified what the returned default yield data looks like or how it relates to crop types, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the sole parameter countryId is already described as 'Country id to filter on'. The description only restates the parameter in the URL path and does not add extra meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), resource ('default yield data'), and scope ('for the crops'), plus the endpoint path. It is distinguishable from sibling tools like grass yield ranges because it clearly targets arable default yields, though it does not explicitly name a sibling it is not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description and 'countryId' parameter imply usage: call this when you need default yield data for a country. However, it does not state when not to use it or mention alternatives, leaving the agent to infer the appropriate context from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It identifies this as a POST request-access action but does not explain side effects, authentication requirements, approval process, response behavior, or whether calling it multiple times has different effects. The behavioral surface is opaque beyond the endpoint itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that conveys the HTTP method, endpoint, and purpose with no filler. Every part of the sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool with one optional parameter and no output schema. The description is minimally viable, but it lacks any note about the relationship to the latest-prices endpoint or what a successful access request returns. Given the simple shape, this is acceptable but not strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of the single body parameter, including a description for 'reason'. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Request access') and a specific resource ('fertiliser latest prices endpoint'), and includes the HTTP method and endpoint path. This makes the tool's purpose immediately clear and distinct from the sibling rb209_fertiliser_prices_latest_prices, which is about retrieving prices rather than requesting access to them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, whether it is a prerequisite for rb209_fertiliser_prices_latest_prices, or what conditions should trigger an access request. It does not mention alternatives or exclusions, leaving the agent to infer the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose that this is a read-only GET operation and that it returns the full list, which suggests no pagination. However, it does not mention output shape, authentication needs, error behavior, or what fields each growth class contains. This is minimal but acceptable disclosure for a simple reference-list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the HTTP verb and endpoint before stating the purpose. There is no filler or redundant information; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list endpoint, this is adequate: it names the endpoint, the parameter, and the returned resource. However, with no output schema, it does not describe the structure of the returned grass growth classes, and it does not point to where valid countryId values can be obtained. These gaps prevent a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with countryId already described as 'The Country ID to filter on'. The description adds that the ID is used in the URL path, but provides no example values, no valid country ID source, and no additional semantics beyond the schema. A baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the endpoint and resource: a full list of grass growth classes for a country. It uses a specific verb ('GET') and states the domain ('grassland fields'). It does not explicitly distinguish itself from sibling tools like rb209_grass_growth_class_by_class or rb209_grass_growth_class_by_soil_type_rainfall_altitude_chalk, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the many related grass growth class tools in the sibling list. 'Full list' faintly implies this is the general list endpoint, but there is no explicit when-to-use, when-not-to-use, or alternative routing. The agent must infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the safety and behavior burden. It only restates the GET semantics and output as 'text'; it does not disclose error behavior, response wrapping, or side-effect/read-only guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one front-loaded sentence that conveys method, resource, and return content with no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup, the description is minimally adequate: it names the input and says the output is text. However, with no output schema or annotations, it leaves the exact response shape and failure behavior unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains swardTypeId as the field's Sward Type Id. The description adds no new semantic detail beyond 'provided sward type id,' so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact operation ('Get the text of the sward type') and the resource identified by a supplied ID. It is clearly a single-item lookup and implicitly contrasts with the plural sibling rb209_grass_sward_types, though it does not name that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for the provided sward type id' implies the caller needs an existing ID, but the description never says when to choose this over alternatives such as rb209_grass_sward_types or related sward-management lookups. Usage context is present only by implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal that this is a read-only GET returning organic material types, which is useful, but it does not explain what the boolean dry matter split represents, whether results can be empty, or what fields are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary detail. The endpoint path is front-loaded and directly informative, making the definition easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter GET endpoint, the description is close to adequate, but it lacks an explanation of what dryMatterSplit=True versus False returns and does not describe the response shape. Since there is no output schema, this missing context leaves the agent somewhat underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single required boolean parameter, so the baseline is 3. The description adds only 'based on filter' and does not explain the meaning of True/False for dryMatterSplit, leaving the agent to infer semantics from the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the HTTP verb (GET), the resource path, and the action ('return organic material types based on filter'). However, it does not explicitly distinguish this from highly similar siblings such as rb209_organic_material_types_by_category_dry_matter_split or rb209_organic_material_types, so the differentiation is left to the tool name and path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many related organic material endpoints, nor any mention of when not to use it. The intended usage is only implied by the dryMatterSplit segment in the name/path and the vague phrase 'based on filter.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavior. It establishes that this is a read-only GET returning a filtered list, but it does not mention response shape, pagination, availability conditions, or any error behavior, which leaves meaningful gaps for an agent deciding how to invoke it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with the endpoint and filter criteria; no redundant or filler text. Every word contributes to describing the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter list endpoint with full schema coverage, the description is minimally sufficient. However, with no output schema and many closely related sibling tools, it lacks guidance on how this filtered list relates to rb209_soil_nutrient_indexes or the by-value/by-index variants, so the agent may still need to inspect those tools to choose correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description merely restates the filter-by-IDs idea without adding format, range, or relationship details, which meets the baseline but adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the HTTP verb and resource ('GET /api/Soil/NutrientIndices/...') and states that it returns a filtered list of nutrient indexes filtered by three specific IDs. This is specific enough to identify the operation, though it does not explicitly contrast with the similarly named sibling rb209_soil_nutrient_indexes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a filtered list of nutrient indexes is needed by nutrient, methodology, and country IDs. However, it offers no explicit when-not-to-use guidance or alternatives, leaving the agent to infer the choice among the many soil nutrient index siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral disclosure burden. It reveals only that this is a GET returning a full list; it does not describe authentication, error behavior, response structure, or any side effects. 'GET' is an endpoint convention rather than a behavioral explanation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the endpoint front-loaded and the purpose stated immediately after the dash. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter GET lookup with no output schema, the description provides the minimally necessary invocation details. However, it omits any context about what NVZ action programs are, why a countryId is needed, or what the list contains, and there is no annotation to fill the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: countryId is documented as 'The value of country id' with integer type. The description merely echoes the placeholder {countryId} in the path, adding no new semantic meaning beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact HTTP verb (GET), the resource path (/api/Soil/NvzActionProgram/{countryId}), and the returned concept ('full list of NVZ action program'). This is specific enough to distinguish it from the many rb209_soil_* sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call this tool versus alternatives, and no exclusions or routing conditions are provided. With dozens of lookup siblings, the agent must infer usage solely 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly identifies the call as a GET and says it returns a list, which signals read-only behavior. However, with no annotations, it does not disclose details such as how results are ordered, whether both IDs must correspond to existing records, or what happens on invalid input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence includes the HTTP method, endpoint path, and return summary with no filler or redundant content. Everything present serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-parameter lookup with no output schema, and the description names the return type. Still, the nature of 'soil ph recommendation level' is vague, and there is no information about cardinality, error behavior, or domain context, making the description adequate but minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description references the parameters only via the URL path and does not add meaning beyond the schema's own descriptions of 'country id' and 'soil type id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('GET') and resource ('SoilPhRecommendation'), plus the return type ('list of soil ph recommendation level'). It is distinguishable from the many sibling RB209 tools by its unique resource, though it does not explicitly contrast itself with any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many related RB209 tools, no use-case context, and no exclusions. An agent can only infer usage from the endpoint name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does disclose that this is a GET request (implying read-only) and that it returns an individual record, but it does not mention possible 404 behavior, authentication requirements, response shape, or any error semantics. For a simple read endpoint this is moderately transparent but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, and it front-loads the endpoint path before the semantic description. It is appropriately sized for a simple two-parameter GET tool, though it partly repeats information already present in the tool name and schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity: two required integer parameters, no output schema, and no nested objects. The description identifies the resource and both filter IDs, which is sufficient for basic invocation. However, since there is no output schema, an agent is left without any indication of what fields or structure the returned 'crop info 1' contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both cropTypeId and cropInfo1Id already documented as 'The ... id to filter on.' The description only restates this filtering relationship and adds no new meaning about parameter formats, ranges, or how the IDs relate to each other. Baseline 3 applies because the schema already covers the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the HTTP verb and resource ('GET /api/Arable/CropInfo1/{cropTypeId}/{cropInfo1Id}') and states that it returns an individual crop info 1 record filtered by two IDs. This distinguishes it from sibling list tools like rb209_arable_crop_info1s and rb209_arable_crop_info1s_by_type, though it stops short of explicitly naming those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Individual crop info 1' and 'filtered by crop type id and crop info 1 id' implies this tool is for fetching a single record when both IDs are known. However, it does not explicitly describe when to choose this tool over the plural or by-type sibling endpoints, so the guidance remains implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it does convey that this is a read-only GET returning an unfiltered list. However, it does not mention response shape, ordering, pagination, or any other runtime behavior, leaving the agent mostly dependent on the endpoint name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that pairs the endpoint with a short gloss. Every word earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list endpoint, this is minimally serviceable: it names the endpoint and what kind of list is returned. But with no output schema, it does not explain what a 'crop info 1' contains, leaving the agent uncertain about how to interpret the response or whether this endpoint is the right one among many crop-related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing for the description to document. The baseline of 4 applies because no parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('GET /api/Arable/CropInfo1s') and clarifies it returns 'the full list,' which distinguishes it from singular or filtered variants like rb209_arable_crop_info1 and rb209_arable_crop_info1s_by_type. However, it does not explicitly name those siblings, and 'crop info 1s' remains domain jargon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this endpoint versus alternatives. The phrase 'full list' implies a contrast with filtered/singular endpoints, but the description never states those cases or names the sibling tools that should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses the HTTP method (GET) and implies a read-only lookup with no side effects, but it does not describe response shape, error behavior, authentication needs, or what happens for an invalid ID.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the endpoint and method. The wording is efficient, though the 'filtered by crop type id' clause is somewhat redundant with the schema parameter description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter GET-by-ID tool, the description provides the essential call context: endpoint, method, and resource. However, with no output schema, it does not describe the returned crop type structure or error behavior, leaving some ambiguity for an agent consuming the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter cropTypeId is documented in the schema. The description only restates that filtering is by crop type id, adding no semantic detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: GET an individual crop type by its ID. It is clear that this tool returns a single resource rather than a list, which partially distinguishes it from plural sibling endpoints, but it does not explicitly name or differentiate those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Individual crop type - filtered by crop type id' implies that this tool should be used when a single crop type is needed by ID. However, there is no explicit guidance about when to prefer this over the plural or grouped crop type endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full disclosure burden. It conveys read-only behavior via 'GET' and the unfiltered response scope via 'full list', which covers the core operation. It does not mention response format, ordering, or pagination, though the zero-parameter, simple-list nature reduces how critical those gaps are.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of roughly a dozen words, front-loaded with the endpoint path, and every word adds value. There is no fluff or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, no nested objects), the essentials are present. However, with no output schema supplied, the description could have said a bit more about what the returned crop types look like, and it leaves the relationship to the singular/by-group siblings entirely implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty with 100% description coverage, so there is no parameter information for the description to add. Per the baseline rule for parameterless tools, a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the HTTP verb, the exact endpoint path, and the resource ('full list of available crop types'), making the operation unambiguous. It distinguishes itself by implication from the filtered rb209_arable_crop_types_by_group and singular rb209_arable_crop_type, though it doesn't name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to select this tool over the many sibling endpoints, particularly rb209_arable_crop_type (singular) and rb209_arable_crop_types_by_group. The phrase 'full list' lightly implies the unfiltered use case, but no exclusion or alternative-routing information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'GET /api/Arable/PotatoVarieties — The full list of available potato varieties'. It does not disclose whether the list is ordered, whether it includes inactive/legacy varieties, whether any authentication is required, or what the output items' shape is. For a read-only reference endpoint with zero annotation support, the description carries the full burden and provides little beyond the endpoint name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that names the endpoint, states what it returns, and adds a scoping qualifier. Every word earns its place; nothing is redundant or missing at a high level.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter lookup endpoint, the description is largely sufficient: an agent can retrieve the full list and knows it is potato-specific. However, the lack of annotations and output schema means the agent does not know what fields each variety will contain, and the sibling relationship to rb209_arable_potato_varieties_by_group is not spelled out. Some practical context is missing but the core operation is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100%. The description appropriately notes the only meaningful condition ('only required for arable potato crops'), which is extra context beyond the empty schema. There are no parameter semantics to explain, so a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('GET') and resource ('the full list of available potato varieties') and adds a scoping note ('only required for arable potato crops'). It does not explicitly distinguish it from the sibling rb209_arable_potato_varieties_by_group, but the 'full list' wording implies the unfiltered version, which is a useful contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: fetch the full list when working with arable potato crops. It does not, however, state when to prefer rb209_arable_potato_varieties_by_group or mention that the latter is the filtered alternative, leaving some routing ambiguity among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden of behavioral disclosure. It does convey that the operation is a read-only GET returning a list of yield ranges filtered by two path IDs. However, it gives no detail on the result structure, ordering, pagination, or error behavior, which matters more 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler; the endpoint contract is front-loaded and a plain-language summary follows. The endpoint prefix is somewhat redundant with the tool name and schema, but it confirms the HTTP contract at negligible cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity two-parameter lookup, the essentials — what it returns and its geographic scope — are present. But since no output schema exists, the description does not compensate by describing the shape of a yield range, and it omits routing context to the closely related England/Wales tool, leaving the agent to infer part of the calling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; both sequenceId and siteClassId are already documented as 'the id ... to filter on.' The description adds no parameter-level meaning beyond echoing the path parameter names, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'GET /api/Grass/YieldRangesScotland/{sequenceId}/{siteClassId} — The list of yield ranges for grass fields in Scotland.' The geographic scope makes it distinguishable from the close sibling rb209_grass_yield_ranges_england_and_wales, though the description never names that alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage signal is the phrase 'for grass fields in Scotland,' which implies the tool is for Scottish grass yield range lookups. There is no explicit guidance on when not to use it, no routing to the England/Wales variant, and no mention of prerequisites such as obtaining a valid sequenceId or siteClassId from the related defoliation/site-class tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the HTTP method (GET) and the list-returning nature, which implies a read-only lookup. However, it does not describe what happens with invalid IDs, whether results are ordered, or any other runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the endpoint, the resource, and the filtering basis. Every element contributes useful information, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter GET endpoint with no output schema, the description is nearly complete: it states the resource and that the result is a filtered list. It could be slightly stronger by pointing to sibling tools for unfiltered lists or related lookups, but nothing essential is missing for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is already documented as an integer filter. The description repeats this same meaning without adding extra context about the parameter's source, constraints, or relationship to other tools. This is the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a GET operation that returns an incorporation method list filtered by organicMaterialTypeId. It names the resource and the filtering parameter, but it does not explicitly differentiate itself from the sibling tool rb209_organic_material_incorporation_methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as rb209_organic_material_incorporation_methods or rb209_organic_material_incorporation_method. The description implies usage through the required parameter but does not state a use case or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does indicate a GET operation that returns data, implying a read-only call. However, it does not clarify the response format, possible deprecation, or whether the endpoint is fully functional, especially given the ambiguous 'used to return' wording.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler and includes the endpoint path upfront. Minor issue: 'used to return' is awkward and should probably be 'is used to return' to remove ambiguity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup, the description covers the endpoint and the filtering intent. But there is no output schema, no description of the returned structure, no sibling routing guidance, and no clarification of the ambiguous tense, leaving the overall completeness slightly short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes organicMaterialCategoryId as an 'Organic material category filter', so the description adds no meaningful extra parameter semantics. It does not explain valid value sources, ranges, or how the ID relates to other category endpoints. Per the baseline for high schema coverage, this is adequate but not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('return'), a resource ('organic material types'), and the filter ('organicMaterialCategoryId'), which clearly matches the tool name. It is distinguishable from siblings like rb209_organic_material_types and rb209_organic_material_types_by_category_dry_matter_split. However, the phrase 'used to return' is ambiguous—it could mean 'is used to return' or imply the endpoint no longer returns anything.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this when you have an organicMaterialCategoryId and want the organic material types for that category. But there is no explicit guidance about when to prefer this over related siblings such as rb209_organic_material_types or rb209_organic_material_types_by_category_dry_matter_split, and no mention of where the category ID comes from.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The GET method and 'Individual advice note text' disclose the primary read-only behavior and the general return content. With no annotations and no output schema, the description does not cover error behavior, exact response format, or assumptions about the code value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the method and path front-loaded and no filler. It is compact and directly communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup, the description is nearly sufficient: it names the endpoint, the method, and the parameter's role. It is incomplete in that it does not differentiate the many advice_note sibling tools or describe the response shape, which matters because there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents adviceNoteCode with 100% coverage, so the description adds little beyond what is structured. Phrases like 'supplied corresponding' reinforce the schema but do not add format, source, or example details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a concrete operation: GET a single advice note text by adviceNoteCode. It is specific about the verb and resource, but it does not distinguish this tool from closely named siblings such as rb209_advice_note_text or rb209_advice_note_advice_notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used when you have an adviceNoteCode and need the corresponding advice note text. However, it gives no explicit when-not guidance or alternatives, which is a gap given the large number of related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses a read-only GET operation and that it returns a list, but it does not describe return fields, ordering, or any other behavioral details. This is acceptable for a simple parameterless reference list but still minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that states the endpoint and the resource in a compact way. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter list endpoint without an output schema, the description is largely complete: it names the endpoint and what it returns. It could have added relationship to the singular or by_type variants, but that is not required for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description need not document parameter behavior. The schema has no properties and the description adds nothing necessary for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a GET endpoint returning the list of sward managements for grass fields. It uses a specific verb and resource, though it does not explicitly contrast itself with sibling tools like rb209_grass_sward_management or rb209_grass_sward_managements_by_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus its siblings. It does not mention alternatives or exclusion criteria, leaving the agent to infer that this is the general list endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does indicate a read-only GET operation and that the result is a list of sward types, which is basic transparency for a zero-parameter lookup tool. However, it does not clarify the shape of the response or any country/field-type constraints on which sward types are 'available.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single tightly written sentence with the HTTP method and resource front-loaded before the semantic explanation. Every part contributes useful information, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter list endpoint, the description is nearly complete: it says what the response is (a list), from which domain (grass fields), and what resource (sward types). There is no output schema, so a bit more detail about returned fields could help, but the absence of parameters and the straightforward nature keep this from being a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so the description has no parameter burden. The baseline for zero-parameter tools is 4, and the description does not need to add parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a GET endpoint returning 'the list of different sward types available for grass fields,' so the verb, resource, and scope are all present. It does not explicitly contrast with the singular sibling 'rb209_grass_sward_type', though the plural 'list' strongly implies the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like rb209_grass_sward_type or rb209_grass_sward_managements_by_type. The description implies it is for retrieving available sward types for grass fields, but it never states exclusions or directs the agent to a more specific endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says the endpoint calculates an SNS index, with no mention of side effects, prerequisites, conditional input combinations, or response behavior. The word 'calculate' implies computation, but the description gives almost no operational detail beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the method, endpoint, purpose, and geographic scope front-loaded. There is no filler. The endpoint path partially repeats the tool name, but the sentence remains tight and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single required nested body with multiple conditional sub-objects and no output schema, making the one-sentence description insufficient. The description does not explain the step-based workflow, when each input variant is relevant, or what the endpoint returns. The rich schema covers parameter details but not the overall invocation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and every parameter has a detailed description including units, ranges, and conditional rules. The tool description itself adds no parameter-level meaning, so the baseline 3 applies. The schema already carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'calculate', the resource 'sns index', and the method 'measurement method'. The geographic qualifier 'in England & Wales' distinguishes it from the sibling rb209_measurement_scotland_measurement_method, so an agent can tell them apart without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear geographic context by explicitly limiting the tool to England & Wales, which implies the Scotland variant is not the right choice. However, it does not name that alternative or state when to prefer this tool over the other measurement-related sibling tools. This is clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the operation is a read-only GET and that it returns the full set, but it does not mention authentication requirements, response format, sorting, or whether pagination applies. For a simple zero-parameter lookup this is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence that front-loads the endpoint and immediately conveys the purpose. Every word earns its place; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list endpoint with no output schema, the description is mostly sufficient: it tells the agent what resource is accessed and that all seasons are returned. However, it does not describe what a season looks like or how the result can be used, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, which earns a baseline of 4. The description does not need to explain parameter semantics because there are none to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the HTTP verb and resource ('GET /api/Measurement/Seasons') and states that it returns a full list of available seasons. It is clear about what the tool does, though it does not explicitly distinguish itself from related sibling endpoints like rb209_grass_seasons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus other season-related endpoints. The description is only a statement of function, with no mention of alternatives, exclusions, or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose that the operation is a GET request and returns a list, implying a safe read-only action. However, it does not describe response format, whether the list is exhaustive, or any other behavioral details, though these are less critical for a zero-parameter list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the endpoint and immediately states what the resource represents. There is no wasted text or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema GET list endpoint, the description provides sufficient context: it identifies the HTTP method, the path, and the resource being listed. It could mention what the list items represent or that no filtering is available, but this is a minor omission for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The schema is empty and the description does not need to explain parameters. Nothing meaningful is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: it returns a list of organic material incorporation methods via a GET endpoint. It is specific enough to identify the tool's function, though it does not explicitly differentiate itself from sibling tools like the singular incorporation_method or the by_type filter variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many related sibling tools, such as rb209_organic_material_incorporation_method or rb209_organic_material_incorporation_methods_by_type. There is no mention of intended use cases, filtering conditions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does state the HTTP method GET, which implies a safe, read-only operation, but it does not describe response format, error behavior, or authentication requirements. For a simple lookup this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence and front-loads the endpoint path, which is useful. Minor redundancy exists in 'This endpoint is used to return' where a direct 'Returns' would be tighter, but there is no wasted fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter GET-by-ID lookup with no nested objects and no output schema, the description plus schema is adequate to invoke the tool. It clearly identifies the resource and the input, though it omits any details about response shape or possible error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter fully with 100% coverage, including its type and description. The description only repeats the ID concept in the endpoint path and adds no additional semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('return') and resource (organic material type) keyed by an ID, making it a specific single-item lookup. It is distinguishable from sibling list endpoints like rb209_organic_material_types, though it does not explicitly name or contrast siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use this when you need one organic material type by its ID. There is no explicit guidance about when not to use it or which sibling endpoint to prefer for listing or filtering, so the agent must infer usage from the endpoint pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the GET endpoint and the id filter; it does not disclose response format, error behavior, authentication requirements, or what happens when the id does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the HTTP method and resource path. There is no wasted wording, and the filtering constraint is stated directly after the resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter GET-by-id tool, the description is minimally adequate. However, with no output schema and no annotation context, it does not explain what the returned 'previous grass' object contains or how the id relates to the plural endpoint, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents previousGrassId as an integer used to filter. The description merely repeats this filter concept without adding new semantic detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the HTTP verb (GET), the exact resource ('Individual previous grass'), and the filter mechanism (by previous grass id). It clearly distinguishes this singular lookup tool from its plural sibling rb209_previous_cropping_previous_grasses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Individual previous grass - filtered by previous grass id' implies this tool is for retrieving a single record when the id is known. However, it does not explicitly state when to prefer this over the plural list endpoint or mention any alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavior disclosure and states the operation's output as average rainfall for the year. It does not mention return format, units, data source, or error behavior, but for a simple read-only lookup the core behavior is reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no redundant words. It states the resource and its output efficiently, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the single parameter is fully schema-documented, but there is no output schema and the description omits units and return format. It also does not point to seasonal siblings, so the annual-versus-seasonal distinction is only implied, not explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the postcode parameter with its first-half format at 100% coverage, so the description does not need to repeat it. The description only adds 'of the field' as contextual framing, which does not meaningfully expand parameter knowledge beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the endpoint and defines its output as 'average rainfall of the field across the whole year,' clearly conveying an annual rainfall lookup. The 'whole year' qualifier distinguishes it from the summer/winter rainfall siblings, though it lacks an explicit verb like 'retrieves.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The annual scope implies when this tool should be used, but it never explicitly mentions seasonal alternatives such as rb209_rainfall_summer_rainfall_average or rb209_rainfall_winter_rainfall_average. No exclusion conditions are stated, so an agent must infer the selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is a GET request and therefore read-only, and it explains what data is returned (average rainfall for winter months). However, with no annotations and no mention of response format, units, or field-specific context, some behavioral details are left unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It includes the HTTP method, endpoint, and semantic outcome efficiently, exactly covering what an agent needs to understand the tool quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter GET endpoint, the description is adequate but not fully complete. It does not clarify what 'field' refers to, what units the rainfall is in, or the response structure, though these may be less critical given the schema and the tool's simple nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single postcode parameter, including an example format. The description only echoes the postcode in the URL path and adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (GET), a specific resource (WinterRainfallAverage/{postcode}), and the outcome (average rainfall during October-March). The explicit mention of winter months distinguishes it from the sibling summer rainfall tool and the general rainfall average tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as rb209_rainfall_summer_rainfall_average or rb209_rainfall_average. The usage is only implied by the tool name and the winter month range, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It clearly signals a read-only operation via 'GET' and a 'full list' with no hidden filtering, but it does not describe output shape, ordering, or any response caveats. It is not misleading, but adds only minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact, front-loaded sentence conveys the endpoint, action, scope, and completeness. No filler; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list endpoint the description is mostly sufficient, but with no output schema and no annotations it stops short of describing what an advice note entry contains or how the list is presented. An agent can call it safely, but may still be uncertain about the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage, so there are no parameter semantics for the description to clarify. Per the zero-parameter baseline, this is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (GET) and resource (the full list of advice notes), and scopes it to England and Wales grass, which separates it from arable and Scottish variants in the sibling list. It does not explicitly name or disambiguate adjacent list endpoints like rb209_advice_note_advice_notes, but the scope is clear enough for most selections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The geographic and crop scope ('England and Wales grass') implies when to use it, and the word 'full list' implies no filtering, but there is no explicit statement about alternatives or a 'use this instead of...' condition. The guidance is present only by inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden; it does disclose that this is a GET (read-only) operation returning a filtered list. It does not cover error cases, response shape, or whether missing data is handled, but for a simple one-parameter read endpoint the stated behavior is a reasonable baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with a leading HTTP method and path, followed by a plain-language summary. There is no padding or redundant restating of the parameter description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter endpoint with no output schema, the description tells the agent what the endpoint returns (a filtered list) and the filter key. It does not explain the domain meaning of 'crop info 1s' or return format, but given the tool's simplicity this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the cropTypeId parameter already has a clear description in the schema. The tool description only repeats 'filtered by crop type id' without adding format, source, or behavior details for the parameter, so the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: GET /api/Arable/CropInfo1s/{cropTypeId}, and says it returns a filtered list. It does not explicitly compare against sibling endpoints like rb209_arable_crop_info1s or rb209_arable_crop_info1, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving crop info 1s filtered by a crop type id, which is a usage cue. However, it does not state when to prefer this over related crop-info siblings or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description itself must convey behavior. It states that this is a filtered GET list, implying a read-only operation, but it does not disclose return structure, empty-list behavior, or error handling for invalid potatoGroupId values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence that front-loads the endpoint and core purpose. Every part contributes: 'GET', 'filtered list', 'filtered by potato group id', and the arable-crop qualifier. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter GET endpoint with no output schema, the description is reasonably complete: it specifies the resource, the filter parameter, and the domain context. It does not describe the shape of the returned variety list, but the complexity is low enough that this is a minor gap rather than a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents potatoGroupId as 'The potato group id to filter on.' The description adds the context that filtering is by potato group id and is only for arable potato crops, but it does not add significant new parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as a GET that returns a list of potato varieties filtered by potatoGroupId. It distinguishes itself from rb209_arable_potato_varieties through the explicit 'filtered by potato group id' wording, though it does not name that sibling directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'only required for arable potato crops' provides some usage context, implying this endpoint is relevant only in arable potato scenarios. However, it does not explicitly contrast with rb209_arable_potato_varieties or state when to use the unfiltered alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description exposes the HTTP method 'GET', which signals a read-only operation. However, no annotations exist and the description provides no further behavioral context such as authentication needs, access restrictions, response format, or units/currency of the returned prices.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that includes both the endpoint and the purpose. There is no filler or redundant content beyond the slight repetition of 'GET' and 'Get'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the only source of information about what the tool returns, yet it only says 'latest prices of fertilisers'. It omits what fertiliser types are covered, units, currency, freshness, and whether access must first be arranged via the sibling request_access tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the schema coverage is 100%, so the schema carries the full parameter story. The baseline for a parameterless tool is 4, and the description correctly does not invent parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get') and a specific resource ('latest prices of fertilisers'), and includes the exact API endpoint. This is enough to distinguish it from the sibling rb209_fertiliser_prices_request_access and the many unrelated RB209 lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to call this tool versus related alternatives. In particular, the closely related sibling rb209_fertiliser_prices_request_access is not referenced, and no mention is made of access prerequisites or conditions for using this endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It communicates GET/read-only semantics and filtering, but does not disclose response shape, empty-result behavior, or any further endpoint behavior. It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the endpoint before giving the business context and output. It avoids unnecessary fluff, though the raw URL path is somewhat redundant with the input schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list endpoint with no output schema or annotations, the description gives enough to understand the general result: a filtered list of second crop types. It does not explain response item structure or how the parameters interrelate, but the endpoint is low-complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented. The description itself adds little beyond the endpoint path and the general notion of filtering, so it meets the baseline without adding extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a GET resource and states that it returns a filtered list of second crop types after a first crop. It is specific enough to separate it from generic crop-type list endpoints, but it does not explicitly differentiate it from sibling tools by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Some crops allow a second crop to be sown in the same crop year' provides a clear context for when this endpoint is relevant. It does not mention alternatives or exclusions, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The GET method and 'text' outcome signal a read-only lookup, which is useful, but the description does not disclose response shape, error behavior, or access constraints. It is minimally adequate for a simple fetch but lacks deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that front-loads the endpoint and core operation. There is no filler or redundant structural baggage; 'corresponding' is mildly repetitive but harmless.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool: one required integer parameter, no nested objects, and no output schema. The description states what is returned ('text') and how it is filtered, which is sufficient for an agent to invoke it correctly. It could mention more about the response, but the simplicity lowers the bar.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the property description already states 'The grass growth class id to filter on.' The tool description essentially repeats the same filtering semantics with 'filtered from the supplied corresponding grass growth class id,' adding no meaningful new parameter insight. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the GET verb and names the exact resource: 'Individual grass growth class (GGC) text'. It also identifies the selector, grassGrowthClassId, clearly distinguishing this single-item lookup from plural collection tools and from the soil/rainfall/altitude filtering sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives like rb209_grass_growth_classes or rb209_grass_growth_class_by_soil_type_rainfall_altitude_chalk. The 'by id' phrasing implies usage, but the description never states when this is the right choice or when another sibling should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that the tool is a POST endpoint that calculates a residue group, which implies a non-destructive computation. However, it does not mention response behavior, error conditions, or whether any data is persisted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It front-loads the endpoint, HTTP method, and core purpose, making it immediately scannable and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 explain what the tool returns, but it only says it 'calculates residue group'. It also omits preconditions, units of the result, and behavior when optional parameters are omitted, leaving important context missing for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'smnDepth' and 'measuredSmn' clearly documented in the schema. The tool description adds no parameter-level detail beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'calculate', the resource 'residue group', and the scope 'using SMN measurement values in Scotland'. It also provides the explicit HTTP method and endpoint path, making the tool's function unambiguous and distinct from sibling measurement tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in Scotland' implies this endpoint is for Scottish SMN measurement calculations, giving the agent some regional context. However, it does not explicitly state when to prefer this tool over alternatives like rb209_measurement_method or rb209_measurement_smn_conversion_method, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It communicates that this is a GET read operation returning organic material types, which is useful. But it does not describe response format, how the dryMatterSplit boolean affects the result set, or any error/pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with no filler; the endpoint path is front-loaded and the purpose follows immediately. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter GET lookup, the description plus full schema coverage is adequate to understand invocation. It lacks detail about the return shape, but the tool's purpose is straightforward and no output schema exists to supplement it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already described ('True/False' and 'Organic material category filter'). The description only restates these parameters in the endpoint path and prose without adding new semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('return organic material types') and identifies the resource via the endpoint path and both filter parameters. It is clear what the tool does, though it does not explicitly contrast itself with sibling tools like organic_material_types_by_category or organic_material_types_by_dry_matter_split.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by saying it returns types 'for provided organicMaterialCategoryId and dryMatterSplit,' which gives the input condition. However, it offers no explicit guidance about when to prefer this endpoint over related sibling endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does disclose that this is a GET request and a singular 'individual item' lookup, signaling a read-only operation with a single result. It does not describe return structure, not-found behavior, or error semantics, but for a simple lookup the disclosed method and arity provide moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with the endpoint path front-loaded and the result type stated immediately after the dash. There is no filler, repetition, or unnecessary explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple four-parameter GET endpoint, the path template plus fully documented schema makes invocation fairly straightforward. However, there is no output schema and no description of what the returned 'nutrient index item' actually contains, and no guidance on choosing among the many similar sibling tools, so the definition has meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by showing the URL path template, which clarifies that all four parameters are path segments in a specific order — meaning not available from the JSON schema alone. It otherwise repeats the parameter names rather than adding deeper semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states an explicit verb and resource ('GET /api/Soil/NutrientIndex/... Individual nutrient index item') and lists all four filter dimensions, including countryId, which distinguishes it from the similar sibling rb209_soil_nutrient_index_by_value_methodology. It does not explicitly name a sibling alternative, but the resource and filters are specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'filtered by nutrient id, nutrient value, methodology id and country Id' implies when to use this tool: when the caller has all four identifiers and needs a single index item. However, it gives no explicit guidance on when not to use it or which sibling tool should be chosen instead, which is a real gap given the large set of soil-nutrient siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the HTTP method 'GET' in the description signals a read-only operation, which is useful behavioral context. However, the description does not disclose potential error cases, authentication requirements, or any other behavior beyond a straightforward fetch. For a simple GET endpoint, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that includes the endpoint, the HTTP method, and the tool's purpose. There is no wasted text or redundant elaboration, making it easy for an agent to quickly parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only lookup tool without an output schema, the description is sufficiently complete. It tells the agent exactly what resource to fetch and how to filter it. The absence of response format details is a minor gap, but the phrase 'Individual soil type' conveys the expected result reasonably well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because the only parameter, soilTypeId, is described as 'The soil type id to filter on'. The description adds little beyond the schema, but it does reinforce the filtering semantics by saying 'filtered by soil type id'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific HTTP verb and resource ('GET /api/Soil/SoilType/{soilTypeId}') and clearly identifies what the tool does: returns an individual soil type filtered by id. The word 'Individual' helps distinguish this from any collection-style or soil-related sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage — call this when you need a single soil type by id — but it gives no explicit guidance about when to choose this tool over alternatives, nor any exclusions or context about related soil tools. This is a minor gap since the tool is a simple lookup, but there are many soil-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full behavioral burden. The explicit 'GET' signals a read-only operation and 'full list' suggests there is no filtering or pagination, which is useful. Still, it does not disclose response shape, ordering, or any access constraints, so transparency is incomplete but adequate for a simple list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with the HTTP method and endpoint front-loaded, followed by a direct statement of what is returned. There is no filler or redundant explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter reference-list tool with no output schema, the description is largely complete: it names the endpoint, the HTTP method, and the exact scope of the response. It could describe the shape of each crop group item, but that is not necessary for an agent to select and invoke this readonly list endpoint correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so there is no parameter semantics to clarify. The 0-parameter baseline applies, and the description adds no unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (GET) and resource (/api/Arable/CropGroups), and it specifies that the tool returns the full list of available crop groups. It does not explicitly contrast with siblings like rb209_arable_crop_group or rb209_arable_crop_types_by_group, but the plural 'groups' and 'full list' make its reference-list role reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool is for obtaining the complete set of crop groups, so usage is implied. However, it provides no explicit guidance about when not to use it or when to choose a sibling such as the singular crop group endpoint or the crop-types-by-group endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does indicate a read-only GET operation and that the result is a full list, but it does not describe response format, ordering, or any other behavioral details. For a zero-parameter lookup this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that combines the endpoint, HTTP method, and purpose without any filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless list endpoint, the description is complete enough: it identifies what is returned and the read-only nature via GET. The lack of an output schema is mitigated by the self-explanatory concept of 'available nutrients,' though slightly more detail about the nutrient fields could help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so the schema already fully documents the parameter surface. The description does not need to explain parameters, and no parameter information is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'GET /api/Field/Nutrients' returning 'the full list of available nutrients.' This is clear and unambiguous, though it does not explicitly name a sibling tool to differentiate from; the 'full list' wording helps but is not a direct contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent would call this to get all available nutrients. However, there is no explicit guidance about when to choose this over related sibling tools such as rb209_field_nutrient, nor any mention of exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does explicitly indicate a GET request and a filtering result, implying a read-only operation, but it does not describe error behavior, response format, or any edge cases. This is acceptable for a simple lookup but lacks deeper transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the HTTP endpoint and immediately conveys the core behavior. There is no wasted text, and all information is relevant and efficiently ordered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required integer parameter, no output schema, no nested objects), and the description gives the essential return value ('field type text'). However, without an output schema, more detail about the response format would help the agent know exactly what to expect. The description is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the single parameter with a clear description ('The field type id to filter on'). The tool description only restates this concept ('filtered from the supplied corresponding field type id') without adding meaningful semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (GET) and resource (Field/FieldType) and specifies that it returns an individual field type text for a given id. The word 'Individual' clearly differentiates this from the plural sibling rb209_field_types, so the tool's purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: 'Individual' and the required fieldTypeId suggest this is for fetching one specific field type, not a list. However, the description does not explicitly mention alternatives or when not to use this tool, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is a GET/calculation operation, which reasonably implies a read-only behavior. With no annotations provided, though, it does not describe the shape of the returned site class id, possible error behavior, or how this result relates to other site-class endpoints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the HTTP method and endpoint and directly states the tool's purpose. There is no filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter calculation, the description plus fully covered schema is largely sufficient. However, the lack of an output schema and any description of the return value leaves a moderate gap in what an agent can expect from the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (altitude, rainfall, soilTypeId) already documented with units or meaning. The description adds no further parameter detail beyond mirroring the endpoint path, so the baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Calculate the site class id') and a clear scope ('for Scottish grassland fields'), making the tool's purpose immediately identifiable. Including the endpoint path reinforces the resource and helps distinguish it from related site-class and growth-class sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for Scottish grassland fields' implies the primary use case, and the schema lists the required inputs. However, the description does not explicitly say when to use this tool instead of related sibling tools, nor does it state any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does state 'GET' and 'list', which imply a read-only operation returning a collection. However, it does not describe response structure, units, error behavior, pagination, or any prerequisites for using the two IDs. Some transparency is present, but meaningful gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no filler. It gives the exact endpoint URL followed by a human-readable summary. Every part adds value, and it is easy to scan. This is appropriately sized for a simple lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-parameter GET with high schema coverage, but there is no output schema and no annotations. The description tells what the resource is and where but does not describe what a yield range entry contains, how the IDs are obtained, or how the output is structured. Adequate for basic invocation, but incomplete for an agent needing to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% and describes both required parameters with concise definitions. The description adds almost nothing about parameter semantics beyond including them in the URL template. Baseline 3 is appropriate because the schema does the heavy lifting and no parameter explanation is missing from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource ('yield ranges for grass fields in England and Wales') and the operation ('list'). It distinguishes this tool from its close sibling rb209_grass_yield_ranges_scotland by explicitly naming the geographic scope. The endpoint path also reinforces the specific resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for England and Wales grass yield ranges, and the sibling tool name signals Scotland as an alternative. However, it does not explicitly state when to choose this tool over another, nor does it mention exclusions or alternatives. The geographic scope is the main usage signal, but it is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. The 'GET' prefix and 'full list' language indicate a read-only lookup with no side effects, but it does not mention auth requirements, rate limits, or response shape. For a simple zero-parameter lookup this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact line that front-loads the HTTP endpoint and immediately states what is returned. Every word contributes to understanding, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list endpoint, the description supplies the essential information: the full URL path and the semantic meaning of the result. It is sufficient to invoke correctly, though it does not describe the output structure or differentiate itself from the singular sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so parameter documentation is unnecessary. The baseline of 4 for no-parameter tools applies here; the description correctly adds no redundant parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the HTTP method and resource ('GET /api/PreviousCropping/PreviousGrasses') and defines the tool as returning 'The full list of available previous grasses.' The plural 'grasses' and 'full list' signal that this is the list variant, though it does not explicitly contrast with the singular sibling tool rb209_previous_cropping_previous_grass.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'full list' implies use when a complete enumeration of previous grasses is needed, but there is no explicit guidance on when to choose this over the singular sibling or other list endpoints. It gives an implied usage context rather than clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does convey that this is a read-only GET operation and specifies the covered months, but it does not describe response format, units, or any edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence conveys the HTTP method, endpoint path, and semantic definition. It is front-loaded with the route and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter GET lookup, the description gives a reasonable high-level understanding. However, there is no output schema and no note about the response value's format or units, so the agent is left inferring what 'average rainfall' means as a return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single 'postcode' parameter with a format example, so the description adds little beyond showing it appears in the URL path. Schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific GET resource and its purpose: returning average rainfall during summer (April–September). This distinguishes it from the sibling winter rainfall average tool and the generic rainfall average tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the season and months, but it does not explicitly say when to use this tool over the winter or generic rainfall siblings. No alternatives or exclusion conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral context. It clearly discloses a GET (read-only) operation for a single resource, which is the key behavioral trait. It does not mention error behavior, authorization, or return shape, but for a simple id lookup this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that includes the exact HTTP method, path, and a brief explanation. There is no wasted text, and the key filtering behavior is stated immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool with one required parameter and no output schema. The description plus schema provide enough information to invoke the tool correctly. It omits response format and error behavior, but those are secondary given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already documents cropGroupId as 'The crop group id to filter on'. The description only restates this filtering purpose without adding additional semantics such as value ranges or format details, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete GET operation on a specific resource ('Individual crop group') and states it is filtered by crop group id. It is clear, though it does not explicitly distinguish itself from close siblings like rb209_arable_crop_groups or rb209_arable_crop_types_by_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'filtered by crop group id' implies this tool is for retrieving a single crop group by ID, but the description gives no explicit when-to-use guidance or mention of alternatives. Usage context 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It does disclose that this is a read-only GET returning the complete set of values, but it says nothing about response format, ordering, or any limitations. That is adequate for a simple no-parameter list but leaves room for more detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that leads with the exact endpoint and immediately states the tool's purpose. Every word contributes; there is no padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only lookup, the description is nearly complete: it identifies the resource, states that it returns all values, and implies no inputs are required. It could be improved by explaining what 'shoot numbers' represent or how the result is intended to be used, but that is not essential for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty and the tool takes zero parameters, so there are no parameter semantics to document. The rubric baseline for zero-parameter tools is 4, and the description correctly implies that no invocation arguments are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific HTTP verb ('GET'), a specific resource ('/api/Measurement/ShootNumbers'), and the exact purpose: returning the full list of available shoot numbers. This clearly separates it from sibling measurement tools like crop_heights and green_area_indexes by naming the distinct resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no when-to-use or when-not-to-use guidance, and it does not mention any alternatives among the many sibling tools. An agent must infer from the name and the phrase 'Full list' that this is a general lookup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It communicates read-only behavior through 'GET' and 'full list', indicating no pagination or filtering. It does not disclose response format, ordering, or access prerequisites, but for a zero-parameter list endpoint the risk is low.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with the endpoint front-loaded and the qualifier at the end; every phrase earns its place. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list endpoint, the description covers the essential selection facts: what it returns and when it is required. The lack of an output schema is partially mitigated by 'full list'; more detail about the item structure would help, but isn't necessary to invoke the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the empty schema fully specifies the call. With no inputs to document, the description does not need to add parameter semantics; the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action: returns the full list of CropInfo2 records, with the scope 'only required for arable cereals crops'. The endpoint path in the description reinforces the resource. It does not explicitly contrast with sibling list endpoints like crop_info1s or the singular crop_info2, so not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'only required for arable cereals crops' gives a clear domain condition for when this lookup matters, implying it is not needed for non-cereal or grass scenarios. It does not name specific sibling alternatives, so it lacks explicit when-not/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It does disclose a read-only GET operation and the id-based filtering behavior. However, it says nothing about behavior for invalid or missing ids, response format details, or whether 'country text' is localized; these gaps are moderate but not severe for a simple lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that states the endpoint before explaining behavior. It has no filler, though the phrasing 'supplied corresponding country id' is slightly redundant and awkward.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only lookup, the description is almost complete: it tells the agent what to call, what parameter to supply, and what kind of value will be returned. It falls just short of fully complete because there is no output schema and no mention of not-found or error behavior, but the low complexity keeps this from being a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents countryId with a description, and schema coverage is 100%. The description's 'supplied corresponding country id' adds no new semantic meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly names the HTTP method (GET), the resource (/api/Field/Country/{countryId}), and the exact purpose: returning individual country text for a given id. 'Individual' distinguishes it from the plural sibling rb209_field_countries, so an agent can select it correctly without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for the case where a specific countryId is known and the corresponding country text is needed. It does not explicitly mention alternatives or exclusions, but the individual-vs-collection contrast with sibling rb209_field_countries provides sufficient contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it warns about the misleading 422 error when field.grass is missing, reveals that the server auto-fills empty objects, explains the cropInfo2Id effect on K, and says the call returns all requested nutrients at once. It omits details like response structure and side effects, but it surfaces the most important non-obvious behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded with the purpose and endpoint, then moves through prerequisites, call count, arable-body requirements, soil-analysis handling, and key parameters. Every sentence carries useful guidance, though the flowing em-dash style could benefit from bullet formatting. It is long, but justified given the complexity of the request body.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deeply nested, complex endpoint with no output schema and no annotations, the description should explain both request construction and return interpretation. It covers the arable case, no-soil-analysis case, and several pitfalls, but it does not explain the response shape, how to interpret the returned values, or how to construct the body for grass/mixed fields. The guidance is strong but incomplete for the full range of inputs the schema supports.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the signal reports 0% schema description coverage, the nested schema actually contains detailed property descriptions. The description adds real value beyond the schema by giving concrete values for cropInfo2Id (1 = straw baled/removed, 2 = straw incorporated), specifying field.grass = {} and field.grassland = {} for arable fields, and explaining soilAnalyses = [] when no soil data exists. It does not add semantics for totals or referenceValue, but the most error-prone fields are covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as the main endpoint to "calculate nutrient recommendations" and specifies the HTTP path. It also states what it returns — every enabled nutrient — which distinguishes it from per-nutrient calls. However, it does not explicitly contrast it with sibling recommendation calculators like calculate_nutrient_offtake or calculate_nutrient_deficiency, so differentiation is implied rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong operational guidance: collect all inputs first, call once, do not call per-nutrient, use rb209_rainfall_average for rainfall, skip lookups when there is no soil analysis, and always ask for cropInfo2Id. It does not explicitly say when to choose a sibling recommendation tool instead, but the when-not guidance is clear enough for the core workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses the T04 'No nutrient indexes found' response behavior and gives a handling instruction for missing soil analysis. It does not describe output structure or authentication, but for a simple list endpoint this is sufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the HTTP method and endpoint, then provides the most important behavioral and usage notes. Every sentence contributes useful information; no filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two parameters, no annotations, and no output schema, the description covers the essential context: what it returns, when it fails, when to skip it, and which sibling to use instead. It could be more complete by describing the response list shape, but the provided guidance is enough for an agent to call it correctly in typical flows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description reinforces that methodologyId is the filter and that the result spans nutrients, but it adds nothing about the optional nutrientId parameter beyond what the schema already states. It neither harms nor significantly augments the schema's parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair ('GET ... a list of the available nutrient indexes') and names the filtering dimension (methodology id). It is reasonably distinct from siblings because it explicitly frames the result as a cross-nutrient list, though it does not differentiate itself from the similarly named rb209_soil_nutrient_indices sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete situational guidance: if there is no soil analysis, skip this tool and send soilAnalyses: [], and use NutrientIndexIdFromValue instead for measured-value conversion. It also warns that many combinations return a 'No nutrient indexes found' error, helping the agent decide when this tool is useful. It doesn't enumerate all alternatives but gives adequate decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It reveals the HTTP method is GET and that the operation is an individual filtered lookup, which implies a read-only action. However, it says nothing about response contents, error behavior, or access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that combines endpoint, resource, filtering behavior, and a usage qualifier with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter GET-by-ID tool, this is adequately complete: it identifies the resource, the parameter, and when it applies. The absence of an output schema and annotations means return value details are not covered, but the simplicity of the operation makes that a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% and the single parameter already has a description. The description's phrase 'filtered by crop info 2 id' essentially repeats the schema's semantic, adding no meaningful new parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb (GET), a specific resource (Arable/CropInfo2/{cropInfo2Id}), and identifies it as the individual lookup by ID. This distinguishes it from sibling list endpoints like rb209_arable_crop_info2s.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description adds a concrete usage condition: 'only required for arable cereals crops.' It also implies the tool is for fetching a single record by ID rather than listing. It doesn't explicitly name alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It states the HTTP method GET and that the results are filtered by ID, which implies a read-only lookup, but it does not mention return format, error behavior, or any other runtime traits. This is adequate for a simple lookup but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that leads with the endpoint and then adds the key usage qualifier. No words are wasted, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter GET lookup with full schema coverage, the description is mostly complete: it gives the endpoint, the filter, and the arable-potato-only context. It lacks explicit response or error details, but those are not required to successfully invoke this simple resource lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter is already documented. The description's 'filtered by potato group id' meaningfully confirms the parameter's role but adds no detail beyond the schema's own description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific operation: GET an individual potato group by its ID. The singular 'Individual potato group' clearly distinguishes this from the plural collection sibling rb209_arable_potato_groups, and the endpoint path reinforces the resource and filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The note 'only required for arable potato crops' gives clear context on when this tool is relevant. It does not explicitly name alternative tools or state when not to use it, but the singular-vs-plural distinction combined with the scope note is sufficient for basic routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states the HTTP method (GET) and the outcome (returns the sward management text), making the read-only, non-destructive nature clear. It does not discuss error cases or response formatting, but for a single-ID lookup this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with the endpoint front-loaded and the purpose stated immediately. No filler or redundant explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, no-output-schema, no-annotation lookup tool, the description explains both the input (an id) and the return (text), so an agent can invoke it correctly. A small gap is the lack of any explicit relationship to plural sibling endpoints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents swardManagementId as an integer with a clear description. The tool description adds no extra parameter-level meaning beyond restating that this id is "provided."
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (GET) and a specific resource (sward management by ID), and the {swardManagementId} path clearly marks this as a singular lookup, distinguishing it from sibling list tools such as rb209_grass_sward_managements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: call this tool when you have a specific sward management id and need its text. However, there is no explicit guidance about when not to use it or a pointer to alternative list endpoints like rb209_grass_sward_managements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description includes the HTTP method GET and describes a list response, which reasonably implies a read-only operation. It does not disclose error behavior, authentication needs, or response details, but for a simple reference lookup this is minimally acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that leads with the endpoint and then gives the semantic meaning. Every part contributes needed information, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool with one required parameter and no output schema or annotations. The description adequately conveys what the tool returns and the input dependency, though it does not mention response fields or how to obtain a valid swardTypeId.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes swardTypeId as 'The sward type id of the field' with 100% coverage. The description adds only that the parameter selects which sward managements are available, which reinforces rather than meaningfully extends the schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation (GET list), the resource (sward managements), and the filtering condition (by the provided sward type). This distinguishes it from the sibling rb209_grass_sward_managements, which presumably returns unfiltered sward managements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the use case clear: call this when you have a swardTypeId and need the sward managements available for that type. It does not explicitly name alternatives or when-not-to-use, but the scoping condition provides adequate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is a GET operation returning the full list, which implies a read-only enumeration. No annotations exist, so the description carries some burden, but it does not describe return format, error behavior, or any limits. Still, for a zero-parameter lookup, this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the endpoint and the resource content without any redundant wording. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only list tool, the description is nearly complete: it says what resource is returned and that it is the full list. It could add a note about how crop heights relate to other measurement tools, but that is not essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the input schema is empty with 100% coverage. The description adds no parameter details, but none are needed. The baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description combines a specific HTTP verb and resource ('GET /api/Measurement/CropHeights') with a clear outcome ('Full list of available crop heights'). This clearly distinguishes it from sibling lookup tools like measurement_shoot_numbers or measurement_green_area_indexes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: an agent should call this when it needs the complete set of available crop heights. However, there is no explicit guidance about when to prefer this tool over related measurement tools, and no alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses a safe read operation through 'GET' and a complete enumeration through 'Full list', but it does not describe the return shape, payload fields, or any potential response details. For a simple zero-parameter list endpoint this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence contains the endpoint, the operation, and the scope. There is no filler, redundant phrasing, or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter GET with no output schema, the description is nearly complete: an agent knows what endpoint to call and what to expect at a high level. It lacks domain context on what a green area index represents or how it is used, but that does not prevent correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so there is no parameter behavior to explain. The description appropriately avoids inventing parameter details, matching the baseline for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (green area indexes), the operation (GET), and that it returns the full list. This distinguishes it from sibling measurement tools like crop heights or shoot numbers by naming the exact endpoint and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Full list of available green area indexes' implies this is a reference lookup for enumerating all indexes, but it does not explicitly state when to use it instead of other measurement-related tools. There are no exclusions, alternatives, or conditions given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The GET verb communicates a read-only operation, and 'full list' indicates no filtering or narrowing. With no annotations and no output schema, the description carries the burden, but it does not disclose response format, ordering, or potential error behavior. This is minimal but acceptable for a zero-parameter lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the endpoint and immediately states the returned content. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, no output schema, and a very simple purpose, the description is sufficient for an agent to invoke it correctly. There is no missing input or filtering information that would leave the agent uncertain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is trivially 100%. The description adds no parameter details, but none are needed; 'full list' reinforces that there are no input constraints. Baseline 4 is appropriate for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource ('/api/Field/Countries'), the HTTP verb (GET), and the exact result ('the full list of available countries'). The plural 'list' clearly distinguishes it from the singular sibling rb209_field_country and other lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent would use this when it needs the complete list of available countries. However, there is no explicit guidance about when not to use it or how it compares to the singular rb209_field_country or other country-related endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that this is a GET operation returning a full list, implying a read-only behavior, but it does not describe response format, ordering, or any other behavioral traits. This is acceptable for a trivial 0-parameter list endpoint but still minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the endpoint method and path front-loaded, followed by a precise scope. There is no wasted text or redundant repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter list endpoint with no output schema, the description communicates the core return value: the full list of advice notes for England and Wales arable. It does not describe the structure of each advice note, but this is not essential for selecting and invoking this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there is no parameter documentation burden. The description adds context that this is an unfiltered 'full list' endpoint, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (GET /api/AdviceNote/ArableEngWal) and a precise scope: the full list of advice notes for England and Wales arable. This clearly distinguishes it from siblings like rb209_advice_note_arable_scot, rb209_advice_note_grass_eng_wal, and rb209_advice_note_grass_scot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'England and Wales arable' qualifier gives clear context for when this tool is appropriate. However, it does not explicitly name alternatives or state when not to use it, leaving some inference to the agent from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a read-only GET operation and that the result is a full list, which covers the basics. However, it does not mention response format, ordering, or any access considerations, though the simple zero-parameter nature limits the gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the endpoint and the result. It is front-loaded and contains no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list retrieval tool, the description provides the essential context: resource path, geographic/crop scope, and result type. It does not explain return item structure, but this is a simple list where 'advice notes' is reasonably self-descriptive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully defines the input surface. The description appropriately focuses on what the tool returns rather than parameter details; the baseline for 0 parameters applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific resource and action: it returns the full list of available advice notes for Scotland grass. The scope (Scotland grass) distinguishes it from siblings like rb209_advice_note_grass_eng_wal and rb209_advice_note_arable_scot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is clear from the explicit scope: use this tool when you need advice notes for grass in Scotland. It does not explicitly state when not to use alternatives, but the naming and description make the context unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly discloses the HTTP method 'GET', indicating a read-only, non-destructive operation, and states that the return value is the sequence text. It does not cover error behavior or authentication, but the read-only nature and return type are clearly conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly structured sentence that front-loads the endpoint and purpose. There is no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup with full schema coverage and no output schema, the description adequately covers the endpoint, input, and return value ('text'). It omits not-found error behavior and response details, but the simplicity of the operation makes this a minor gap rather than a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is already fully documented in the schema. The description only echoes 'provided defoliation sequence id' without adding format, range, source, or usage nuances. This matches the baseline of 3 for fully schema-covered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('the text of the defoliation sequence'), and the identifying parameter ('defoliationSequenceId'). It is clearly distinct from sibling list endpoints such as rb209_grass_defoliation_sequences because it targets a single sequence by ID and returns its text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for the provided defoliation sequence id' gives clear context: use this tool when you already have a defoliation sequence ID and need the corresponding text. It does not explicitly name alternatives or exclusion conditions, but for a simple single-resource lookup this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fairly discloses the important behaviors: it is a GET that returns the full list, the list is fixed, and it only returns data for countryId 3. It does not state what happens for other countryIds, but for a simple lookup this is a reasonable disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the endpoint and purpose before the usage caveat and fixed values. Each clause contributes information, though the repeated em-dash style makes it slightly choppy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter GET with no output schema, the description is essentially complete: it names the endpoint, the returned concept, the fixed result values, and the countryId constraint. The only gap is an explicit description of behavior for countryId values other than 3, but that is implied by 'only returns data for countryId 3.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, countryId, is not described in the schema, and schema coverage is 0%, so this is the only place to learn its meaning. The description ties countryId to the path and says data is returned only for 3, giving the agent a concrete value to pass. It could be more explicit that 3 is the intended/only useful input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the exact HTTP verb and path, and states the result is 'the full list of available field types.' This clearly distinguishes it from the singular sibling rb209_field_type, so an agent knows this variant returns the whole set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises 'You usually don't need this' because fieldType is fixed to three known values, and warns that data is only available for countryId 3. It omits naming a specific sibling to use instead, but the fixed values themselves tell the agent the look-up is unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. The explicit 'GET' signals a read-only operation, and 'full list' indicates the endpoint returns the complete set without filtering or pagination. It does not describe the response item shape, but for a parameterless list-retrieval tool, the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-front-loaded sentence: endpoint first, then result scope. It contains no filler, no repeated schema information, and every word contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list endpoint, the description is largely complete: it identifies the endpoint, the geographic/crop scope, and that the full list is returned. Since there is no output schema, a little more detail about whether the returned items are note identifiers, titles, or full text would be helpful, but the sibling set provides reasonable surrounding context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and 100% schema description coverage, so there are no parameters for the description to explain. The zero-parameter baseline of 4 applies here; the description need not add parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('GET /api/AdviceNote/ArableScot') and explicitly scopes the result to 'Scotland arable.' This distinguishes it clearly from sibling tools like rb209_advice_note_arable_eng_wal and rb209_advice_note_grass_scot. 'The full list of available advice notes' also makes the output general shape clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Scotland arable' scope gives a clear contextual signal for when this tool is appropriate, and the sibling names make obvious alternatives such as the England/Wales arable and grass Scotland advice notes. However, the description does not explicitly name alternatives or state when not to use this tool, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden of disclosing behavior. It clearly communicates a read-only list retrieval via 'GET' and 'full list,' which implies no side effects. The scope qualifier about arable potato crops adds useful behavioral context beyond the endpoint itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. It front-loads the endpoint and core purpose, then adds the relevant usage qualifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter list endpoint, the description provides enough information to select and invoke the tool. It does not describe the shape of the returned potato group objects, but without an output schema and given the low complexity, this is a minor gap rather than a blocking omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the empty schema fully covers invocation. The description does not need to explain parameter semantics, and the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a GET endpoint for 'the full list of available potato groups,' which names the resource and action precisely. The phrase 'potato groups' and 'full list' distinguish it from singular-item and variety-related siblings such as rb209_arable_potato_group and rb209_arable_potato_varieties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical 'only required for arable potato crops' gives a clear usage context and implies this lookup is not needed for other crop types. It does not explicitly name alternative tools or provide a when-not-to-use statement, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

rb209-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![rb209-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/charles-gentry/rb209-mcp/badges/card.svg)](https://glama.ai/mcp/servers/charles-gentry/rb209-mcp)

Score Badge

Copy to your README.md:

[![rb209-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/charles-gentry/rb209-mcp/badges/score.svg)](https://glama.ai/mcp/servers/charles-gentry/rb209-mcp)