Sous

Overview Schema Source Related Servers Discussions Admin

Optional: Create a weekly standing order

create_standing_order

Saves a buyer's recurring weekly grocery order and usual delivery day without placing an order, so agents can renew the same repeat order each week.

Instructions

Save the buyer's recurring weekly order (e.g. milk + butter + cream every Monday). Places no order.

items: [{product_ids: [...candidates], amount, unit: 'L' | 'KG' | 'SALES_UNIT', label: 'milk'}]. weekday: mon..sun, the usual delivery day. Renew it each week with renew_standing_order.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "mandate_id": "<mandate_id>",
      "agent_id": "<agent_id>",
      "name": "<name>",
      "items": "<items>"
    },
    "name": "create_standing_order"
  }
}

Input Schema

Name	Required	Default
`name`	Yes
`items`	Yes
`weekday`	No	mon
`agent_id`	Yes
`mandate_id`	Yes

Output Schema

Name	Required	Description
`id`	Yes	SO-XXXXXXXX
`name`	Yes
`buyer`	Yes
`items`	Yes
`active`	Yes
`cadence`	Yes
`agent_id`	Yes
`created_at`	Yes
`mandate_id`	Yes
`updated_at`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 15, 2026

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent write. The description adds one genuinely useful behavioral fact beyond them: creating the standing order places no order. It does not mention that repeated calls will create duplicate standing orders (idempotentHint=false), nor what authorization/mandate is required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

Purpose is front-loaded and the prose is short, but the pseudo-schema `items: [...]` line partially duplicates the already richly documented $defs and does so inaccurately (missing 'ST'). The mixed prose/notation formatting makes it less scannable than it could be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, and the no-order semantics plus renewal lifecycle are covered. Still, for a tool with four required parameters including a mandate identifier, the description omits what a mandate is needed for and what happens on the first scheduled run — gaps an agent must guess at.

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?

Top-level schema coverage is 0%, so the description must compensate. It explains the shape of `items` and the `weekday` value range (mon..sun), which helps, but leaves the required `mandate_id`, `agent_id` and `name` entirely unexplained — the two most consequential identifiers for a write tool. The unit notation also omits the 'ST' enum value present in the schema.

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?

The description states a specific verb and resource — saving a buyer's recurring weekly order — with a concrete example (milk + butter + cream every Monday). The line 'Places no order' sharply separates it from place_order and from immediate-purchase siblings, though it never names place_order as the one-off alternative.

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?

Usage context is implied by 'recurring weekly order', and the follow-up routing to renew_standing_order is explicit. However, there is no explicit statement of when to choose this over placing a one-off order, nor any prerequisite such as needing a mandate before a standing order can be created.

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

Deploy Server