F
licenseNot graded
qualityD
maintenanceAn MCP Server that enables interaction with MLB scores and statistics via the SportsData.io MLB V3 Scores API, allowing users to access baseball data through natural language queries.
-
balldontlie-mcp
by mikechao
Balldontlie MCP 서버
NBA, NFL, MLB의 선수, 팀 및 경기에 대한 정보를 제공하기 위해 Balldontlie API를 통합한 MCP 서버 구현입니다.
도구
get_teams
NBA, NFL 또는 MLB 팀 목록을 받으세요
입력:
league(enum ['NBA', 'NFL', 'MLB']): 팀을 가져올 스포츠 리그
플레이어를 얻으세요
NBA, NFL 또는 MLB의 선수 목록을 가져옵니다.
입력:
league(enum ['NBA', 'NFL', 'MLB']): 선수를 모집하는 스포츠 리그firstName(문자열, 선택 사항): 검색할 플레이어의 첫 번째 이름lastName(문자열, 선택 사항): 검색할 플레이어의 성cursor(숫자, 선택 사항): 페이지 매김을 위한 커서
게임 받기
NBA, NFL 또는 MLB의 게임 목록을 가져옵니다.
입력:
league(enum ['NBA', 'NFL', 'MLB']): 게임을 가져올 스포츠 리그dates(문자열[], 선택 사항): 특정 날짜의 게임을 가져옵니다. 형식: YYYY-MM-DDteamIds(문자열[], 선택 사항): 특정 게임에 대한 게임 가져오기cursor(숫자, 선택 사항): 페이지 매김을 위한 커서
게임 받기
NBA, MLB, NFL 중 하나의 특정 리그에서 특정 게임을 받으세요
입력:
league(enum ['NBA', 'NFL', 'MLB']): 게임을 가져올 스포츠 리그gameId(숫자): get_games 도구에서 가져온 게임의 ID
Related MCP server: mlb-api-mcp
프롬프트
스케줄 생성기
리그(NBA, MLB, NFL)와 시작 날짜, 종료 날짜가 주어지면 Claude Desktop에서 대화형 일정이 생성됩니다.
구성
API 키 받기
Balldontlie.io 에 계정을 등록하세요
이 MCP 서버에는 무료 플랜이 충분합니다.
Smithery를 통해 설치
Smithery를 통해 Claude Desktop에 balldontlie-mcp를 자동으로 설치하려면:
지엑스피1
Claude Desktop과 함께 사용
claude_desktop_config.json 에 다음을 추가하세요:
{
"mcp-servers": {
"balldontlie": {
"command": "npx",
"args": [
"-y",
"balldontlie-mcp"
],
"env": {
"BALLDONTLIE_API_KEY": "YOUR API KEY HERE"
}
}
}
}LibreChat과 함께 사용
mcpServers:
balldontlie:
command: sh
args:
- -c
- BALLDONTLIE_API_KEY=your-api-key-here npx -y balldontlie-mcp특허
이 MCP 서버는 MIT 라이선스에 따라 라이선스가 부여됩니다. 즉, MIT 라이선스의 조건에 따라 소프트웨어를 자유롭게 사용, 수정 및 배포할 수 있습니다. 자세한 내용은 프로젝트 저장소의 LICENSE 파일을 참조하세요.
부인 성명
이 라이브러리는 balldontlie.io와 공식적으로 제휴 관계가 없습니다. MCP 서버를 기반으로 balldontlie API를 구현한 타사 라이브러리입니다.
Available Tools
4 toolsget_gameB
Get a specific game from one of the following leagues NBA (National Basketball Association), MLB (Major League Baseball), NFL (National Football League)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| league | Yes | ||
| gameId | Yes | Game ID to get the game for, the value should be Game ID from previous call of get_games tool |
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks details on behavior like read-only status, authentication, or potential side effects, leaving agents uninformed.
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?
A single, well-structured sentence with no redundant information, efficiently conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too sparse, omitting return values, usage constraints, and other context needed for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one of two parameters (gameId) has a description in the schema; the description does not add meaningful info beyond enumerating leagues and referencing the game ID source.
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 retrieves a specific game from NBA, MLB, or NFL leagues, distinguishing it from siblings like get_games (list) and other tools.
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?
Implicitly, the tool is for fetching a single game, but no explicit guidance on when not to use it or alternatives is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_gamesB
Gets the list of games from one of the following leagues NBA (National Basketball Association), MLB (Major League Baseball), NFL (National Football League)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| league | Yes | ||
| dates | No | Get games for a range of dates, format: YYYY-MM-DD, optional | |
| seasons | No | Get games for a specific season, format: YYYY, optional | |
| teamIds | No | Get games for specific team IDs, optional | |
| cursor | No | Cursor for pagination, the value should be next_cursor from previous call of get_games tool, optional |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description only states read operation but omits pagination behavior (despite cursor param), auth requirements, rate limits, or what happens with no results. No annotations to supplement.
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?
Single efficient sentence with no fluff. Could be restructured to front-load list nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and description does not mention return format. With 5 params, moderate complexity, description should hint at response structure or pagination.
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 80% so parameters mostly documented. Description adds no extra meaning beyond listing leagues. 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?
Clear verb+resource: 'Gets the list of games' from specific leagues. Siblings get_game (singular), get_players, get_teams are distinct, so no confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs siblings (e.g., use get_game for a single game). Also no indication of when to use dates vs seasons or cursor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_playersA
Gets the list of players from one of the following leagues NBA (National Basketball Association), MLB (Major League Baseball), NFL (National Football League)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| league | Yes | ||
| firstName | No | First name of the player to search for, optional | |
| lastName | No | Last name of the player to search for, optional | |
| cursor | No | Cursor for pagination, the value should be next_cursor from previous call of get_players tool, optional |
TDQS
A3.5/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully inform about behavior. It only states a read operation without mentioning pagination (cursor parameter exists), rate limits, or other behavioral traits, leaving gaps.
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 a single clear sentence that efficiently communicates the tool's purpose without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description covers basic purpose but omits context about optional parameters and pagination cursor usage, leaving some completeness gaps.
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 75% (three of four parameters have descriptions), and the description adds no extra parameter information. Baseline of 3 is appropriate as the schema does the heavy lifting.
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 specifies the verb 'Gets the list' and resource 'players', and explicitly lists the leagues (NBA, MLB, NFL), distinguishing it from siblings like get_game and get_teams.
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 implies usage for retrieving players by league but does not explicitly state when to use this tool over alternatives like get_game or get_teams, nor does it provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_teamsA
Gets the list of team from one of the following leagues NBA (National Basketball Association), MLB (Major League Baseball), NFL (National Football League)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| league | Yes |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes a straightforward read operation with no disclosure of authentication, rate limits, or result format. Minimal behavioral context beyond purpose.
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?
Single sentence conveys all necessary information without redundancy. Front-loaded with action and resource.
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 simple structure (1 param, no output schema), description covers the core functionality. Could mention return structure (e.g., team names or IDs) but not essential for selection. Minor gap in completeness.
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 has one param 'league' with enum but no description. Description adds meaning by listing the three league values and indicating they serve as selection criteria. Adds value beyond the bare 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?
Description clearly states verb 'gets' and resource 'teams', with specific leagues (NBA, MLB, NFL). Distinguishes from sibling tools (get_game, get_games, get_players) by focusing on team listing.
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?
Specifies the tool retrieves teams from listed leagues, but no guidance on when to use vs alternatives or when not to use. Implicitly clear but lacks explicit context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
v1.0.0- Added
get_game - Added
get_games - Added
get_players - Added
get_teams
TDQS
A3.7/5.0
Scored across 4 tools
Disambiguation5/5
Each tool targets a distinct resource: a single game, list of games, players, or teams. There is no overlap in functionality.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with get_ prefix and snake_case. No deviations.
Tool Count5/5
Four tools are well-scoped for a sports data server covering three leagues. Not too many or too few.
Completeness3/5
The server provides only read operations. Missing single-player and single-team retrieval, and no filtering or search capabilities are indicated in descriptions.
Maintenance
ActivityInactive
ResponsivenessUnresponsive
Related MCP Connectors
The official MCP Server for the Mux API
A simple MCP server built with FastMCP and python
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
Related MCP Servers
- AlicenseBqualityBmaintenancePython MCP server that provides comprehensive access to MLB statistics and baseball data through a FastAPI-based interface. Acts as a bridge between AI applications and MLB data sources, enabling seamless integration of baseball statistics, game information, player data, and more.2459MIT
- FlicenseNot gradedqualityDmaintenanceAn MCP server for accessing college basketball statistics through the SportsData.io CBB v3 Stats API, enabling AI agents to retrieve and analyze college basketball data through natural language interactions.-
- AlicenseAqualityCmaintenanceMCP server for NBA live data and stats, providing read-only tools to query live scores, box scores, player info, standings, and more from NBA.com.1516 npm1MIT