Skip to main content
Glama

Continue filing session

continue_filing_session
DestructiveIdempotent

Checks the taxpayer's completed draft packet for a federal return and, when it passes, holds it as an unsigned draft and returns the link to the filing page; otherwise returns a list of problems to correct. This call files nothing and sends nothing to the IRS: the taxpayer reviews, signs and files on the filing page.

Inputs: the filing session's continuationHandle, completedReturnPacketJson (the whole packet as one JSON string, in this server's packet schema) and packetSchemaSha256 (that schema's digest); other arguments are refused by name. The tax year is return.taxYear=2025 inside the packet. The packet carries the facts the taxpayer stated in this chat and the figures printed on documents the taxpayer gave in it; a fact the taxpayer has not stated is left out rather than written as no, none or 0, and a required fact that is left out comes back as a blocker asking for the taxpayer's answer.

Output: status filing_session_ready with a filingSessionUrl when the packet is accepted; the taxpayer opens that link to give permission, review the return and sign it. Otherwise, blockers (each with a path, a rule and a plain detail) and no link; that packet is not kept, and the same handle accepts a corrected packet. Nothing is filed or charged through a link that expires or is left unfinished, and the same packet sent again with a new filing session's handle returns a fresh link. An accepted packet is held until the taxpayer gives permission on the filing page; declining there, or expiry, erases it. Federal returns: no state, territory or local return is filed. The return has no taxpayer identity fields: the taxpayer's own details go in the packet's separate, required agentIdentity section, which the filing page shows for the taxpayer to confirm. Business identifiers printed on each source form, such as an employer's or payer's name and EIN, are packet fields.

Input Schema

NameRequiredDescriptionDefault
continuationHandleNo
packetSchemaSha256NoThe current digest returned by get_packet_schema. The server checks it against the current packet schema; packet-schema-stale means the submitted digest no longer matches that schema.
completedReturnPacketJsonNoThe complete return packet as one JSON string, in this server's packet schema. Its values are the facts the taxpayer stated and the figures printed on the taxpayer's documents.

Output Schema

NameRequiredDescriptionDefault
statusNo
blockersNo
filingSessionUrlNo
readBackToTaxpayerNoWith the filing link: the packet's own answers to the which-apply questions, in plain words, to read to the taxpayer before they open the link.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: nothing is filed or sent to the IRS, accepted packets are held only until taxpayer permission, declining or expiry erases them, rejected packets are not kept, and federal-only scope applies. These details clarify the destructive and idempotent behavior implied by the annotations without contradicting them.

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 front-loaded and every section contributes useful information about behavior, inputs, and outputs. It is long and dense, with some run-on sentences, but the length is largely justified by the complexity of the filing handoff.

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

Completeness5/5

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

For a complex, mutating, potentially destructive filing tool, the description is complete: it covers what is filed or not filed, what happens on acceptance and rejection, retry semantics, expiry and erasure, federal-only scope, and identity handling. With an output schema present, it does not need to explain return-value structure further.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 67%, the description adds meaningful semantics for all key inputs: continuationHandle, completedReturnPacketJson as the whole packet in this server's schema, packetSchemaSha256 as the schema digest, the required tax year inside the packet, and the required agentIdentity section. It also explains that omitted taxpayer facts become blockers rather than default zero/no values, which is valuable guidance beyond the schema.

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 states a precise verb and resource: it checks a completed draft federal return packet, holds an accepted packet as an unsigned draft, and returns a filing-page link or blockers. This is clearly differentiated from creating a filing session or retrieving the packet schema, so an agent can identify the tool's role immediately.

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?

It makes clear when this call is appropriate: after a completed return packet exists for a filing session, and when the taxpayer needs review/signature or correction feedback. It also explains retry behavior with blockers and corrected packets, but it does not explicitly name sibling tools or state when not to use this tool.

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.