Skip to main content
Glama
FFBB MCP Server

FFBB MCP Server

Résumé complet d'équipe

ffbb_team_summary
Read-onlyIdempotent

Synthèse recommandée d'une équipe (résultats, prochain match, classement, dynamique en 1 appel).

Instructions

Synthèse recommandée d'une équipe (résultats, prochain match, classement, dynamique en 1 appel).

Préférer cet outil pour toute question d'équipe ('Comment vont les U13M2 ?', 'NM3', etc.).
Pour une analyse multi-phases ou coupes, utiliser `ffbb_bilan_saison`.
Restituer strictement les chiffres officiels sans présumer de forfaits ou d'anomalies sur la seule base de scores faibles (fréquents en catégories jeunes).

Input Schema

NameRequiredDescriptionDefault
detailNoSi True, inclut les colonnes détaillées du classement (pénalités, forfaits, logos).
includeNoSections à inclure : 'bilan', 'last', 'next', 'classement', 'dynamique'. Défaut: ['bilan', 'last', 'next', 'classement'].
poule_idNoID FFBB de la poule pour désambiguïser.
categorieNoCatégorie/division + genre + numéro d'équipe (ex: 'U11M1', 'U13F2', 'SEM1', 'NM3', 'PNM').
club_nameNoNom du club (ex: 'Stade Clermontois', 'ASVEL').
season_idNoID de la saison FFBB (optionnel).
organisme_idNoID FFBB du club (alternative plus rapide à club_name).
engagement_idNoID FFBB de l'engagement (prioritaire pour désambiguïser).
force_refreshNoSi True, force un rafraichissement des donnees
numero_equipeNoNuméro d'équipe dans la catégorie (ex: 1, 2).
competition_idNoID FFBB de la compétition pour désambiguïser.
competition_typeNoType de compétition ('PLAT', 'COUPE', etc.) pour désambiguïser.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.16.11
    • addedInput schema / properties / detail
      Added value: +{
      +  "default": false,
      +  "description": "Si True, inclut les colonnes détaillées du classement (pénalités, forfaits, logos).",
      +  "title": "Detail",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / include
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Sections à inclure : 'bilan', 'last', 'next', 'classement', 'dynamique'. Défaut: ['bilan', 'last', 'next', 'classement'].",
      +  "title": "Include"
      +}
  2. Changed9 schema fields changedv1.13.0
    • changedInput schema / anyOf
      Previous value: -[
      -  {
      -    "required": [
      -      "club_name"
      -    ]
      -  },
      -  {
      -    "required": [
      -      "organisme_id"
      -    ]
      -  }
      -]New value: +[
      +  {
      +    "required": [
      +      "organisme_id"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "club_name"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "engagement_id"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "poule_id"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "competition_id"
      +    ]
      +  }
      +]
    • addedInput schema / properties / competition_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "ID FFBB de la compétition pour désambiguïser.",
      +  "title": "Competition Id"
      +}
    • addedInput schema / properties / competition_type
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Type de compétition ('PLAT', 'COUPE', etc.) pour désambiguïser.",
      +  "title": "Competition Type"
      +}
    • addedInput schema / properties / engagement_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "ID FFBB de l'engagement (prioritaire pour désambiguïser).",
      +  "title": "Engagement Id"
      +}
    • addedInput schema / properties / numero_equipe / anyOf
      Added value: +[
      +  {
      +    "type": "integer"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / numero_equipe / default
      Previous value: -1New value: +null
    • removedInput schema / properties / numero_equipe / type
      Removed value: -"integer"
    • addedInput schema / properties / poule_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "ID FFBB de la poule pour désambiguïser.",
      +  "title": "Poule Id"
      +}
    • addedInput schema / properties / season_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "ID de la saison FFBB (optionnel).",
      +  "title": "Season Id"
      +}
  3. Changed1 schema field changedv1.10.0
    • changedInput schema / properties / categorie / description
      Previous value: -"Catégorie + genre + numéro d'équipe (ex: 'U11M1', 'U13F2', 'U15M', 'Senior')."New value: +"Catégorie/division + genre + numéro d'équipe (ex: 'U11M1', 'U13F2', 'SEM1', 'NM3', 'PNM')."
  4. Changed2 schema fields changedv1.9.0
    • addedInput schema / anyOf
      Added value: +[
      +  {
      +    "required": [
      +      "club_name"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "organisme_id"
      +    ]
      +  }
      +]
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "ffbb_team_summaryDictOutput",
      -  "type": "object"
      -}New value: +null
  5. Changed2 schema fields changedv1.8.0
    • addedInput schema / properties / force_refresh
      Added value: +{
      +  "default": false,
      +  "description": "Si True, force un rafraichissement des donnees",
      +  "title": "Force Refresh",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / numero_equipe
      Added value: +{
      +  "default": 1,
      +  "description": "Numéro d'équipe dans la catégorie (ex: 1, 2).",
      +  "title": "Numero Equipe",
      +  "type": "integer"
      +}
  6. Addedv1.3.2
  7. Removedv1.3.1
  8. Addedv1.2.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds genuine behavioural guidance beyond them: the single-call aggregation promise and the caution to report only official figures rather than inferring forfeits/anomalies from low scores in youth categories. It does not mention caching or what force_refresh actually re-fetches, which is the one remaining gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short, front-loaded lines: what it returns, when to prefer it, which sibling to use instead, and one interpretive caveat. Nothing is restated and the scope statement comes first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter, identifier-flexible aggregation tool, the description covers scope, routing and interpretation but never sketches the shape of the assembled response (no output schema exists), leaving the agent to guess how bilan/last/next/classement are returned. Otherwise complete enough given 100% parameter documentation.

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

Parameters3/5

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

Schema description coverage is 100% and every one of the 12 parameters carries its own description (include sections, categorie format, id-vs-name alternatives, force_refresh), so the schema does the heavy lifting. The description echoes the section list parenthetically but adds no syntax or precedence semantics beyond that, which matches the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Synthèse d'une équipe') and enumerates the exact payload (résultats, prochain match, classement, dynamique en 1 appel), which lets an agent distinguish it from the narrower siblings ffbb_last_result, ffbb_next_match and ffbb_bilan without opening any schema. It also explicitly names ffbb_bilan_saison as the multi-phase variant.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Préférer cet outil pour toute question d'équipe' with two worked example queries gives an explicit when-to-use, and 'Pour une analyse multi-phases ou coupes, utiliser `ffbb_bilan_saison`' names the alternative and the condition that selects it. Routing is unambiguous.

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