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 personally on the filing page. Takes 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); any other argument, including a schema argument, is refused by name. The packet holds only facts the taxpayer stated in this chat and figures printed on documents the taxpayer gave in it. The tax year is return.taxYear=2025 inside the packet. Returns status filing_session_ready with one filingSessionUrl when the packet is accepted: the only response that contains the link, which the taxpayer opens to give permission, review the return and sign it. Otherwise returns blockers, each with a path, a rule and a plain detail, and no link: that packet is not kept, every blocker that can be checked arrives in one response, a check that depends on a missing or refused answer runs once that answer is corrected, and the same handle accepts a corrected packet. No filing link is issued until the packet holds every item the return and the filing page need from this conversation, the agentIdentity section included; each missing item comes back as its own blocker naming its path and the exact question for the taxpayer, all in one response, and only what the law has the taxpayer enter personally, the review and the signature are left for the filing page. A link left unopened for 15 minutes lapses, and sending the same packet again returns a new one. An accepted packet is held until the taxpayer gives permission on the filing page; declining there, or expiry, erases it. Federal only: no state, territory or local return is filed. The return has no taxpayer identity fields: the taxpayer's own details go only 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. The filing session's status reports progress.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
continuationHandleNo
packetSchemaSha256NoThe digest of this server's packet schema, as returned with the 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

TableJSON Schema
NameRequiredDescriptionDefault
statusNo
blockersNo
filingSessionUrlNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With destructiveHint=true and idempotentHint=true already declared, the description still adds substantial behavior: nothing is filed or sent to the IRS, blockers arrive all at once, a rejected packet is not kept, the link lapses after 15 minutes unopened, resending the same packet yields a new link, and an accepted packet is erased on decline or expiry. The erase-on-decline detail directly substantiates the destructive annotation.

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 detail is valuable, but the single dense paragraph is roughly 450 words with repetition: the taxpayer review/sign flow and the 'no filing link until the packet is complete' idea are restated two or three times. Trimming the duplicated signing and link-material sentences would keep every fact without the bulk.

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 multi-constraint setup call, everything an agent needs is present: prerequisites, accepted/blocker response shapes, expiry, resubmission, federal-only scope, and the agentIdentity requirement. Since an output schema exists, its coverage of return fields need not be duplicated, and the description still orients the agent on what the link is for.

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?

Schema coverage is only 67%, and the description compensates: it defines completedReturnPacketJson as the whole packet in this server's packet schema, packetSchemaSha256 as that schema's digest, and continuationHandle as the session's handle, plus it states that any other argument, including a schema argument, is refused by name. It also gives packet content constraints (tax year 2025, agentIdentity section) that the schema does not.

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 precise verb and resource: checks the completed draft packet, holds it as an unsigned draft and returns the filing-page link, or returns blockers. The scope statement ('This call files nothing') and the mention of returning a link versus problems clearly separate it from create_filing_session, get_filing_status and get_packet_schema.

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?

Gives clear context: use it when a session already exists (continuationHandle) and a packet is ready, refused arguments are named, and a corrected packet can be resubmitted to the same handle. It does not explicitly name get_filing_status or get_packet_schema as the alternative for progress or schema retrieval, so routing among siblings is inferred rather than stated.

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.