F
licenseA
qualityD
maintenanceEnables AI assistants to help compile the Italian Modello 730 income tax return by providing IRPEF calculations, deduction tools, and tax rule guidance.
12
23
-
Terminal Tax
by tax.terminal
Server Details
E-file a 2025 US federal Form 1040 from your AI assistant; you review and sign on one hosted page.
Ownership verified
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- maxdhs/terminal-tax-mcp-server
- GitHub Stars
- 0
TDQS
A4.1/5.0
Scored across 4 tools
Disambiguation4/5
The four tools map to distinct lifecycle stages: start a session, fetch the schema, submit the packet, and read status. The only mild overlap is between create_filing_session and continue_filing_session, both of which touch the same continuationHandle and both mention filingSessionUrl, so an agent could momentarily confuse which one submits the packet.
Naming Consistency5/5
All four names follow a consistent verb_noun pattern (create_/continue_/get_ + filing_*). The shared filing_* stem makes the domain obvious and predictable across the set.
Tool Count4/5
Four tools is on the lean side for such a large domain, but the workflow is coherent: create, schema, submit, status. Each tool earns its place, with no filler or redundant entries.
Completeness4/5
The core federal filing lifecycle (create session, understand the packet schema, submit, check status) is fully covered, and the federal-only scope is explicit. Minor gaps exist: there is no explicit tool to withdraw/cancel a session or to retrieve/amend an already accepted return, leaving a few dead ends.
Available Tools
4 toolscontinue_filing_sessionContinue filing sessionADestructiveIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| continuationHandle | No | ||
| packetSchemaSha256 | No | The digest of this server's packet schema, as returned with the schema. | |
| completedReturnPacketJson | No | The 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| status | No | |
| blockers | No | |
| filingSessionUrl | No |
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.
create_filing_sessionStart filing sessionADestructiveInspect
Starts a filing session when the taxpayer asks to file a US federal individual income tax return. Receives no tax facts. Takes the taxpayer's answers to where they live now (residenceState), which state returns this filing carries (stateReturns) and whether anyone on the return lives in Connecticut or lived there this year (anyoneInConnecticut), and returns a continuationHandle, which identifies this filing session in later calls. Without a filingSessionUrl in the answer, the one link is returned when the service accepts the complete packet. A Connecticut filer's return is sent only after the taxpayer's own permission, so where those answers point to Connecticut or are not given, a deployment that files real returns also returns the filingSessionUrl at once and the packet follows that permission. Federal only: covers the US federal individual return and no state or local return. What can be filed: one original TY2025 federal Form 1040 or 1040-SR, or a tax year 2025 Form 1040-SS for a single bona fide resident of Puerto Rico with no Form 1040 filing requirement who owes self-employment tax on Schedule C business profit (net self-employment earnings of $400 or more), with no other income, credits, wages, estimated tax, or farm, partnership or church self-employment income; no state or local return, amendment, extension or 1040-NR. Accepted situations include W-2 wages (with the Form 2555 foreign earned income exclusion), 1099-INT and 1099-DIV with Schedule B, the foreign tax credit on dividends, some 1099-B/1099-DA sales, 1099-G, 1099-C (with the Form 982 bankruptcy, insolvency or principal residence exclusion), 1099-R with the Form 5329 additional taxes and Form 8606 IRA basis and Roth conversions, SSA-1099, W-2G, rental and royalty income (2025-placed rental depreciation and vehicle expenses on each rental's own Form 4562), some K-1 income, up to five Schedule C sole proprietorships (either spouse on a joint return) with Schedule SE and Form 1099-NEC, the self-employed health insurance deduction (Form 7206) and one SEP, SIMPLE IRA or solo 401(k) per person, head of household, some HSA (Form 8889), Archer or Medicare Advantage MSA distributions (Form 8853, filingChoices.form8853), Additional Medicare Tax, educator expenses, the residential clean energy credit, the clean vehicle credit for one new personal-use vehicle (Form 8936), the Lifetime Learning Credit, the refueling property credit (Form 8911), household employment taxes (Schedule H Part I, no federal unemployment tax), unreported tips (Form 4137, with Form 8959 above the threshold), Form 1099-NEC compensation reported as wages (Form 8919), dependents with the Child Tax Credit, Additional Child Tax Credit, Credit for Other Dependents and Earned Income Credit, the dependent care credit for children under 13, Form 8862 after an earlier-year disallowance, a decedent's return (a joint return signed by the surviving spouse, whose primary may be the spouse who died via filingChoices.jointReturnSignerFacts.primaryTaxpayerDied, or a single, head of household or married filing separately return signed by the personal representative, via filingChoices.decedentReturnSignerFacts, with a refund on Form 1310 via filingChoices.form1310), married filing separately in a community property state with wages, interest and dividends (Form 8958, filingChoices.communityPropertyAllocation), a cash-method Schedule F farm with a profit or an at-risk, materially participated loss and a profitable Form 4835 farm rental (each with the Form 8995 qualified business income deduction when all of its profit is qualified business income), Schedule 1-A deductions, standard or itemized deductions, student-loan interest, the qualified business income deduction (Form 8995; Form 8995-A for one Schedule C business and Schedule K-1 trades above the threshold), the American Opportunity Credit at the taxpayer's own Form 8863 amounts, the Saver's Credit, the premium tax credit (Form 8962), Net Investment Income Tax (Form 8960), K-1 returns included, Form 8615, estimated payments, and a refund or balance due (electronic funds withdrawal and Form 9465 included). Refused today: an EIC needing a disability answer, a Form 8862 child born or died in 2025, a dependent care credit for anyone 13 or older, a decedent's refund with a court-appointed representative, a joint return whose two spouses both died, community property married filing separately beyond allocated wages, interest and dividends, on a rental, section 179, a depreciated vehicle or 2025 amortization, a zero-profit Schedule C, a Schedule C loss without material participation or needing Form 6198, more than one business beside section 179 in two of them, statutory-employee income, Form 4361, Schedule C tips, Schedule F or Form 4835, the self-employed health insurance or retirement deduction beside the owner's own Schedule F, a K-1 or Marketplace coverage credits, a second plan of either kind for one person, and on Schedule C depletion (line 12), employee benefit programs (line 14) and the energy efficient commercial buildings deduction (line 27a). Blind, 65-or-older and no-one-can-claim-as-dependent are each required as an explicit answer; a blank is not read as no.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| No | The taxpayer's email address, used only to email the verification code for the filing page, under the Terminal Tax privacy notice. | ||
| stateReturns | No | The two-letter codes of the state returns this filing will carry; [] for a federal-only filing. | |
| residenceState | No | The state the taxpayer lives in now, as its two-letter code, e.g. NJ. | |
| anyoneInConnecticut | No | The taxpayer's own yes or no: whether anyone on this return (the taxpayer, a spouse or a dependent) lives in Connecticut now or lived there at any time this tax year. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| blockers | No | |
| filingSessionUrl | No | |
| continuationHandle | No |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite safety annotations already being present, the description adds substantial behavioral context beyond them: it takes no tax facts, returns a continuationHandle, gates the filingSessionUrl behind Connecticut-filer permission, and notes required explicit answers (blind/65+/dependent) that cannot be blank. It does not, however, explain the destructiveHint=true implication or the irreversibility of filing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence, but the body is an enormous run-on crammed with exhaustive eligibility lists that overwhelm the reader. Far more prose than an agent needs to select and invoke the tool, and the density makes it hard to parse rather than concise.
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?
The tool is complex (mutation-style session creation) with an output schema and full annotation coverage, and the description supplies the scope, permission gating and return handle needed to call it correctly. The output schema carries return-value detail, so the remaining gap around failure modes is minor rather than disqualifying.
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?
With 100% schema coverage the baseline is 3, and the description adds meaning beyond the schema: it frames residenceState/stateReturns/anyoneInConnecticut as the taxpayer's own answers and explains the Connecticut permission rationale behind that flag. It omits any description of the email parameter, but the schema covers it.
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 first sentence gives a specific verb and resource ('Starts a filing session') plus a clear trigger ('when the taxpayer asks to file a US federal individual income tax return'). It distinguishes the start of a session from a continuation by stating it returns a continuationHandle for later calls, though it never names the sibling continue_filing_session directly.
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 states the trigger condition and provides extensive when-not coverage through the 'Accepted situations' and 'Refused today' lists, so an agent can judge whether this tool can handle a given return. It stops short of naming alternatives, so it does not reach the explicit when/when-not/alternatives bar of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_filing_statusGet filing statusARead-onlyIdempotentInspect
Answers a taxpayer's question about the filing created through this connector: reads ordered, status-only results for every jurisdiction in its one current Terminal Tax filing. IRS results appear only for a filing whose taxpayer signed the optional status-sharing consent on the filing page; otherwise the status is results_emailed, and Terminal Tax emails the results to the taxpayer. Takes the filing session's continuationHandle, or no arguments on a legacy authenticated connector. Reads no return content, payment data, identity, raw IRS rejection text or filing history.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| continuationHandle | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| filings | No | |
| nextStep | No |
TDQS
A4.1/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, openWorld), the description discloses real behavior: the consent-gated IRS results, the fallback results_emailed status and emailing behavior, and an explicit enumeration of what it does NOT read (return content, payment data, identity, raw IRS rejection text, history). This is unusually rich context that annotations alone could not convey.
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 core action is front-loaded in the first clause, followed by the gating condition and then the parameter note. It is dense and every sentence carries information, though the long run-on sentence could be split for easier scanning.
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?
An output schema exists, so return formatting need not be described. Combined with the consent gating, the results_emailed fallback, the scope exclusions, and the parameter mode, an agent has everything required to call this 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 0%, so the description must carry the parameter burden, and it does: it explains the continuationHandle comes from the filing session and that no arguments are used on a legacy authenticated connector. It doesn't cover the maxLength constraint, but the semantic origin and optionality are well explained.
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?
States a specific verb and resource: it 'reads ordered, status-only results for every jurisdiction' in the taxpayer's current filing. This clearly differentiates it from the session-management siblings by what it retrieves, though it never names an alternative tool explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the consent condition (IRS results only with signed status-sharing consent, otherwise results_emailed) and the handle/no-argument invocation modes. However, it never states when to reach for this versus continue_filing_session or get_packet_schema, so the routing guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_packet_schemaGet packet schemaARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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
ParametersJSON 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. |
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
- First observed
continue_filing_session - First observed
create_filing_session - First observed
get_filing_status - First observed
get_packet_schema
Related MCP Connectors
Verifiable US tax oracle for AI agents: cited, machine-checkable federal and state tax computation
Current source-cited 2026 US tax constants and calculators for AI agents; every answer cites IRS.
2026 state, city and platform tax profiles for gig workers and creators, plus Roth IRA signups.
44 calculators for AI agents: US tax, finance, business + an MCP engineering & security suite.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables AI assistants to compute US take-home pay, self-employment taxes, and capital gains taxes for the 2026 tax year using the engine from statetakehome.com.349 npmMIT
- AlicenseNot gradedqualityBmaintenanceEnables an AI assistant to build and update an IRPF 2026 tax return entirely on your machine, reading and writing the official program's .DBK backup file, adding income and expenses, computing tax under both the simplified and complete models, explaining every calculation line by line, checking integrity and flagging pending items. Nothing is sent over the network, and the resulting file is restored and transmitted by the user in the official Receita Federal program.AGPL 3.0
- AlicenseBqualityAmaintenance39 tax tools for US individual taxpayers — federal/state tax calculations, credits, deductions, retirement strategies, audit risk, and tax planning. All calculations run locally, no data leaves the machine. Supports TY2024 and TY2025 (One Big Beautiful Bill Act).44129 npm13MIT
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.