Skip to main content
Glama
parissaahmadi

cmms-mcp-server

assign_work_order

Idempotent

Assign or reassign open work orders in a CMMS to a technician or supervisor; restricted to supervisors. Use to route maintenance tasks to the right person.

Instructions

Assign (or reassign) an open or assigned work order. Supervisors only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actorYesUsername performing the action, e.g. 'tech.a'. Never guess one.
assigneeYesUsername of a technician or supervisor.
work_order_idYesWork-order id such as WO-2026-0001.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
eventsYes
work_orderYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare this as a non-read-only, idempotent, non-destructive operation, so safety is covered. The description adds value beyond them by disclosing the authorization requirement ('Supervisors only'), which the agent cannot infer from annotations or schema, though it says nothing about side effects on notifications or prior assignees.

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?

Two short sentences, no filler, eligibility scope stated first and the authorization constraint second. Every clause earns its place.

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?

An output schema exists so return values need no explanation, annotations cover the safety profile, and the description supplies the missing auth requirement. What remains thin is the reassignment semantics (what happens to the previous assignee) and the failure mode for ineligible work-order states.

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% and each parameter has a clear description (actor, assignee, work-order id format), so the schema carries the load. The description adds no parameter-level meaning beyond confirming that work_order_id must reference an open or assigned order; 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 (assign/reassign) and resource (work order), plus a status constraint ('open or assigned') that narrows which work orders are eligible. It does not explicitly distinguish itself from sibling transition_work_order, which is the nearest ambiguity, so it falls one step short of top marks.

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

Usage Guidelines3/5

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

'Supervisors only' and 'open or assigned work order' give a precondition and an eligibility scope, which is implied usage guidance. However, it never names alternatives (e.g. transition_work_order for status changes) or says what to do when the work order is closed or already assigned to the target user, so routing guidance is incomplete.

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