Skip to main content
Glama
Hug0x0

mcp-reunion

reunion_get_caf_amounts

Retrieve monthly total amounts paid by CAF Réunion for social benefits. Filter by benefit type and date range to analyze public spending on categories like RSA or AAH.

Instructions

Monthly total amounts (in EUR) paid out by CAF Réunion for each social-benefit category. Each row is one (month × benefit type) with the cumulated payouts for that category. Useful for public-spending analysis, social-policy monitoring, comparison with beneficiary counts (use reunion_get_caf_beneficiaries to derive average per beneficiary). Sorted by date descending.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
benefit_typeNoBenefit type label prefix match. Examples: "RSA", "AAH", "Prime d'activité", "Allocations familiales"
fromNoInclusive lower bound on date, ISO format YYYY-MM-DD
toNoInclusive upper bound on date, ISO format YYYY-MM-DD
limitNoMax rows to return (1-500, default 50)

Implementation Reference

  • The handler function for 'reunion_get_caf_amounts' tool. It queries the OpenDataSoft API dataset 'montant-presta-sociales-caf-lareunion', filters by benefit_type, date range (from/to), applies a limit, and returns monthly total amounts (in EUR) paid out by CAF Réunion per social-benefit category. Results include date, benefit_type, and amount_eur.
    server.tool(
      'reunion_get_caf_amounts',
      'Monthly total amounts (in EUR) paid out by CAF Réunion for each social-benefit category. Each row is one (month × benefit type) with the cumulated payouts for that category. Useful for public-spending analysis, social-policy monitoring, comparison with beneficiary counts (use reunion_get_caf_beneficiaries to derive average per beneficiary). Sorted by date descending.',
      {
        benefit_type: z.string().optional().describe('Benefit type label prefix match. Examples: "RSA", "AAH", "Prime d\'activité", "Allocations familiales"'),
        from: z.string().optional().describe('Inclusive lower bound on date, ISO format YYYY-MM-DD'),
        to: z.string().optional().describe('Inclusive upper bound on date, ISO format YYYY-MM-DD'),
        limit: z.number().int().min(1).max(500).default(50).describe('Max rows to return (1-500, default 50)'),
      },
      async ({ benefit_type, from, to, limit }) => {
        try {
          const data = await client.getRecords<RecordObject>(DATASET_CAF_AMOUNTS, {
            where: buildWhere([
              benefit_type ? `type_de_prestation LIKE ${quote(`${benefit_type}%`)}` : undefined,
              from ? `date >= date${quote(from)}` : undefined,
              to ? `date <= date${quote(to)}` : undefined,
            ]),
            order_by: 'date DESC',
            limit,
          });
          return jsonResult({
            total_rows: data.total_count,
            series: data.results.map((row) => ({
              date: pickString(row, ['date']),
              benefit_type: pickString(row, ['type_de_prestation']),
              amount_eur: pickNumber(row, ['montant']),
            })),
          });
        } catch (error) {
          return errorResult(error instanceof Error ? error.message : 'Failed to fetch CAF amounts');
        }
      }
    );
  • Zod schema defining the input parameters for reunion_get_caf_amounts: benefit_type (optional string prefix match), from (optional ISO date), to (optional ISO date), and limit (number 1-500, default 50).
    {
      benefit_type: z.string().optional().describe('Benefit type label prefix match. Examples: "RSA", "AAH", "Prime d\'activité", "Allocations familiales"'),
      from: z.string().optional().describe('Inclusive lower bound on date, ISO format YYYY-MM-DD'),
      to: z.string().optional().describe('Inclusive upper bound on date, ISO format YYYY-MM-DD'),
      limit: z.number().int().min(1).max(500).default(50).describe('Max rows to return (1-500, default 50)'),
    },
  • The tool is registered via server.tool('reunion_get_caf_amounts', ...) inside registerSocialTools() in src/modules/social.ts. registerSocialTools is called from src/modules/index.ts (line 49) and ultimately bootstrapped in src/index.ts (line 22).
    server.tool(
      'reunion_get_caf_amounts',
      'Monthly total amounts (in EUR) paid out by CAF Réunion for each social-benefit category. Each row is one (month × benefit type) with the cumulated payouts for that category. Useful for public-spending analysis, social-policy monitoring, comparison with beneficiary counts (use reunion_get_caf_beneficiaries to derive average per beneficiary). Sorted by date descending.',
      {
        benefit_type: z.string().optional().describe('Benefit type label prefix match. Examples: "RSA", "AAH", "Prime d\'activité", "Allocations familiales"'),
        from: z.string().optional().describe('Inclusive lower bound on date, ISO format YYYY-MM-DD'),
        to: z.string().optional().describe('Inclusive upper bound on date, ISO format YYYY-MM-DD'),
        limit: z.number().int().min(1).max(500).default(50).describe('Max rows to return (1-500, default 50)'),
      },
      async ({ benefit_type, from, to, limit }) => {
        try {
          const data = await client.getRecords<RecordObject>(DATASET_CAF_AMOUNTS, {
            where: buildWhere([
              benefit_type ? `type_de_prestation LIKE ${quote(`${benefit_type}%`)}` : undefined,
              from ? `date >= date${quote(from)}` : undefined,
              to ? `date <= date${quote(to)}` : undefined,
            ]),
            order_by: 'date DESC',
            limit,
          });
          return jsonResult({
            total_rows: data.total_count,
            series: data.results.map((row) => ({
              date: pickString(row, ['date']),
              benefit_type: pickString(row, ['type_de_prestation']),
              amount_eur: pickNumber(row, ['montant']),
            })),
          });
        } catch (error) {
          return errorResult(error instanceof Error ? error.message : 'Failed to fetch CAF amounts');
        }
      }
    );
  • buildWhere() helper used to construct the ODSQL WHERE clause from the optional filter conditions (benefit_type, from, to).
    export function buildWhere(
      conditions: Array<string | undefined | null | false>
    ): string | undefined {
      const valid = conditions.filter((condition): condition is string => Boolean(condition));
      return valid.length > 0 ? valid.join(' AND ') : undefined;
    }
  • quote() helper used to safely quote ODSQL string literals in filter conditions.
    export function quote(value: string): string {
      return `'${escapeOdSqlString(value)}'`;
    }
