Deere Ops Center MCP

Overview Schema Source Related Servers Discussions Admin

jd_export_field_operations

DestructiveIdempotent

Export all field operations for one field across multiple seasons into a JSON file, including dates, crops, products, and totals. Returns the file path and per-season operation counts.

Instructions

Save every field operation for one field across several seasons to a JSON file.

    Use this for multi-season history (for example five years of planting, applications
    and harvests) instead of reading each season into the conversation. Each operation
    includes its dates, crop, products, varieties and measurement totals such as area,
    rate and yield. The JSON file holds org_id, field_id and a "seasons" object mapping
    each year to its list of operations. This tool returns the file path and the number of
    operations per season, not the operations themselves; use jd_list_field_operations to
    read a single season directly. Organization and field IDs come from
    jd_list_organizations and jd_list_fields. If a season is listed in truncated_seasons,
    it had more results than the page cap allows and the file holds only the first part.

Input Schema

TableJSON Schema

Name	Required	Description
`org_id`	Yes	Organization ID, from jd_list_organizations.
`seasons`	Yes	Crop seasons (years) to export, for example [2022, 2023, 2024].
`field_id`	Yes	Field ID, from jd_list_fields.
`filename`	No	File name to save as, inside the output folder. Defaults to field-<field_id>-operations.json.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 16, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the file-writing nature is partly covered. The description goes further by describing the file's contents (org_id, field_id, seasons map), the return payload (file path plus per-season counts, not the operations), and the truncated_seasons caveat when the page cap is hit. That is substantial added disclosure, though it does not address what happens to an existing file at the same filename.

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?

Front-loaded with the core action and scope, then usage, then output shape and truncation. Each sentence carries useful information, though it runs a bit long across five sentences for a tool this simple.

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?

Covers the scoping, the alternative sibling, ID sources, the file layout, the returned summary (path and counts), and the truncation edge case. Even with an output schema present, the explanation of what the file contains and what is NOT returned is exactly what an agent needs to avoid mis-using 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 description coverage is 100%, so org_id, field_id, seasons and filename are already documented in the schema, including the filename default. The description adds only the ID provenance and a sample seasons list, which the schema already implies. 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?

States a specific verb+resource+scope: saving all field operations for one field across multiple seasons to a JSON file. It explicitly distinguishes itself from jd_list_field_operations, which reads a single season, so an agent can separate the two without opening either schema.

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

Usage Guidelines5/5

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

Gives an explicit when-to-use ('multi-season history ... instead of reading each season into the conversation') and an explicit alternative ('use jd_list_field_operations to read a single season directly'), plus points to jd_list_organizations and jd_list_fields for the required IDs. Nothing about selection 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.