This server provides MCP tools to query official French basketball (FFBB) data: schedules, standings, results, live scores, club/team info, and regulations.
🔎 Search across clubs, competitions, matches, venues, tournaments, and more (universal search with filters).
🗓️ Get calendars and multiple upcoming/past matches for a club or team (ffbb_club).
🏆 Retrieve standings and full standings tables for a pool (ffbb_get, ffbb_club).
📊 Get aggregated season records (wins/losses/draws, points, phases) in one call (ffbb_bilan, ffbb_bilan_saison).
🔴 View live match scores, refreshed every 15s (ffbb_lives).
⚽ Get a team's last result or next single match (ffbb_last_result, ffbb_next_match).
🧑🤝🧑 Resolve ambiguous team names/categories to specific teams (ffbb_resolve_team).
📋 Obtain a full team summary combining record, standings, last match, and next match (ffbb_team_summary).
⚔️ Compare two teams and analyze head-to-head history, recent form, and statistical duels (ffbb_head_to_head).
📜 Search and read official FFBB regulations, including tiebreak rules and list of available regulatory texts (ffbb_search_regulations, ffbb_get_regulation_article, ffbb_explain_tiebreak_rules, ffbb_list_regulations).
🏢 Access club details, venues, competitions, and other entities by ID (ffbb_get).
📅 List available FFBB seasons (ffbb_saisons).
ℹ️ Check server version and runtime diagnostics (ffbb_version).
Enables GitHub Copilot to retrieve French basketball data from FFBB through the MCP server.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@FFBB MCP Server Show me the live scores for current basketball matches"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Le basket français officiel, directement dans vos assistants IA.
Serveur MCP pour consulter calendriers, classements, bilans, résultats, scores live et règlements officiels de la FFBB (Fédération Française de Basketball).
🇺🇸 English Summary: Official Model Context Protocol (MCP) server for French Basketball (FFBB). Connect your AI assistants (Claude, Cursor, Copilot, ChatGPT, Antigravity) to live French basketball schedules, standings, scores, team records, club directories, and official federal regulations via Streamable HTTP or Stdio.
🌐 Site · 🧩 Extension VS Code · 📚 Documentation · 💬 Support
Aucune installation requise : le serveur est hébergé publiquement. Ajoutez simplement l'endpoint MCP à votre client :
https://ffbb.desimone.fr/mcpPuis posez vos questions en langage naturel :
« Quel est le prochain match des U15 de mon club ? » « Donne-moi le classement de la poule et le dernier résultat. » « Y a-t-il des matchs en direct ce soir ? »
👉 Voir la section Installation pour brancher l'endpoint sur VS Code, Claude, Cursor, etc.
Related MCP server: SportScore
🗓️ Calendriers & résultats — matchs passés et à venir, par club ou par équipe.
🏆 Classements — poules complètes avec points, différentiel et forme.
📊 Bilans agrégés — toutes phases confondues en un seul appel.
🔴 Scores live — matchs en cours, mis à jour toutes les 30 s.
🔎 Recherche universelle — clubs, compétitions, salles, engagements.
🚀 Optimisé pour les LLM — réponses agrégées et cache TTL pour réduire le contexte et le nombre d'appels.
Option recommandée — installer l'extension FFBB Basketball MCP depuis les releases, puis ouvrir Copilot Chat en mode agent.
Alternative sans extension — ➕ Installer FFBB MCP en un clic
Ouvrez les Paramètres de Claude, puis Connecteurs (ou Plugins).
Cliquez sur Ajouter un connecteur personnalisé.
Renseignez l'URL publique https://ffbb.desimone.fr/mcp et validez.
Claude Desktop n'accepte que le transport stdio local : on utilise donc le bridge SSE officiel via npx.
Prérequis : Node.js (inclut npm et npx). Sans Node.js, privilégiez l'Option A.
{
"mcpServers": {
"ffbb": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/client-sse", "https://ffbb.desimone.fr/mcp"]
}
}
}Configurez un serveur MCP distant :
Champ | Valeur |
Type |
|
URL |
|
Configurez directement l'URL distante dans mcp_config.json via la directive native serverUrl :
{
"mcpServers": {
"ffbb_mcp": {
"serverUrl": "https://ffbb.desimone.fr/mcp"
}
}
}Outil | Usage |
| Informations de version et configuration runtime du serveur FFBB MCP. |
| Recherche FFBB — clubs, compétitions, matchs, salles, tournois, etc. |
| Bilan complet d'une équipe toutes phases confondues en UN seul appel (V/D/N, paniers, phases). |
| Recupere une ressource FFBB par identifiant. |
| Outils agrégés club : calendrier (matchs pluriels), équipes engagées ou classement. |
| Matchs en cours (scores live, rafraîchissement toutes les 15s). Retourne [] si aucun match. |
| Liste des saisons FFBB (référentiel temporel). |
| Identifie une equipe unique (Pivot central). |
| Résumé complet et agent-friendly pour une équipe. |
| Dernier résultat d'une équipe précise. |
| Prochain match à jouer pour une équipe précise. |
| Bilan détaillé de la saison pour une équipe précise (toutes phases). |
| Compare deux équipes et analyse leurs confrontations directes (H2H). |
| Recherche plein texte déterministe dans les règlements officiels FFBB, régionaux et départementaux. |
| Récupère le texte intégral et exact d'un article spécifique de règlement sans troncature. |
| Fournit les règles officielles de départage en cas d'égalité (Article 28 du RSG FFBB). |
| Liste l'ensemble des textes réglementaires fédéraux (RSG, RSP Élite, NM1-NM3, LF2-NF3),. |
Référence complète des paramètres :docs/TOOLS_REFERENCE.md.
Endpoint MCP (transport Streamable HTTP) :
https://ffbb.desimone.fr/mcpEndpoint | URL |
📊 Dashboard |
|
📈 Métriques |
|
❤️ Santé |
|
flowchart LR
A[Client MCP<br/>Claude · Cursor · Antigravity] -->|Streamable HTTP / Stdio| B[FFBB MCP Server<br/>FastMCP]
B --> C[Services métier<br/>Cache SWR & Agrégation]
C --> D[ffbb-data-client<br/>SDK Python]
D --> E[(API Directus &<br/>Meilisearch FFBB)]Points clés :
Double transport : Streamable HTTP distant (spec 2025-11-25) ou Stdio local (uvx) ;
SDK Python découplé : Requêtes réseau et parsing Pydantic v2 délégués à ffbb-data-client ;
Agrégation composite : 12 outils optimisés pour réduire les allers-retours et le contexte LLM ;
Cache intelligent & SWR : Stale-While-Revalidate avec TTL par type de donnée (30 s lives, 1 h bilans, 24 h clubs) ;
Observabilité complète : Dashboard HTML, métriques Prometheus, snapshot JSON et healthcheck intégrés.
Détails : docs/ARCHITECTURE.md et docs/PERFORMANCE.md.
uv sync --extra dev # installer les dépendances
uv run ruff format . # formater
uv run ruff check --fix . # linter
uv run mypy src # vérifier les types
uv run pytest # lancer les testsVoir CONTRIBUTING.md pour les règles de contribution.
uv run pytest # tests unitaires + couverture
uv run pytest tests/ # cibléLe pipeline CI (.github/workflows/ci.yml) exécute ruff, mypy, pytest et le contrôle de couverture à chaque push/PR.
Symptôme | Cause probable | Solution |
| Wrapper | Utiliser |
Claude Desktop refuse l'URL | Claude Desktop impose | Utiliser le bridge |
Données live obsolètes | Cache TTL | Attendre le rafraîchissement (≤ 30 s) ou interroger l'endpoint |
Bilan complet d'une équipe toutes phases confondues en UN seul appel (V/D/N, paniers, phases).
Outil prioritaire pour 'quel est le bilan de X ?' ou 'résultats de U11M1'.
| Name | Required | Description | Default |
|---|---|---|---|
| poule_id | No | ID FFBB de la poule pour désambiguïser. | |
| categorie | No | Catégorie/genre/numéro (ex: 'U11M1', 'Senior'). | |
| club_name | No | Nom du club (ex: 'Stade Clermontois', 'ASVEL'). Requis si organisme_id absent. | |
| season_id | No | ID de la saison FFBB (optionnel). | |
| organisme_id | No | ID FFBB du club (ex: '9326' ou 'ARA0063058'). Requis si club_name absent. | |
| engagement_id | No | ID FFBB de l'engagement (prioritaire pour désambiguïser). | |
| force_refresh | No | Si True, contourne le cache. | |
| numero_equipe | No | Numéro d'équipe (ex: 1, 2). | |
| competition_id | No | ID FFBB de la compétition pour désambiguïser. | |
| competition_type | No | Type de compétition ('PLAT', 'COUPE', etc.) pour désambiguïser. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: a single call aggregates all phases and returns V/D/N, paniers, and phases. It does not cover every behavioral detail, but it adds meaningful value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The main capability and single-call advantage are front-loaded, and the usage guidance is compact and directly actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description partially fills the return-value gap by naming V/D/N, paniers, and phases, and clarifies the all-phases scope. The 10-parameter anyOf selection logic is left to the schema, which is acceptable given full schema coverage, though explicit guidance on when to prefer ffbb_bilan_saison would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's example 'U11M1' hints at using the 'categorie' parameter, but it does not add significant parameter-specific meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action and resource: 'Bilan complet d'une équipe toutes phases confondues' and enumerates the returned content (V/D/N, paniers, phases). This distinguishes it from sibling tools like ffbb_bilan_saison by emphasizing the 'toutes phases' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly marks the tool as the priority for common queries like 'quel est le bilan de X ?' or 'résultats de U11M1', giving the agent clear situational guidance. It does not explicitly mention exclusions or alternatives, but the examples and 'toutes phases' phrasing imply when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bilan détaillé de la saison pour une équipe précise (toutes phases).
Cet outil est optimisé pour les questions du type "Quel est le bilan de la saison des U11M1 ?".
Il agrège toutes les phases (toutes poules) de la saison FFBB pour l'équipe identifiée par (organisme_id/club_name, categorie, numero_equipe).
Pour chaque phase, il retourne :
competition
poule_id
position
match_joues, gagnes, perdus, nuls
paniers_marques, paniers_encaissés, difference
Et fournit également un champ bilan_total qui cumule toutes les phases.
| Name | Required | Description | Default |
|---|---|---|---|
| poule_id | No | ID FFBB de la poule pour désambiguïser. | |
| categorie | No | Catégorie + genre + numéro d'équipe facultatif (ex: 'U11M', 'U11M1', 'U13F2', 'SeniorM'). Cette valeur sert à filtrer les engagements et les poules. | |
| club_name | No | Nom du club (ex: 'Stade Clermontois', 'ASVEL'). | |
| season_id | No | ID de la saison FFBB (optionnel). | |
| organisme_id | No | ID FFBB du club (alternative plus rapide à club_name). | |
| engagement_id | No | ID FFBB de l'engagement (prioritaire pour désambiguïser). | |
| force_refresh | No | Si True, contourne le cache pour récupérer des données fraîches. | |
| numero_equipe | No | Numéro d'équipe (1, 2, ...) pour identifier l'équipe précise dans la catégorie (défaut: 1). | |
| competition_id | No | ID FFBB de la compétition pour désambiguïser. | |
| competition_type | No | Type de compétition ('PLAT', 'COUPE', etc.) pour désambiguïser. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context: it aggregates all phases, returns per-phase statistics, and provides a cumulative bilan_total. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, followed by a concise bullet list of return fields. There is slight repetition of 'toutes phases', but the overall structure is clear and economical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 10 parameters and no output schema, the description covers the tool's use case, identification logic, aggregation behavior, and return fields. Optional disambiguation parameters are left to the schema, which is reasonable given the 100% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the parameters. The description usefully groups the team identification parameters (organisme_id/club_name, categorie, numero_equipe), but it does not add much per-parameter meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource and action: a detailed season record for a specific team, covering all phases. It also gives an example question and lists the returned fields. It does not explicitly name a sibling alternative, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames the tool as optimized for questions like 'Quel est le bilan de la saison des U11M1 ?', giving an agent a clear trigger for when to use it. It does not state when not to use it or mention alternatives such as ffbb_bilan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Outils agrégés club : calendrier (matchs pluriels), équipes engagées ou classement.
Outil de référence pour toute demande au pluriel : matchs restants, calendrier complet.
Pour une équipe senior au niveau national ou régional, la catégorie FFBB interne est souvent SEM1 ou SEF1 ;
le serveur résout désormais NM3, NM2, NF1, PNM, R2, etc. vers la bonne équipe et sa poule.
Pour action='classement', le poule_id est optionnel si club_name/organisme_id et categorie (ou filtre) sont fournis.
Utiliser adversaire avec action='calendrier' pour isoler les confrontations directes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Nombre max de matchs retournés (1-100, pagination). | |
| phase | No | Nom ou numéro de phase (ex: 'Phase 2'). | |
| action | No | Action : 'calendrier' (matchs pluriels/restants), 'equipes' ou 'classement'. | calendrier |
| filtre | No | Filtre catégorie/genre (alias pour 'categorie', ex: 'U11M', 'Senior', 'NM3'). | |
| offset | No | Index de départ pour pagination calendrier (défaut 0). | |
| date_fin | No | Date fin YYYY-MM-DD (action='calendrier'). | |
| poule_id | No | ID poule (action='classement' ou 'calendrier'). Optionnel si club et catégorie sont fournis. | |
| categorie | No | Catégorie, division ou filtre d'équipe (alias pour 'filtre', ex: 'NM3', 'U15M', 'Senior'). | |
| club_name | No | Nom du club (ex: 'Stade Clermontois'). Requis si organisme_id absent. | |
| season_id | No | ID de la saison FFBB (optionnel). | |
| adversaire | No | Nom adversaire pour filtrer les confrontations directes (action='calendrier'). | |
| date_debut | No | Date début YYYY-MM-DD (action='calendrier'). | |
| organisme_id | No | ID FFBB du club (ex: '9326'). Requis si club_name absent. | |
| engagement_id | No | ID FFBB de l'engagement (prioritaire pour désambiguïser). | |
| force_refresh | No | Si True, contourne le cache. | |
| numero_equipe | No | Numéro d'équipe (ex: 1, 2) pour action='calendrier' ou 'classement'. | |
| competition_id | No | ID FFBB de la compétition pour désambiguïser. | |
| competition_type | No | Type de compétition ('PLAT', 'COUPE', etc.) pour désambiguïser. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, so the description correctly adds value beyond them. It discloses meaningful server behavior: the resolution of NM3, NM2, NF1, PNM, R2 etc. to internal FFBB categories like SEM1/SEF1, and automatic team/poule identification. It also states when poule_id becomes optional, which is useful operational context not inferable from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose first, then usage nuances, then caveats. There is minor overlap between 'matchs pluriels' and 'matchs restants, calendrier complet', but it is used for emphasis and does not bloat the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 18 parameters, zero required fields, and no output schema, the description covers the main aggregated actions and alias resolution, which helps a lot. However, it leaves some gaps: no explicit recommended parameter combinations for action='equipes', no guidance on season/date defaults, and little direction for ambiguous multi-parameter calls. It is adequate for typical plural requests but not exhaustive for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining action-specific parameter usage: classement can work without poule_id when club/organisme and categorie/filtre are provided, and adversaire is intended for calendrier direct confrontations. The alias mapping between public divisions (NM3, R2) and internal FFBB categories (SEM1, SEF1) clarifies semantic relationships the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear statement of scope — 'calendrier (matchs pluriels), équipes engagées ou classement' — and then reinforces it as 'Outil de référence pour toute demande au pluriel'. It names the specific resource (club data) and the three aggregate outputs, distinguishing it from singular sibling tools without needing a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly frames when to use the tool ('toute demande au pluriel : matchs restants, calendrier complet') and gives action-specific conditions such as classement not needing poule_id when club and categorie are supplied, and adversaire for calendrier head-to-heads. It does not explicitly name the singular alternatives like ffbb_next_match or ffbb_last_result, but the 'au pluriel' phrasing makes the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fournit les règles officielles de départage en cas d'égalité (Article 28 du RSG FFBB).
Explique le calcul du point-average particulier (confrontations directes), du quotient particulier, et du mini-championnat à 3 équipes ou plus. Lecture seule, idempotent, sans effet de bord ; cache SWR court.
Utilise cet outil uniquement quand deux équipes ou plus sont à égalité de points
dans une poule et que tu dois expliquer pourquoi l'une est classée devant l'autre.
Avec poule_id, les règles sont appliquées à la poule concrète ; sans, tu obtiens
les règles génériques. Ne pas utiliser pour rechercher un extrait réglementaire —
utilise ffbb_search_regulations à la place ; pour récupérer le texte d'un article
précis — utilise ffbb_get_regulation_article ; pour lister les règlements
disponibles — utilise ffbb_list_regulations. Ne pas utiliser non plus pour
obtenir le classement brut — utilise ffbb_club(action="classement") — ni pour
le bilan chiffré — utilise ffbb_bilan. Utilise ffbb_explain_tiebreak_rules
au lieu de ffbb_search_regulations quand la question porte sur le départage
et non sur le texte réglementaire.
| Name | Required | Description | Default |
|---|---|---|---|
| season | No | Saison sportive (défaut '2026-2027') | 2026-2027 |
| poule_id | No | ID optionnel de la poule FFBB pour appliquer les règles de départage |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description reinforces this and adds the 'cache SWR court' detail, which is new behavioral context. It does not contradict the annotations. Since the annotations carry most of the safety profile, the description adds a small but useful extra detail about caching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose. It is longer than a typical description but every sentence serves a purpose: explaining what it does, the calculation types, safety note, and usage guidance with alternatives. It could be slightly trimmed, but it remains efficient and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (explaining tiebreak rules) and simple schema (2 optional params), the description covers purpose, usage, parameter semantics, and safety. It does not describe the output format, but with no output schema and the tool being an explanation tool, this is not a critical omission. The description is complete enough for an agent to decide when to use it and how to pass parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (season and poule_id) already have descriptions. The description adds meaningful semantics for poule_id: 'Avec poule_id, les règles sont appliquées à la poule concrète ; sans, tu obtiens les règles génériques.' This clarifies the effect of the optional parameter, going beyond the schema's basic description. This earns a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool provides official tiebreak rules (Article 28 du RSG FFBB) and explains the calculations for point-average, quotient, and mini-championnat. It clearly distinguishes from sibling tools by naming alternatives for different tasks, so an agent can immediately understand what this tool is for and what it is not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use ('uniquement quand deux équipes ou plus sont à égalité de points dans une poule') and when-not-to-use, naming specific alternatives (ffbb_search_regulations, ffbb_get_regulation_article, ffbb_list_regulations, ffbb_club(action='classement'), ffbb_bilan). It even clarifies that this tool is preferred over ffbb_search_regulations for tiebreak questions. This is comprehensive and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recupere une ressource FFBB par identifiant.
type="competition" equivaut a get_competition. Si club est fourni, localise directement la poule du club au sein de la compétition.
type="poule" charge la poule (classements + rencontres).
type="organisme" charge les details d'un club.
type="rencontre" charge une rencontre précise.
type="salle" charge les details d'une salle et son adresse normalisée.
⚠️ Attention: type="poule" peut être tronqué si la poule est grande.
Pour un calendrier exhaustif, préférez ffbb_club(action="calendrier").
Avertissement: ne pas utiliser pour obtenir un score ou un prochain match.
Utiliser ffbb_last_result et ffbb_next_match a la place.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Identifiant FFBB exact (string opaque, ex: '200000003057825'). Ne pas passer un nom de club: utiliser d'abord ffbb_search pour résoudre l'id. | |
| club | No | Nom ou ID du club à localiser dans les poules (si type='competition'). Permet de trouver directement l'ID et le nom de poule d'un club dans une compétition multi-poules. | |
| type | Yes | Type de ressource a charger. | |
| force_refresh | No | Si True et type='poule', contourne le cache pour recuperer la poule en temps reel (scores live). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds a meaningful behavioral caveat beyond those annotations: 'type="poule" peut être tronqué si la poule est grande' and the cache-bypass behavior via force_refresh. It does not discuss errors or pagination, but with these annotations the net gap is small.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized: a short front-loaded opening, a bulleted list of types, and two warning paragraphs. It is slightly long but each sentence conveys distinct information about a type or an alternative, so nothing feels wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the common type branches well and carries enough for a tool with 4 params and no output schema. But it does not explain the 'officiel' and 'entraineur' enum values at all, nor the general shape of the returned resource. These blind spots make it adequate but incomplete for the full range of tool uses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds substantial meaning to the 'type' enum by explaining what each supported type returns (e.g., 'type="poule" charge la poule (classements + rencontres)') and how 'club' locates a pool within a competition. The only notable hole is omitting the 'officiel' and 'entraineur' enum values, which the schema merely lists as types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Récupère une ressource FFBB par identifiant') and then enumerates the main resource types. It also distinguishes the tool from siblings by explicitly name-dropping ffbb_last_result, ffbb_next_match, and ffbb_club, so an agent can tell them apart without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when not to use the tool ('Avertissement: ne pas utiliser pour obtenir un score ou un prochain match') and names the exact alternatives (ffbb_last_result, ffbb_next_match). It also recommends ffbb_club(action="calendrier") for an exhaustive calendar when type='poule' is truncated, and the schema instructs agents to use ffbb_search first to resolve ids.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Récupère le texte intégral et exact d'un article spécifique de règlement sans troncature.
Retourne dict avec document_id, article_number, titre, contenu et
saison ; lecture seule, idempotent, sans effet de bord, cache SWR.
Utilise cet outil quand tu connais le numéro d'article et le document (obtenu via
ffbb_list_regulations ou ffbb_search_regulations) et que tu veux le contenu
verbatim. Ne pas utiliser pour rechercher par mot-clé — utilise
ffbb_search_regulations à la place ; pour lister les documents disponibles —
utilise ffbb_list_regulations ; pour expliquer un départage — utilise
ffbb_explain_tiebreak_rules. Si document_id est omis, précise organizer
et season pour lever l'ambiguïté.
| Name | Required | Description | Default |
|---|---|---|---|
| season | No | Saison sportive (défaut '2026-2027') | 2026-2027 |
| organizer | No | Organisateur du texte (ex: 'FFBB', 'Ligue AURA', 'Comité 63') | |
| document_id | No | Identifiant du document source (ex: 'rsg_ffbb_2026_2027', 'rsp_u15_elite_2026_2027', 'reglement_aura_2026_2027', 'reglement_comite_63_2026_2027') | |
| article_number | Yes | Numéro ou référence de l'article (ex: 'Article 28', 'Article 51', 'Article 4.1', 'Article 7') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds useful behavior beyond annotations: no truncation, SWR cache behavior, and the exact dict fields returned. It does repeat some annotation signals, but the cache and return-format context provide extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose, return behavior, then usage guidance. Every sentence contributes, and the alternative tools are listed clearly without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description covers the necessary context: exact return fields, idempotence and caching, when to use it, and how to disambiguate when document_id is absent. Nothing important is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful parameter relationships: if document_id is omitted, organizer and season should be provided to avoid ambiguity, and the document can be obtained via ffbb_list_regulations or ffbb_search_regulations. This goes beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise action: retrieving the full, exact text of a specific regulation article without truncation. It clearly differentiates from siblings by naming what this tool is not for — keyword search, listing documents, and tiebreak explanations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use the tool: when the article number and document are already known and verbatim content is needed. It also gives exclusions with exact sibling alternatives: use ffbb_search_regulations for keyword search, ffbb_list_regulations for listing, and ffbb_explain_tiebreak_rules for tiebreak explanations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare deux équipes et analyse leurs confrontations directes (H2H).
Fournit :
Bilan historique des confrontations directes de la saison (victoires A vs B, scores, écarts)
Forme récente respective de chaque équipe (V-D-V-V...) et séries en cours
Duel statistique des styles : Attaque vs Défense, ratio de victoires domicile/extérieur
Points clés narratifs prêts pour la rédaction d'articles ou de synthèses d'avant-match
| Name | Required | Description | Default |
|---|---|---|---|
| club_a | No | Nom du premier club (ex: 'Stade Clermontois'). | |
| club_b | No | Nom du second club / adversaire (ex: 'Vichy', 'Roanne'). | |
| poule_id | No | ID FFBB de la poule pour désambiguïser. | |
| categorie | No | Catégorie d'équipe commune à comparer (ex: 'SEM1', 'U18M', 'Senior'). | |
| club_name | No | Alias pour club_a : nom du premier club (ex: 'Stade Clermontois'). | |
| season_id | No | ID de la saison FFBB (optionnel). | |
| adversaire | No | Alias pour club_b : nom du second club / adversaire (ex: 'Vichy'). | |
| organisme_id | No | Alias pour organisme_id_a : ID FFBB du premier club. | |
| adversaire_id | No | Alias pour organisme_id_b : ID FFBB du second club / adversaire. | |
| engagement_id | No | ID FFBB de l'engagement partagé ou équipe A (alias pour engagement_id_a). | |
| force_refresh | No | Si True, force le rafraîchissement des données | |
| competition_id | No | ID FFBB de la compétition pour désambiguïser. | |
| organisme_id_a | No | ID FFBB du premier club (ex: '9326'). | |
| organisme_id_b | No | ID FFBB du second club / adversaire. | |
| engagement_id_a | No | ID FFBB de l'engagement équipe A (prioritaire). | |
| engagement_id_b | No | ID FFBB de l'engagement équipe B (prioritaire). | |
| competition_type | No | Type de compétition ('PLAT', 'COUPE', etc.) pour désambiguïser. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, indicating a safe, read-only, potentially open-ended tool. The description adds that it provides historical confrontations, recent form, and narrative points, which is useful context but does not detail specific behaviors like data freshness, caching, or the scope of the 'level' (season vs all-time). It doesn't contradict annotations, so scores a 3 for adding some value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a bulleted list under the main sentence, making it scannable. It is concise with no fluff, but could be slightly more front-loaded by placing the core purpose before the bullet list. The bullet points are relevant and add substance without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with 17 parameters and no output schema. The description explains what it returns (e.g., historical bilan, recent form, style duel) but does not clarify how to specify the two teams given the multiple ways to identify them (e.g., by club_a/club_b vs organisme_id_a/b). It also does not mention that parameters are optional, which could confuse an agent about required inputs. Given the complexity, this is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the schema already documents all parameters. The description adds value by explaining the overall purpose and indicating that parameters like club_a and club_b are used for comparison, but it does not introduce new parameter semantics beyond what the schema provides. However, it clarifies that parameters are aliases (as seen in schema descriptions), so the description's mention of 'two teams' helps agents understand the pairing semantics. Given high coverage, a 4 is justified as it slightly augments the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it compares two teams and analyzes their direct confrontations (H2H), which is a specific verb-resource pairing. It distinguishes itself from siblings like ffbb_team_summary or ffbb_bilan by focusing on head-to-head and comparative analysis. However, it does not explicitly name these siblings to differentiate, so it loses one point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description outlines the use case (comparing two teams, analyzing H2H, preparing pre-match articles) but does not state when NOT to use it or mention specific alternatives. It implies usage for pre-match analysis but lacks explicit routing to other tools like ffbb_bilan for individual team performance or ffbb_search for general queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dernier résultat d'une équipe précise.
SINGULIER UNIQUEMENT: retourne le dernier match joué d'une seule équipe.
Recommendation LLM : Si la categorie est imprécise ou sans numéro (ex: 'U11M'),
appeler d'abord ffbb_resolve_team pour obtenir le numero_equipe reel.
| Name | Required | Description | Default |
|---|---|---|---|
| poule_id | No | ID FFBB de la poule pour désambiguïser. | |
| categorie | No | Catégorie de l'équipe précise (ex: 'U11M1', 'U11M', 'SEM1', 'NM3'). | |
| club_name | No | Nom du club (ex: 'Stade Clermontois') | |
| season_id | No | ID de la saison FFBB (optionnel). | |
| organisme_id | No | Identifiant FFBB du club (organisme_id, ex: '9326' ou 'ARA0063058'). | |
| engagement_id | No | ID FFBB de l'engagement (prioritaire pour désambiguïser). | |
| force_refresh | No | Si True, force un rafraichissement des donnees de poule | |
| numero_equipe | No | Numéro d'équipe dans la catégorie. Résoudre avec ffbb_resolve_team si ambigu. | |
| competition_id | No | ID FFBB de la compétition pour désambiguïser. | |
| competition_type | No | Type de compétition ('PLAT', 'COUPE', etc.) pour désambiguïser. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior. The description adds useful behavioral nuance beyond annotations: the tool only handles one team at a time and may need an exact resolved `numero_equipe` for ambiguous categories. No contradiction with the readOnlyHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with the core singular-only behavior stated first and the resolver recommendation as a targeted extra. The first two sentences are slightly redundant, but the whole thing remains tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Together with the rich schema and annotations, the description is sufficiently complete: it specifies the return scope, emphasizes singularity, and gives a concrete disambiguation workflow. There is no output schema, so a note on the exact result fields would be an enhancement, but it is not a blocker.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter already has a meaningful description, including the resolver note on `numero_equipe`. The tool description adds no new per-parameter meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'retourne le dernier match joué d'une seule équipe' (returns the last played match of a single team), with a specific resource and scope. It emphasizes singular-only behavior, which distinguishes it from any batch or team-wide tools, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a direct LLM recommendation: if the category is imprecise or lacks a number, call `ffbb_resolve_team` first to obtain the real `numero_equipe`. It also makes the singular-only constraint explicit. It does not mention exclusions or compare against sibling tools such as `ffbb_next_match`, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| season | No | Saison sportive (défaut '2026-2027') | 2026-2027 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark read-only, idempotent, and non-destructive, and the description adds the non-obvious SWR cache with TTL ≈24h. It also discloses the return shape as a dict with documents[] containing document_id, titre, organizer, level, season, sorted by jurisdiction, which is beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into three focused blocks: scope, return/behavior, and usage routing. Every sentence adds useful information, examples like RSG and Ligues IDF clarify the catalog, and the scoping verb is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully compensates by specifying the exact returned structure and sort order. It also covers the one parameter, the default, and the operational characteristics (cache, side effects), making the tool callable without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a generic 'Saison sportive' description. The tool description adds meaning by stating that season 'filtre l'inventaire à la saison ciblée' and reinforcing the default '2026-2027', which is a clear improvement over the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Liste l'ensemble des textes réglementaires' and enumerates the federal, regional, and departmental scope. It distinguishes itself from siblings by naming ffbb_get_regulation_article and ffbb_search_regulations as tools with a different purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use this tool: discover document_id before ffbb_get_regulation_article or choose a perimeter before ffbb_search_regulations. It also gives direct counter-guidance: not for textual search, article text, or tiebreak explanation, each with the correct sibling tool named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Matchs en cours (scores live, rafraîchissement toutes les 15s). Retourne [] si aucun match.
| Name | Required | Description | Default |
|---|---|---|---|
| include_scheduled | No | Si True, inclut aussi les matchs programmés à venir (statut SCHEDULED). Par défaut (False), ne retourne que les matchs réellement en cours de jeu. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a read-only, idempotent, non-destructive operation. The description adds useful behavioral details beyond annotations: the data refreshes every 15 seconds and an empty array is returned when no match is ongoing. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short statements that front-load the main behavior and then cover the empty-result edge case. Every word contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and rich safety annotations, the description covers the key behavior, refresh behavior, and empty-array case. The exact shape of a live match object is not described, but the tool's low complexity and schema coverage make this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter is fully described in the input schema (100% coverage), including its default and effect. The tool description itself adds no parameter-specific meaning, but this is acceptable because the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns ongoing matches with live scores and a 15-second refresh. While it does not explicitly differentiate it from siblings like ffbb_next_match or ffbb_last_result, the phrase 'Matchs en cours' makes its specific scope evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this when you need current live matches. However, it does not mention any alternatives or explicitly state when not to use it, leaving the agent to infer routing from the sibling list and the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prochain match à jouer pour une équipe précise.
⚠️ SINGULIER UNIQUEMENT. Si la demande est au pluriel ("matchs restants", "derniers matchs à jouer", "calendrier"), utiliser ffbb_club(action="calendrier") à la place.
⚠️ ATTENTION LLM : Cet outil retourne STRICTEMENT LE PROCHAIN MATCH UNIQUE.
Ne l'utilise JAMAIS si l'utilisateur demande "les prochains matchs" au pluriel.
Pour toute requête au pluriel, utilise OBLIGATOIREMENT ffbb_club(action="calendrier")
et filtre les résultats toi-même.
Recommendation LLM : Si la categorie est imprécise ou sans numéro (ex: 'U11M'),
appeler d'abord ffbb_resolve_team pour obtenir le numero_equipe reel.
| Name | Required | Description | Default |
|---|---|---|---|
| poule_id | No | ID FFBB de la poule pour désambiguïser. | |
| categorie | No | Catégorie de l'équipe précise (ex: 'U11M1', 'U11M', 'SEM1', 'NM3'). | |
| club_name | No | Nom du club (ex: 'Stade Clermontois') | |
| season_id | No | ID de la saison FFBB (optionnel). | |
| organisme_id | No | Identifiant FFBB du club (organisme_id, ex: '9326' ou 'ARA0063058'). | |
| engagement_id | No | ID FFBB de l'engagement (prioritaire pour désambiguïser). | |
| force_refresh | No | Si True, force un rafraichissement des donnees de poule | |
| numero_equipe | No | Numéro d'équipe dans la catégorie. Résoudre avec ffbb_resolve_team si ambigu. | |
| competition_id | No | ID FFBB de la compétition pour désambiguïser. | |
| competition_type | No | Type de compétition ('PLAT', 'COUPE', etc.) pour désambiguïser. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond annotations, notably that the tool returns STRICTLY ONE next match and should never be used for plural requests. No annotation contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and the critical singular-only constraint. The warnings about plural requests are somewhat repeated, but each repetition reinforces an important failure mode Lewis: 'ATTENTION LLM' is redundant with the earlier warning yet still earns its place due to the high cost of misuse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, an anyOf selection constraint, and no output schema, the description provides critical routing and parameter-resolution guidance. It does not fully explain how to choose among organisme_id, club_name, engagement_id, poule_id, and competition_id, but the schema descriptions largely cover those fields, and the description covers the main ambiguity traps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds extra semantic guidance by explaining that an imprecise category such as 'U11M' should first be resolved via ffbb_resolve_team to get the real numero_equipe, which clarifies how to use the categorie and numero_equipe parameters together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb plus resource: 'Prochain match à jouer pour une équipe précise.' This clearly distinguishes it from siblings like ffbb_last_result and ffbb_club(action="calendrier") by emphasizing the singular next match for one team.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use and when-not-to-use guidance: use it only for singular next-match requests, and use ffbb_club(action="calendrier") for plural requests. It also recommends ffbb_resolve_team when the category lacks a number, directly steering the agent to the correct alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identifie une equipe unique (Pivot central).
DOIT etre utilise avant ffbb_next_match ou ffbb_last_result si l'agent
ne connait pas le numero d'equipe exact ou si la categorie est ambiguë (ex: 'U11M').
Pour une équipe senior au niveau national ou régional, la catégorie FFBB interne est souvent SEM1 ou SEF1 ;
le serveur résout désormais NM3, NM2, NF1, PNM, R2, etc. vers la bonne équipe et sa poule.
| Name | Required | Description | Default |
|---|---|---|---|
| poule_id | No | ID FFBB de la poule pour désambiguïser. | |
| categorie | No | Catégorie + genre + numéro d'équipe (ex: 'U11M1', 'U13F2', 'SEM1') ou division (ex: 'NM3', 'R2', 'PNM'). Si le numéro manque, cet outil retourne la bonne équipe ou des candidats. | |
| club_name | No | Nom du club (ex: 'Stade Clermontois', 'ASVEL'). | |
| season_id | No | ID de la saison FFBB (optionnel). | |
| organisme_id | No | ID FFBB du club (alternative plus rapide à club_name). | |
| engagement_id | No | ID FFBB de l'engagement (prioritaire pour désambiguïser). | |
| force_refresh | No | Si True, force le rafraîchissement des données. | |
| numero_equipe | No | Numéro d'équipe facultatif (ex: 1, 2). | |
| competition_id | No | ID FFBB de la compétition pour désambiguïser. | |
| competition_type | No | Type de compétition ('PLAT', 'COUPE', etc.) pour désambiguïser. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/openWorld/idempotent/non-destructive behavior, and the description does not contradict them. It adds meaningful context by explaining that the server resolves common division labels into internal FFBB categories and pools, and that the tool acts as a central prerequisite before dependent tools. It does not, however, describe the candidate-return behavior in the main text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, followed by direct usage guidance and a useful alias-resolution nuance. Each sentence earns its place, and there is no redundant restating of the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a resolver tool with no output schema, the description conveys the core behavior — it identifies a unique team, is a central prerequisite, and maps common division labels to the correct team and pool. The parameter schema further fills in ambiguity handling by mentioning 'la bonne équipe ou des candidats.' It could still explain the output shape more explicitly, but the current guidance is largely sufficient given the rich schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 10 parameters have schema descriptions (100% coverage), so the baseline is 3 and the schema already carries the parameter meaning. The main description reinforces the 'categorie' semantics with division examples, but adds little beyond what the 'categorie' parameter description already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Identifie une equipe unique (Pivot central).' It clearly positions this tool as the central team resolver and distinguishes it from the sibling match/result/search tools by naming which tools depend on it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('DOIT etre utilise avant ffbb_next_match ou ffbb_last_result') and the exact condition: when the agent does not know the exact team number or the category is ambiguous. It also provides a concrete senior-category alias example (NM3, NM2, NF1, PNM, R2), giving clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liste des saisons FFBB (référentiel temporel).
Retourne la liste complète des saisons FFBB sous forme list[dict] triée
chronologiquement, chaque entrée contenant season_id, label, debut, fin,
enCours (calculé via debut <= today <= fin). Lecture seule, idempotent,
sans effet de bord ni écriture. Cache SWR avec TTL long (≈24h) ;
force_refresh=True contourne le cache pour données fraîches et
active_only=True filtre côté serveur pour ne garder que la saison active.
Utilise cet outil pour récupérer les season_id disponibles avant d'appeler
ffbb_bilan, ffbb_club ou ffbb_team_summary avec un filtre de saison.
Ne pas utiliser pour obtenir un classement, un calendrier ou un bilan — utilise
ffbb_club(action="classement") ou ffbb_bilan à la place ; pour la version
du serveur, utilise ffbb_version.
| Name | Required | Description | Default |
|---|---|---|---|
| active_only | No | True = saison active uniquement. | |
| force_refresh | No | Si True, contourne le cache. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description reinforces these with 'Lecture seule, idempotent, sans effet de bord ni écriture'. Beyond that, it adds behavioral detail not covered by annotations: SWR caching with a ~24h TTL, the force_refresh parameter to bypass cache, the active_only server-side filter, and the enCours calculation logic. This is rich behavioral transparency that exceeds what the annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about 6 sentences, each adding distinct value: purpose, return format, behavioral notes (cache, idempotency), parameter effects, and usage guidance with alternatives. It is front-loaded with the primary purpose, and there is no filler or redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description is complete. It covers what the tool returns, the structure of each entry, the caching behavior, the filter parameters, and when to use it versus alternatives. Nothing an agent needs to correctly invoke or interpret the result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% – both parameters have descriptions (active_only: 'True = saison active uniquement', force_refresh: 'Si True, contourne le cache'). The description adds further meaning by explaining how each parameter interacts with the cache and server-side filtering, e.g., 'force_refresh=True contourne le cache' and 'active_only=True filtre côté serveur'. This goes beyond the schema and clarifies the practical effect of each flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear statement of what the tool returns: the complete list of FFBB seasons as a chronologically sorted list of dicts with specific fields. It distinguishes itself from siblings like ffbb_version (server version) and ffbb_club/ffbb_bilan by explicitly stating it is a temporal referential for seasons. The purpose is unmistakable and specific to the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: fetch season_id before calling bilan/club/team_summary with a season filter. It also names alternatives for other needs (classement, calendrier, bilan) and explicitly says to use ffbb_club(action='classement') or ffbb_bilan instead, and ffbb_version for server version. This fully covers both positive and negative usage cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche FFBB — clubs, compétitions, matchs, salles, tournois, etc.
type='all' → recherche globale (meilleur point d'entrée).
type='organismes' → clubs uniquement.
type='competitions' → compétitions uniquement.
type='salles' → salles / gymnases.
filter_by='codePostal = "63000"' → filtrage par code postal ou critères Meilisearch.
Résultats contiennent un 'id' à utiliser avec ffbb_get ou ffbb_club.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Tri Meilisearch (ex: ['libelle:asc']). | |
| type | No | Type de données. 'all' cherche partout (défaut). | all |
| limit | No | Nombre maximum de résultats à retourner (1-100). | |
| query | Yes | Texte libre (ex: 'Vichy', 'U13F Auvergne'). | |
| offset | No | Index de départ pour pagination (défaut: 0). | |
| filter_by | No | Filtre Meilisearch natif (ex: 'codePostal = "63000"', 'codePostal IN ["63000", "63100"]', 'departement = "Puy-de-Dôme"'). | |
| force_refresh | No | Si True, force le rafraîchissement des données. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context about type-based filtering and the presence of an id in results, but it does not disclose any additional behavioral traits like force_refresh implications or pagination behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a tight bullet list with no filler. Each line earns its place, key usage is front-loaded, and examples are practical. It is very easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main search entry points, common type filters, and the critical follow-up behavior (results contain an id to use with ffbb_get/ffbb_club). It omits explanations for some less obvious enum values, but those are mostly self-explanatory, so the description is reasonably complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 7 parameters, and the description adds meaning beyond that by explaining specific type values ('organismes' → clubs, 'competitions' → compétitions, 'salles' → salles/gymnases) and giving a concrete filter_by example. This enriches what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a multi-index FFBB search tool covering clubs, competitions, matches, halls, tournaments, etc., and explains type-specific search behavior. It does not explicitly distinguish itself from the sibling ffbb_search_regulations, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage guidance such as 'type=all → recherche globale (meilleur point d'entrée)' and advises that results contain an id to use with ffbb_get or ffbb_club. However, it does not mention when to prefer this tool over ffbb_search_regulations or other sibling search tools, leaving some routing ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche plein texte déterministe dans les règlements officiels FFBB, régionaux et départementaux.
Permet de retrouver les articles pertinents sur les qualifications, montées/descentes,
brassages jeunes, règles techniques (durée, ballons, zone), forfaits et brûlage.
Retourne dict avec extraits[] (document_id, article_number, score, extrait)
triés par pertinence ; lecture seule, idempotent, cache SWR.
Utilise cet outil quand tu ne connais pas le numéro d'article et que tu cherches par
mots-clés. Ne pas utiliser pour récupérer un article précis — utilise
ffbb_get_regulation_article à la place ; pour lister les documents — utilise
ffbb_list_regulations ; pour expliquer un départage — utilise
ffbb_explain_tiebreak_rules au lieu de chercher le texte. Affûte avec level,
organizer, category et limit pour réduire le bruit.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Niveau de compétition ciblé : 'federal' (FFBB national / RSG / Élite), 'regional' (Ligues, ex: AURA), 'departmental' (Comités, ex: Comité 63) | |
| limit | No | Nombre maximal d'extraits d'articles à retourner (défaut 5, max 10) | |
| query | No | Terme ou question de recherche dans les règlements (ex: 'brûlage équipe réserve', 'défense de zone U13', 'brassages départementaux', 'barrages accession') | |
| topic | No | Mots-clés thématiques (ex: 'departages', 'brulage', 'forfaits', 'poule_haute') | |
| season | No | Saison sportive ciblée (par défaut '2026-2027') | 2026-2027 |
| category | No | Catégorie d'âge ou division (ex: 'U13', 'U15', 'U18', 'seniors', 'elite') | |
| organizer | No | Nom ou sigle de l'organisateur (ex: 'FFBB', 'Ligue AURA', 'Comité 63') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses concrete behavior: it is deterministic, uses SWR caching, returns a dict with extraits[] containing document_id, article_number, score, and extrait, and sorts results by relevance. This adds useful context beyond the readOnlyHint/idempotentHint annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured into three focused paragraphs: the core function and scope, the return value and behavioral properties, then usage guidance with alternatives. Every sentence delivers useful information, and the key purpose and exclusions appear early.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 7 optional parameters, no required fields, and no output schema, the description is complete: it covers what the tool searches, what it returns, how results are ordered, its side-effect-free behavior, when to use it, when not to use it, and which parameters to refine with. The rich schema fills the remaining detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all 7 parameters with examples and defaults, so the description does not need to repeat them. The line 'Affûte avec level, organizer, category et limit pour réduire le bruit' adds a small amount of grouping/purpose information, but it is not essential given the 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a precise verb and resource: 'recherche plein texte déterministe dans les règlements officiels FFBB, régionaux et départementaux.' It further clarifies the scope by listing concrete topics such as qualifications, montées/descentes, and forfaits, and it distinguishes itself from the relevant sibling tools (ffbb_get_regulation_article, ffbb_list_regulations, ffbb_explain_tiebreak_rules).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is explicit about when to use the tool: 'quand tu ne connais pas le numéro d'article et que tu cherches par mots-clés.' It also gives explicit exclusions and alternatives: use ffbb_get_regulation_article for a specific article, ffbb_list_regulations to list documents, and ffbb_explain_tiebreak_rules for tiebreak explanations, so an agent is not left guessing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Résumé complet et agent-friendly pour une équipe.
Combine en UN seul appel :
bilan global (toutes phases)
phase courante et son classement
dernier match joué
prochain match à venir
Pour une équipe senior au niveau national ou régional, la catégorie FFBB interne est souvent SEM1 ou SEF1 ;
le serveur résout désormais NM3, NM2, NF1, PNM, R2, etc. vers la bonne équipe et sa poule.
Recommandé pour une vue rapide d'une équipe précise. Si la catégorie est ambiguë
ou sans numéro d'équipe, l'outil tente une résolution via ffbb_resolve_team.
Pour une liste de matchs restants, utiliser plutôt ffbb_club(action="calendrier").
| Name | Required | Description | Default |
|---|---|---|---|
| poule_id | No | ID FFBB de la poule pour désambiguïser. | |
| categorie | No | Catégorie/division + genre + numéro d'équipe (ex: 'U11M1', 'U13F2', 'SEM1', 'NM3', 'PNM'). | |
| club_name | No | Nom du club (ex: 'Stade Clermontois', 'ASVEL'). | |
| season_id | No | ID de la saison FFBB (optionnel). | |
| organisme_id | No | ID FFBB du club (alternative plus rapide à club_name). | |
| engagement_id | No | ID FFBB de l'engagement (prioritaire pour désambiguïser). | |
| force_refresh | No | Si True, force un rafraichissement des donnees | |
| numero_equipe | No | Numéro d'équipe dans la catégorie (ex: 1, 2). | |
| competition_id | No | ID FFBB de la compétition pour désambiguïser. | |
| competition_type | No | Type de compétition ('PLAT', 'COUPE', etc.) pour désambiguïser. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds non-obvious behavioral context: it combines several data types into one call, resolves labels like NM3/PNM server-side, and falls back to ffbb_resolve_team on ambiguous categories. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The bulleted 'Combine en UN seul appel' block front-loads the core aggregation behavior, followed by a compact paragraph covering resolution rules and the sibling alternative. Every sentence earns its place without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with anyOf-based identifiers and no output schema, the description covers what the summary contains, how identifiers are resolved, when to prefer this tool, and which sibling handles remaining-match lists. Parameter details are fully covered by the schema, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds real parameter context by showing accepted category examples like SEM1, NM3, and PNM, and by clarifying how ambiguous or missing team numbers trigger resolution, which goes beyond the schema's generic category format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Résumé complet et agent-friendly pour une équipe' and then explicitly enumerates what the call aggregates: bilan global, phase courante/classement, dernier match, and prochain match. This is a specific verb-resource statement that clearly distinguishes it from narrower siblings like ffbb_bilan or ffbb_last_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states 'Recommandé pour une vue rapide d'une équipe précise', explains when category resolution applies via ffbb_resolve_team, and explicitly defers remaining-match lists to ffbb_club(action='calendrier'). This gives the agent both positive selection criteria and a clear exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Informations de version et configuration runtime du serveur FFBB MCP.
Retourne dict compact et typé {package_version, mcp_sdk_version, python_version, transport, cache_ttls} ; lecture seule, idempotent, sans
appel réseau externe ni effet de bord, <10ms.
Utilise cet outil pour diagnostiquer la version déployée, vérifier le transport
(stdio vs streamable-http) ou inspecter les TTL avant de debugger un autre
outil. Ne pas utiliser pour obtenir des données basket — utilise ffbb_search,
ffbb_club ou ffbb_bilan à la place ; pour la santé live, préfère /health.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description is fully consistent with them (no contradiction). The description adds valuable context beyond annotations: no external network call, no side effects, <10ms latency, and the compact typed return shape. Given the annotations carry the safety profile, the extra performance and network behavior context earns a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded paragraphs: purpose and return shape first, then use cases, then exclusions. Every sentence earns its place, though the return fields are effectively mentioned twice (once in the dict description and once in the use-case sentence), a minor redundancy that keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only diagnostic tool with rich annotations, the description covers purpose, use cases, exclusions, return shape, and performance. It does not spell out the exact format of each dict value, but for such a low-complexity tool nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies — there is nothing to document. The description instead clarifies the output shape ({package_version, mcp_sdk_version, python_version, transport, cache_ttls}), which is genuinely useful since there is no output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific purpose: diagnosing server version and runtime configuration. It names the exact resource (FFBB MCP server), lists the returned fields, and explicitly differentiates itself from basket-data tools (ffbb_search, ffbb_club, ffbb_bilan) and from the live-health endpoint (/health). An agent can instantly tell what this tool is and is not for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it (diagnose deployed version, verify transport stdio vs streamable-http, inspect TTLs before debugging another tool) and when not to (not for basket data, not for live health, with named alternatives). This is textbook usage guidance — nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.13.0ffbb_bilan8 fields changedInput schema / anyOfPrevious value: -[
- {
- "required": [
- "club_name"
- ]
- },
- {
- "required": [
- "organisme_id"
- ]
- }
-]New value: +[
+ {
+ "required": [
+ "organisme_id"
+ ]
+ },
+ {
+ "required": [
+ "club_name"
+ ]
+ },
+ {
+ "required": [
+ "engagement_id"
+ ]
+ },
+ {
+ "required": [
+ "poule_id"
+ ]
+ },
+ {
+ "required": [
+ "competition_id"
+ ]
+ }
+]Input schema / properties / club_name / descriptionPrevious value: -"Nom du club (ex: 'Stade Clermontois', 'ASVEL')."New value: +"Nom du club (ex: 'Stade Clermontois', 'ASVEL'). Requis si organisme_id absent."Input schema / properties / competition_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de la compétition pour désambiguïser.",
+ "title": "Competition Id"
+}Input schema / properties / competition_typeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Type de compétition ('PLAT', 'COUPE', etc.) pour désambiguïser.",
+ "title": "Competition Type"
+}Input schema / properties / engagement_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de l'engagement (prioritaire pour désambiguïser).",
+ "title": "Engagement Id"
+}Input schema / properties / organisme_id / descriptionPrevious value: -"ID FFBB du club (ex: 9326)."New value: +"ID FFBB du club (ex: '9326' ou 'ARA0063058'). Requis si club_name absent."Input schema / properties / poule_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de la poule pour désambiguïser.",
+ "title": "Poule Id"
+}Input schema / properties / season_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID de la saison FFBB (optionnel).",
+ "title": "Season Id"
+}ffbb_bilan_saison7 fields changedInput schema / anyOfPrevious value: -[
- {
- "required": [
- "club_name"
- ]
- },
- {
- "required": [
- "organisme_id"
- ]
- }
-]New value: +[
+ {
+ "required": [
+ "organisme_id"
+ ]
+ },
+ {
+ "required": [
+ "club_name"
+ ]
+ },
+ {
+ "required": [
+ "engagement_id"
+ ]
+ },
+ {
+ "required": [
+ "poule_id"
+ ]
+ },
+ {
+ "required": [
+ "competition_id"
+ ]
+ }
+]Input schema / properties / competition_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de la compétition pour désambiguïser.",
+ "title": "Competition Id"
+}Input schema / properties / competition_typeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Type de compétition ('PLAT', 'COUPE', etc.) pour désambiguïser.",
+ "title": "Competition Type"
+}Input schema / properties / engagement_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de l'engagement (prioritaire pour désambiguïser).",
+ "title": "Engagement Id"
+}Input schema / properties / numero_equipe / defaultPrevious value: -1New value: +nullInput schema / properties / poule_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de la poule pour désambiguïser.",
+ "title": "Poule Id"
+}Input schema / properties / season_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID de la saison FFBB (optionnel).",
+ "title": "Season Id"
+}ffbb_club14 fields changedInput schema / anyOfPrevious value: -[
- {
- "required": [
- "club_name"
- ]
- },
- {
- "required": [
- "organisme_id"
- ]
- },
- {
- "required": [
- "poule_id"
- ]
- }
-]New value: +[
+ {
+ "required": [
+ "organisme_id"
+ ]
+ },
+ {
+ "required": [
+ "club_name"
+ ]
+ },
+ {
+ "required": [
+ "poule_id"
+ ]
+ },
+ {
+ "required": [
+ "engagement_id"
+ ]
+ },
+ {
+ "required": [
+ "competition_id"
+ ]
+ }
+]Input schema / properties / action / defaultAdded value: +"calendrier"Input schema / properties / competition_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de la compétition pour désambiguïser.",
+ "title": "Competition Id"
+}Input schema / properties / competition_typeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Type de compétition ('PLAT', 'COUPE', etc.) pour désambiguïser.",
+ "title": "Competition Type"
+}Input schema / properties / engagement_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de l'engagement (prioritaire pour désambiguïser).",
+ "title": "Engagement Id"
+}Input schema / properties / filtre / descriptionPrevious value: -"Filtre catégorie/genre (ex: 'U11M', 'Senior', 'NM3')."New value: +"Filtre catégorie/genre (alias pour 'categorie', ex: 'U11M', 'Senior', 'NM3')."Input schema / properties / limit / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / limit / descriptionPrevious value: -"Nombre max de matchs retournés (pagination)."New value: +"Nombre max de matchs retournés (1-100, pagination)."Input schema / properties / offsetAdded value: +{
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Index de départ pour pagination calendrier (défaut 0).",
+ "title": "Offset"
+}Input schema / properties / organisme_id / descriptionPrevious value: -"ID FFBB du club (ex: 9326). Requis si club_name absent."New value: +"ID FFBB du club (ex: '9326'). Requis si club_name absent."Input schema / properties / poule_id / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / poule_id / descriptionPrevious value: -"ID poule (action='classement'). Optionnel si club et catégorie sont fournis."New value: +"ID poule (action='classement' ou 'calendrier'). Optionnel si club et catégorie sont fournis."Input schema / properties / season_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID de la saison FFBB (optionnel).",
+ "title": "Season Id"
+}Input schema / requiredRemoved value: -[
- "action"
-]ffbb_explain_tiebreak_rulesffbb_get3 fields changedInput schema / properties / id / anyOfAdded value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / id / descriptionPrevious value: -"Identifiant numérique FFBB exact. Ne pas passer un nom de club: utiliser d'abord ffbb_search pour résoudre l'id."New value: +"Identifiant FFBB exact (string opaque, ex: '200000003057825'). Ne pas passer un nom de club: utiliser d'abord ffbb_search pour résoudre l'id."Input schema / properties / id / typeRemoved value: -"integer"ffbb_get_regulation_articleffbb_head_to_head15 fields changedInput schema / anyOfAdded value: +[
+ {
+ "required": [
+ "club_a"
+ ]
+ },
+ {
+ "required": [
+ "organisme_id_a"
+ ]
+ },
+ {
+ "required": [
+ "club_name"
+ ]
+ },
+ {
+ "required": [
+ "organisme_id"
+ ]
+ },
+ {
+ "required": [
+ "engagement_id_a"
+ ]
+ },
+ {
+ "required": [
+ "engagement_id"
+ ]
+ },
+ {
+ "required": [
+ "poule_id"
+ ]
+ }
+]Input schema / properties / adversaireAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Alias pour club_b : nom du second club / adversaire (ex: 'Vichy').",
+ "title": "Adversaire"
+}Input schema / properties / adversaire_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Alias pour organisme_id_b : ID FFBB du second club / adversaire.",
+ "title": "Adversaire Id"
+}Input schema / properties / club_b / descriptionPrevious value: -"Nom du second club (ex: 'Vichy', 'Roanne')."New value: +"Nom du second club / adversaire (ex: 'Vichy', 'Roanne')."Input schema / properties / club_nameAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Alias pour club_a : nom du premier club (ex: 'Stade Clermontois').",
+ "title": "Club Name"
+}Input schema / properties / competition_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de la compétition pour désambiguïser.",
+ "title": "Competition Id"
+}Input schema / properties / competition_typeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Type de compétition ('PLAT', 'COUPE', etc.) pour désambiguïser.",
+ "title": "Competition Type"
+}Input schema / properties / engagement_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de l'engagement partagé ou équipe A (alias pour engagement_id_a).",
+ "title": "Engagement Id"
+}Input schema / properties / engagement_id_aAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de l'engagement équipe A (prioritaire).",
+ "title": "Engagement Id A"
+}Input schema / properties / engagement_id_bAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de l'engagement équipe B (prioritaire).",
+ "title": "Engagement Id B"
+}Input schema / properties / organisme_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Alias pour organisme_id_a : ID FFBB du premier club.",
+ "title": "Organisme Id"
+}Input schema / properties / organisme_id_a / descriptionPrevious value: -"ID FFBB du premier club (ex: 9326)."New value: +"ID FFBB du premier club (ex: '9326')."Input schema / properties / organisme_id_b / descriptionPrevious value: -"ID FFBB du second club."New value: +"ID FFBB du second club / adversaire."Input schema / properties / poule_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de la poule pour désambiguïser.",
+ "title": "Poule Id"
+}Input schema / properties / season_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID de la saison FFBB (optionnel).",
+ "title": "Season Id"
+}ffbb_last_result15 fields changedInput schema / anyOfPrevious value: -[
- {
- "required": [
- "club_name"
- ]
- },
- {
- "required": [
- "organisme_id"
- ]
- }
-]New value: +[
+ {
+ "required": [
+ "organisme_id"
+ ]
+ },
+ {
+ "required": [
+ "club_name"
+ ]
+ },
+ {
+ "required": [
+ "engagement_id"
+ ]
+ },
+ {
+ "required": [
+ "poule_id"
+ ]
+ },
+ {
+ "required": [
+ "competition_id"
+ ]
+ }
+]Input schema / properties / categorie / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / categorie / defaultAdded value: +nullInput schema / properties / categorie / descriptionPrevious value: -"Catégorie de l'équipe précise (ex: 'U11M1', 'U11M', 'U11F')"New value: +"Catégorie de l'équipe précise (ex: 'U11M1', 'U11M', 'SEM1', 'NM3')."Input schema / properties / categorie / typeRemoved value: -"string"Input schema / properties / competition_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de la compétition pour désambiguïser.",
+ "title": "Competition Id"
+}Input schema / properties / competition_typeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Type de compétition ('PLAT', 'COUPE', etc.) pour désambiguïser.",
+ "title": "Competition Type"
+}Input schema / properties / engagement_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de l'engagement (prioritaire pour désambiguïser).",
+ "title": "Engagement Id"
+}Input schema / properties / numero_equipe / anyOfAdded value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / numero_equipe / defaultPrevious value: -1New value: +nullInput schema / properties / numero_equipe / typeRemoved value: -"integer"Input schema / properties / organisme_id / descriptionPrevious value: -"Identifiant FFBB du club (organisme_id, ex: 1234 ou 'ARA0063058')"New value: +"Identifiant FFBB du club (organisme_id, ex: '9326' ou 'ARA0063058')."Input schema / properties / poule_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de la poule pour désambiguïser.",
+ "title": "Poule Id"
+}Input schema / properties / season_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID de la saison FFBB (optionnel).",
+ "title": "Season Id"
+}Input schema / requiredRemoved value: -[
- "categorie"
-]ffbb_list_regulationsffbb_lives1 field changedInput schema / properties / include_scheduledAdded value: +{
+ "default": false,
+ "description": "Si True, inclut aussi les matchs programmés à venir (statut SCHEDULED). Par défaut (False), ne retourne que les matchs réellement en cours de jeu.",
+ "title": "Include Scheduled",
+ "type": "boolean"
+}ffbb_next_match15 fields changedInput schema / anyOfPrevious value: -[
- {
- "required": [
- "club_name"
- ]
- },
- {
- "required": [
- "organisme_id"
- ]
- }
-]New value: +[
+ {
+ "required": [
+ "organisme_id"
+ ]
+ },
+ {
+ "required": [
+ "club_name"
+ ]
+ },
+ {
+ "required": [
+ "engagement_id"
+ ]
+ },
+ {
+ "required": [
+ "poule_id"
+ ]
+ },
+ {
+ "required": [
+ "competition_id"
+ ]
+ }
+]Input schema / properties / categorie / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / categorie / defaultAdded value: +nullInput schema / properties / categorie / descriptionPrevious value: -"Catégorie de l'équipe précise (ex: 'U11M1', 'U11M', 'U11F')"New value: +"Catégorie de l'équipe précise (ex: 'U11M1', 'U11M', 'SEM1', 'NM3')."Input schema / properties / categorie / typeRemoved value: -"string"Input schema / properties / competition_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de la compétition pour désambiguïser.",
+ "title": "Competition Id"
+}Input schema / properties / competition_typeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Type de compétition ('PLAT', 'COUPE', etc.) pour désambiguïser.",
+ "title": "Competition Type"
+}Input schema / properties / engagement_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de l'engagement (prioritaire pour désambiguïser).",
+ "title": "Engagement Id"
+}Input schema / properties / numero_equipe / anyOfAdded value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / numero_equipe / defaultPrevious value: -1New value: +nullInput schema / properties / numero_equipe / typeRemoved value: -"integer"Input schema / properties / organisme_id / descriptionPrevious value: -"Identifiant FFBB du club (organisme_id, ex: 1234 ou 'ARA0063058')"New value: +"Identifiant FFBB du club (organisme_id, ex: '9326' ou 'ARA0063058')."Input schema / properties / poule_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de la poule pour désambiguïser.",
+ "title": "Poule Id"
+}Input schema / properties / season_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID de la saison FFBB (optionnel).",
+ "title": "Season Id"
+}Input schema / requiredRemoved value: -[
- "categorie"
-]ffbb_resolve_team7 fields changedInput schema / anyOfPrevious value: -[
- {
- "required": [
- "club_name"
- ]
- },
- {
- "required": [
- "organisme_id"
- ]
- }
-]New value: +[
+ {
+ "required": [
+ "organisme_id"
+ ]
+ },
+ {
+ "required": [
+ "club_name"
+ ]
+ },
+ {
+ "required": [
+ "engagement_id"
+ ]
+ },
+ {
+ "required": [
+ "poule_id"
+ ]
+ },
+ {
+ "required": [
+ "competition_id"
+ ]
+ }
+]Input schema / properties / competition_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de la compétition pour désambiguïser.",
+ "title": "Competition Id"
+}Input schema / properties / competition_typeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Type de compétition ('PLAT', 'COUPE', etc.) pour désambiguïser.",
+ "title": "Competition Type"
+}Input schema / properties / engagement_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de l'engagement (prioritaire pour désambiguïser).",
+ "title": "Engagement Id"
+}Input schema / properties / force_refreshAdded value: +{
+ "default": false,
+ "description": "Si True, force le rafraîchissement des données.",
+ "title": "Force Refresh",
+ "type": "boolean"
+}Input schema / properties / poule_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de la poule pour désambiguïser.",
+ "title": "Poule Id"
+}Input schema / properties / season_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID de la saison FFBB (optionnel).",
+ "title": "Season Id"
+}ffbb_saisons1 field changedInput schema / properties / force_refreshAdded value: +{
+ "default": false,
+ "description": "Si True, contourne le cache.",
+ "title": "Force Refresh",
+ "type": "boolean"
+}ffbb_search4 fields changedInput schema / properties / filter_by / descriptionPrevious value: -"Filtre Meilisearch natif (ex: 'codePostal = \"63000\"')."New value: +"Filtre Meilisearch natif (ex: 'codePostal = \"63000\"', 'codePostal IN [\"63000\", \"63100\"]', 'departement = \"Puy-de-Dôme\"')."Input schema / properties / force_refreshAdded value: +{
+ "default": false,
+ "description": "Si True, force le rafraîchissement des données.",
+ "title": "Force Refresh",
+ "type": "boolean"
+}Input schema / properties / limit / descriptionPrevious value: -"Nombre maximum de résultats à retourner."New value: +"Nombre maximum de résultats à retourner (1-100)."Input schema / properties / offsetAdded value: +{
+ "default": 0,
+ "description": "Index de départ pour pagination (défaut: 0).",
+ "title": "Offset",
+ "type": "integer"
+}ffbb_search_regulationsffbb_team_summary9 fields changedInput schema / anyOfPrevious value: -[
- {
- "required": [
- "club_name"
- ]
- },
- {
- "required": [
- "organisme_id"
- ]
- }
-]New value: +[
+ {
+ "required": [
+ "organisme_id"
+ ]
+ },
+ {
+ "required": [
+ "club_name"
+ ]
+ },
+ {
+ "required": [
+ "engagement_id"
+ ]
+ },
+ {
+ "required": [
+ "poule_id"
+ ]
+ },
+ {
+ "required": [
+ "competition_id"
+ ]
+ }
+]Input schema / properties / competition_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de la compétition pour désambiguïser.",
+ "title": "Competition Id"
+}Input schema / properties / competition_typeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Type de compétition ('PLAT', 'COUPE', etc.) pour désambiguïser.",
+ "title": "Competition Type"
+}Input schema / properties / engagement_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de l'engagement (prioritaire pour désambiguïser).",
+ "title": "Engagement Id"
+}Input schema / properties / numero_equipe / anyOfAdded value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / numero_equipe / defaultPrevious value: -1New value: +nullInput schema / properties / numero_equipe / typeRemoved value: -"integer"Input schema / properties / poule_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID FFBB de la poule pour désambiguïser.",
+ "title": "Poule Id"
+}Input schema / properties / season_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID de la saison FFBB (optionnel).",
+ "title": "Season Id"
+}v1.10.0ffbb_club4 fields changedInput schema / properties / categorieAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Catégorie, division ou filtre d'équipe (alias pour 'filtre', ex: 'NM3', 'U15M', 'Senior').",
+ "title": "Categorie"
+}Input schema / properties / filtre / descriptionPrevious value: -"Filtre catégorie/genre (ex: 'U11M', 'Senior')."New value: +"Filtre catégorie/genre (ex: 'U11M', 'Senior', 'NM3')."Input schema / properties / numero_equipe / descriptionPrevious value: -"Numéro d'équipe (ex: 1, 2) pour action='calendrier'."New value: +"Numéro d'équipe (ex: 1, 2) pour action='calendrier' ou 'classement'."Input schema / properties / poule_id / descriptionPrevious value: -"ID poule (action='classement')."New value: +"ID poule (action='classement'). Optionnel si club et catégorie sont fournis."ffbb_get2 fields changedInput schema / properties / clubAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Nom ou ID du club à localiser dans les poules (si type='competition'). Permet de trouver directement l'ID et le nom de poule d'un club dans une compétition multi-poules.",
+ "title": "Club"
+}Input schema / properties / type / enumPrevious value: -[
- "competition",
- "poule",
- "organisme",
- "rencontre",
- "officiel",
- "entraineur"
-]New value: +[
+ "competition",
+ "poule",
+ "organisme",
+ "rencontre",
+ "officiel",
+ "entraineur",
+ "salle"
+]ffbb_resolve_team1 field changedInput schema / properties / categorie / descriptionPrevious value: -"Catégorie + genre + numéro d'équipe (ex: 'U11M1', 'U13F2', 'U15M'). Si le numéro manque, cet outil retourne la bonne équipe ou des candidats."New value: +"Catégorie + genre + numéro d'équipe (ex: 'U11M1', 'U13F2', 'SEM1') ou division (ex: 'NM3', 'R2', 'PNM'). Si le numéro manque, cet outil retourne la bonne équipe ou des candidats."ffbb_team_summary1 field changedInput schema / properties / categorie / descriptionPrevious value: -"Catégorie + genre + numéro d'équipe (ex: 'U11M1', 'U13F2', 'U15M', 'Senior')."New value: +"Catégorie/division + genre + numéro d'équipe (ex: 'U11M1', 'U13F2', 'SEM1', 'NM3', 'PNM')."v1.9.0ffbb_bilan6 fields changedInput schema / anyOfAdded value: +[
+ {
+ "required": [
+ "club_name"
+ ]
+ },
+ {
+ "required": [
+ "organisme_id"
+ ]
+ }
+]Input schema / properties / categorie / descriptionPrevious value: -"Catégorie + genre + numéro d'équipe (ex: 'U11M1', 'U13F2', 'U15M', 'Senior')."New value: +"Catégorie/genre/numéro (ex: 'U11M1', 'Senior')."Input schema / properties / force_refresh / descriptionPrevious value: -"Si True, contourne le cache pour récupérer des données fraîches."New value: +"Si True, contourne le cache."Input schema / properties / numero_equipe / descriptionPrevious value: -"Numéro d'équipe facultatif (ex: 1, 2)."New value: +"Numéro d'équipe (ex: 1, 2)."Input schema / properties / organisme_id / descriptionPrevious value: -"ID FFBB du club (alternative plus rapide à club_name)."New value: +"ID FFBB du club (ex: 9326)."Output schema / (root)Previous value: -{
- "$defs": {
- "BilanResponse": {
- "description": "Réponse structurée et typée pour le bilan d'une équipe.",
- "properties": {
- "_meta": {
- "additionalProperties": true,
- "description": "Métadonnées de fraîcheur et de cache.",
- "title": "Meta",
- "type": "object"
- },
- "bilan_total": {
- "$ref": "#/$defs/BilanTotal",
- "description": "Totaux cumulés toutes phases."
- },
- "categorie": {
- "description": "Catégorie d'âge/genre.",
- "title": "Categorie",
- "type": "string"
- },
- "club": {
- "description": "Nom officiel du club.",
- "title": "Club",
- "type": "string"
- },
- "competitions_incluses": {
- "description": "Liste des noms de compétitions incluses dans le bilan.",
- "items": {
- "type": "string"
- },
- "title": "Competitions Incluses",
- "type": "array"
- },
- "dynamique": {
- "anyOf": [
- {
- "$ref": "#/$defs/FormeRecente"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Dynamique et forme récente de l'équipe principale sur les 5 derniers matchs."
- },
- "equipes_bilan": {
- "additionalProperties": true,
- "description": "Bilans ventilés par numéro d'équipe.",
- "title": "Equipes Bilan",
- "type": "object"
- },
- "phase_courante": {
- "anyOf": [
- {
- "$ref": "#/$defs/PhaseBilan"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Détails de la dernière phase en cours."
- },
- "phases": {
- "description": "Liste de toutes les phases jouées.",
- "items": {
- "$ref": "#/$defs/PhaseBilan"
- },
- "title": "Phases",
- "type": "array"
- },
- "profil_avance": {
- "anyOf": [
- {
- "additionalProperties": true,
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Profil tactique avancé : rangs attaque/défense, style de jeu, clutch index et bilans domicile/extérieur.",
- "title": "Profil Avance"
- },
- "saison_terminee": {
- "default": true,
- "description": "Indique si la saison est terminée pour cette équipe (toutes les phases jouées).",
- "title": "Saison Terminee",
- "type": "boolean"
- }
- },
- "required": [
- "club",
- "categorie",
- "bilan_total"
- ],
- "title": "BilanResponse",
- "type": "object"
- },
- "BilanTotal": {
- "description": "Statistiques cumulées d'une équipe (victoires, défaites, paniers).",
- "properties": {
- "difference": {
- "default": 0,
- "description": "Différence de paniers (marqués - encaissés).",
- "title": "Difference",
- "type": "integer"
- },
- "gagnes": {
- "default": 0,
- "description": "Nombre de matchs gagnés.",
- "title": "Gagnes",
- "type": "integer"
- },
- "match_joues": {
- "default": 0,
- "description": "Nombre de matchs joués.",
- "title": "Match Joues",
- "type": "integer"
- },
- "nuls": {
- "default": 0,
- "description": "Nombre de matchs nuls.",
- "title": "Nuls",
- "type": "integer"
- },
- "paniers_encaisses": {
- "default": 0,
- "description": "Total des paniers encaissés.",
- "title": "Paniers Encaisses",
- "type": "integer"
- },
- "paniers_marques": {
- "default": 0,
- "description": "Total des paniers marqués.",
- "title": "Paniers Marques",
- "type": "integer"
- },
- "perdus": {
- "default": 0,
- "description": "Nombre de matchs perdus.",
- "title": "Perdus",
- "type": "integer"
- }
- },
- "title": "BilanTotal",
- "type": "object"
- },
- "FormeRecente": {
- "description": "Indicateur complet de dynamique et de forme récente (5 derniers matchs).",
- "properties": {
- "defaites_5_derniers": {
- "default": 0,
- "description": "Nombre de défaites sur les 5 derniers matchs.",
- "title": "Defaites 5 Derniers",
- "type": "integer"
- },
- "diff_moyenne_5": {
- "default": 0,
- "description": "Différentiel moyen de points sur les 5 derniers matchs.",
- "title": "Diff Moyenne 5",
- "type": "number"
- },
- "forme": {
- "description": "Résultats des 5 derniers matchs par ordre chronologique (ex: ['V', 'V', 'D', 'V', 'V']).",
- "items": {
- "type": "string"
- },
- "title": "Forme",
- "type": "array"
- },
- "forme_str": {
- "default": "",
- "description": "Représentation texte compacte de la forme (ex: 'V-V-D-V-V').",
- "title": "Forme Str",
- "type": "string"
- },
- "matchs": {
- "description": "Détail des matchs récents analysés.",
- "items": {
- "$ref": "#/$defs/MatchForme"
- },
- "title": "Matchs",
- "type": "array"
- },
- "meilleure_victoire": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Plus large victoire récente (ex: '+24 vs ASPTT (84-60)').",
- "title": "Meilleure Victoire"
- },
- "nuls_5_derniers": {
- "default": 0,
- "description": "Nombre de nuls sur les 5 derniers matchs.",
- "title": "Nuls 5 Derniers",
- "type": "integer"
- },
- "pire_defaite": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Plus lourde défaite récente (ex: '-12 vs US Chauriat (62-74)').",
- "title": "Pire Defaite"
- },
- "pts_encaisses_moyenne_5": {
- "default": 0,
- "description": "Moyenne de points encaissés par match sur les 5 derniers matchs.",
- "title": "Pts Encaisses Moyenne 5",
- "type": "number"
- },
- "pts_marques_moyenne_5": {
- "default": 0,
- "description": "Moyenne de points marqués par match sur les 5 derniers matchs.",
- "title": "Pts Marques Moyenne 5",
- "type": "number"
- },
- "ratio_victoires_5_derniers": {
- "default": 0,
- "description": "Pourcentage de victoires sur les 5 derniers matchs (0-100%).",
- "title": "Ratio Victoires 5 Derniers",
- "type": "number"
- },
- "serie_actuelle": {
- "$ref": "#/$defs/SerieEnCours",
- "description": "Série globale en cours toutes compétitions."
- },
- "serie_domicile": {
- "$ref": "#/$defs/SerieEnCours",
- "description": "Série en cours pour les matchs à domicile."
- },
- "serie_exterieur": {
- "$ref": "#/$defs/SerieEnCours",
- "description": "Série en cours pour les matchs à l'extérieur."
- },
- "tendance": {
- "default": "Stable ➡️",
- "description": "Tendance de la forme ('En hausse ↗️', 'Stable ➡️', 'En baisse ↘️').",
- "title": "Tendance",
- "type": "string"
- },
- "victoires_5_derniers": {
- "default": 0,
- "description": "Nombre de victoires sur les 5 derniers matchs.",
- "title": "Victoires 5 Derniers",
- "type": "integer"
- }
- },
- "title": "FormeRecente",
- "type": "object"
- },
- "MatchForme": {
- "description": "Détail d'un match pris en compte dans la forme récente.",
- "properties": {
- "adversaire": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Nom de l'adversaire.",
- "title": "Adversaire"
- },
- "date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Date et heure du match.",
- "title": "Date"
- },
- "domicile": {
- "default": true,
- "description": "True si domicile, False si déplacement.",
- "title": "Domicile",
- "type": "boolean"
- },
- "ecart": {
- "default": 0,
- "description": "Différence de points (+13 ou -8).",
- "title": "Ecart",
- "type": "integer"
- },
- "journee": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Nom ou numéro de journée.",
- "title": "Journee"
- },
- "resultat": {
- "description": "'V' (Victoire), 'D' (Défaite) ou 'N' (Nul).",
- "title": "Resultat",
- "type": "string"
- },
- "salle": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Nom de la salle.",
- "title": "Salle"
- },
- "score": {
- "description": "Score du match (ex: '78 - 65').",
- "title": "Score",
- "type": "string"
- },
- "score_contre": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Points encaissés.",
- "title": "Score Contre"
- },
- "score_pour": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Points marqués.",
- "title": "Score Pour"
- }
- },
- "required": [
- "resultat",
- "score"
- ],
- "title": "MatchForme",
- "type": "object"
- },
- "PhaseBilan": {
- "description": "Bilan détaillé pour une phase de compétition spécifique.",
- "properties": {
- "competition": {
- "description": "Nom de la compétition.",
- "title": "Competition",
- "type": "string"
- },
- "difference": {
- "default": 0,
- "description": "Différence de paniers.",
- "title": "Difference",
- "type": "integer"
- },
- "gagnes": {
- "default": 0,
- "description": "Matchs gagnés.",
- "title": "Gagnes",
- "type": "integer"
- },
- "match_joues": {
- "default": 0,
- "description": "Matchs joués dans cette phase.",
- "title": "Match Joues",
- "type": "integer"
- },
- "nuls": {
- "default": 0,
- "description": "Matchs nuls.",
- "title": "Nuls",
- "type": "integer"
- },
- "numero_equipe": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Numéro de l'équipe (ex: '1', '2').",
- "title": "Numero Equipe"
- },
- "paniers_encaisses": {
- "default": 0,
- "description": "Paniers encaissés.",
- "title": "Paniers Encaisses",
- "type": "integer"
- },
- "paniers_marques": {
- "default": 0,
- "description": "Paniers marqués.",
- "title": "Paniers Marques",
- "type": "integer"
- },
- "perdus": {
- "default": 0,
- "description": "Matchs perdus.",
- "title": "Perdus",
- "type": "integer"
- },
- "phase_terminee": {
- "default": false,
- "description": "Indique si la phase est terminée.",
- "title": "Phase Terminee",
- "type": "boolean"
- },
- "phase_type": {
- "default": "poule",
- "description": "Type de phase (poule ou élimination).",
- "title": "Phase Type",
- "type": "string"
- },
- "position": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Position actuelle au classement.",
- "title": "Position"
- },
- "poule_id": {
- "description": "ID de la poule.",
- "title": "Poule Id",
- "type": "string"
- },
- "total_equipes": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Nombre total d'équipes dans la poule.",
- "title": "Total Equipes"
- }
- },
- "required": [
- "competition",
- "poule_id"
- ],
- "title": "PhaseBilan",
- "type": "object"
- },
- "SerieEnCours": {
- "description": "Série actuelle de victoires, défaites ou invincibilité.",
- "properties": {
- "count": {
- "default": 0,
- "description": "Nombre de matchs consécutifs dans la série.",
- "title": "Count",
- "type": "integer"
- },
- "label": {
- "default": "",
- "description": "Description lisible (ex: '3 victoires consécutives').",
- "title": "Label",
- "type": "string"
- },
- "type": {
- "default": "aucune",
- "description": "'victoires', 'defaites', 'nuls' ou 'aucune'.",
- "title": "Type",
- "type": "string"
- }
- },
- "title": "SerieEnCours",
- "type": "object"
- }
- },
- "properties": {
- "result": {
- "anyOf": [
- {
- "additionalProperties": true,
- "type": "object"
- },
- {
- "$ref": "#/$defs/BilanResponse"
- }
- ],
- "title": "Result"
- }
- },
- "required": [
- "result"
- ],
- "title": "ffbb_bilanOutput",
- "type": "object"
-}New value: +nullffbb_bilan_saison2 fields changedInput schema / anyOfAdded value: +[
+ {
+ "required": [
+ "club_name"
+ ]
+ },
+ {
+ "required": [
+ "organisme_id"
+ ]
+ }
+]Output schema / (root)Previous value: -{
- "additionalProperties": true,
- "title": "ffbb_bilan_saisonDictOutput",
- "type": "object"
-}New value: +nullffbb_club14 fields changedInput schema / anyOfAdded value: +[
+ {
+ "required": [
+ "club_name"
+ ]
+ },
+ {
+ "required": [
+ "organisme_id"
+ ]
+ },
+ {
+ "required": [
+ "poule_id"
+ ]
+ }
+]Input schema / properties / action / descriptionPrevious value: -"Action club. Utiliser 'calendrier' pour les demandes au pluriel (matchs restants, calendrier, prochaines journées)."New value: +"Action : 'calendrier' (matchs pluriels/restants), 'equipes' ou 'classement'."Input schema / properties / adversaire / descriptionPrevious value: -"Nom de l'équipe adversaire pour filtrer uniquement les confrontations directes (ex: 'Royat Orcines', 'Stade Clermontois'). Utilisé avec action='calendrier'. Insensible à la casse et aux accents."New value: +"Nom adversaire pour filtrer les confrontations directes (action='calendrier')."Input schema / properties / club_name / descriptionPrevious value: -"Nom du club (recommande, ex: 'Stade Clermontois'). Si absent, `organisme_id` doit etre fourni."New value: +"Nom du club (ex: 'Stade Clermontois'). Requis si organisme_id absent."Input schema / properties / date_debut / descriptionPrevious value: -"Date de début de filtrage au format YYYY-MM-DD (ex: '2026-05-01')."New value: +"Date début YYYY-MM-DD (action='calendrier')."Input schema / properties / date_fin / descriptionPrevious value: -"Date de fin de filtrage au format YYYY-MM-DD (ex: '2026-05-31')."New value: +"Date fin YYYY-MM-DD (action='calendrier')."Input schema / properties / filtre / descriptionPrevious value: -"Filtre facultatif de categorie/genre (ex: 'U11', 'U11M', 'U11F'). Pour une équipe précise, compléter avec numero_equipe."New value: +"Filtre catégorie/genre (ex: 'U11M', 'Senior')."Input schema / properties / force_refresh / descriptionPrevious value: -"Si True, contourne le cache pour les donnees de calendrier ou de classement (utile les jours de match)."New value: +"Si True, contourne le cache."Input schema / properties / limit / descriptionPrevious value: -"Nombre maximum de matchs de calendrier à retourner (pagination/limite)."New value: +"Nombre max de matchs retournés (pagination)."Input schema / properties / numero_equipe / descriptionPrevious value: -"Numéro d'équipe facultatif (ex: 1, 2, 3). Utilisé avec action='calendrier' pour ne récupérer que les matchs de cette équipe précise."New value: +"Numéro d'équipe (ex: 1, 2) pour action='calendrier'."Input schema / properties / organisme_id / descriptionPrevious value: -"Identifiant FFBB du club (ex: 1234 ou 'ARA0063058'). Si absent, `club_name` est utilise pour effectuer une recherche."New value: +"ID FFBB du club (ex: 9326). Requis si club_name absent."Input schema / properties / phase / descriptionPrevious value: -"Nom ou numéro de la phase (ex: 'Phase 3', '2'). Utilisé avec action='classement' pour auto-résoudre la poule."New value: +"Nom ou numéro de phase (ex: 'Phase 2')."Input schema / properties / poule_id / descriptionPrevious value: -"Identifiant de la poule (obligatoire pour action='classement' si aucun filtre ne permet de determiner la poule)."New value: +"ID poule (action='classement')."Output schema / (root)Previous value: -{
- "$defs": {
- "CalendrierMatch": {
- "description": "Structure de données typée représentant un match de calendrier.",
- "properties": {
- "adresse": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Adresse complète de la salle.",
- "title": "Adresse"
- },
- "adresse_salle": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Adresse de la salle.",
- "title": "Adresse Salle"
- },
- "competition_nom": {
- "default": "",
- "description": "Nom de la compétition associée.",
- "title": "Competition Nom",
- "type": "string"
- },
- "competition_type": {
- "default": "poule",
- "description": "Type de phase (poule ou élimination).",
- "title": "Competition Type",
- "type": "string"
- },
- "date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Date et heure du match en ISO format.",
- "title": "Date"
- },
- "equipe1": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Nom de l'équipe 1 (domicile).",
- "title": "Equipe1"
- },
- "equipe2": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Nom de l'équipe 2 (extérieur).",
- "title": "Equipe2"
- },
- "id": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "string"
- }
- ],
- "description": "ID unique de la rencontre.",
- "title": "Id"
- },
- "is_last_match": {
- "default": false,
- "description": "Indique s'il s'agit du dernier match joué.",
- "title": "Is Last Match",
- "type": "boolean"
- },
- "is_next_match": {
- "default": false,
- "description": "Indique s'il s'agit du prochain match à venir.",
- "title": "Is Next Match",
- "type": "boolean"
- },
- "joue": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "boolean"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Indique si le match a été joué (1 ou True) ou non (0 ou False).",
- "title": "Joue"
- },
- "lieu_complet": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Adresse formatée complète : 'Nom Salle - Adresse, CP Ville'.",
- "title": "Lieu Complet"
- },
- "nom_salle": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Nom de la salle (libelle).",
- "title": "Nom Salle"
- },
- "num_journee": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "string"
- }
- ],
- "default": "",
- "description": "Numéro de la journée de championnat.",
- "title": "Num Journee"
- },
- "played": {
- "default": false,
- "description": "Indique si le match est déjà joué.",
- "title": "Played",
- "type": "boolean"
- },
- "salle": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "additionalProperties": true,
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Nom de la salle de sport ou dictionnaire d'informations.",
- "title": "Salle"
- },
- "salle_details": {
- "anyOf": [
- {
- "additionalProperties": true,
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Détails enrichis de la salle de sport.",
- "title": "Salle Details"
- },
- "score_equipe1": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Score de l'équipe 1.",
- "title": "Score Equipe1"
- },
- "score_equipe2": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Score de l'équipe 2.",
- "title": "Score Equipe2"
- },
- "ville": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Ville où se situe la salle.",
- "title": "Ville"
- }
- },
- "required": [
- "id"
- ],
- "title": "CalendrierMatch",
- "type": "object"
- }
- },
- "properties": {
- "result": {
- "anyOf": [
- {
- "items": {
- "additionalProperties": true,
- "type": "object"
- },
- "type": "array"
- },
- {
- "items": {
- "$ref": "#/$defs/CalendrierMatch"
- },
- "type": "array"
- }
- ],
- "title": "Result"
- }
- },
- "required": [
- "result"
- ],
- "title": "ffbb_clubOutput",
- "type": "object"
-}New value: +nullffbb_get1 field changedOutput schema / (root)Previous value: -{
- "additionalProperties": true,
- "title": "ffbb_getDictOutput",
- "type": "object"
-}New value: +nullffbb_head_to_head1 field changedOutput schema / (root)Previous value: -{
- "additionalProperties": true,
- "title": "ffbb_head_to_headDictOutput",
- "type": "object"
-}New value: +nullffbb_last_result2 fields changedInput schema / anyOfAdded value: +[
+ {
+ "required": [
+ "club_name"
+ ]
+ },
+ {
+ "required": [
+ "organisme_id"
+ ]
+ }
+]Output schema / (root)Previous value: -{
- "additionalProperties": true,
- "title": "ffbb_last_resultDictOutput",
- "type": "object"
-}New value: +nullffbb_lives1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "result": {
- "items": {
- "additionalProperties": true,
- "type": "object"
- },
- "title": "Result",
- "type": "array"
- }
- },
- "required": [
- "result"
- ],
- "title": "ffbb_get_livesOutput",
- "type": "object"
-}New value: +nullffbb_next_match2 fields changedInput schema / anyOfAdded value: +[
+ {
+ "required": [
+ "club_name"
+ ]
+ },
+ {
+ "required": [
+ "organisme_id"
+ ]
+ }
+]Output schema / (root)Previous value: -{
- "additionalProperties": true,
- "title": "ffbb_next_matchDictOutput",
- "type": "object"
-}New value: +nullffbb_resolve_team2 fields changedInput schema / anyOfAdded value: +[
+ {
+ "required": [
+ "club_name"
+ ]
+ },
+ {
+ "required": [
+ "organisme_id"
+ ]
+ }
+]Output schema / (root)Previous value: -{
- "additionalProperties": true,
- "title": "ffbb_resolve_teamDictOutput",
- "type": "object"
-}New value: +nullffbb_saisons1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "result": {
- "items": {
- "additionalProperties": true,
- "type": "object"
- },
- "title": "Result",
- "type": "array"
- }
- },
- "required": [
- "result"
- ],
- "title": "ffbb_get_saisonsOutput",
- "type": "object"
-}New value: +nullffbb_search1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "result": {
- "items": {
- "additionalProperties": true,
- "type": "object"
- },
- "title": "Result",
- "type": "array"
- }
- },
- "required": [
- "result"
- ],
- "title": "ffbb_searchOutput",
- "type": "object"
-}New value: +nullffbb_team_summary2 fields changedInput schema / anyOfAdded value: +[
+ {
+ "required": [
+ "club_name"
+ ]
+ },
+ {
+ "required": [
+ "organisme_id"
+ ]
+ }
+]Output schema / (root)Previous value: -{
- "additionalProperties": true,
- "title": "ffbb_team_summaryDictOutput",
- "type": "object"
-}New value: +nullffbb_version1 field changedOutput schema / (root)Previous value: -{
- "additionalProperties": true,
- "title": "ffbb_versionDictOutput",
- "type": "object"
-}New value: +nullv1.8.0ffbb_bilan6 fields changedInput schema / properties / numero_equipeAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Numéro d'équipe facultatif (ex: 1, 2).",
+ "title": "Numero Equipe"
+}Output schema / $defs / BilanResponse / properties / dynamiqueAdded value: +{
+ "anyOf": [
+ {
+ "$ref": "#/$defs/FormeRecente"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Dynamique et forme récente de l'équipe principale sur les 5 derniers matchs."
+}Output schema / $defs / BilanResponse / properties / profil_avanceAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Profil tactique avancé : rangs attaque/défense, style de jeu, clutch index et bilans domicile/extérieur.",
+ "title": "Profil Avance"
+}Output schema / $defs / FormeRecenteAdded value: +{
+ "description": "Indicateur complet de dynamique et de forme récente (5 derniers matchs).",
+ "properties": {
+ "defaites_5_derniers": {
+ "default": 0,
+ "description": "Nombre de défaites sur les 5 derniers matchs.",
+ "title": "Defaites 5 Derniers",
+ "type": "integer"
+ },
+ "diff_moyenne_5": {
+ "default": 0,
+ "description": "Différentiel moyen de points sur les 5 derniers matchs.",
+ "title": "Diff Moyenne 5",
+ "type": "number"
+ },
+ "forme": {
+ "description": "Résultats des 5 derniers matchs par ordre chronologique (ex: ['V', 'V', 'D', 'V', 'V']).",
+ "items": {
+ "type": "string"
+ },
+ "title": "Forme",
+ "type": "array"
+ },
+ "forme_str": {
+ "default": "",
+ "description": "Représentation texte compacte de la forme (ex: 'V-V-D-V-V').",
+ "title": "Forme Str",
+ "type": "string"
+ },
+ "matchs": {
+ "description": "Détail des matchs récents analysés.",
+ "items": {
+ "$ref": "#/$defs/MatchForme"
+ },
+ "title": "Matchs",
+ "type": "array"
+ },
+ "meilleure_victoire": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Plus large victoire récente (ex: '+24 vs ASPTT (84-60)').",
+ "title": "Meilleure Victoire"
+ },
+ "nuls_5_derniers": {
+ "default": 0,
+ "description": "Nombre de nuls sur les 5 derniers matchs.",
+ "title": "Nuls 5 Derniers",
+ "type": "integer"
+ },
+ "pire_defaite": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Plus lourde défaite récente (ex: '-12 vs US Chauriat (62-74)').",
+ "title": "Pire Defaite"
+ },
+ "pts_encaisses_moyenne_5": {
+ "default": 0,
+ "description": "Moyenne de points encaissés par match sur les 5 derniers matchs.",
+ "title": "Pts Encaisses Moyenne 5",
+ "type": "number"
+ },
+ "pts_marques_moyenne_5": {
+ "default": 0,
+ "description": "Moyenne de points marqués par match sur les 5 derniers matchs.",
+ "title": "Pts Marques Moyenne 5",
+ "type": "number"
+ },
+ "ratio_victoires_5_derniers": {
+ "default": 0,
+ "description": "Pourcentage de victoires sur les 5 derniers matchs (0-100%).",
+ "title": "Ratio Victoires 5 Derniers",
+ "type": "number"
+ },
+ "serie_actuelle": {
+ "$ref": "#/$defs/SerieEnCours",
+ "description": "Série globale en cours toutes compétitions."
+ },
+ "serie_domicile": {
+ "$ref": "#/$defs/SerieEnCours",
+ "description": "Série en cours pour les matchs à domicile."
+ },
+ "serie_exterieur": {
+ "$ref": "#/$defs/SerieEnCours",
+ "description": "Série en cours pour les matchs à l'extérieur."
+ },
+ "tendance": {
+ "default": "Stable ➡️",
+ "description": "Tendance de la forme ('En hausse ↗️', 'Stable ➡️', 'En baisse ↘️').",
+ "title": "Tendance",
+ "type": "string"
+ },
+ "victoires_5_derniers": {
+ "default": 0,
+ "description": "Nombre de victoires sur les 5 derniers matchs.",
+ "title": "Victoires 5 Derniers",
+ "type": "integer"
+ }
+ },
+ "title": "FormeRecente",
+ "type": "object"
+}Output schema / $defs / MatchFormeAdded value: +{
+ "description": "Détail d'un match pris en compte dans la forme récente.",
+ "properties": {
+ "adversaire": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Nom de l'adversaire.",
+ "title": "Adversaire"
+ },
+ "date": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Date et heure du match.",
+ "title": "Date"
+ },
+ "domicile": {
+ "default": true,
+ "description": "True si domicile, False si déplacement.",
+ "title": "Domicile",
+ "type": "boolean"
+ },
+ "ecart": {
+ "default": 0,
+ "description": "Différence de points (+13 ou -8).",
+ "title": "Ecart",
+ "type": "integer"
+ },
+ "journee": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Nom ou numéro de journée.",
+ "title": "Journee"
+ },
+ "resultat": {
+ "description": "'V' (Victoire), 'D' (Défaite) ou 'N' (Nul).",
+ "title": "Resultat",
+ "type": "string"
+ },
+ "salle": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Nom de la salle.",
+ "title": "Salle"
+ },
+ "score": {
+ "description": "Score du match (ex: '78 - 65').",
+ "title": "Score",
+ "type": "string"
+ },
+ "score_contre": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Points encaissés.",
+ "title": "Score Contre"
+ },
+ "score_pour": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Points marqués.",
+ "title": "Score Pour"
+ }
+ },
+ "required": [
+ "resultat",
+ "score"
+ ],
+ "title": "MatchForme",
+ "type": "object"
+}Output schema / $defs / SerieEnCoursAdded value: +{
+ "description": "Série actuelle de victoires, défaites ou invincibilité.",
+ "properties": {
+ "count": {
+ "default": 0,
+ "description": "Nombre de matchs consécutifs dans la série.",
+ "title": "Count",
+ "type": "integer"
+ },
+ "label": {
+ "default": "",
+ "description": "Description lisible (ex: '3 victoires consécutives').",
+ "title": "Label",
+ "type": "string"
+ },
+ "type": {
+ "default": "aucune",
+ "description": "'victoires', 'defaites', 'nuls' ou 'aucune'.",
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "title": "SerieEnCours",
+ "type": "object"
+}ffbb_bilan_saison13 fields changedInput schema / properties / categorie / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / categorie / defaultAdded value: +nullInput schema / properties / categorie / descriptionPrevious value: -"Catégorie + genre (ex: 'U11M', 'U13F', 'SeniorM'). Cette valeur sert à filtrer les engagements et les poules."New value: +"Catégorie + genre + numéro d'équipe facultatif (ex: 'U11M', 'U11M1', 'U13F2', 'SeniorM'). Cette valeur sert à filtrer les engagements et les poules."Input schema / properties / categorie / typeRemoved value: -"string"Input schema / properties / club_nameAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Nom du club (ex: 'Stade Clermontois', 'ASVEL').",
+ "title": "Club Name"
+}Input schema / properties / numero_equipe / anyOfAdded value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / numero_equipe / defaultAdded value: +1Input schema / properties / numero_equipe / descriptionPrevious value: -"Numéro d'équipe (1, 2, ...) pour identifier l'équipe précise dans la catégorie."New value: +"Numéro d'équipe (1, 2, ...) pour identifier l'équipe précise dans la catégorie (défaut: 1)."Input schema / properties / numero_equipe / typeRemoved value: -"integer"Input schema / properties / organisme_id / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "string"
- }
-]New value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / organisme_id / defaultAdded value: +nullInput schema / properties / organisme_id / descriptionPrevious value: -"ID FFBB du club (organisme) concerné."New value: +"ID FFBB du club (alternative plus rapide à club_name)."Input schema / requiredRemoved value: -[
- "organisme_id",
- "categorie",
- "numero_equipe"
-]ffbb_head_to_headffbb_resolve_team1 field changedInput schema / properties / numero_equipeAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Numéro d'équipe facultatif (ex: 1, 2).",
+ "title": "Numero Equipe"
+}ffbb_team_summary2 fields changedInput schema / properties / force_refreshAdded value: +{
+ "default": false,
+ "description": "Si True, force un rafraichissement des donnees",
+ "title": "Force Refresh",
+ "type": "boolean"
+}Input schema / properties / numero_equipeAdded value: +{
+ "default": 1,
+ "description": "Numéro d'équipe dans la catégorie (ex: 1, 2).",
+ "title": "Numero Equipe",
+ "type": "integer"
+}v1.5.1ffbb_bilan3 fields changedOutput schema / $defs / BilanResponse / properties / competitions_inclusesAdded value: +{
+ "description": "Liste des noms de compétitions incluses dans le bilan.",
+ "items": {
+ "type": "string"
+ },
+ "title": "Competitions Incluses",
+ "type": "array"
+}Output schema / $defs / BilanResponse / properties / saison_termineeAdded value: +{
+ "default": true,
+ "description": "Indique si la saison est terminée pour cette équipe (toutes les phases jouées).",
+ "title": "Saison Terminee",
+ "type": "boolean"
+}Output schema / $defs / PhaseBilan / properties / total_equipesAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Nombre total d'équipes dans la poule.",
+ "title": "Total Equipes"
+}ffbb_club6 fields changedInput schema / properties / adversaireAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Nom de l'équipe adversaire pour filtrer uniquement les confrontations directes (ex: 'Royat Orcines', 'Stade Clermontois'). Utilisé avec action='calendrier'. Insensible à la casse et aux accents.",
+ "title": "Adversaire"
+}Input schema / properties / organisme_id / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / organisme_id / descriptionPrevious value: -"Identifiant FFBB du club. Si absent, `club_name` est utilise pour effectuer une recherche."New value: +"Identifiant FFBB du club (ex: 1234 ou 'ARA0063058'). Si absent, `club_name` est utilise pour effectuer une recherche."Output schema / $defs / CalendrierMatch / properties / competition_typeAdded value: +{
+ "default": "poule",
+ "description": "Type de phase (poule ou élimination).",
+ "title": "Competition Type",
+ "type": "string"
+}Output schema / $defs / CalendrierMatch / properties / lieu_completAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Adresse formatée complète : 'Nom Salle - Adresse, CP Ville'.",
+ "title": "Lieu Complet"
+}Output schema / $defs / CalendrierMatch / properties / nom_salleAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Nom de la salle (libelle).",
+ "title": "Nom Salle"
+}ffbb_last_result2 fields changedInput schema / properties / organisme_id / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / organisme_id / descriptionPrevious value: -"Identifiant FFBB du club (organisme_id)"New value: +"Identifiant FFBB du club (organisme_id, ex: 1234 ou 'ARA0063058')"ffbb_next_match2 fields changedInput schema / properties / organisme_id / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / organisme_id / descriptionPrevious value: -"Identifiant FFBB du club (organisme_id)"New value: +"Identifiant FFBB du club (organisme_id, ex: 1234 ou 'ARA0063058')"v1.4.0ffbb_bilan5 fields changedOutput schema / $defsAdded value: +{
+ "BilanResponse": {
+ "description": "Réponse structurée et typée pour le bilan d'une équipe.",
+ "properties": {
+ "_meta": {
+ "additionalProperties": true,
+ "description": "Métadonnées de fraîcheur et de cache.",
+ "title": "Meta",
+ "type": "object"
+ },
+ "bilan_total": {
+ "$ref": "#/$defs/BilanTotal",
+ "description": "Totaux cumulés toutes phases."
+ },
+ "categorie": {
+ "description": "Catégorie d'âge/genre.",
+ "title": "Categorie",
+ "type": "string"
+ },
+ "club": {
+ "description": "Nom officiel du club.",
+ "title": "Club",
+ "type": "string"
+ },
+ "equipes_bilan": {
+ "additionalProperties": true,
+ "description": "Bilans ventilés par numéro d'équipe.",
+ "title": "Equipes Bilan",
+ "type": "object"
+ },
+ "phase_courante": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/PhaseBilan"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Détails de la dernière phase en cours."
+ },
+ "phases": {
+ "description": "Liste de toutes les phases jouées.",
+ "items": {
+ "$ref": "#/$defs/PhaseBilan"
+ },
+ "title": "Phases",
+ "type": "array"
+ }
+ },
+ "required": [
+ "club",
+ "categorie",
+ "bilan_total"
+ ],
+ "title": "BilanResponse",
+ "type": "object"
+ },
+ "BilanTotal": {
+ "description": "Statistiques cumulées d'une équipe (victoires, défaites, paniers).",
+ "properties": {
+ "difference": {
+ "default": 0,
+ "description": "Différence de paniers (marqués - encaissés).",
+ "title": "Difference",
+ "type": "integer"
+ },
+ "gagnes": {
+ "default": 0,
+ "description": "Nombre de matchs gagnés.",
+ "title": "Gagnes",
+ "type": "integer"
+ },
+ "match_joues": {
+ "default": 0,
+ "description": "Nombre de matchs joués.",
+ "title": "Match Joues",
+ "type": "integer"
+ },
+ "nuls": {
+ "default": 0,
+ "description": "Nombre de matchs nuls.",
+ "title": "Nuls",
+ "type": "integer"
+ },
+ "paniers_encaisses": {
+ "default": 0,
+ "description": "Total des paniers encaissés.",
+ "title": "Paniers Encaisses",
+ "type": "integer"
+ },
+ "paniers_marques": {
+ "default": 0,
+ "description": "Total des paniers marqués.",
+ "title": "Paniers Marques",
+ "type": "integer"
+ },
+ "perdus": {
+ "default": 0,
+ "description": "Nombre de matchs perdus.",
+ "title": "Perdus",
+ "type": "integer"
+ }
+ },
+ "title": "BilanTotal",
+ "type": "object"
+ },
+ "PhaseBilan": {
+ "description": "Bilan détaillé pour une phase de compétition spécifique.",
+ "properties": {
+ "competition": {
+ "description": "Nom de la compétition.",
+ "title": "Competition",
+ "type": "string"
+ },
+ "difference": {
+ "default": 0,
+ "description": "Différence de paniers.",
+ "title": "Difference",
+ "type": "integer"
+ },
+ "gagnes": {
+ "default": 0,
+ "description": "Matchs gagnés.",
+ "title": "Gagnes",
+ "type": "integer"
+ },
+ "match_joues": {
+ "default": 0,
+ "description": "Matchs joués dans cette phase.",
+ "title": "Match Joues",
+ "type": "integer"
+ },
+ "nuls": {
+ "default": 0,
+ "description": "Matchs nuls.",
+ "title": "Nuls",
+ "type": "integer"
+ },
+ "numero_equipe": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Numéro de l'équipe (ex: '1', '2').",
+ "title": "Numero Equipe"
+ },
+ "paniers_encaisses": {
+ "default": 0,
+ "description": "Paniers encaissés.",
+ "title": "Paniers Encaisses",
+ "type": "integer"
+ },
+ "paniers_marques": {
+ "default": 0,
+ "description": "Paniers marqués.",
+ "title": "Paniers Marques",
+ "type": "integer"
+ },
+ "perdus": {
+ "default": 0,
+ "description": "Matchs perdus.",
+ "title": "Perdus",
+ "type": "integer"
+ },
+ "phase_terminee": {
+ "default": false,
+ "description": "Indique si la phase est terminée.",
+ "title": "Phase Terminee",
+ "type": "boolean"
+ },
+ "phase_type": {
+ "default": "poule",
+ "description": "Type de phase (poule ou élimination).",
+ "title": "Phase Type",
+ "type": "string"
+ },
+ "position": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Position actuelle au classement.",
+ "title": "Position"
+ },
+ "poule_id": {
+ "description": "ID de la poule.",
+ "title": "Poule Id",
+ "type": "string"
+ }
+ },
+ "required": [
+ "competition",
+ "poule_id"
+ ],
+ "title": "PhaseBilan",
+ "type": "object"
+ }
+}Output schema / additionalPropertiesRemoved value: -trueOutput schema / propertiesAdded value: +{
+ "result": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "$ref": "#/$defs/BilanResponse"
+ }
+ ],
+ "title": "Result"
+ }
+}Output schema / requiredAdded value: +[
+ "result"
+]Output schema / titlePrevious value: -"ffbb_bilanDictOutput"New value: +"ffbb_bilanOutput"ffbb_club7 fields changedInput schema / properties / date_debutAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Date de début de filtrage au format YYYY-MM-DD (ex: '2026-05-01').",
+ "title": "Date Debut"
+}Input schema / properties / date_finAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Date de fin de filtrage au format YYYY-MM-DD (ex: '2026-05-31').",
+ "title": "Date Fin"
+}Input schema / properties / limitAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Nombre maximum de matchs de calendrier à retourner (pagination/limite).",
+ "title": "Limit"
+}Output schema / $defsAdded value: +{
+ "CalendrierMatch": {
+ "description": "Structure de données typée représentant un match de calendrier.",
+ "properties": {
+ "adresse": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Adresse complète de la salle.",
+ "title": "Adresse"
+ },
+ "adresse_salle": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Adresse de la salle.",
+ "title": "Adresse Salle"
+ },
+ "competition_nom": {
+ "default": "",
+ "description": "Nom de la compétition associée.",
+ "title": "Competition Nom",
+ "type": "string"
+ },
+ "date": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Date et heure du match en ISO format.",
+ "title": "Date"
+ },
+ "equipe1": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Nom de l'équipe 1 (domicile).",
+ "title": "Equipe1"
+ },
+ "equipe2": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Nom de l'équipe 2 (extérieur).",
+ "title": "Equipe2"
+ },
+ "id": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ }
+ ],
+ "description": "ID unique de la rencontre.",
+ "title": "Id"
+ },
+ "is_last_match": {
+ "default": false,
+ "description": "Indique s'il s'agit du dernier match joué.",
+ "title": "Is Last Match",
+ "type": "boolean"
+ },
+ "is_next_match": {
+ "default": false,
+ "description": "Indique s'il s'agit du prochain match à venir.",
+ "title": "Is Next Match",
+ "type": "boolean"
+ },
+ "joue": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Indique si le match a été joué (1 ou True) ou non (0 ou False).",
+ "title": "Joue"
+ },
+ "num_journee": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ }
+ ],
+ "default": "",
+ "description": "Numéro de la journée de championnat.",
+ "title": "Num Journee"
+ },
+ "played": {
+ "default": false,
+ "description": "Indique si le match est déjà joué.",
+ "title": "Played",
+ "type": "boolean"
+ },
+ "salle": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Nom de la salle de sport ou dictionnaire d'informations.",
+ "title": "Salle"
+ },
+ "salle_details": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Détails enrichis de la salle de sport.",
+ "title": "Salle Details"
+ },
+ "score_equipe1": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Score de l'équipe 1.",
+ "title": "Score Equipe1"
+ },
+ "score_equipe2": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Score de l'équipe 2.",
+ "title": "Score Equipe2"
+ },
+ "ville": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Ville où se situe la salle.",
+ "title": "Ville"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "title": "CalendrierMatch",
+ "type": "object"
+ }
+}Output schema / properties / result / anyOfAdded value: +[
+ {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "items": {
+ "$ref": "#/$defs/CalendrierMatch"
+ },
+ "type": "array"
+ }
+]Output schema / properties / result / itemsRemoved value: -{
- "additionalProperties": true,
- "type": "object"
-}Output schema / properties / result / typeRemoved value: -"array"v1.3.2ffbb_bilanffbb_bilan_saisonffbb_clubffbb_getffbb_last_resultffbb_livesffbb_next_matchffbb_resolve_teamffbb_saisonsffbb_searchffbb_team_summaryffbb_versionv1.3.1ffbb_bilanffbb_bilan_saisonffbb_clubffbb_getffbb_last_resultffbb_livesffbb_next_matchffbb_resolve_teamffbb_saisonsffbb_searchffbb_team_summaryffbb_versionv1.2.0ffbb_bilanffbb_bilan_saisonffbb_clubffbb_getffbb_get_competitionffbb_get_livesffbb_get_organismeffbb_get_pouleffbb_get_saisonsffbb_last_resultffbb_livesffbb_multi_searchffbb_next_matchffbb_resolve_teamffbb_saisonsffbb_searchffbb_search_competitionsffbb_search_organismesffbb_search_rencontresffbb_search_sallesffbb_team_summaryffbb_versionv0.1.0ffbb_get_competitionffbb_get_livesffbb_get_organismeffbb_get_pouleffbb_get_saisonsffbb_multi_searchffbb_search_competitionsffbb_search_organismesffbb_search_rencontresffbb_search_sallesScored across 17 tools
Several team-facing tools overlap heavily: ffbb_bilan and ffbb_bilan_saison both claim to return all-phase team records, and ffbb_team_summary also bundles bilan, last result, and next match. ffbb_get(type='poule') further overlaps with ffbb_club(action='classement'/'calendrier'), making tool selection error-prone.
All tools share the ffbb_ prefix, but the naming convention is mixed: some are noun-only (ffbb_saisons, ffbb_bilan, ffbb_lives), some are verb_noun (ffbb_list_regulations, ffbb_resolve_team), and some are generic actions (ffbb_get, ffbb_search). French and English are also intermingled, though readability remains acceptable.
17 tools is borderline heavy and would be easier to navigate if duplicate bilan/summary endpoints were consolidated. The count is not extreme, but some tools overlap enough that they don't clearly earn a separate place in the set.
The server covers the main FFBB read-only domain well: live scores, seasons, search, team records, next/last matches, H2H, and regulation documents. Minor gaps exist, such as no standalone competition-schedule tool or player-level stats, but agents can usually work around them with ffbb_get or ffbb_club.
Live sports stats and pre-computed analysis for AI assistants across NBA, MLB, NFL, and NHL.
Live and historical NBA/NFL/NHL data — fantasy bots, content sites, betting research.
French & European company registry for AI agents: KYB, sanctions, annual accounts. x402, no API key.
