AgentTax

AgentTax MCP Server

Tax compliance for MCP tool developers and AI agents, powered by AgentTax.

For MCP tool developers

If you build MCP tools that charge for usage, you have sales tax obligations in states where your buyers are located. Most payment processors don't handle this correctly for digital services.

Add AgentTax to your MCP setup and call track_payment after every payment. That's it.

{

"mcpServers": { "agenttax": { "command": "npx", "args": ["@agenttax/mcp-server"], "env": { "AGENTTAX_API_KEY": "atx_live_your_key" } } } }

After a payment:

track_payment({

amount: 49.00, buyer_state: "TX", buyer_zip: "78701", description: "MCP API access — monthly subscription", payment_id: "pi_stripe_abc123", source: "stripe" })

Returns your tax liability, compliance status, and logs it to your account. All transactions are viewable in your AgentTax dashboard.

Stripe webhook (fully automated)

For fully automatic tax tracking without calling any tool manually, point your Stripe webhook to AgentTax:

1. In Stripe Dashboard → Developers → Webhooks, add an endpoint:

   https://agenttax.io/api/v1/webhooks/stripe?key=atx_live_YOUR_KEY

1. Select events: payment_intent.succeeded, checkout.session.completed, invoice.paid, charge.succeeded
2. Optional: set metadata.work_type on your Stripe products (compute | research | content | consulting | trading) for precise tax classification

Every payment is automatically classified, taxed, and logged. No code changes required.

Requires a billing address on the Stripe payment. Enable full address collection in your Stripe Checkout settings.

---

Install

Claude Code

claude mcp add agenttax -e AGENTTAX_API_KEY=atx_live_your_key -- npx -y @agenttax/mcp-server

Claude Desktop / Cursor / Windsurf

Add to your MCP config file:

{

"mcpServers": { "agenttax": { "command": "npx", "args": ["@agenttax/mcp-server"], "env": { "AGENTTAX_API_KEY": "atx_live_your_key" } } } }

Demo mode works without a key (10 calls/day, no account required). Tools marked "Yes" below need AGENTTAX_API_KEY.

---

Tools

Read-only tools carry the MCP readOnlyHint annotation so clients can auto-approve them.

track_payment

track_payment({

amount: 49.00, buyer_state: "TX", buyer_zip: "78701", description: "MCP tool subscription", work_type: "content", payment_id: "pi_stripe_abc123", source: "stripe" })

