Skip to main content
Glama

TheSportsDB team search: up to 5 teams matching a name

dev_thesportsdb
Read-only

TheSportsDB team search: up to 5 teams matching a name, with sport, league, formed year, stadium, country, website and English description. Community-maintained database; uses TheSportsDB's public test key unless the owner sets THESPORTSDB_KEY. Related tools on this server, for a different need: dev_sherdog when you need Sherdog MMA fighter profile by Sherdog fighter id: name; dev_teamrankings when you need TeamRankings team stat table for NBA or NFL, for one stat. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "team": "<team>"
    },
    "name": "dev_thesportsdb"
  }
}

Input Schema

NameRequiredDescriptionDefault
teamYesTeam name to search for, 2 to 60 characters

Output Schema

NameRequiredDescriptionDefault
countNo
queryNo
teamsNo
sourceNo
checkedAtNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the readOnly and openWorld annotations, the description discloses the result cap (up to 5 teams), the output fields, the community-maintained database nature, the API key fallback behavior, and per-call pricing with failure not charged. These are meaningful operational details that an agent would not get from annotations alone.

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 purpose is front-loaded and the sentences are purposeful, but the description is a dense paragraph that includes lengthy sibling-tool descriptions and pricing details. Some of the sibling context could be trimmed without losing essential guidance.

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 simple one-parameter read-only search tool with an output schema and annotations, the description covers purpose, result shape, limitations (test key fallback), cost model, and alternatives. Nothing material is missing 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?

The schema coverage is 100% and already documents the single 'team' parameter with its 2–60 character constraint. The description adds no syntax, format, or matching semantics beyond what the schema provides, so 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 states a specific verb and resource: 'TheSportsDB team search: up to 5 teams matching a name.' It also lists the returned fields, making the tool's scope unambiguous and easily distinguishable from unrelated siblings.

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 names two related tools and gives the condition for each (dev_sherdog for MMA fighter profiles, dev_teamrankings for NBA/NFL stat tables), which implicitly frames this tool as the team-search option. It stops short of an explicit 'use this when...' statement or exclusions, so the guidance is clear but not fully exhaustive.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources