Server Quality Checklist

Tool Scores

• ffbb_saisonsA
  3.6/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose4/5

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

  The description states a specific verb ('Liste') and resource ('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.

  Usage Guidelines3/5

  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.

• ffbb_versionA
  3.7/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• ffbb_last_resultA
  3.8/5.0
  Behavior3/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose4/5

  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.

  Usage Guidelines4/5

  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.

• ffbb_livesA
  3.9/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• ffbb_bilanA
  4/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• ffbb_bilan_saisonA
  4.1/5.0
  Behavior4/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

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

  With no output schema, the description 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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• ffbb_clubA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• ffbb_head_to_headA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• ffbb_searchA
  4.2/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• ffbb_next_matchA
  4.4/5.0
  Behavior4/5

  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.

  Conciseness3/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• ffbb_resolve_teamA
  4.4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• ffbb_team_summaryA
  4.6/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• ffbb_getA
  4.8/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.