cmms-mcp-server

list_work_orders

Read-onlyIdempotent

Retrieve and filter work orders by status, priority, asset, or assignee, sorted by priority then due date to help prioritize maintenance tasks.

Instructions

List work orders, highest priority first, then earliest due date.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Page size (1-100).
`offset`	No	Items to skip; use next_offset from the previous page.
`status`	No	Filter by status.
`asset_id`	No	Only work orders of this asset, e.g. AST-0001.
`assignee`	No	Username the work is assigned to.
`priority`	No	Filter by priority.
`overdue_only`	No	Only active work orders past their due date.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`items`	Yes
`total`	Yes
`next_offset`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 19, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent and non-destructive, covering the safety profile. The description adds the one behavioral trait they don't: the deterministic sort order. It says nothing about pagination behavior or result caps, though the schema's offset hint partially covers that.

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?

A single tight sentence with the ordering constraint front-loaded after the verb; nothing is wasted. It is arguably too terse for a 7-parameter list tool, which keeps it from a 5.

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 an output schema present and full parameter descriptions, the description need not explain return values or field semantics. The annotations cover safety, and the sort order is disclosed; only the pagination contract and the absence of filter guidance remain mild gaps.

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 all seven parameters are already documented in the schema (including the next_offset pagination hint). The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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+resource ('List work orders') plus a meaningful default ordering (priority, then due date). It implicitly distinguishes itself from the singular get_work_order sibling, but never explicitly names alternatives, so it stops just 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 Guidelines2/5

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

The description gives no when-to-use or when-not-to-use guidance and never points to get_work_order for a single record or create/assign/transition siblings for mutations. An agent must infer from the name alone that this is the browse/enumerate entry point.

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

Deploy Server