Skip to main content
Glama

fr_aides_get

Read-only

COMPLETE record of an aid (source of truth after re-ranking fr_aides_search — full purpose/conditions/amount, funders, contacts, official sources). Decoded text (HTML entities cleaned) and cache_indexation reduced to its useful extracts (natures, funders, territories, contacts, sources).

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": {
      "id_aid": "<id_aid>"
    },
    "name": "fr_aides_get"
  }
}

Input Schema

NameRequiredDescriptionDefault
rawNoTrue = raw database record (not decoded, bulky; for a consumer that depends on it).
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
id_aidYesaid identifier (`id` field of fr_aides_search).
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true; the description adds real behavioral detail beyond that — text is HTML-decoded and cache_indexation is trimmed to useful extracts, so the agent knows the payload is processed rather than raw. It also flags that the raw record is bulky, which informs the choice of the raw flag. Return shape/field list is left unspecified, keeping it short of a 5.

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?

Two dense sentences, front-loaded with the strongest claim ('COMPLETE record') and followed by the sibling relationship and payload processing notes. Backticked identifiers and parentheticals are compact rather than wasteful, though the second sentence packs several concepts into one clause.

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?

There is no output schema, but the description characterizes what comes back (decoded fields, reduced cache_indexation) well enough for a read-only lookup. With 100% schema coverage, the remaining parameters need no explanation; only a statement of what happens when the id is unknown 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 baseline is 3. The description earns above baseline by explaining the semantic difference between the default decoded output and the 'raw database record (not decoded, bulky)' behind the raw flag — meaning the schema only hints at.

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 — 'COMPLETE record of an aid' — and explicitly positions it relative to the sibling fr_aides_search ('source of truth after re-ranking'), naming what the record contains (purpose/conditions/amount, funders, contacts, official sources). An agent can distinguish it from the search tool without opening either 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 phrase 'source of truth after re-ranking fr_aides_search' gives a concrete workflow cue: use this once search has produced an id. It does not give explicit when-not guidance or state that an id_aid from search is required, but the ordering is clear enough to act on.

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