The FFBB MCP Server lets AI assistants query official French basketball (FFBB) data via MCP tools:
Search (ffbb_search): Find clubs, competitions, matches, venues, tournaments, and more using free text or filters.
Club dashboard (ffbb_club): Aggregated club data — full calendar, team listings, and standings, with filtering by category, date range, opponent, and team number.
Full team record (ffbb_bilan): Complete win/loss/draw record for a team across all competition phases, including points scored/conceded.
Detailed season record (ffbb_bilan_saison): Per-phase season breakdown for a specific team (position, points, scores).
Team summary (ffbb_team_summary): All-in-one overview combining overall record, current standings, last result, and next match.
Last result (ffbb_last_result): Most recent match result for a specific team.
Next match (ffbb_next_match): Upcoming match for a specific team.
Live scores (ffbb_lives): Real-time scores for ongoing matches (refreshed every 30 seconds).
Resource lookup (ffbb_get): Fetch any FFBB resource (competition, pool, club, match, official, coach) by its numeric ID.
Team resolution (ffbb_resolve_team): Resolve ambiguous team names/categories to exact team identifiers.
Seasons list (ffbb_saisons): List all available FFBB seasons, optionally returning only the active one.
Server info (ffbb_version): Server version, runtime configuration, and health diagnostics.
Enables GitHub Copilot to retrieve French basketball data from FFBB through the MCP server.
Click on "Install 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 et scores live de la FFBB.
🌐 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, cache 30s). Retourne [] si aucun match. |
| Liste des saisons FFBB. active_only=True pour la saison en cours uniquement. |
| 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). |
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 |
|---|---|---|---|
| categorie | No | Catégorie/genre/numéro (ex: 'U11M1', 'Senior'). | |
| club_name | No | Nom du club (ex: 'Stade Clermontois', 'ASVEL'). | |
| organisme_id | No | ID FFBB du club (ex: 9326). | |
| force_refresh | No | Si True, contourne le cache. | |
| numero_equipe | No | Numéro d'équipe (ex: 1, 2). |
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 context about scope (all phases, one call, result contents) but does not disclose behaviors such as freshness, caching, or limits beyond what the annotation hints imply.
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: the first sentence states exactly what the tool does, and the second gives concrete query examples. Every sentence earns its place with no wasted words.
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 moderate-complexity tool with 5 params, full schema coverage, and no output schema, the description provides enough high-level output expectation (V/D/N, paniers, phases) and example usage. It could be more complete with explicit mention of the required club_name/organisme_id identification, but the schema covers that.
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 parameters are already documented with examples in the input schema. The description does not add extra semantic value for parameters, which matches the baseline of 3 when the schema carries the burden.
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 action and resource: producing a complete bilan (record) for a team across all phases in a single call, and enumerates included data (V/D/N, paniers, phases). This clearly distinguishes it from siblings like ffbb_bilan_saison and ffbb_team_summary.
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 positions the tool as the priority choice for queries like 'quel est le bilan de X ?' and 'résultats de U11M1', giving clear usage context. It does not explicitly name alternatives or exclusion conditions, so it stops short of full when-not guidance.
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 |
|---|---|---|---|
| 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'). | |
| organisme_id | No | ID FFBB du club (alternative plus rapide à club_name). | |
| 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds useful behavioral context by explaining that it 'agrège toutes les phases' and returns both per-phase details and a 'bilan_total' field. This goes beyond the annotations by showing the aggregation logic and exact return shape.
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, followed by an example trigger and a clear bulleted list of returned fields. Each part adds value, especially given there is no output schema. It is slightly longer than strictly necessary but not repetitive or padded.
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 appropriately details the per-phase return fields and the cumulative bilan_total. It also specifies the team identification parameters. Minor gaps remain, such as cache behavior, handling of ambiguous club names, or disambiguation between categorie and numero_equipe, but these are largely covered by the 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?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the team-identification tuple (organisme_id/club_name, categorie, numero_equipe), but does not add significant semantic detail beyond the schema. It does not explain force_refresh beyond what the schema already states.
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 and resource: 'Bilan détaillé de la saison pour une équipe précise (toutes phases)'. It clearly explains that the tool aggregates all phases and all pools for team identified by organisme_id/club_name, categorie, and numero_equipe. It distinguishes itself from siblings by emphasizing 'toutes phases' and the per-phase plus total output.
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 a clear use case: 'Cet outil est optimisé pour les questions du type "Quel est le bilan de la saison des U11M1 ?"'. This provides strong contextual guidance on when to invoke the tool. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a 5.
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. Utiliser adversaire avec action='calendrier' pour isoler les confrontations directes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Nombre max de matchs retournés (pagination). | |
| phase | No | Nom ou numéro de phase (ex: 'Phase 2'). | |
| action | Yes | Action : 'calendrier' (matchs pluriels/restants), 'equipes' ou 'classement'. | |
| filtre | No | Filtre catégorie/genre (ex: 'U11M', 'Senior'). | |
| date_fin | No | Date fin YYYY-MM-DD (action='calendrier'). | |
| poule_id | No | ID poule (action='classement'). | |
| club_name | No | Nom du club (ex: 'Stade Clermontois'). Requis si organisme_id absent. | |
| 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. | |
| force_refresh | No | Si True, contourne le cache. | |
| numero_equipe | No | Numéro d'équipe (ex: 1, 2) pour action='calendrier'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral context beyond the annotations by clarifying that this tool returns plural/aggregated data (matchs pluriels, calendrier complet) and supports head-to-head filtering with the adversaire parameter.
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: the first line states the resource and actions, the second gives the primary use case, and the third gives a specific parameter guidance. Every sentence earns its place with no redundant 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 multi-action tool with 12 parameters, the description gives enough context to select it and understand its three main modes. The schema covers parameter-level details, and the annotations cover safety. A short note on expected return shape would improve it, but the current level is sufficient 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 description coverage is 100%, so the schema already documents every parameter. The description reinforces the usage of adversaire with action='calendrier' for direct confrontations, but this is also stated in the adversaire parameter description, so the added value is marginal.
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 specific resource (club) and the three concrete operations: calendrier, équipes, classement. It also defines a clear scope — 'toute demande au pluriel' (remaining matches, full calendar) — which distinguishes it from singular sibling tools like ffbb_next_match and 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?
The description explicitly states when to use the tool: 'Outil de référence pour toute demande au pluriel : matchs restants, calendrier complet.' It also gives a specific usage pattern (adversaire avec action='calendrier') for direct confrontations. However, it does not explicitly name sibling alternatives or state when not to use this tool.
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.
type="poule" charge la poule (classements + rencontres).
type="organisme" charge les details d'un club.
type="rencontre" charge une rencontre précise.
⚠️ 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 numérique FFBB exact. Ne pas passer un nom de club: utiliser d'abord ffbb_search pour résoudre l'id. | |
| 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=true, idempotentHint=true, and openWorldHint=true, and the description adds meaningful behavioral nuance: 'type='poule' peut être tronqué si la poule est grande' and force_refresh 'contourne le cache... en temps réel (scores live)'. This explains side effects, caching, and truncaton beyond the annotation flags, with no contradiction.
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 well structured: a leading one-line purpose, bulleted resource type meanings, and two focused warnings. Every sentence contributes either a direct behavior or a routing decision, with no fluff or redundancy.
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 multi-type getter with no output schema, the description covers the important behavioral and routing details: resource types, truncaton risk, cache behavior, and exclusions for score/next-match use. It does not describe the 'officiel' and 'entraineur' enum variants, but the essential guidance for correct selection and invocation is present.
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?
Input schema description coverage is 100%, so the baseline is 3; the description adds semantic meaning for the type enum by stating what each major type loads, e.g. competition, pocle, organisme, rencontre. It also reinforces the id resolution behavior indirectly by warning about using ffbb_search in the schema, and contextualises force_refresh for live scores.
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 concrete verb and object – 'Recupere une ressource FFBB par identifiant' – and then enumerates what each resource type returns, e.g. 'type='poule' charge la poule (classments + rencontres)' and 'type='organisme' charge les details d'un club'. This makes the tool's purpose and scope clear and distinguishes it from focused siblings like ffbb_last_result and ffbb_next_match.
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?
Gives explicit when-to-use guidance for the main resource types and provides direct alternatives: for an exhaustive schedule, 'préférez ffbb_club(action='calendrier')' and for a score or next match, use 'ffbb_last_result' and 'ffbb_next_match' instead. This is factual routing guidance, not a generic hint.
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 (ex: 'Vichy', 'Roanne'). | |
| categorie | No | Catégorie d'équipe commune à comparer (ex: 'SEM1', 'U18M', 'Senior'). | |
| force_refresh | No | Si True, force le rafraîchissement des données | |
| organisme_id_a | No | ID FFBB du premier club (ex: 9326). | |
| organisme_id_b | No | ID FFBB du second club. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior. The description adds useful behavioral context by enumerating the analysis dimensions returned (historical H2H, form, attack/defense duel, narrative points). It does not disclose edge cases like missing H2H data, but the annotation coverage lowers the burden.
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 front-loads the main purpose in one sentence and then organizes the additional value into four compact, semantically distinct bullets. Every bullet earns its place and there is no filler or repetition.
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 6-parameter tool with no output schema, the bullet list covers the major return contents well, and the annotations cover side effects. However, it does not state which parameters are needed to start (e.g., club_a/club_b vs organisme_id_a/b or categorie), though the input schema compensates. This gap keeps it just below a 5.
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?
Input schema coverage is 100% and every parameter (club_a, club_b, categorie, force_refresh, organisme_id_a/b) has its own description, so the baseline is 3. The tool description adds no parameter-specific guidance beyond the notion of comparing two teams; it does not explain the name-vs-ID alternatives or the need for a common categorie, but the schema already covers these.
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 action ('Compare deux équipes') and a specific resource ('confrontations directes (H2H)'). The bullets clearly define the output as a head-to-head analysis covering historical record, recent form, statistical duel, and narrative points, which differentiates it from single-team siblings like ffbb_team_summary or ffbb_bilan.
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 clear use context: the output is 'prêtes pour la rédaction d'articles ou de synthèses d'avant-match', so an agent can infer it is for pre-match comparison articles. It does not, however, explicitly state when not to use it or name alternative tools, so it stops short of 5.
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 |
|---|---|---|---|
| categorie | Yes | Catégorie de l'équipe précise (ex: 'U11M1', 'U11M', 'U11F') | |
| club_name | No | Nom du club (ex: 'Stade Clermontois') | |
| organisme_id | No | Identifiant FFBB du club (organisme_id, ex: 1234 ou 'ARA0063058') | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, non-destructive behavior, so the bar for extra disclosure is lower. The description adds the singular-team constraint and the category-resolution recommendation, which are useful, but it does not describe output shape, error behavior, or what happens with unresolved categories. No contradiction with annotations 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 short, front-loaded with the core purpose, and uses a clear recommendation block. There is minor redundancy between the first sentence and the title, but the singular-only warning and LLM recommendation both earn their 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 read-only tool with rich annotations and fully documented parameters, the description covers the essential selection and invocation logic: singular scope, category ambiguity, and the resolve-team prerequisite. It does not detail the return payload, but no output schema exists and the core return concept is stated.
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 five parameters have schema descriptions, so the baseline is 3. The description goes further by explaining how `categorie` and `numero_equipe` relate, and recommends calling `ffbb_resolve_team` when the category lacks a number. This adds practical parameter-level guidance beyond 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 identifies the tool's purpose: it returns the last played match for a single team. The explicit 'SINGULIER UNIQUEMENT' warning and reference to a precise team make the scope unambiguous, though it does not explicitly contrast with sibling tools like ffbb_next_match.
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 clear context for when to use the tool (single team only) and provides a concrete prerequisite workflow: resolve an imprecise category via ffbb_resolve_team before calling. It stops short of explaining when to choose this over alternatives such as ffbb_next_match or team summaries.
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, cache 30s). Retourne [] si aucun match.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavior beyond the annotations by noting a 30-second cache and the empty-array return when no matches are ongoing. The annotations already establish read-only, idempotent, non-destructive behavior, so the description's extra details are meaningful and non-contradictory.
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 compact, with every phrase earning its place: it states what is returned, adds the cache detail, and handles the no-match edge case. It is front-loaded and easy to parse.
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 tool, the description covers the essential behavior: current matches, live scores, caching, and empty result. An output schema is absent, so the exact shape of each live score entry is not specified, but the simplicity of the tool makes 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?
There are zero parameters, so the description is not required to explain any input schema. Schema description coverage is effectively 100%, and the description adds relevant output semantics (live scores, empty result) that help the agent understand what the tool returns.
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 identifies the resource (ongoing/live matches) and the output (live scores, empty array if no match). It is clear and specific, though it does not explicitly distinguish itself from sibling tools such as ffbb_last_result or ffbb_next_match.
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 phrase 'Matchs en cours' implies the tool should be used when the agent needs current live scores, and the 30s cache hints at near-real-time data. However, there is no explicit guidance about when to choose this tool over alternatives or when not to use it.
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 |
|---|---|---|---|
| categorie | Yes | Catégorie de l'équipe précise (ex: 'U11M1', 'U11M', 'U11F') | |
| club_name | No | Nom du club (ex: 'Stade Clermontois') | |
| organisme_id | No | Identifiant FFBB du club (organisme_id, ex: 1234 ou 'ARA0063058') | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, openWorld, and non-destructive behavior, so the bar is lower. The description adds important behavioral context: it returns exactly one match, is not suitable for plural queries, and may require team resolution when the category is ambiguous. It does not describe the response format, but the core behavioral constraints are well communicated.
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 and structured with clear warning sections, but the singular-only message is repeated in multiple paragraphs with heavy capitalization and emoji. The plural-request guidance appears twice, so not every sentence earns its place despite the criticality of the warning.
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 five parameters and no output schema, the description covers the critical context: strict singular behavior, which sibling to use for plurals, and how to resolve ambiguous categories. Parameter details are covered by the schema, and the safety profile is covered by annotations. The only notable gap is the lack of return-format description, which is mitigated by the simple 'next match' concept.
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 that an imprecise category like 'U11M' should be resolved via ffbb_resolve_team to obtain the real numero_equipe. This goes beyond the schema by linking parameter disambiguation to a concrete workflow.
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 tool's purpose: returning the next match to be played for a specific team. It explicitly says the tool returns strictly one unique match and distinguishes itself from the sibling ffbb_club, which handles plural/calendar requests. There is no ambiguity about what the tool does.
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: singular requests only, and plural requests must use ffbb_club(action='calendrier') instead. It also recommends using ffbb_resolve_team when the category is imprecise, which is concrete and actionable routing advice.
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').
| Name | Required | Description | Default |
|---|---|---|---|
| categorie | No | 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. | |
| club_name | No | Nom du club (ex: 'Stade Clermontois', 'ASVEL'). | |
| organisme_id | No | ID FFBB du club (alternative plus rapide à club_name). | |
| numero_equipe | No | Numéro d'équipe facultatif (ex: 1, 2). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond that: it resolves to a unique team, acts as a central pivot, and should be invoked before match/result tools when there is ambiguity. It does not detail return shape or error behavior, but given the annotations, this is acceptable.
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, front-loaded with the core purpose, and each sentence earns its place. The prerequisite usage guidance is delivered in a clear, direct way without redundant 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?
Given the rich schema descriptions and strong annotations, the description adequately explains the tool's purpose and when to invoke it. A small gap is that it does not explicitly state what the return value should be used for, though 'identifie une equipe unique' and the prerequisite wording strongly imply it.
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 input schema already documents all parameters. The description adds no parameter-level detail beyond mentioning category ambiguity in the usage example. Therefore the baseline score of 3 is appropriate.
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 differentiates the tool from siblings by stating it is a prerequisite for `ffbb_next_match` and `ffbb_last_result`, so an agent can understand what this tool does and how it fits into a workflow.
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: before `ffbb_next_match` or `ffbb_last_result` when the exact team number is unknown or the category is ambiguous. This gives concrete usage conditions and names the alternative workflow it supports, leaving little to inference.
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. active_only=True pour la saison en cours uniquement.
| Name | Required | Description | Default |
|---|---|---|---|
| active_only | No | True = saison active uniquement. |
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, covering the safety profile. The description adds the active_only filtering behavior, which is beyond annotations, but it does not disclose return format, pagination, or data source; the lowered bar for annotated tools makes this acceptable.
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?
Two short sentences, front-loaded with the core purpose, with the second sentence covering the only parameter. No filler or redundant explanation.
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, optional-parameter, read-only list tool with rich annotations, the description is functionally complete. It could go further by describing the shape of the returned season list, since there is no output schema, but the name and verb make the expected return reasonably clear.
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%: the sole boolean parameter already has a description ('True = saison active uniquement'). The description mostly restates this in prose, adding little semantic value beyond the schema. Baseline 3 is appropriate.
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 ('Liste') and resource ('saisons FFBB'), making the purpose immediately clear. It does not explicitly differentiate from related season-specific siblings like ffbb_bilan_saison, but no sibling appears to offer the same season-list functionality.
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 purpose implies when to use it: when a list of FFBB seasons is needed, optionally restricted to the current season. However, there is no explicit when-to-use vs alternatives guidance or exclusions, so the usage context is mainly implied.
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. 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. | |
| query | Yes | Texte libre (ex: 'Vichy', 'U13F Auvergne'). | |
| filter_by | No | Filtre Meilisearch natif (ex: 'codePostal = "63000"'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), lowering the bar. The description adds one behavioral trait beyond annotations — results contain an 'id' consumable by ffbb_get or ffbb_club — but discloses nothing further such as result grouping, pagination behavior, or any auth/rate constraints. This matches the calibration case where annotation-covered safety with mild added context scores a 3.
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?
Five short lines, each a functional unit: the scope line, three type-mode bullets, and one follow-up sentence. The purpose is front-loaded before any parameter detail, and there is no filler or restatement of schema content.
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 5-parameter Meilisearch-backed tool with no output schema, the description covers the agent's core needs: what is searched, the best entry mode, how to narrow by type, and how to consume the result id. The only material gap is the undisclosed multi-index return shape — since no output schema exists, the agent cannot know whether results arrive flat or grouped by type — which keeps this just below a 5.
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 value beyond the schema by giving concrete semantics to the type enum — 'organismes' → clubs uniquement, 'competitions' → compétitions uniquement — and ranking 'all' as the best entry point, which the schema's one-line property descriptions do not convey. The query examples are redundant with the schema, but the type guidance is genuinely additive.
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 — 'Recherche FFBB — clubs, compétitions, matchs, salles, tournois, etc.' — and immediately frames the scope as a multi-entity search. The closing note that results contain an 'id' to feed into ffbb_get or ffbb_club positions it as the entry-point search distinct from those retrieval siblings. An agent can tell this tool apart from the lookup-focused siblings 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?
It gives actionable guidance: 'type='all' → recherche globale (meilleur point d'entrée)' names the canonical entry mode, and the final sentence instructs the agent on the follow-up step. However, it never states when NOT to use this tool relative to search-adjacent siblings like ffbb_resolve_team or ffbb_team_summary, so the exclusions are left implicit.
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
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 |
|---|---|---|---|
| categorie | No | Catégorie + genre + numéro d'équipe (ex: 'U11M1', 'U13F2', 'U15M', 'Senior'). | |
| club_name | No | Nom du club (ex: 'Stade Clermontois', 'ASVEL'). | |
| organisme_id | No | ID FFBB du club (alternative plus rapide à club_name). | |
| force_refresh | No | Si True, force un rafraichissement des donnees | |
| numero_equipe | No | Numéro d'équipe dans la catégorie (ex: 1, 2). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it combines four data categories into one call and attempts team resolution via ffbb_resolve_team under ambiguous conditions. This is useful but does not fully describe response structure or edge-case behavior, hence not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured: a one-line overview, a bulleted list of what the combined call contains, and two short sentences for usage guidance and alternatives. It is front-loaded with the core purpose and every sentence serves a clear role, with no redundant explanation.
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 moderate complexity (5 parameters, no output schema), the description covers the key invocation decisions: what the summary includes, when to use it, the resolution fallback, and the alternative tool for remaining matches. A fully explicit response format is not specified, but the annotations and full schema coverage compensate enough that the agent can reliably select and invoke the 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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the resolution behavior tied to categorie/numero_equipe ('Si la catégorie est ambiguë ou sans numéro d'équipe, l'outil tente une résolution via ffbb_resolve_team'). This clarifies parameter semantics more than the schema descriptions 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 clearly states a specific verb and resource: it produces a complete team summary in a single call, and explicitly lists the four combined components (global bilan, current phase/ranking, last match, next match). It also differentiates itself from sibling tools by naming ffbb_club for a different need and ffbb_resolve_team for resolution behavior.
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 usage context: 'Recommandé pour une vue rapide d'une équipe précise'. It also provides an alternative tool for a different use case ('Pour une liste de matchs restants, utiliser plutôt ffbb_club(action="calendrier")') and explains the resolution fallback when the category is ambiguous or no team number is provided.
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 une structure compacte et strictement typée, pratique pour les agents et les outils de supervision.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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, covering the safety profile. The description adds useful behavioral context about the return value ('structure compacte et strictement typée'), which helps agents parse the response, but it does not disclose additional runtime behaviors such as caching, latency, or what specific version fields are included.
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?
Two tight sentences with no filler. The first sentence states what the tool returns, and the second explains the return structure's shape and intended audience. Everything 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 zero-parameter version/diagnostics tool, the description covers the essentials: what is returned (version and runtime configuration) and the nature of the return structure (compact, strictly typed). With no output schema present, this is adequate for an agent to know what to expect and how it differs from the data-focused sibling tools.
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 and schema description coverage is 100%, so there is nothing for the description to clarify about arguments. The baseline of 4 for parameterless tools applies here, and the description appropriately focuses on the output rather than inputs.
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 resource (the FFBB MCP server) and what it returns: 'Informations de version et configuration runtime du serveur FFBB MCP.' This aligns with the title 'Version et diagnostics serveur' and is easily distinguishable from the sibling tools (search, bilan, get), which serve different purposes.
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 a use context—'pratique pour les agents et les outils de supervision'—indicating this is a diagnostics/monitoring tool. However, it does not explicitly state when to use it versus alternatives, nor does it name any sibling or exclusion condition. Usage is implied rather than explicit.
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. Dates show when Glama detected each change.
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_sallesMost tools have clear distinct roles, and the descriptions contain helpful routing warnings (singular vs plural, resolve-before-lookup, prioritization notes). However, ffbb_bilan and ffbb_bilan_saison cover nearly the same all-phases season bilan, and ffbb_team_summary also overlaps with bilan/last/next, so some selection ambiguity remains.
All tools share the ffbb_ prefix and consistently use lowercase snake_case, which makes the set feel cohesive. The grammatical pattern is slightly mixed (verbs like search/get/resolve_team vs noun phrases like bilan, team_summary, head_to_head), but nothing is erratic or inconsistent in style.
13 tools is well within the ideal 3-15 range for a domain-specific read-only API. The count covers discovery, detail retrieval, club/team aggregations, live scores, seasons, and head-to-head analysis without feeling bloated.
The surface is quite complete for the FFBB basketball domain: search, resource retrieval, club schedules, team summaries, last/next matches, live scores, seasons, and head-to-head. Minor gaps remain, such as no non-truncated competition-wide calendar (ffbb_get type='poule' warns about truncation) and no roster/player tools, but agents can work around these.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nickdesi/FFBB-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
