Agro GPS

Campaign close forecast

campaign_forecast

Read-onlyIdempotent

Estimate how each crop's campaign will close: yield x price minus costs and pending budget, shown as low/mid/high ranges total and per hectare. Indicates if assumptions are saved, reused, or missing.

Instructions

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "farm_id": "<farm_id>"
    },
    "name": "campaign_forecast"
  }
}

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Sep 29, 2026

TDQS

A3.7/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

Deploy Server