Server Quality Checklist

Tool Scores

• list_picksA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It adds valuable context that picks are 'computed live from upcoming fixtures' and 'volumes vary by day', and it lists the data fields included. It doesn't discuss side effects (not needed for a list) or auth/rate limits, which keeps it at a solid mid-range.

  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 concise: three sentences with clear logical flow (purpose → return contents → usage cue). 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?

  The description covers the tool's function, the pick data contents, and the usage context. With 5 optional params and no output schema, it sufficiently describes what the agent needs to know. It omits pagination/sorting details, but these are not critical for a simple list tool.

  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 description doesn't need to explain parameters. It mentions the filter dimensions (league, market, min edge, quality tier) but doesn't add details 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.

  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 with a specific verb ('List') and resource ('Statos's current betting suggestions'). It distinguishes from siblings like get_match_picks by emphasizing 'current' suggestions and the filter dimensions.

  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 provides an explicit usage cue: 'Use this for "what does Statos suggest today?" type queries.' It doesn't explicitly name alternatives or mention when not to use it, but the context is clear.

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

• suppress_marketA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description discloses key behavioral aspects: it is an 'ADMIN kill switch' (high impact), requires a specific scope ('admin:market_suppressions'), clarifies that league_id 0 is a wildcard, and indicates reversibility. It also implies a time-windowed effect via 'for a time window' and 'expiry'. This provides substantial behavioral transparency beyond the bare minimum.

  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, front-loaded with the primary action, and uses a dash to present an illustrative example. The subsequent sentences cover auth, wildcard scope, reversibility, and a caution in a logical order. Every sentence earns its place with no redundancy or 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 tool with no annotations or output schema, the description provides a strong overall context: what it does, when to use it, what permissions are needed, how scope works, and that it is reversible. It does not detail the response format or side effects on existing picks, but for a suppression tool these are less critical and the description still gives sufficient operational guidance.

  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%, so the description doesn't need to restate parameter purposes. It does reinforce league_id semantics ('league_id 0 = all leagues') and gives an example of market_type, but these are already present in the schema. The description adds no novel parameter insights beyond the schema, warranting the baseline score.

  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: 'stop Statos emitting a (league × market) for a time window WITHOUT a deploy'. It uses a specific verb ('suppress'), names the resource ('market'), and delivers a clear scope (league × market). It is distinguished from siblings by explicitly referencing the reverse operation (unsuppress_market) and framing itself as an 'ADMIN kill switch'.

  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?

  Provides a concrete use case ('during the World Cup if 'cards' starts firing 30% below claimed hit rate') and states reversibility ('Reversible via unsuppress_market or expiry'). It also notes the admin prerequisite and advises 'Use sparingly.' While it doesn't explicitly compare to list_suppressions, it gives clear context for when to use this tool versus alternatives.

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

• unsuppress_marketA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It reveals the timing ('within ~60s'), the active-state requirement ('active market suppression'), and the authorization scope ('admin:market_suppressions'). This goes beyond the bare action and gives useful behavioral context, though it doesn't describe error cases or return values.

  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 two sentences, with the primary action in the first sentence and a supplementary scope note in the second. Every word earns its place; it is front-loaded with the verb and resource. No wasted text.

  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?

  Despite having no annotations and no output schema, the description covers the essential aspects: what it does, the timing effect, and the required scope. It does not explain behavior for non-existent or already-canceled suppressions, but for a simple one-parameter mutation tool, this is reasonably complete.

  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?

  The schema provides 100% coverage for the single parameter 'id', with its own description 'Suppression id to cancel.' The tool description adds no additional semantic value beyond restating 'by id'. Baseline of 3 is appropriate given the schema's strong coverage.

  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 specific action: 'Cancel an active market suppression by id'. The verb 'Cancel' is unambiguous, the resource is 'market suppression', and the method 'by id' is explicit. It distinguishes itself from the sibling tool 'suppress_market' which performs the opposite action.

  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: this tool is used to cancel an active suppression, with the effect described. It does not explicitly mention alternatives or exclusions, but the presence of the inverse sibling 'suppress_market' makes the intended usage obvious. The scope requirement also hints at conditions for use.

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

• get_match_picksA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses the scope ('every suggestion', 'single match'), the return shape ('same BetSuggestion shape as list_picks'), and the relationship to sibling list_picks. While it doesn't explicitly call out read-only or pagination, the behavior is sufficiently transparent for a simple fetch-by-ID tool.

  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 sentences, front-loaded with the main action, and zero filler. Every clause adds value: the action, the use case, and the output shape comparison.

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

  Completeness5/5

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

  For a one-parameter tool with no output schema, the description provides enough context: it explains the scope, the return shape, and the use case. The reference to list_picks covers the missing output schema details, and the tool is simple enough that no additional edge-case disclosure is needed.

  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%, with match_id already described in the schema. The tool description adds no further parameter details beyond referring to 'a single match,' so the minimum viable baseline of 3 applies.

  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?

  Purpose is explicitly stated: 'Fetch every suggestion the Statos engine has emitted for a single match.' The verb 'Fetch' identifies the action, the resource is clearly the predictions for one match, and the phrase 'scoped to one match' directly distinguishes it from sibling list_picks.

  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?

  Clear use case is given: 'Useful for per-match analysis' with an illustrative question. It also contrasts with list_picks by noting the same shape but scoped to one match, implicitly guiding the agent to choose this when a single match is of interest. Explicit exclusion of when not to use is absent, so not a perfect 5.

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

• list_suppressionsA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description takes on the burden of disclosing behavior: it clearly states the operation is read-only and restricted to admin scope, and limits results to 'currently active' suppressions. It doesn't describe response fields or error behavior, but for a zero-parameter list tool the key behavioral traits are disclosed.

  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; the first is front-loaded with the core action and object, the second adds essential safety/authorization context. No filler 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 zero-parameter read-only list tool with no output schema, the description covers purpose, scope, and authorization clearly. It lacks an explicit note about the shape of returned entries, but that is largely inferable from the tool name and sibling context.

  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 input schema has zero properties, so schema coverage is vacuously 100% and there are no parameters to explain. Baseline 4 applies because the description needs no parameter elaboration.

  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 it 'List the currently active market suppressions' with a clarifying parenthetical '(the kill switches in effect)'. This is a specific verb+resource combination that distinguishes it from the mutating siblings suppress_market and unsuppress_market.

  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?

  Explicitly identifies itself as read-only and scopes authorization to 'same admin scope as suppress_market', signaling when it is safe/appropriate to call and under what permissions. It doesn't explicitly name alternatives or exclusion cases, but in context the sibling tools are clearly the mutating counterparts.

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

• get_accountA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden and explicitly states 'Read-only,' a key behavioral trait. It also discloses the nuanced 'effective role (trial-elevated while a trial is active)' behavior, which goes beyond a simple field list. It lacks details on auth specifics or rate limits, but the core safety profile is disclosed.

  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 two sentences, front-loaded with the main purpose, and every clause adds value (field list, usage context, read-only status, role nuance). No wasted words.

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

  Completeness5/5

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

  Given the tool's simplicity (no parameters, no output schema), the description is fully self-contained: it explains what is returned, the key nuance of trial elevation, and the use case. The sibling context shows clear differentiation, and no additional information is needed for an agent to decide when to use it.

  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, so there is nothing to document for invocation. The description instead enriches the return semantics by detailing the meaning of 'role' and 'effective role', which adds value beyond the empty input schema.

  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 starts with a specific verb+resource ('Return the API-key holder's account info') and enumerates the exact fields returned, making the purpose unmistakable. It clearly distinguishes from sibling tools like list_picks or suppress_market, which deal with other domains.

  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 provides clear context on when to use it ('Useful for an AI assistant to explain what plan the user is on and which leagues they have access to'), effectively indicating the tool's role among siblings. However, it doesn't explicitly state when not to use it or name alternative tools, though the domain separation from siblings is implicit.

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

• list_leaguesA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses plan-based access restrictions and explains that the is_specialized flag indicates leagues the engine biases toward, adding meaningful behavioral context beyond the schema. It does not explicitly state read-only behavior, but 'List' strongly implies it, and the additional context is sufficient.

  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 concise, front-loaded with the main action, and every sentence provides value—from the plan filter to the output fields to example queries. No redundancy or filler.

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

  Completeness5/5

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

  Given no output schema and no annotations, the description thoroughly covers what the tool returns (id, name, country, continent, is_specialized flag), notes plan-based restrictions, and even mentions the integration point with list_picks. It is fully sufficient for an agent to understand and invoke the tool correctly.

  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 input schema has 100% coverage with clear parameter descriptions, so the baseline is 3. The description adds extra meaning by explaining the is_specialized flag and how the id relates to list_picks, enriching the semantics of the specialized_only parameter and the output's utility.

  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 lists soccer leagues tracked by the Statos engine and explicitly mentions plan-based filtering. It differentiates itself from siblings by noting that league IDs can be used with list_picks, making the tool's role in the ecosystem clear.

  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 provides concrete use-case examples ('which European leagues can I see?') and explains how to filter for specialized leagues. It does not explicitly contrast with alternative tools, but the discovery-oriented framing and reference to list_picks give clear guidance on when this tool is appropriate.

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