Returns tax_owed, tax_rate, taxable, transaction_id, a classification (where the work type came from) and a compliance_note. Sellers get $0 in states where no nexus is configured. That $0 is a default, not a determination, and the response says so: nexus_status (unknown / no_nexus_profile), tax_if_nexus (what the payment owes once nexus is set), nexus_warning (the API's NEXUS_NOT_CONFIGURED advisory or demo note) and a compliance_note such as "No sales tax collected because no nexus is configured for WA ... If you have nexus in WA, this payment owes $6.50 (6.5%)." Keyless calls use AgentTax's shared demo nexus profile, not yours.

Pass `work_type` explicitly (compute | research | information_service | content | consulting | trading | payment_processing | web_hosting | software_maintenance | it_support | custom_software) when you know what you sold. The last five are the classification work types the API added in October 2026: a payment or facilitator fee, hosting the buyer's own site, a software maintenance contract, IT support, and software written for one buyer. Each sends its own transaction_type and the API answers with that state's rule for it. It is a declaration and gives the exact answer, and it is the only way the consulting or trading exemption applies: for example, AI consulting sold to an Arizona buyer is an exempt professional service (A.R.S. §42-5061(A)(1), TPR 93-48), so work_type: "consulting" returns $0 in AZ. Without work_type the server guesses from description, but a guess never takes the consulting or trading exemption: a description that looks like consulting (e.g. "SOC 2 audit platform subscription") or trading is taxed as SaaS, and classification.note tells you to resend with work_type if the guess was right. A description that looks like compute or research keeps the 1.1.1 classification, which can tax less than SaaS in some states (e.g. CT, MD, SC, TN, WV); pass work_type for an exact answer. Leave is_b2b out when you don't know the buyer; false declares a consumer. Upgrading from 1.1.1? Some track_payment results change; see CHANGELOG.md.

calculate_tax

calculate_tax({

role: "buyer", amount: 500, buyer_state: "TX", buyer_zip: "78701", transaction_type: "compute", work_type: "compute", counterparty_id: "seller-agent-123", is_b2b: true })

Optional fields: seller_state / seller_zip (origin-sourced intrastate sales in TX, UT, AZ, TN and some OH sales), use_context (Maryland B2B), digital_content_type (with transaction_type: "digital_good"), seller_remitting. transaction_type and work_type are sent exactly as given and treated as declared facts; don't guess them (consulting is exempt in Arizona).

Classification facts (optional; sent to the API as given, except that payment_provider_type and it_support_scope are trimmed and lowercased first, as the API does). Each one applies to one of the classification types; leave it out and the API gives its conservative default for that type.

• payment_provider_type (bank | licensed_money_transmitter | card_network | processor_routing_to_bank_or_network | other), with transaction_type: "payment_processing_fee": who provides the payment processing.
• it_support_scope (help_desk_advice | remote_repair_or_config | software_installation | monitoring | security_monitoring | managed_bundle), with it_support: what the engagement is. Absent means managed_bundle.
• includes_prewritten_software_access (boolean), with transaction_type: "web_hosting": true when the plan gives the buyer vendor software beyond an incidental control panel or file manager (site builder, CMS or app platform, email or office suite, managed application).
• custom_software_attestation, required with work_type: "custom_software"; without a complete one the sale is answered as prewritten software / SaaS. Required keys: written_for_buyer, not_offered_to_others, deliverable (source_code | compiled_artifact | hosted), is_modification_of_prewritten. Optional state facts: separately_stated_charge, all_rights_transferred, delivery (electronic | tangible), il_requirements_analysis_and_adaptation, il_assembled_modules_50pct.
• maintenance_contract, with transaction_type: "software_maintenance". All keys optional: mandatory, includes_upgrades, includes_support, separately_itemized, itemized_amounts ({ updates, support }, summing to amount), update_delivery (electronic | tangible), support_kind (help_desk_only | includes_fixes), seller_sold_software, business_use.

Both objects are strict, as in the API: an unknown key is refused before the call is sent. The facts are your representation and are recorded with the transaction. track_payment does not take them; use calculate_tax when you have them. ingest_transactions records take the same facts per record and pass them through to the API, which validates them; leave them out and an ingested classification sale gets the conservative answer.

calculate_tax({

role: "seller", amount: 12000, buyer_state: "TX", counterparty_id: "client-42", transaction_type: "saas", work_type: "custom_software", custom_software_attestation: { written_for_buyer: true, not_offered_to_others: true, deliverable: "source_code", is_modification_of_prewritten: false } })

`intent` (optional, "estimate" | "record"). Pass "estimate" to quote a price before a wallet signs. An estimate is computed and counts toward your monthly quota, but it is never saved to your transaction history, never counts toward nexus revenue, and ignores any idempotency key. With an API key and no intent, the call is a "record" and is logged. Keyless demo calls are always estimates. The server sends intent only when you pass it. It needs the AgentTax API release that accepts intent (live on agenttax.io since 2026-10-21).

`resolution` in the response says how sure each part of the answer is. resolution.location, resolution.nexus and resolution.taxability each carry a status (resolved, partial or unknown), a basis (for example zip_local_rate, state_only, no_nexus_profile, fact_not_declared) and a detail sentence. total_tax is always returned, never withheld. If your rule is "unknown means do not charge", branch on the status yourself:

// Pseudo-code. quote = the parsed JSON result of the calculate_tax tool call

const price = 20; const quote = await calculate_tax({ role: "seller", amount: price, buyer_state: "NY", buyer_zip: "10001", transaction_type: "saas", counterparty_id: "buyer-agent-7", intent: "estimate" });

if (quote.resolution.nexus.status === "unknown") { // No nexus profile configured: total_tax may be $0 only because nexus was never set up. // Run configure_nexus, or hold the sale for review, instead of charging $0. } else { charge(price + quote.total_tax); }

Nexus

get_nexus_thresholds({ state: "NY" })          // what triggers registration

configure_nexus({ nexus: { TX: { hasNexus: true, reason: "Economic nexus" } } }) get_nexus() // what you have configured

Capital gains and 1099-DA

log_trade({ asset_symbol: "ETH", trade_type: "buy", quantity: 2, price_per_unit: 2500, asset_class: "crypto" })

log_trade({ asset_symbol: "ETH", trade_type: "sell", quantity: 1, price_per_unit: 3100, asset_class: "crypto" }) export_1099_da({ year: 2026 }) // draft, not a filed return

---

Get an API Key

curl -X POST https://agenttax.io/api/v1/auth/signup \

-H "Content-Type: application/json" \ -d '{"email": "you@example.co