Deere Ops Center MCP

Overview Schema Source Related Servers Discussions Admin

jd_get_machine_location_history

Read-only

Retrieve GPS location points for a machine across a date range, or its current position, to review equipment movement history.

Instructions

Get GPS location points for one machine.

    Returns the points under 'locations'. `principal_id` comes from jd_list_equipment. Deere
    allows at most 1 month between start_date and end_date in a single request. For where the
    machine is now, prefer last_known=True instead of pulling history.

Input Schema

TableJSON Schema

Name	Required	Description
`end_date`	No	End of the window, ISO 8601 UTC, e.g. 2026-10-07T00:00:00Z.
`last_known`	No	True for only the most recent position.
`start_date`	No	Start of the window, ISO 8601 UTC, e.g. 2026-10-01T00:00:00Z.
`principal_id`	Yes	Machine principal ID: the 'principalId' of an item from jd_list_equipment.

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.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond that: results arrive under a 'locations' key, Deere enforces a maximum 1-month span per request, and principal_id must be sourced from jd_list_equipment. No auth or pagination detail, and nothing contradicts 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.

Conciseness5/5

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

Four short sentences, front-loaded with the purpose, then return shape, then prerequisites, then the alternative mode. Every clause carries information; no filler or restatement of the name.

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?

An output schema exists, so return values need not be described in depth, and the description still notes the 'locations' container. Combined with complete parameter docs and an explicit range limit and dependency, an agent has everything needed to invoke it 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?

Schema coverage is 100%, so all four parameters are already documented with formats and defaults (ISO 8601 UTC, last_known semantics). The description still adds cross-tool provenance for principal_id and the relational constraint between start_date and end_date, which the schema does not express.

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 verb and resource with clear scope: 'Get GPS location points for one machine.' An agent immediately knows this is telemetry history, not alerts or engine hours. However, it never names a sibling tool it should be chosen over, 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 Guidelines4/5

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

Gives concrete usage direction: 'For where the machine is now, prefer last_known=True instead of pulling history,' and states the 1-month window constraint. It does not, though, route the agent between this tool and other machine-level tools such as jd_get_machine_device_state_reports.

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