Skip to main content
Glama

schedule-iii

Ingest upload into the books

ingest_upload
Destructive

Commit a validated upload into the entity’s books. This is a TWO-CALL approval: if the upload has any warnings, or would permanently delete existing trial-balance rows for a period it covers, the first call writes NOTHING and refuses with every warning, the exact record counts, and a short-lived removal_token. Show your user every warning and both counts, get their explicit go-ahead, then resend the SAME call adding removal_token and removal_count exactly as returned. acknowledge_warnings is IGNORED on this connection — the token is the only acknowledgment, so sending it changes nothing. A clean, additive ingest needs no token and succeeds on the first call. Returns the ingestion outcome including any notices.

Input Schema

NameRequiredDescriptionDefault
upload_idYesThe upload session id returned by upload_trial_balance.
removal_countNoThe exact removal count returned by the removal preview.
removal_tokenNoOnly include the short-lived token returned by the removal preview for this exact upload.
confirm_mergesNo
acknowledge_warningsNo
acknowledged_state_digestNoBrowser/REST only, and IGNORED on the agent connection exactly as acknowledge_warnings is: the destroy_state_digest returned by the confirm-mapping step, resent unchanged so the server can prove the acknowledgment was given against the data that is still there. On this connection the removal_token already pins the rows at risk, so sending this changes nothing.
confirm_identity_correctionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / confirm_identity_correction
      Added value: +{
      +  "type": "boolean"
      +}
  2. Changed3 schema fields changed
    • addedInput schema / properties / acknowledged_state_digest
      Added value: +{
      +  "description": "Browser/REST only, and IGNORED on the agent connection exactly as acknowledge_warnings is: the destroy_state_digest returned by the confirm-mapping step, resent unchanged so the server can prove the acknowledgment was given against the data that is still there. On this connection the removal_token already pins the rows at risk, so sending this changes nothing.",
      +  "pattern": "^[0-9a-f]{64}$",
      +  "type": "string"
      +}
    • addedInput schema / properties / removal_count
      Added value: +{
      +  "description": "The exact removal count returned by the removal preview.",
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedInput schema / properties / removal_token
      Added value: +{
      +  "description": "Only include the short-lived token returned by the removal preview for this exact upload.",
      +  "maxLength": 200,
      +  "minLength": 20,
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Discloses the destructive behavior beyond the destructiveHint annotation, including permanent deletion of existing trial-balance rows. It also explains the two-call approval protocol, that the first call writes nothing when warnings/deletions exist, and that acknowledge_warnings is ignored on this connection.

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?

Front-loads the core action and then walks through the two-call protocol efficiently. Every sentence carries operational meaning, including the warning about ignored acknowledgment fields.

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?

Provides the full decision flow for a complex destructive ingest, including what to show the user and how to resend with the token. The main gap is unexplained semantics for the optional merge and identity-correction parameters.

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?

Adds substantial meaning beyond the schema for removal_token, removal_count, and acknowledge_warnings, including that the token is the only valid acknowledgment on this connection. However, it does not explain the confirm_merges or confirm_identity_correction parameters, which lack schema descriptions.

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?

States a specific verb and resource: commit a validated upload into the entity’s books. It clearly distinguishes this from uploading/validating by referring to a validated upload and tying it to the upload_trial_balance workflow.

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?

Explains exactly when a token is needed: any warnings or permanent deletion of existing rows triggers a first-call refusal, while a clean additive ingest succeeds without a token. It gives clear operational context but does not explicitly name alternative sibling tools.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources