therundown-dataofficial
F
licenseA
qualityB
maintenanceEnables local read-only access to TheRundown Product API data including sports, affiliates, market definitions, events, futures, and open main lines using your own API key.
6
-
TheRundown Documentation MCP
Server Details
Official TheRundown API documentation search. No live data or authenticated Product API calls.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- TheRundown/documentation-mcp
- GitHub Stars
- 0
TDQS
A4.5/5.0
Scored across 3 tools
Disambiguation4/5
submit_feedback is clearly distinct, and the two documentation lookup tools have differentiated roles: search_the_rundown_api for broad semantic queries, query_docs_filesystem for exact keyword/regex reads and page access. There is slight overlap since both can locate relevant docs, but the descriptions provide enough guidance to pick correctly.
Naming Consistency3/5
All tool names start with verbs (query, search, submit), but the naming conventions are mixed: one tool uses a verbose 'query_docs_filesystem_the_rundown_api' pattern, another shorter 'search_the_rundown_api', and the third omits the product name entirely. The inconsistency is readable but not predictable.
Tool Count5/5
Three tools is well-scoped for a documentation MCP: one filesystem-style reader, one semantic search, and one feedback channel. Each tool earns its place without redundancy or bloat.
Completeness5/5
The domain is documentation access, and the set covers the full workflow: search for relevant pages, read/filter content with the filesystem query tool, and report docs issues via feedback. No obvious dead ends or missing operations for the stated purpose.
Available Tools
3 toolsquery_docs_filesystem_the_rundown_apiARead-onlyIdempotentInspect
Run a read-only shell-like query against a virtualized, in-memory filesystem rooted at / that contains ONLY the TheRundown API documentation pages and OpenAPI specs. This is NOT a shell on any real machine — nothing runs on the user's computer, the server host, or any network. The filesystem is a sandbox backed by documentation chunks.
This is how you read documentation pages: there is no separate "get page" tool. To read a page, pass its .mdx path (e.g. /quickstart.mdx, /api-reference/create-customer.mdx) to head or cat. To search the docs with exact keyword or regex matches, use rg. To understand the docs structure, use tree or ls.
Workflow: Start with the search tool for broad or conceptual queries like "how to authenticate" or "rate limiting". Use this tool when you need exact keyword/regex matching, structural exploration, or to read the full content of a specific page by path.
Supported commands: rg (ripgrep), grep, find, tree, ls, cat, head, tail, stat, wc, sort, uniq, cut, sed, awk, jq, plus basic text utilities. No writes, no network, no process control. Run --help on any command for usage.
Each call is STATELESS: the working directory always resets to / and no shell variables, aliases, or history carry over between calls. If you need to operate in a subdirectory, chain commands in one call with && or pass absolute paths (e.g., cd /api-reference && ls or ls /api-reference). Do NOT assume that cd in one call affects the next call.
Examples:
tree / -L 2— see the top-level directory layoutrg -il "rate limit" /— find all files mentioning "rate limit"rg -C 3 "apiKey" /api-reference/— show matches with 3 lines of context around each hithead -80 /quickstart.mdx— read the top 80 lines of a specific pagehead -80 /quickstart.mdx /installation.mdx /guides/first-deploy.mdx— read multiple pages in one callcat /api-reference/create-customer.mdx— read a full page when you need everythingcat /openapi/spec.json | jq '.paths | keys'— list OpenAPI endpoints
Output is truncated to 30KB per call. Prefer targeted rg -C or head -N over broad cat on large files. To read only the relevant sections of a large file, use rg -C 3 "pattern" /path/file.mdx. Batch multiple file reads into a single head or cat call whenever possible.
When referencing pages in your response to the user, convert filesystem paths to URL paths by removing the .mdx extension. For example, /quickstart.mdx becomes /quickstart and /api-reference/overview.mdx becomes /api-reference/overview.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | A shell command to run against the virtualized documentation filesystem (e.g., `rg -il "keyword" /`, `tree / -L 2`, `head -80 /path/file.mdx`). |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the annotations: it is a sandbox, not a real shell; no writes, no network, no process control; each call is stateless; working directory always resets to /; output is truncated to 30KB; and `cd` does not affect subsequent calls. These details are not present in annotations and meaningfully change how the agent should invoke the tool.
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 long but well-organized with clear sections (introduction, workflow, supported commands, statelessness, examples, output truncation, URL conversion). It is verbose because the tool is complex, but nearly every section earns its place. It has minor redundancy around preferring `rg -C`/`head` over `cat`, but this is not a major penalty for an otherwise useful, structured definition.
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 complexity and lack of output schema, the description is remarkably complete. It explains the virtual filesystem, all supported commands, statelessness, output truncation, how to batch reads, and even how to map paths back to URLs. An agent has everything needed to use this tool correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single `command` parameter already has 100% schema coverage, but the description greatly enriches its semantics: it lists supported commands (rg, grep, find, tree, ls, cat, head, tail, stat, etc.), provides multiple examples, explains chaining with `&&`, notes absolute-path usage, and warns about statelessness. This goes far beyond the schema's one-line description.
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 very specific verb and resource: 'Run a read-only shell-like query against a virtualized, in-memory filesystem rooted at /' containing only TheRundown API docs. It distinguishes itself from the sibling search_the_rundown_api by saying the search tool is for broad/conceptual queries while this tool is for exact keyword/regex matching, structural exploration, and reading full pages by path.
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?
It gives explicit when-to-use guidance: 'Start with the search tool for broad or conceptual queries... Use this tool when you need exact keyword/regex matching, structural exploration, or to read the full content of a specific page by path.' It also clarifies that this is the only way to read documentation pages and warns about statelessness and reset behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_the_rundown_apiSearch documentationARead-onlyIdempotentInspect
Search across the TheRundown API knowledge base to find relevant information, code examples, API references, and guides. Use this tool when you need to answer questions about TheRundown API, find specific documentation, understand how features work, or locate implementation details. The search returns contextual content with titles and direct links to the documentation pages. If you need the full content of a specific page, use the query_docs_filesystem tool to head or cat the page path (append .mdx to the path returned from search — e.g. head -200 /api-reference/create-customer.mdx).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context beyond that: it returns contextual content with titles and direct links, and clarifies that it does not return full page content, pointing to a filesystem command for that. This is meaningful extra information.
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?
Three sentences, each earning its place: purpose, when-to-use, and output/alternative workflow. The embedded example (`head -200 /api-reference/create-customer.mdx`) is practical and not excessive. The description is front-loaded with the primary purpose before any secondary instructions.
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 search tool with strong annotations, this description is complete. It explains what the search returns, how to get full content when needed, and which sibling to use. Nothing an agent needs to invoke the tool correctly is missing.
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 only parameter, query, is fully documented in the schema with the description 'Search query', so schema coverage is 100%. The tool description does not add parameter-level detail, but none is needed given the simple single-parameter design.
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 action ('Search across the TheRundown API knowledge base') and enumerates what can be found: relevant information, code examples, API references, and guides. It also distinguishes itself from query_docs_filesystem by focusing on search results rather than full page content.
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?
Explicitly says when to use: 'Use this tool when you need to answer questions about TheRundown API, find specific documentation, understand how features work, or locate implementation details.' It also gives an explicit alternative for full content retrieval using query_docs_filesystem, including how to append `.mdx` to returned paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_feedbackSubmit documentation feedbackAInspect
Report a problem with this documentation site so the docs team can fix it. Use when a documentation page is incorrect, outdated, confusing, incomplete, or has a broken example. This is for feedback about the documentation content itself — not for product support requests or feedback about this tool or assistant.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | The documentation page path the feedback is about (e.g., the page you were reading, such as `/quickstart`). | |
| feedback | Yes | A clear description of the documentation issue or suggestion — what is incorrect, outdated, missing, or confusing. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the operation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds useful context by stating the feedback is routed to the docs team to fix the issue, while the exclusion of unrelated feedback clarifies the tool's boundaries.
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 focused sentences: the first front-loads the action and purpose, the second packs the usage criteria and exclusions. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema coverage, descriptive annotations, and no output schema, the description is complete. It tells the agent what the tool does, when to use it, and when not to use it, so correct selection and invocation are fully supported.
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 both `path` and `feedback` parameters are already well documented with examples. The description does not need to add parameter-level detail and adds only indirect context by emphasizing the feedback is about documentation content.
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 ('Report a problem') and resource ('this documentation site'), with the clear goal of enabling the docs team to fix issues. It clearly differentiates this tool from the query/search siblings by focusing on feedback submission rather than information retrieval.
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?
Explicit use cases are listed: when a page is incorrect, outdated, confusing, incomplete, or has a broken example. It also explicitly excludes product support requests and feedback about the tool or assistant, giving clear when-not-to-use guidance.
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. Dates show when Glama detected each change.
3 tool updates
- First observed
query_docs_filesystem_the_rundown_api - First observed
search_the_rundown_api - First observed
submit_feedback
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
NFL/NBA/MLB/NHL/PGA + DFS and prediction-market data. Browse free; query with a free API key.
Search the Final POS REST API documentation.
TheSportsDB MCP — sports catalog (teams, players, events)
Live Steam Market API docs, schemas, products, games, markets and endpoint search.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceProvides comprehensive sports intelligence including live scores, standings, schedules, betting odds, news, highlights, and more via SSE transport.-
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to query sports data including teams, players, events, and standings from TheSportsDB through natural language or direct tool calls.6MIT
- AlicenseNot gradedqualityCmaintenanceProvides access to comprehensive sports data from 5 major leagues (NBA, NFL, MLB, EPL, NHL) including teams, players, games, statistics, standings, injuries, and betting odds through 67+ endpoints. Enables users to query sports information and analytics through natural language.12MIT