Paperasse MCP

search_fiche

Search official service-public.fr guides on French administrative procedures like CAF, URSSAF, taxes, and residence permits. Translates questions into French keywords to find matching fiches.

Instructions

Search official service-public.fr guides (fiches) about a French administrative procedure.

Use this first for any question about French paperwork: CAF (APL, RSA, prime d'activité),
URSSAF, impôts, titre de séjour, carte Vitale, logement social, carte grise,
micro-entreprise, création d'entreprise, etc.
The fiches are in French: always translate the user's question into a few French keywords
using official administrative terms before calling, even if the user writes in another
language (e.g. "I lost my residence permit" -> "perte titre de séjour";
"student housing aid" -> "APL étudiant"; "auto-entrepreneur" or "freelance" ->
"micro-entrepreneur"). Don't pass a full sentence.

`audience`: "all" (default) searches both guides for individuals (service-public.fr) and for
professionals (entreprendre.service-public.fr: self-employed, micro-entrepreneurs, companies,
employers). Pass "particuliers" or "professionnels" only when the user's situation is
clearly one or the other.

Returns up to `limit` (max 10) fiches, best match first, each with id, title, summary,
official url (the page on the site of the requested audience), audiences, updated_at and
`match` (0-1: how much of the query the title and summary cover). Then call get_fiche(id) to read the full text before answering: the summary alone
is not enough to answer.

If `low_confidence` is true, the best result probably doesn't answer the question: retry
once with different French official terms (synonyms, the name of the benefit or document).
If it is still low, don't present these fiches as the answer; say no matching official
guide was found.

Input Schema

Name	Required	Default
`limit`	No
`query`	Yes
`audience`	No	all

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 29, 2026

TDQS

A4.9/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden and does: it discloses result ordering ('best match first'), the cap ('max 10'), the per-result fields, the meaning of the `match` score (0-1 title/summary coverage), and the `low_confidence` signal plus the correct recovery behavior. It also warns that summaries are insufficient for answering, which is a genuine behavioral constraint an agent would otherwise get wrong.

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 with purpose, then query guidance, then audience, then returns, then the low_confidence fallback – a logical order with no dead sentences. It runs long and the returns paragraph partly restates what the output schema already carries, but the length is earned by the parameter and recovery guidance.

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?

For a search tool with an output schema and no annotations, the description supplies everything an agent needs: query construction rules, audience selection, result limits and ranking, interpretation of the confidence signal, and the mandated follow-up call. Nothing required to invoke it correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate entirely, and it does for all three parameters: `query` requires translated French administrative keywords with three concrete translation examples and a 'no full sentences' rule, `audience` defines 'all' vs 'particuliers'/'professionnels' with the site each maps to and a default, and `limit` is bounded at max 10.

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?

States a specific verb and resource ('search official service-public.fr guides (fiches)') and enumerates the exact subject domain (CAF, URSSAF, impôts, titre de séjour, etc.). It is clearly a retrieval-by-keyword tool and is distinguishable from the sibling get_fiche, which is explicitly named as the follow-up full-text read.

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?

Explicitly says 'Use this first for any question about French paperwork' and then hands off: 'Then call get_fiche(id) to read the full text before answering.' It even prescribes the failure path (retry once on low_confidence with synonyms, then report no match), so when-to-use, what-to-do-next, and when-to-give-up are all covered.

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

Deploy Server