MCP server for Agro GPS, the digital field notebook.
Free, no key: search and check plant protection products (pesticides, fungicides, herbicides) in the official registers of 30 European countries, mirrored by Agro GPS: is it still authorised, which substances, which uses, is it allowed on this crop.
With your key: your farms, field notebook, group dashboard, advisor queue and farm finances and, with a write key, recording new notebook entries.
{
"mcpServers": {
"agro-gps": {
"command": "npx",
"args": ["-y", "agro-gps-mcp"]
}
}
}That is enough for the public tools. For your own farm data, create a key in the app at agrogps.eu/app (Settings → API and webhooks) and add it:
"env": { "AGROGPS_API_KEY": "agk_your_key_here" }Variable | Required | Default |
| only for farm tools | — |
| no |
|
| no |
|
Related MCP server: agriculture-mcp-server
Tool | What it does |
| Search a country's official register by trade name; authorisation state and a link to each product page |
| One product by registration number: state, expiry, substances, authorised uses and, with |
Examples: "Is Roundup Ultra Plus still authorised in Spain?", "Can I use product 7400057 on grapevine in France?". Public endpoints are rate limited per IP address.
The key acts as you: it only sees the farms and groups you belong to, with your role in each. A read key only
queries; a write key can also use record_entry. Revoke it from the same screen at any time. Without a key these
tools are still listed and answer with instructions to create one.
Tool | What it does | Access |
| Farms the key can see, role, plan and whether holder data is complete | read |
| Notebook entries of a farm with compliance fields, paginated | read |
| Audit trail of one entry, field by field | read |
| Groups (company or cooperative) the key owner belongs to | read |
| Consolidated panel of a group per farm and crop | read |
| Farms an advisor reviews, with a traffic light | read |
| Entries of a farm pending review or missing fields | read |
| Costs, income and margins of a farm or group per campaign | read |
| Budget vs actual per line | read |
| Estimated campaign close per crop (low / mid / high) | read |
| Receivables and payables | read |
| Cash-flow forecast by week or month | read |
| Imported bank movements and match candidates | read |
| Adds a new entry to the notebook | write |
record_entry only adds entries: nothing in this server edits or deletes existing data. Every entry is attributed
to the key owner and marked as written through the API in the audit trail. Official submission to the
administration never happens here: it needs a person's session in the app.
Servidor MCP del cuaderno de campo Agro GPS. Sin clave, consulta los registros oficiales
de fitosanitarios de 30 países: si un producto sigue autorizado, sus sustancias, sus usos y si vale para un
cultivo. Con clave (créala en agrogps.eu/app, Ajustes → API y webhooks), el
asistente consulta tus explotaciones, cuaderno, grupos, cola del asesor y cuentas; con write además registra
labores nuevas. La clave ve solo tus explotaciones y nunca borra ni edita nada. El envío oficial a la
administración no pasa por aquí.
npm ci
npm run lint && npm test && npm run build
node build/index.jsnpm run pages regenerates src/data/product-pages.ts (which products have a page on agrogps.eu) from the
landing repo checked out at ../landing.
MIT
Entries of a farm that still need review or lack mandatory fields, with the list of missing fields.
| Name | Required | Description | Default |
|---|---|---|---|
| farm_id | Yes | Farm id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description does not need to restate safety. It does add value by disclosing what the response contains ('with the list of missing fields'), but says nothing about ordering, pagination, or empty-result behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the scoping ('of a farm') and result content front-loaded; no filler. It is slightly terse for a definition with no output schema, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only lookup with no output schema, the description conveys the core return contract (pending entries plus missing fields). It omits result ordering or pagination, which is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single farm_id parameter, so the schema already documents the UUID input. The phrase 'of a farm' loosely reinforces the scoping, but adds no syntax or format detail beyond the schema — baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('Entries of a farm') and the precise subset it returns ('still need review or lack mandatory fields'), which is more specific than the bare name advisor_pending. It does not explicitly contrast itself with siblings like list_entries or entry_history, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an advisor wanting the review backlog would infer this is the right tool. There is no explicit when-to-use statement, no mention of when to prefer list_entries or entry_history instead, and no prerequisites such as required permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For advisors and owners: every farm they can review, with entries, missing compliance fields, pending, flagged and approved counts and a traffic light.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds access scoping ('every farm they can review') and the aggregated status fields returned, but it does not cover pagination, empty-state behavior, or deeper authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with audience and scope, with no filler. It efficiently packs the returned fields without repeating structured data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, read-only/idempotent annotations, and no output schema, the description carries the burden of describing returns. It names the farm portfolio and status counts, though it leaves some ambiguity about how this differs from other list/reporting tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so there are no parameter semantics to explain; the baseline for a zero-parameter tool is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the resource ('every farm they can review') and enumerates the payload (entries, missing compliance fields, pending, flagged and approved counts, traffic light). It does not explicitly contrast with siblings like list_farms or advisor_pending, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only audience context ('For advisors and owners') is given. There is no when-to-use guidance, no condition selecting this tool over list_farms, group_overview, or advisor_pending, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Imported bank accounts with their last balance and movements, what each one was matched to and, for the unmatched ones, the best candidates with a score.
| Name | Required | Description | Default |
|---|---|---|---|
| farm_id | No | Farm id (from list_farms). Omit to use group_id | |
| group_id | No | Group id (from list_groups) for figures consolidated across its farms | |
| only_open | No | Only unmatched movements |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context — that it includes both matched movements and, for unmatched ones, candidate matches with scores — but says nothing about volume, pagination, or freshness of the imported data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with no redundant filler, and the most important content (accounts, balances, movements, matches) is front-loaded. The trailing clause about candidates with scores is slightly run-on but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does carry the burden of describing returns and does so reasonably well (accounts, last balance, movements, matches, scored candidates). However, it omits scoping behavior, result volume, and how the farm_id/group_id consolidation choice affects output, leaving gaps for a tool the agent must invoke without further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (farm_id, group_id, only_open) are already documented, including the farm_id/group_id fallback relationship. The description adds no parameter-level detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description conveys what data is surfaced (imported bank accounts, last balance, movements, matches, candidate scores) but never states an action verb, so the agent must infer that this is a retrieval/reconciliation tool. It is distinguishable from financial siblings like cash_flow or finance_dashboard by its matching/candidate framing, but the purpose is stated as a noun phrase rather than a clear verb+resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings such as finance_dashboard, treasury_dues, or cash_flow. The schema hints that farm_id/group_id are alternatives sourced from list_farms/list_groups, but the description itself provides no context for selecting or scoping the call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Budget lines (campaign x farm x crop x category) with actual spend, remaining, used percentage and status ok / warning (90%+) / over. Amounts in euro cents.
| Name | Required | Description | Default |
|---|---|---|---|
| farm_id | No | Farm id (from list_farms). Omit to use group_id | |
| campaign | No | Campaign as its starting year (a campaign runs from 1 September to 31 August). Default: current | |
| group_id | No | Group id (from list_groups) for figures consolidated across its farms |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: the status thresholds (ok / warning at 90%+ / over) and the unit convention (euro cents), which an agent cannot derive from annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences that front-load the resource and grain, then append the status/unit conventions. No filler, though the terse telegraphic style is slightly less scannable than a full sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does it well: it names the measures and the status vocabulary. Only minor gaps remain, such as whether a default campaign is used and how multiple lines are ordered or aggregated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each of farm_id, campaign and group_id documented including defaults and provenance (list_farms, list_groups). The description adds only the crop/category output grouping, not new parameter meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the resource (budget lines), the grouping grain (campaign x farm x crop x category) and the returned measures (actual spend, remaining, used %, status). This clearly separates it from siblings like finance_dashboard or campaign_forecast, though it never uses an explicit verb such as 'list' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus alternatives such as finance_dashboard, campaign_forecast or group_overview. Usage is only implied by the returned fields; the agent must infer that this tool answers budget-vs-actual questions rather than being told.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ESTIMATE of how the campaign closes per crop: expected yield x price minus costs already imputed and the budget still pending, as a low / mid / high range, total and per hectare. Says whether each assumption was saved by the farm, taken from last campaign or is missing. Always present it as an estimate.
| Name | Required | Description | Default |
|---|---|---|---|
| farm_id | Yes | Farm id | |
| campaign | No | Campaign as its starting year (a campaign runs from 1 September to 31 August). Default: current |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real value by disclosing the return semantics and, importantly, that each assumption is flagged as farm-saved, carried over from last campaign, or missing – a data-provenance caveat an agent would otherwise have to discover at runtime.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the ESTIMATE framing, and the second sentence adds a genuinely distinct point about assumption provenance. The first sentence is dense and slightly run-on but every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the work of describing the return shape (low/mid/high range, total and per hectare) plus the provenance flag on assumptions. Missing only the when-to-use routing, which is a usage rather than completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, including the campaign format and its September–August definition, so the schema already carries the parameter meaning. The description adds nothing about farm_id or campaign and does not clarify the 'per crop' grouping as a parameter concern; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (estimate) and resource (how the campaign closes per crop), and spells out the computation, the range shape, and the per-hectare breakdown. An agent can distinguish this from finance_dashboard, budget_variance or cash_flow purely from the text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is a presentation rule ('Always present it as an estimate'), which is about framing, not about when to call the tool. No alternatives are named and no condition distinguishing it from the other finance/budget siblings is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Expected cash in and out by week or month from open receivables and payables, starting from the last imported bank balance, with overdue amounts apart.
| Name | Required | Description | Default |
|---|---|---|---|
| farm_id | No | Farm id (from list_farms). Omit to use group_id | |
| horizon | No | Number of weeks or months | |
| group_id | No | Group id (from list_groups) for figures consolidated across its farms | |
| granularity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the description's value is the provenance detail: the forecast derives from open receivables/payables and starts from the last imported bank balance, with overdue amounts broken out separately. That data-source dependency (accuracy hinges on the last import) is genuinely useful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that packs the source data, time grouping, and the overdue-separation trait with no filler. The trailing phrase 'with overdue amounts apart' is slightly awkward but still earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should carry more about the returned shape, and it leaves open what happens when neither farm_id nor group_id is supplied (all params optional) and what the default horizon/granularity are. The annotations cover the safety profile, so this is adequate but with visible gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, and the schema already spells out farm_id/group_id sourcing and horizon bounds. The description's 'by week or month' loosely maps to the undescribed granularity enum, but it adds no defaults, no 'at least one of farm_id/group_id is required' note, and no format guidance beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (cash-flow forecast) along with the exact computation basis: expected in/out from open receivables and payables, seeded by the last imported bank balance. This is clear enough to distinguish it from siblings like finance_dashboard or bank_movements, though it does not name any sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No statement of when to use this versus treasury_dues, finance_dashboard, or budget_variance, and no guidance on choosing granularity or horizon. Usage is only implied by the tool's nature as a forward-looking projection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, no API key. Looks up one product by its official registration number in a country's register: authorisation state (authorised / withdrawn / expired), expiry date, formulation, active substances and authorised uses. With crop_eppo it also says whether the product is authorised on that crop. Includes a link to the product page.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ISO 3166-1 alpha-2 country whose official register to use, e.g. ES, FR, DE, IT, PT, PL | |
| crop_eppo | No | EPPO code of the crop to check the product against, e.g. VITVI (grapevine), OLVEU (olive) | |
| registration | Yes | Official registration number, e.g. ES-00725, 7400057 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and non-open-world behavior, so the safety profile is covered. The description adds useful context beyond that: the response fields (authorisation state, expiry, formulation, active substances, uses), the effect of crop_eppo, and that a product-page link is included. It does not cover rate limits or error behavior, but the baseline is lower with annotations present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a key constraint (free, no API key), then states the lookup behavior, then the optional-parameter effect, then the link. Every sentence adds information, and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of explaining return data, which it does by naming the authorisation state, expiry date, formulation, active substances, authorised uses, and product-page link. Combined with annotations covering safety and a fully documented input schema, an agent has enough to invoke and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that crop_eppo causes the result to state whether the product is authorised on that crop, which clarifies the parameter's behavioral effect rather than merely restating its type and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (looks up) and resource (one product by official registration number in a country's register), and distinguishes itself from the sibling search_plant_protection_products by emphasizing a single registration lookup rather than a search. An agent can immediately tell what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is given: use this when you have a single registration number and country, with optional crop_eppo for crop-specific authorisation. However, it does not explicitly name or contrast with the sibling search_plant_protection_products, so the alternative is left implicit rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who created, edited or deleted a notebook entry and when, field by field (audit trail).
| Name | Required | Description | Default |
|---|---|---|---|
| entry_id | Yes | Entry id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds valuable behavioral context by describing the returned content as a field-by-field audit trail including who, when, and what action occurred.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence, front-loaded with the core purpose, with zero wasted words. It efficiently conveys the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one well-documented parameter and no output schema, the description provides sufficient context about what the audit trail contains. It could be slightly richer about return format or pagination, but overall it covers the essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter entry_id is documented in the schema as 'Entry id'. The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a clear purpose: retrieve audit trail of a notebook entry, specifying who, when, and field-by-field changes. It distinguishes from sibling tools like list_entries and record_entry by focusing on history, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The phrase 'audit trail' implies the tool is for viewing historical changes, but no alternatives or conditions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Money of a farm or a whole group for one campaign: month-by-month cost and income, cost by category (phyto, fertiliser, fuel, labour, machinery, seed, insurance, other), cost per hour per worker and per machine, margin per hectare per parcel and per crop, per-farm totals and KPIs of the last three campaigns. Amounts are integer euro cents.
| Name | Required | Description | Default |
|---|---|---|---|
| crop | No | Only this crop code | |
| farm_id | No | Farm id (from list_farms). Omit to use group_id | |
| campaign | No | Campaign as its starting year (a campaign runs from 1 September to 31 August). Default: current | |
| group_id | No | Group id (from list_groups) for figures consolidated across its farms |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds useful behavioral context beyond that: amounts are integer euro cents and the dashboard covers the last three campaigns. It does not mention auth needs, rate limits, or caching, so it is incremental rather than rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The main payload is front-loaded ('Money of a farm or a whole group for one campaign'), and the dense category enumeration is justified because no output schema exists to convey the return shape. It is a single long sentence that could be split, but little is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, describing the returned breakdowns and units is appropriate and largely complete; parameters are fully covered by the schema and safety by annotations. The main gap is the absence of any routing guidance to sibling financial tools, which is a usage rather than a completeness defect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (crop, farm_id, campaign, group_id) are already documented including formats and defaults. The description adds nothing parameter-specific beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact scope and content: financial figures for a farm or group for one campaign, broken down by month, category, worker/machine hour, and margin per hectare. This is specific enough to distinguish it from financial siblings like budget_variance or campaign_forecast. However, it reads as an enumeration of return values rather than stating what the tool does as an action, keeping it out of the 5 range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named despite many financial siblings (budget_variance, campaign_forecast, cash_flow, group_overview). The parameter semantics imply filtering by farm/group/campaign, but the agent must infer when this dashboard is the right choice versus the other financial tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consolidated panel of a group: per farm, entries, cost, income, margin, treated hectares, compliance light (green/amber/red), pending review counts and a breakdown by crop; plus totals.
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | Yes | Group id from list_groups |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered and the description need not repeat it. What the description does add is the concrete return content — costs, margins, compliance traffic-light, pending-review counts, crop breakdown — which is genuinely valuable because no output schema exists. It remains silent on pagination, aggregation time window, and permission scoping, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the resource ('Consolidated panel of a group') before the field list. Every clause carries content, though the field enumeration is list-heavy and could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only aggregation tool whose annotations fully cover the safety profile, the description supplies the missing return-shape detail that an absent output schema would otherwise leave blank. What is missing is the relationship to the other dashboard/list tools and any scoping or time-window caveats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter, group_id, and schema description coverage is 100% with the schema already pointing to list_groups as the source. The description implies the group scoping ('panel of a group') but adds no format, sourcing, or error detail 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (a group) and precisely enumerates what the panel consolidates: per-farm entries, cost, income, margin, treated hectares, compliance status, pending reviews, crop breakdown, plus totals. An agent can tell this is a composite read/reporting tool. It does not, however, distinguish itself from sibling dashboards such as finance_dashboard or budget_variance, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no statement of when this panel is preferable to finance_dashboard, budget_variance, advisor_pending or list_groups, and no exclusions or prerequisites. The agent must infer usage entirely from the tool name and the returned-field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Field notebook entries (labores) of a farm: treatments, fertilising, irrigation, sowing, harvest, expenses… with the compliance fields (Anexo II). Paginated: pass since = the next cursor of the previous page. Deleted entries come back with deleted=true so a mirror can stay in sync.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | Change cursor; 0 for the full notebook | |
| farm_id | Yes | Farm id from list_farms |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: deleted entries are still returned with deleted=true, which is essential for incremental sync. Return-shape detail is otherwise thin (no output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with what the resource is, then pagination, then the sync nuance. No filler and every sentence carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description covers the key non-obvious return behavior (deleted=true) and pagination, but does not sketch the entry shape beyond a topic list, leaving some return-value inference to the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema lacks: `since` is not just a cursor but specifically the `next` value from the previous page, establishing the pagination protocol. farm_id semantics are left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource (list field notebook entries) and enumerates what those entries contain: treatments, fertilising, irrigation, sowing, harvest, expenses, plus Anexo II compliance fields. An agent can immediately distinguish this from record_entry (write) and entry_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete usage context — paginate by passing `since` = the `next` cursor of the previous page, and states the mirror-sync use case. It does not, however, state when to prefer this over the sibling entry_history, so an exclusion or alternative is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Farms (explotaciones) the API key can see, with the key owner's role in each, the plan and whether the holder data required for official submissions is complete. Call this first to get farm ids.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive/closed-world, so the safety profile is settled. The description adds genuinely new behavioral context: results are auth-scoped to the calling key and each row carries the key owner's role, plan, and a completeness flag relevant to official submissions — disclosure the annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, no filler. The payload contents come first and the operational instruction ('call this first') is placed last where it lands as the takeaway.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description carries the burden of describing returns — and it does, covering scope, per-farm role, plan, and submission-readiness. Combined with annotations covering safety and idempotency, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero input parameters, so there is nothing for the description to document and the baseline applies. The description instead characterizes the output shape, which is a useful substitute given there is no output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list) and resource (farms/explotaciones) and immediately scopes it to what the API key can see. It also enumerates the return payload (role, plan, holder-data completeness), so an agent knows exactly what this returns and how it differs from any other listing tool among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call this first to get farm ids' gives explicit sequencing guidance — the tool is framed as the entry point whose output feeds other calls. No alternatives or exclusions are named, but none of the sibling tools overlap in this domain, so there is little to exclude.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Groups (a company or cooperative holding several farms) the key owner belongs to, with their role.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds the useful constraint that results are limited to groups the key owner belongs to and include role information, but says nothing about ordering, pagination, or empty-result behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the resource definition and then the scoping rule. Every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of explaining returns; it partially does so by noting the role is included, but omits the group's other fields (name, id) and whether multiple groups can be returned. For a trivial zero-parameter read this is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4. Nothing in the description misrepresents the absence of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The name and title supply the verb (list) and resource (farm groups), and the description defines what a group is ('a company or cooperative holding several farms') and scopes the result to the key owner. It is clear and specific, but it never distinguishes itself from the sibling group_overview, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'the key owner belongs to' implicitly tells the agent this returns only the current owner's groups, which is useful scoping context. However, there is no explicit when-to-use guidance and no mention of when to prefer group_overview or any other sibling, 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.
Register a task in the farm's field notebook (needs a key with write scope). The entry is attributed to the key owner and marked as written by API in the audit trail; the server stores when it arrived and rejects future dates. It only adds new entries: it never edits or deletes existing ones. Confirm the farm, parcel, product and date with the user before calling it. Official submission to the administration is never done here: it needs a person's session in the app.
| Name | Required | Description | Default |
|---|---|---|---|
| unit | No | Unit, e.g. 'L/ha', 'kg', 'mm' | |
| title | Yes | Short title, e.g. 'Tratamiento · Azufre mojable' | |
| farm_id | Yes | Farm id from list_farms | |
| event_at | Yes | When it happened (ISO 8601 with offset) | |
| quantity | No | Quantity applied | |
| crop_code | No | EPPO crop code, e.g. OLVEU | |
| cost_cents | No | Cost in euro cents | |
| entry_type | Yes | Kind of task | |
| safety_days | No | Pre-harvest interval in days | |
| product_name | No | Product or input used | |
| parcel_refcat | Yes | Cadastral reference of the parcel | |
| treated_area_ha | No | Treated area in hectares | |
| registration_number | No | Official registration number of the product (fito) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (not readOnly, not idempotent, non-destructive), and the description adds substantial context beyond them: it needs a write-scoped key, entries are attributed to the key owner and marked API-written in the audit trail, the server timestamps arrival, future dates are rejected, and it is strictly additive (never edits or deletes). This is exactly the behavioral disclosure a mutation tool needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the write-scope requirement are front-loaded, and the remaining sentences are informative rather than filler. It is slightly long at five sentences, but each one carries a distinct constraint (attribution, timestamping, add-only, confirmation, submission boundary).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter, no-output-schema mutation tool, the description covers the essential behavior: scope requirements, attribution, side effects and the add-only guarantee. Its only real gap is not indicating what the call returns (e.g., the created entry identifier), which would help chaining, but overall it is sufficient to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 13 parameters and the enum. The description only indirectly highlights farm, parcel, product and date as the values to confirm, without adding format or meaning beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Register a task in the farm's field notebook.' This clearly distinguishes it from read-oriented siblings like list_entries and entry_history, and an agent knows exactly what the call produces 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives real usage context: 'Confirm the farm, parcel, product and date with the user before calling it,' and clarifies the boundary that official administration submission is done elsewhere, in a person's app session. It stops short of naming a sibling tool as the alternative, but the when/when-not framing is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, no API key. Searches the official register of plant protection products (pesticides, fungicides, herbicides) of a European country by commercial product name and says whether each one is still authorised. Returns up to 15 matches with registration number, holder, status and a link to its page. Search by trade name (e.g. 'Roundup'), not by active substance.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | At least three letters of the commercial product name | |
| country | Yes | ISO 3166-1 alpha-2 country whose official register to use, e.g. ES, FR, DE, IT, PT, PL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world. The description adds genuinely new traits: no API key needed, a hard cap of 15 matches, and the exact fields returned. It does not describe pagination or how to get beyond 15 results, which is the one notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, front-loaded with the key facts (free, no key, what it searches). The result-limit and result-fields sentence is information-dense and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by enumerating the returned fields and the 15-result cap. Combined with the annotation-covered safety profile, an agent has everything needed to call and interpret this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds real meaning: q is the commercial trade name with an example ('Roundup') and an explicit exclusion of active substances, which prevents a common misuse. country is described as selecting which official register to query, matching the schema's ISO code definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb and resource: searching the official national register of plant protection products and reporting authorisation status. It also bounds scope (one European country, by commercial trade name) so an agent can distinguish it from a per-product lookup like check_plant_protection_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for use and an explicit negative constraint: 'Search by trade name (e.g. Roundup), not by active substance.' It does not name a sibling tool to use instead when the input is an active substance, so routing in that case is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Money to collect (receivable) and to pay (payable) with issue date, due date, paid date, status (open / overdue / paid) and days overdue, plus totals.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | ||
| farm_id | No | Farm id (from list_farms). Omit to use group_id | |
| group_id | No | Group id (from list_groups) for figures consolidated across its farms | |
| direction | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful content about what is returned (dates, status, days overdue, totals), but says nothing about pagination, date-range limits, or how overdue is computed relative to 'today'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with no filler, and the core value (what money is owed in each direction) is front-loaded. The trailing field list is dense but informative rather than wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does a decent job of enumerating return fields and totals, which partially compensates. But for a 4-parameter tool with 50% schema coverage, the silence on status/direction semantics and on farm_id vs group_id exclusivity leaves real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: farm_id and group_id carry descriptions, while status and direction do not. The description merely restates three of the four status values already given by the schema enum (and omits 'all'), and never mentions the direction parameter or the farm_id/group_id scoping rule, so it adds essentially nothing beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete resource — receivables and payables with their key fields (issue/due/paid dates, status, days overdue) plus totals — so an agent knows exactly what data comes back. However, there is no verb framing (e.g. 'list'/'get') and no explicit differentiation from financial siblings such as finance_dashboard, cash_flow or bank_movements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no mention of alternatives. An agent must infer that this is the tool for outstanding customer/supplier balances versus the dashboard/forecast siblings, with nothing in the text to confirm or exclude that choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0advisor_pendingadvisor_portfoliobank_movementsbudget_variancecampaign_forecastcash_flowcheck_plant_protection_productentry_historyfinance_dashboardgroup_overviewlist_entrieslist_farmslist_groupsrecord_entrysearch_plant_protection_productstreasury_duesScored across 16 tools
Most tools have clearly distinct purposes: field notebook operations, product lookups, farm/group listing, compliance review, and several financial views. There is some overlap between group_overview, advisor_portfolio, and finance_dashboard in reporting metrics, but descriptions scope them differently enough for an agent to choose correctly.
All names use consistent snake_case and are descriptive, which makes the set readable. The main deviation is that some tools use verb_noun (list_farms, record_entry) while others use noun_noun (finance_dashboard, budget_variance), but the pattern is still predictable.
16 tools is slightly above the ideal 3-15 range, but the server covers multiple domains: field entries, compliance, groups/advisors, product registers, and finance. Each tool appears to earn its place, so the count is reasonable rather than excessive.
The surface covers core read and reporting workflows plus entry creation, audit history, compliance review, product lookups, and extensive financial views. Minor gaps exist, such as no update/delete for entries and no active-substance product search, but these appear intentional or workable around.
Farm management for Brazilian farms: pest scouting, rainfall, work orders, inventory, fleet, post-harvest and cost per field. Reads and records, with OAuth on the user's own upCampo account. Nothing is ever deleted.
11.3M entities, 10 countries, 12 tools. EU VAT (VIES), BORME, GLEIF, KYB. Free: 100 req/month.
Free EU VAT (VIES) + pan-EU company data (10 registers), payable in EURC/USDC via x402.
Screen farm plots for EUDR deforestation risk with the official EU JRC maps.