Terminal Tax

Get packet schema

get_packet_schema

Read-onlyIdempotent

Takes the filing session's continuationHandle. Returns the packet schema a completed return packet is checked against: requestPacketSchema=true returns the schema digest (packetSchemaSha256, sent with the completed packet), an outline whose larger parts are named sections, the section list and the packetStarterTemplates list; packetSchemaSection= returns one section and packetStarterTemplate= one complete starter packet, in which each taxpayer-specific value is the placeholder REPLACE_WITH_TAXPAYER_VALUE, refused by path until replaced, with its askTheTaxpayer messages (the questions for the taxpayer) and each preset answer listed in presets with how it is settled. Read-only: no tax facts are sent here and no return is written. The tax year is return.taxYear=2025 inside the packet, not a tool argument; any other argument is refused by name.

Input Schema

TableJSON Schema

Name	Required	Description
`continuationHandle`	No
`packetSchemaSection`	No	One section of the packet schema, by a name from packetSchemaSections. Returns that section's members exactly as they sit in the full schema, where the outline shows {"x-terminalTaxSchemaSection":"<name>"}, with the section's own sha256.
`requestPacketSchema`	No	Returns the packet schema outline, its section list and digest, and the starter-template list; no tax facts are sent and no return is written.
`packetStarterTemplate`	No	One complete starter packet, by an id from packetStarterTemplates.templates, with its askTheTaxpayer messages and its presets.

Output Schema

TableJSON Schema

Name	Required	Description
`blockers`	No
`packetSchemaSha256`	No	SHA-256 of the compact JSON serialization of the FULL packet schema: the outline with every section's members put back in place of its marker.
`packetSchemaOutline`	No	The packet JSON Schema with each sectioned member replaced by {"x-terminalTaxSchemaSection":"<section name>"}.
`packetSchemaSection`	No	One section: name, covers, parentPointer (JSON Pointer of the properties object its members belong to), sha256 and members.
`packetSchemaSections`	No	Every schema section left out of the outline: name, what it covers, its size in characters and the sha256 of its members.
`packetSchemaRetrieval`	No
`packetStarterTemplate`	No	One starter template: id, shape, askTheTaxpayer, packet and presets.
`packetStarterTemplates`	No	How to use a starter template, the presets every template carries, and the list of templates; a template's packet comes back with packetStarterTemplate.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive), it discloses that no tax facts are sent and no return is written, that unexpected arguments are refused by name, that the tax year lives inside the packet (return.taxYear=2025) rather than being an argument, and that starter-template values are placeholders (REPLACE_WITH_TAXPAYER_VALUE) refused by path until replaced. That is materially more than the structured fields provide.

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?

Front-loaded: the short first sentence identifies the input, the second says what is returned, and the read-only/refusal caveats close it out. The middle sentence is an ~90-word run-on with heavy nesting, which hurts scanability, though each clause carries non-redundant information.

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 tool with a oneOf-constrained schema, two enums and an output schema, the description supplies everything needed: mode selection, input source, placeholder/refusal semantics, and the tax-year location. Return shapes are covered by the output schema, so nothing essential is missing.

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 coverage is 75%, and the description goes further by explaining the semantics of the placeholder values, the askTheTaxpayer messages and presets inside starter packets, and the fact that continuationHandle comes from the filing session. The oneOf exclusivity is implied by the prose rather than stated as a rule, which is the main gap.

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 names a specific resource (the packet schema a completed return packet is checked against) and enumerates the three retrieval modes, so an agent knows exactly what it gets back. It never references the sibling tools (continue_filing_session, create_filing_session, get_filing_status), but the purpose is distinct enough that confusion is unlikely.

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 clearly routes between the three mutually exclusive modes: requestPacketSchema=true for the outline/digest/template list, packetSchemaSection=<name> for one section, packetStarterTemplate=<id> for one starter packet. It also states that other arguments are refused by name, which tells the agent not to invent parameters. It stops short of saying when this tool should be preferred over a sibling like get_filing_status.

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

All Terminal Tax tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.