Skip to main content
Glama

US compliance and books health

by com.medianfi

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_bandNo
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.

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description explains the tool's narrowing behavior, that it consumes all known facts, and that it returns only open/unsettled facts. It also clarifies that output is an internal research cue, not something to forward to the user.

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 compact and front-loaded with the most important caveat ('NOT the place to start'). Each sentence adds distinct value: sequencing, output behavior, input strategy, and downstream use.

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?

Despite having 21 parameters and no output schema, the description covers the workflow context and what the results mean, while the schema handles parameter details. It makes clear what to do after the call, which is key for a refinement tool.

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?

The input schema covers 95% of the 21 parameters with rich, field-level descriptions, so the tool description carries little param-specific burden. The general instruction to 'pass every fact you already know' is useful but does not add per-parameter semantics beyond the schema.

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?

Description immediately frames this as a refinement step that returns 'the facts that flip an answer,' distinguishing it from the preceding list_compliance_obligations call. It gives clear verb+resource semantics and explicitly says it is NOT the starting point.

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?

Explicit ordering guidance is provided: call list_compliance_obligations first, then call this. It also states when not to use it ('NOT the place to start') and instructs that results are for the agent to look up in user documents, not a questionnaire to send the user.

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

All US compliance and books health toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation4/5

Tools mostly demand exactly one job: the list/explain/score path is clearly labeled per domain, and the START-HERE markers guide entry points. The fuzzy spots are get_conf_lefts and get_evidence_recipe (both refinement steps after list_compliance_obligations) plus list_services vs get_company_overview (they overlap on what Median does); these are distinguishable from the descritions but are the kinds of pairs that could send an agent the wrong way.

Naming Consistency5/5

All twelve names follow the same verb_noun snake_case convention with consistent verbs: list the collections (_lists), get facts/computed refinements, explain single-item detail, and score the assessment. The pair structure (list vs explain vs proof) makes the intent predictable from the name for the first decode.

Tool Count4/5

Twelve tools is right within the ideal for a domain-focused server: seven true domain tools (compliance + books) and five content/take-usational helpers. The content cluster (services, overview, pricing, blog, blog_post) is a bit tangential to a compliance/books mission, but this is a company-fronting server, so the zone works with a reason.

Completeness4/5

Both workflows close their loop: compliance has list → explain → confounders → evidence, and books has list → explain → score, with no obvious dead-end in either. Minor residuals exist (no explicit tool for showing covered versus non-covered states, other collaboration across the two domains), but an agent can work out these as of today's.

Resources