sixty60-mcp

Sixty60 orders

sixty60_orders

Read-only

List active Sixty60 orders, switch to full order history with all=true, or pass an order reference to inspect its items and status.

Instructions

Order list. Active orders by default; set all=true for history. Pass reference to get one order's items and status.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "sixty60_orders"
  }
}

Input Schema

Name	Required	Description	Default
`all`	No
`reference`	No	An order reference from the list, for full details.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 9, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Annotations only declare readOnlyHint=true; the description usefully adds that the default scope is active orders and that supplying a reference changes the response to a single order with items and status. It does not cover pagination, ordering, or how many orders come back, so the behavioral picture is partial rather than complete.

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?

Three short sentences, front-loaded with what the tool is before the mode-switching rules. Every sentence carries operational information; nothing is padding.

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 two-parameter read tool with readOnlyHint already set and no output schema, the description covers scope defaults, the history toggle, and the drill-down mode. Missing only minor detail such as result volume or ordering, which is low-risk for this tool's complexity.

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 50% – `reference` is documented in the schema but `all` is not – and the description fills exactly that gap by explaining all=true switches to history. It also clarifies that reference must come from the list and expands the result to items and status, adding meaning beyond the schema text.

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?

"Order list" names the resource and operation, and the two modes (default active list vs. single order via reference) are spelled out, so an agent can tell how this differs from list-like siblings. It does not explicitly distinguish itself from sixty60_past_purchases, which appears to overlap with the all=true history mode.

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?

The description gives clear selection rules between its own modes: leave defaults for active orders, set all=true for history, pass reference to get one order's items and status. It stops short of naming an alternative sibling (e.g., past_purchases) when history is the goal, so the routing is clear internally but not against siblings.

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

Deploy Server