Skip to main content
Glama
FFBB MCP Server

FFBB MCP Server

Liste des règlements et juridictions FFBB disponibles

ffbb_list_regulations
Read-onlyIdempotent

Liste l'ensemble des textes réglementaires fédéraux (RSG, RSP Élite, NM1-NM3, LF2-NF3), régionaux (Ligues IDF, Hauts-de-France, AURA...) et départementaux (Comités Paris, Nord, Rhône, Puy-de-Dôme...) indexés.

Instructions

Liste l'ensemble des textes réglementaires fédéraux (RSG, RSP Élite, NM1-NM3, LF2-NF3), régionaux (Ligues IDF, Hauts-de-France, AURA...) et départementaux (Comités Paris, Nord, Rhône, Puy-de-Dôme...) indexés.

Retourne l'inventaire complet sous forme `dict` avec `documents[]`
(`document_id`, `titre`, `organizer`, `level`, `season`) trié par juridiction.
Lecture seule, idempotent, sans effet de bord ; cache SWR (TTL ≈24h).

Utilise cet outil pour découvrir les `document_id` disponibles avant d'appeler
`ffbb_get_regulation_article` ou pour choisir un périmètre avant
`ffbb_search_regulations`. Ne pas utiliser pour rechercher un extrait textuel —
utilise `ffbb_search_regulations` à la place ; pour obtenir le texte d'un article
précis — utilise `ffbb_get_regulation_article` ; pour expliquer un départage —
utilise `ffbb_explain_tiebreak_rules`. Avec `season`, filtre l'inventaire à la
saison ciblée (défaut `2026-2027`).

Input Schema

NameRequiredDescriptionDefault
seasonNoSaison sportive (défaut '2026-2027')2026-2027

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.13.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the 'lecture seule, idempotent, sans effet de bord' sentence largely restates them. However, the description goes beyond annotations by disclosing the SWR cache with a ~24h TTL and the return shape (dict with documents[] sorted by jurisdiction), which is genuine behavioral context.

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?

The description is front-loaded with purpose, then return contract, then routing guidance, and every section is functional. The long parenthetical enumerations of leagues/committees are domain-useful but slightly verbose for a single-parameter list tool.

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?

With no output schema, the description compensates by naming the return type, the documents[] fields, and the sort order. For a one-parameter read-only listing tool, nothing an agent needs 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.

Parameters3/5

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

There is a single optional parameter with 100% schema description coverage, so the schema already documents season and its default. The description adds only a restatement of the filtering behaviour and the same '2026-2027' default, no extra syntax or semantics.

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 description states a specific verb (Liste) and resource (textes réglementaires fédéraux/régionaux/départementaux) with precise scope, enumerating the categories covered. It is immediately distinguishable from siblings like ffbb_search_regulations and ffbb_get_regulation_article, which are named explicitly.

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?

It gives explicit when-to-use cases (discover document_id before calling ffbb_get_regulation_article, or choose a perimeter before ffbb_search_regulations) and explicit when-not-to-use cases, routing to three named alternative tools for search, article retrieval, and tiebreak explanation.

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