schedule-iii

Save provision movements

save_provision_movements

Destructive

Upsert provision movements (additions, amounts utilised) per provision line. Omitted saved lines stay unchanged. To remove selected saved lines, pass remove_leaf_codes; to remove the entire saved set, pass clear_all (never both). An actual removal first returns an approval request; nothing changes then. Review current movements in the Schedule III workspace, then resend the unchanged request with the approval details to proceed.

Input Schema

TableJSON Schema

Name	Required	Description
`clear_all`	No
`client_id`	Yes	The entity (client) id — from list_clients.
`movements`	Yes
`period_id`	Yes
`template_id`	Yes
`removal_count`	No
`removal_token`	No
`remove_leaf_codes`	No

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotation destructiveHint=true, the description discloses critical behavioral traits: omitted saved lines stay unchanged (upsert semantics), removals first trigger an approval request and nothing changes until the request is resent with approval details, and the two removal modes are mutually exclusive. This provides significant operational context beyond the mere 'destructive' flag.

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?

The description is five sentences long and front-loaded with the core action. Each sentence adds valuable detail: upsert behavior, omission semantics, removal modes, approval flow, and required workflow. It is slightly longer than ideal but appropriately so given the tool's complexity and destructive potential.

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 complex tool with destructive capabilities and an approval workflow, the description covers the essential semantics: upsert behavior, removal handling, and the resend-with-approval process. It does not explicitly state the success response for regular saves, but given the output schema is absent and the workflow is clearly outlined, this is a minor gap. Overall, it gives an agent enough context to use the tool correctly.

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 description coverage is low (13%), and the description compensates well by explaining key parameters: remove_leaf_codes, clear_all, and the movements array (additions, utilised). It also hints at approval tokens via 'approval details.' However, it does not explain template_id or period_id, nor the exact format constraints for additions, so the compensation is strong but not complete.

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?

The description opens with a specific verb 'Upsert' and clearly identifies the resource as 'provision movements' per provision line. It also differentiates from sibling save tools (e.g., save_asset_movements) by naming the target. The additional detailing of removal modes and the upsert semantics leaves no ambiguity about what the tool does.

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 provides clear context on when to use the tool (to save provision movements) and how to handle removals (via remove_leaf_codes or clear_all, never both). It also outlines a workflow: review current movements in the Schedule III workspace, then resend with approval details. While it does not explicitly name alternative tools for other movement types, the context is clear enough for an agent to select this tool appropriately.

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

All schedule-iii tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct resource or action — get_* reads, save_* writes, confirm_* approves, preview_* shows consequences before approval. Even the management-data trio (budgets, allocations, variance) is cleanly separated by surface. Two-step flows like preview_chart_rebaseline → confirm_complete_chart are clearly sequenced, so an agent won't confuse the stages.

Naming Consistency5/5

Tool names follow a highly consistent verb_noun pattern: get_* for reads, list_* for discovery, save_* for section writes, confirm_* for approvals, create_* for new entities/centres, preview_* for pre-approval checks. The few one-offs (ingest_upload, upload_trial_balance, set_header_row) still fit the verb-first convention. No camelCase or style mixing.

Tool Count2/5

At 67 tools this is well past the 'too many' threshold. While the Schedule III domain genuinely is broad — statutorily mandated sections, two-phase approval flows, readiness checks, and a separate management-data area — the surface is heavy; an agent will spend real effort just surveying the tool list. Some consolidation of the save_reserves/provisions/assets movements or merging preview+confirm pairs is possible.

Completeness4/5

The surface covers the full lifecycle: upload → mapping/costing → grouping → capture (all statutory sections) → declarations → readiness → generate → finalise → download, plus entity setup and consolidated statements. Minor gaps: no tool directly exposes historical version diffing beyond list_snapshots, and the management-data section (budgets, allocations, variance) feels bolted on rather than integral to the core flow.

Resources

Need Help?