Skip to main content
Glama

Get micro-entrepreneur start-up exemption terms

well_get_micro_acre_terms
Read-only

Get the ACRE terms of a French micro-entrepreneur from the day the activity started: the last day of the ACRE exemption and the ACRE share of the normal contribution rate. It reads only and stores nothing.

Pass start_date (YYYY-MM-DD), the day the micro activity started.

end_date is the last day of the ACRE: the end of the third calendar quarter after the quarter of start_date (end_date_source_url, service-public.gouv.fr F11677). A start on 2026-03-01 ends on 2026-12-31, a start on 2026-08-15 on 2027-06-30.

share_status "found" gives share, the fraction of the normal rate paid under ACRE on that start date (a decimal string such as "0.5" or "0.75"), with share_effective_from and share_source_url. "not_found": no stored share covers the start date, so the share is not known. "read_failed": the share could not be read; it is unknown, never zero. The end date holds in all three cases.

On success false, error_reason "invalid_start_date" means start_date is not a real calendar date, and error says so.

Input Schema

NameRequiredDescriptionDefault
start_dateYesThe day the micro activity started, YYYY-MM-DD.
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
errorNo
shareNoThe fraction of the normal rate paid under ACRE, a decimal string.
successYes
end_dateNoThe last day of the ACRE, YYYY-MM-DD.
start_dateNo
error_reasonNo
share_statusNo
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.
share_source_urlNo
end_date_source_urlNo
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
share_effective_fromNo
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. Changed6 schema fields changed
    • removedOutput schema / properties / share / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / share / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / share_effective_from / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / share_effective_from / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / share_source_url / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / share_source_url / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations (readOnlyHint true, destructiveHint false, openWorldHint false) are consistent with 'it reads only and stores nothing'. Beyond that, it discloses the derivation rule for end_date with a source reference (service-public.gouv.fr F11677) and worked examples, and distinguishes 'not_found' from 'read_failed', explicitly warning that read_failed is 'unknown, never zero' — exactly the kind of trap an agent would otherwise misread as zero.

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?

Front-loaded purpose sentence, then the input, then the derivation and output semantics, then the error case — each paragraph does distinct work and nothing is repeated from the structured fields verbatim.

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 and annotations cover the safety profile, so the description need only supply the semantics an agent cannot infer: the end-date computation, the three share_status states, and the error_reason. All are present, so nothing needed for a correct call is missing.

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; however the description adds real meaning to start_date by giving the derivation from it and two concrete date examples. The other three parameters (workspace_id, conversation_id, workspace_scope) are left entirely to the schema, so it does not fully earn a 5.

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?

Specific verb plus resource: 'Get the ACRE terms of a French micro-entrepreneur from the day the activity started', and it immediately names the two outputs (last day of the ACRE exemption, ACRE share of the normal rate). An agent can tell this apart from siblings such as well_get_micro_turnover or well_prepare_micro_declaration without opening any schema.

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?

The description states the exact required input and the condition under which the tool is the right one (a micro-entrepreneur's ACRE terms from the activity's start date), plus the invalid_start_date failure condition. It does not explicitly name alternative or sibling tools for related French micro-entrepreneur questions (e.g. turnover or declarations), so the routing is clear but not disambiguated against alternatives.

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