Behavior4/5

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

No annotations provided, so description must carry behavioral burden. It declares result is sorted by date descending, rows represent aggregated monthly payouts, and the tool is for analysis (implying read-only). Could be more explicit about side effects (none expected) and date range behavior, but sufficient for safe usage.

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?

Three sentences, front-loaded with core purpose. Every sentence adds value: purpose, row structure, use cases, sibling reference, sorting order. No fluff.

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?

Given no output schema, the description explains the output shape (rows with month, benefit type, cumulated payout) and suggests analytical use. Could mention limit effect, but schema covers that. Missing details like column names are minor. Complete enough for confident tool selection.

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

Parameters3/5

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

Schema coverage is 100%, so all parameters are documented in the schema. The description adds context like 'month × benefit type' implying benefit_type filter, but no detailed parameter semantics beyond what schema provides. Baseline 3 is appropriate.

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?

Description clearly states what the tool does: returns monthly total amounts in EUR per social-benefit category. It specifies row structure (month × benefit type) and cumulated payouts. Differentiates from sibling reunion_get_caf_beneficiaries by mentioning amounts vs. beneficiary counts, and explicitly names that sibling for deriving averages.

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 states use cases: public-spending analysis and social-policy monitoring. Provides clear guidance on when to use an alternative tool (reunion_get_caf_beneficiaries) for beneficiary counts and averaging. No ambiguity.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Hug0x0/mcp-reunion'

If you have feedback or need assistance with the MCP directory API, please join our Discord server