Skip to main content
Glama

US compliance and books health

Get confounding questions

get_confounders
Read-onlyIdempotent

Refinement step, NOT the place to start: call list_compliance_obligations first, then call this to narrow what is still genuinely open. Returns the facts that flip an answer, such as whether an employer of record is the legal employer. Pass every fact you already know and it returns only what those facts leave unsettled. These are things for YOU to look up in the user's own documents. They are not a questionnaire to send the user.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
answersNoAnswers to the yes/no threshold questions this tool asks, keyed by the threshold id shown in the question, e.g. { "foreign-accounts-over-10k": false, "ny-sales-over-500k": false }. Without this the same questions repeat forever and the obligations behind them can never resolve. Omit a key you genuinely do not know.
answeredNoOnly for confounders with no matching fact field above (who-paid, prepaid-multi-year). For everything else pass the fact itself, e.g. payroll_model: 'eor', not answered: { 'payroll-model': 'eor' }.
tax_yearNoTax year under review. Defaults to last calendar year.
sells_saasNoWhether the product is SaaS. New York taxes SaaS as prewritten software.
entity_typeNoLegal entity type.
company_nameNoOptional, and the only identifying thing this tool records. Median stores it to see which companies use this tool and may follow up. It changes nothing about the answer, so omit it if the user has not agreed to share it. Send the legal entity name only, never an address, EIN or anything from a document.
revenue_bandNoGross annual revenue as a band, never an exact figure: 'pre-revenue', 'under-250k', '250k-1m', '1m-5m' or 'over-5m'. Drives revenue-scaled thresholds such as state franchise tax minimums and economic nexus. Leave unset if unknown; the tool asks for it rather than guessing.
sales_statesNoStates with customers.
foreign_ownedNoWhether any non-US person owns 25% or more. Leave unset if genuinely unknown.
payroll_modelNoCritical. An employer of record holds state registrations under its own entity, so the answer flips entirely on this.
presence_typeNoPer-state presence, e.g. { NY: 'virtual-mailbox' }.
registered_inNoWhether the company is already registered to do business in a state, e.g. { NY: false }. Drives obligations that only begin at registration.
formation_dateNoISO date the entity was formed.
employee_statesNoStates where W-2 employees work.
fiscal_year_endNoMM-DD, e.g. '12-31'. Defaults to 12-31.
formation_stateNoTwo-letter state of formation, e.g. 'DE'.
extensions_filedNoWhether a tax extension was filed, keyed 'US' for federal and by state code, e.g. { US: true, NY: false }. OMIT a key you are unsure about: no deadline is asserted for an unknown key, because assuming an extension tells a late filer they have months in hand.
operating_statesNoStates where the company operates.
payroll_providerNoThe provider's name only, e.g. 'Deel', 'Gusto', 'Rippling'. Not account numbers, not employee details, not anything else.
contractor_statesNoStates where 1099 contractors work.
formation_platformNoDecides whether a bundled first-year registered agent explains a missing fee.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / revenue_band / description
      Added value: +"Gross annual revenue as a band, never an exact figure: 'pre-revenue', 'under-250k', '250k-1m', '1m-5m' or 'over-5m'. Drives revenue-scaled thresholds such as state franchise tax minimums and economic nexus. Leave unset if unknown; the tool asks for it rather than guessing."
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already provide readOnlyHint=true and idempotentHint=true, and the description adds behavioral context: it reveals that the tool returns only unsettled facts and that output should be investigated by the agent. It does not contradict the annotations and enriches them with workflow semantics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the critical workflow constraint ('NOT the place to start') and every sentence earns its place, covering sequencing, output purpose, input policy, and user interaction guidance without redundancy.

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?

Despite 21 parameters and no output schema, the description gives sufficient context for an agent to call the tool correctly: it explains when to call it, what to pass, what it returns, and how to use the results. It could be slightly more explicit about the exact output shape, but the conceptual return type is adequately conveyed.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents every parameter in detail. The description adds a global instruction to 'pass every fact you already know,' but it does not add parameter-specific meaning beyond what the schema provides. Baseline 3 is appropriate.

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 specific verb and resource: it 'narrows what is still genuinely open' and 'returns the facts that flip an answer.' It clearly distinguishes itself from list_compliance_obligations by naming it as the prerequisite, so an agent can tell this tool apart from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'NOT the place to start' and instructs calling list_compliance_obligations first, giving a clear ordering constraint. It also tells the agent to pass every known fact and clarifies that the results are for the agent to look up in user documents, not a questionnaire to send to the user.

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.