Skip to main content
Glama

Verify a tax declaration

well_verify_tax_declaration
Read-only

Check a tax declaration Well prepared against the tax authority's own controls, before the person files it. It reads the stored draft and the records Well holds now (for a CA3: the books on the basis the draft was prepared on, the company's SIREN, the prior return; for a micro turnover declaration: the period's bank receipts, and the URSSAF rates read again from their published source), and runs every rule of that declaration type. It never changes the draft. The micro check reads the URSSAF rate pages on the web and stores a rate it reads that is newer than the one Well holds, in the public rate table every workspace shares; it stores nothing of the workspace. Call it again after any change.

Call it with the declaration_type and the document_id of the draft: fr-vat-ca3 for the French VAT return, as well_prepare_vat_return returned it, or fr-micro-turnover for the URSSAF micro-entrepreneur turnover declaration, as well_prepare_micro_declaration returned it. Use it when the person asks whether the prepared declaration is right, and before a filing or a fill starts.

On status: "ok", rules lists every rule with its outcome (pass, fail or not_checkable), its severity, the control_id it restates (an authority control or legal text, a Well control id such as WELL-MICRO-ARITH-1, or null for a CA3 control Well adds), and on a fail the boxes at fault in lines (draft_euros the draft holds, expected_euros the rule expects).

  • blocking_rule_ids not empty: fillable is false. Say which rule failed and on which box, in plain words. The declaration is not filled until the draft is prepared again and passes.

  • prior_credit_confirmed in blocking_rule_ids: line 22 carries a credit Well assumed from a prior return it never saw filed. Ask once whether it is « le crédit reporté de ta déclaration précédente », naming no line, then call well_prepare_vat_return again for the same period with the prior_credit_euros the person gives.

  • On a micro draft, contribution_arithmetic failing means the printed estimate no longer holds, because a URSSAF rate or an assumption the sheet states changed since the draft: prepare the draft again, say the new estimate, and ask again before the fill. rate_source_read failing means the rates could not be read: the fill waits until a later check reads them. bank_sources_fresh failing means a bank copy is missing or not fresh enough for the period, or receipts came from no listed bank: well_prepare_micro_declaration names each source in stale_sources; request a sync with well_request_sync or ask for the missing statement or bank, then prepare the draft again and check again. vat_basis_known failing is an alert: say which receipts count on an assumed VAT basis, and ask the person to confirm the boxes.

  • alert_rule_ids not empty: say each one with its figures in one sentence. The person may still file.

  • A not_checkable rule needs a record Well does not hold for this declaration. Never say it passed.

unknown_draft: the workspace holds no draft of that type with that document_id; prepare it first. unsupported_declaration_type: Well does not check that declaration type yet, so never say it was checked. failed: the check could not run; its result is unknown, never a pass.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Input Schema

NameRequiredDescriptionDefault
document_idYesThe `document_id` of the stored draft, as the tool that prepared it returned it.
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several: this read reports one workspace's own figures and will not choose which.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.
workspace_scopeNoRestrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.
declaration_typeYesThe declaration the draft is: `fr-vat-ca3` for the French VAT return (CA3), `fr-micro-turnover` for the URSSAF micro-entrepreneur turnover declaration.

Output Schema

NameRequiredDescriptionDefault
errorNo
rulesNo
statusYes
successYes
fillableNoTrue when no BLOCKING rule failed.
document_idNo
alert_rule_idsNo
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
newly_connectedNoTools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
declaration_typeNo
blocking_rule_idsNo
resolved_workspaceNoThe workspace that answered, when the caller named none and the token authorizes several.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • removedOutput schema / properties / resolved_workspace / properties / name / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / resolved_workspace / properties / name / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / rules / items / properties / control_id / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / rules / items / properties / control_id / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / rules / items / properties / lines / items / properties / column / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / rules / items / properties / lines / items / properties / column / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / rules / items / properties / lines / items / properties / draft_euros / anyOf
      Removed value: -[
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / rules / items / properties / lines / items / properties / draft_euros / type
      Added value: +[
      +  "number",
      +  "null"
      +]
    • removedOutput schema / properties / rules / items / properties / lines / items / properties / expected_euros / anyOf
      Removed value: -[
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / rules / items / properties / lines / items / properties / expected_euros / type
      Added value: +[
      +  "number",
      +  "null"
      +]
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover read-only/safety, but the description goes well beyond them: it discloses the web read of URSSAF rate pages, the write of a newer rate into a shared public rate table with the explicit note 'it stores nothing of the workspace', and it enumerates the terminal states (unknown_draft, unsupported_declaration_type, failed) with the interpretation rule for each. The 'stores a rate' side effect sits slightly in tension with readOnlyHint, but the description scopes it clearly to public published data, not workspace data, so it reads as clarification rather than contradiction.

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?

Purpose is front-loaded and the bulk is high-value operational guidance (per-rule-failure instructions, error semantics). It is nevertheless very long for one description, with some near-repetition around 'prepare the draft again and check again' and 'The declaration is not filled until...' that could be tightened.

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, yet the description still maps the important return fields (rules, outcome, severity, control_id, lines/draft_euros/expected_euros, blocking_rule_ids, alert_rule_ids, not_checkable) to required agent behaviour. Combined with the per-declaration-type failure handling and the workspace resolution rule, an agent has everything needed to call it and act on the result 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 coverage is 100%, so the baseline is 3; the description earns above that by adding provenance ('as well_prepare_vat_return returned it', 'as well_prepare_micro_declaration returned it') and by explaining the multi-workspace rule for workspace_id that the schema states more tersely. It does not, however, touch conversation_id or workspace_scope, leaving those entirely to 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?

The first sentence states a specific verb and resource with scope: 'Check a tax declaration ... against the tax authority's own controls, before the person files it.' It names the concrete inputs it reads (books, SIREN, prior return, bank receipts, URSSAF rates) and explicitly distinguishes itself from the preparation siblings (well_prepare_vat_return, well_prepare_micro_declaration), so an agent can place it without opening a schema.

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 gives explicit triggers ('when the person asks whether the prepared declaration is right, and before a filing or a fill starts') and an explicit re-use rule ('Call it again after any change'). It also routes to alternatives for remediation (well_request_sync, preparing the draft again), and states when a workspace_id must be supplied vs omitted.

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.

Resources