Deere Ops Center MCP

Overview Schema Source Related Servers Discussions Admin

jd_list_equipment

Read-only

List machines and implements in an organization to get IDs, principal IDs, names, categories, types, and archive status needed for further equipment or machine queries.

Instructions

List the machines and implements in an organization.

    Returns id, principalId, name, category, type, archived and uri for each item. `org_id`
    comes from jd_list_organizations. The principalId of a machine is what the
    jd_get_machine_* tools (alerts, engine hours, hours of operation, location history,
    device state reports) take as `principal_id`; `id` is what jd_get_equipment takes. When
    `embed` is set, the full record with the embedded data is added to each item under 'raw'.

Input Schema

TableJSON Schema

Name	Required	Description
`ids`	No	Only these equipment IDs.
`embed`	No	Ask Deere to embed extra data in each item; returned under 'raw'.
`org_id`	Yes	Organization ID, from jd_list_organizations.
`archived`	No	True for archived equipment only, False for active only.
`category`	No	Only machines or only implements.
`capable_of`	No	'Connectivity' for connected equipment, '!Connectivity' for the rest.
`item_limit`	No	Page size, 1 to 5000. Deere's default applies when omitted.
`principal_ids`	No	Only equipment with these principal IDs.
`serial_numbers`	No	Only equipment with these serial numbers.
`organization_role_type`	No	Whether this organization controls the equipment or only sees it.

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

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds meaningful behavior: the exact identifier mapping between tools and the fact that `embed` injects the full record under 'raw'. It stops short of describing pagination semantics, which item_limit hints at but doesn't fully explain.

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?

Purpose is front-loaded in the first sentence, followed by return fields and ID semantics. It is dense but every sentence carries information relevant to correct invocation; the return-field list is slightly redundant given an output schema exists.

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 10-parameter list tool with full schema coverage, an output schema, and annotations, the description covers the essential cross-tool wiring an agent needs. Remaining gaps (paging behavior, default page size) are minor and partly covered by parameter descriptions.

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 genuine value by disambiguating `id` vs `principalId`/`principal_ids`, which are the most error-prone parameters in this tool and directly affect whether downstream calls succeed.

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 and resource ('List the machines and implements in an organization') and scopes it clearly. It is distinguishable from jd_get_equipment, which the description explicitly notes takes `id`, and from the jd_list_* siblings by resource.

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 strong chaining guidance: org_id comes from jd_list_organizations, and it explains that principalId feeds the jd_get_machine_* tools while id feeds jd_get_equipment. This tells the agent how to route the outputs. It does not explicitly state when to prefer this list over a single-entity get, but the context is clear.

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