Skip to main content
Glama

Calculate social charges

well_calculate_urssaf
Read-only

Calculate with the official Urssaf engine (mon-entreprise.urssaf.fr): employer costs, net pay and contributions for the situation the person gives. The result is a calculation by that engine, never a legal citation.

Pass each figure to compute as an expressions item, using the engine's own dotted names (for example "salarié . coût total employeur"), and the facts of the situation as situation: a map of the engine's names to values, such as "salarié . contrat . salaire brut": "3000 €/mois".

missing_variables lists the facts the engine still needs for a value; ask the person for them before you rely on a value.

On a refusal, tell the member in one plain line that the calculation could not be done this time, and never show the refusal code.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "expressions": "<expressions>",
      "situation": "<situation>"
    },
    "name": "well_calculate_urssaf"
  }
}

Input Schema

NameRequiredDescriptionDefault
situationYesThe facts of the situation, keyed by the engine's names.
expressionsYesThe engine names of the figures to compute.
workspace_idNoTarget workspace. Optional: this tool describes the token itself rather than one workspace's data, so omitting it returns the same answer.
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.

Output Schema

NameRequiredDescriptionDefault
statusYes
valuesNo
messageNo
refusalNo
successYes
source_urlNo
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.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
missing_variables_cutNo
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. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly and openWorld, so the safety profile is covered; the description adds the non-obvious behavioral facts: the answer comes from an external Urssaf engine, is a computation rather than legal advice, can come back incomplete via `missing_variables`, and can refuse. It does not mention latency, rate limits, or what a partial success looks like beyond the missing-variables case.

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 what and the caveat come first, then parameter conventions, then output handling. Four short paragraphs with no filler, though the refusal paragraph is an instruction aimed at a specific host rather than general tool semantics and could be trimmed.

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?

An output schema exists, so return shapes needn't be explained, and the description still flags `missing_variables` behavior usefully. The one real gap is that it never says how to discover or validate the engine's dotted names — the agent is told to use them without a stated lookup path.

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, but the description adds real meaning the schema lacks: the dotted engine-name convention with worked examples ('salarié . coût total employeur', 'salarié . contrat . salaire brut': '3000 €/mois') and the fact that `situation` maps names to values. It omits the 10-item cap on `expressions`, which only the schema states.

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 names a specific verb (calculate), a concrete resource set (employer costs, net pay, contributions) and the authority used (the official Urssaf engine, mon-entreprise.urssaf.fr). It also draws an explicit boundary against the law-lookup siblings: 'The result is a calculation by that engine, never a legal citation.'

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 actionable procedural guidance: pass figures in `expressions` using engine names, ask the person for facts listed in `missing_variables` before relying on a value, and on refusal say one plain line and never surface the refusal code. It stops short of routing the agent away from or toward similar siblings such as well_get_computed_figures or well_get_figure.

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