Skip to main content
Glama

Football Atlas

by app.futbolatlas

Server Details

The Laws of the Game and world football's major competitions, every claim cited to primary sources

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
citarium/futbolatlas-mcp
GitHub Stars
0
Server Listing
Football Atlas

Available Tools

8 tools
answerAnswer a question about Football AtlasA
Read-onlyIdempotent
Inspect

Answer a question from the corpus. Returns the matched object's claims with sources and confidence — never an unsourced answer. Use this when the user asked a question in words; use search when you want to see the candidates yourself.

ParametersJSON Schema
NameRequiredDescriptionDefault
questionYesThe question to answer, in the words the user asked it.

Output Schema

ParametersJSON Schema
NameRequiredDescription
claimsNo
entityNo
answeredYes
matched_questionNo

TDQS

A4.5/5.0
Behavior4/5

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

Annotations cover read-only and idempotent behavior, and the description adds meaningful context: it never returns an unsourced answer and returns claims with sources and confidence. This goes beyond the annotations and helps set expectations without contradicting them.

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 short sentences, each earning its place: the action, the return guarantee, and the usage guidance. The core purpose is front-loaded, and there is no redundant wording.

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 tool with full schema coverage, rich annotations, and an output schema, the description is complete. It covers purpose, behavior, return characteristics, and when to choose an alternative.

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 the description does not add meaning beyond what the schema already provides for the single 'question' parameter. The baseline of 3 applies because the schema carries the parameter semantics fully.

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 verb and resource: it answers a question from the corpus. It also differentiates from the 'search' sibling by emphasizing that it returns a direct answer with sources and confidence, not just candidates.

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 instructs when to use the tool: when the user asked a question in words. It also names the alternative 'search' and the condition for choosing it, giving the agent clear routing guidance.

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

get_entityGet one Football Atlas knowledge objectA
Read-onlyIdempotent
Inspect

Fetch one knowledge object by id, with its claims and the sources each claim cites. Use this once search, answer or get_topic has given you an id. An unknown id is not a dead end: the answer names near-miss ids you can retry with.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe knowledge object's id, as returned by search, answer, get_topic or get_related — the last segment of its canonical URL.

Output Schema

ParametersJSON Schema
NameRequiredDescription
foundYes
entityNo
recoveryNo

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable contextual behavior: an unknown id is recoverable via near-miss ids named in the answer. This is meaningful beyond what the schema or annotations state.

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 short sentences, each earning its place: what the tool returns, when to call it, and what to do on an unknown id. No filler, no repetition of annotated facts, and the main purpose is front-loaded.

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 single-parameter read-only tool with full schema coverage, annotations, and an output schema, this description gives the agent everything needed: trigger condition, return contents, and failure behavior. Nothing critical 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?

Schema coverage is 100%, and the schema already explains that id is returned by search, answer, get_topic, or get_related and is the last segment of the canonical URL. The description adds workflow context but no additional parameter-level meaning, so the 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 action ('Fetch one knowledge object by id') and names the resource plus its distinguishing contents (claims and cited sources). This makes it clear that get_entity is the id-based retrieval sibling among search, get_topic, and get_overview.

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 explicitly tells the agent when to use this tool: after search, answer, or get_topic has supplied an id. It also gives useful recovery guidance for unknown ids. It does not explicitly contrast get_entity with get_overview or get_related, so it stops short of full when-not instructions.

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

get_latestLatest verified Football Atlas objectsA
Read-onlyIdempotent
Inspect

Most recently verified knowledge objects (freshness signal). Use this to judge how current the corpus is, or to see what changed since you last read it. It ranks by verification date and ignores your topic entirely — use search or get_topic when you want objects that are relevant rather than recent.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoHow many recently verified objects to return, newest verification first.

Output Schema

ParametersJSON Schema
NameRequiredDescription
totalYes
resultsYes

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds meaningful behavioral context: ranking by verification date and that the tool ignores the user's topic entirely, which goes beyond the structured annotations.

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 no filler. The core behavior and freshness signal are front-loaded, followed by explicit usage guidance and exclusion of irrelevant alternatives. Every sentence earns its place.

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?

With only one optional parameter, an output schema present, and annotations covering safety, the description supplies the missing contextual pieces: when to use the tool, what it ignores, and how it differs from siblings. Nothing critical is missing for an agent to invoke it correctly.

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 input schema documents the only parameter (limit) with a clear description, default, min, and max, so schema description coverage is 100%. The tool description adds no further parameter details, which is acceptable per the baseline; the schema carries the semantic weight.

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 returns 'Most recently verified knowledge objects' and 'ranks by verification date,' giving a specific verb and resource. It also distinguishes itself from siblings by explicitly noting it ignores the user's topic, which sets it apart from search and get_topic.

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 provides explicit usage context: use this to judge how current the corpus is or to see what changed since last read. It also names alternatives and the condition that selects them: 'use search or get_topic when you want objects that are relevant rather than recent.' This is model guidance.

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

get_overviewOverview of Football AtlasA
Read-onlyIdempotent
Inspect

Corpus overview: what this instance knows, counts by type, published tags, freshness. Use this first when you land here and do not yet know whether this corpus can answer your question.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
tagsYes
by_typeYes
instanceYes
descriptionYes
total_mediaYes
total_objectsYes
newest_verificationYes
oldest_verificationYes

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly, non-destructive, idempotent behavior. The description adds useful context about what the overview exposes (counts by type, published tags, freshness) and frames it as a triage tool. It does not repeat annotation information, and there is 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?

Two concise sentences that front-load the core purpose and then give practical usage guidance. Every word earns its place; no filler or redundancy.

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 parameterless metadata inspection tool with output schema and safety annotations, the description fully covers purpose, contents, and when to use it. Nothing essential is missing.

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 the baseline is 4. The description does not need to explain parameter meaning, and the output schema covers the return structure.

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?

Description states it provides a corpus overview with counts by type, published tags, and freshness. It clearly identifies the resource (the corpus) and what it reveals, though it uses a noun phrase rather than an explicit verb+resource structure. It is sufficiently distinct from siblings like search and get_entity by being the high-level entry point.

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 instructs to use this tool first when arriving and before knowing whether the corpus can answer the question. This provides strong placement guidance among siblings, though it does not explicitly name alternatives or state 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.

get_sourcesSources behind Football AtlasA
Read-onlyIdempotent
Inspect

The instance's whole source registry, or just the sources cited by one object — each with its evidence tier, reliability and access date. Use this when you need the registry entry behind a citation, or the whole registry to judge the corpus before trusting it; get_entity already tells you which sources a claim cites.

ParametersJSON Schema
NameRequiredDescriptionDefault
object_idNoRestrict the answer to the sources cited by this knowledge object. Omit it to get the instance's whole source registry.

Output Schema

ParametersJSON Schema
NameRequiredDescription
foundYes
sourcesYes
recoveryNo

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 destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context: the tool can return either the whole registry or a filtered set depending on object_id, and it specifies the output attributes (evidence tier, reliability, access date). No contradiction with annotations.

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 core behavior, then targeting the use case and sibling differentiation. Every clause earns its place; there is no redundancy or padding.

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 read-only tool with one optional parameter, rich annotations, an output schema, and a clear differentiator from get_entity, the description is fully sufficient. It tells the agent what the tool returns, when to use it, and how it relates to a sibling 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%, and the schema already explains that object_id restricts results and can be omitted for the whole registry. The tool description mainly restates this same information, adding no substantially new parameter semantics beyond what the schema already provides.

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: retrieving the source registry or the sources cited by one object, including evidence tier, reliability, and access date. It actively distinguishes itself from get_entity, which already tells which sources a claim cites, making the tool's unique scope clear.

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 explains when to use this tool: when you need the registry entry behind a citation, or the whole registry to judge the corpus. It also calls out get_entity as the alternative for seeing which sources a claim cites, providing clear routing guidance.

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

get_topicBrowse Football Atlas by topicA
Read-onlyIdempotent
Inspect

List the knowledge objects carrying a tag (topics are content-backed tags). Use this to browse a known topic; use search when you have a question rather than a tag, and get_overview to see which tags exist. An unknown tag comes back with the topics that do exist, so a miss still moves you forward.

ParametersJSON Schema
NameRequiredDescriptionDefault
tagYesThe topic to list, spelled exactly as get_overview publishes it. Every published topic has objects under it, so an empty answer means the topic does not exist.

Output Schema

ParametersJSON Schema
NameRequiredDescription
tagYes
totalYes
resultsYes
recoveryNo

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety burden is covered. The description adds real behavioral value on top: the semantics of topics as content-backed tags and the graceful miss behavior ('an unknown tag comes back with the topics that do exist'), which an agent could not infer from annotations alone. It stops short of disclosing result ordering or pagination, but the output schema covers return shape, so a 4 is appropriate.

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, zero waste: the core action is front-loaded, the routing guidance follows, and the edge-case behavior closes it out. Every sentence carries distinct information, and none repeats the schema or annotations.

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 single-parameter, read-only browse tool, the description plus annotations and output schema cover everything an agent needs: what it does, when to use it, what an unknown tag yields, and how to phrase the tag. Return values are covered by the output schema, so the description need not explain them. No meaningful gap remains.

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 the schema itself is exemplary: it specifies exact spelling as published by get_overview and states that an empty answer means the topic does not exist. The description only adds marginal param-level meaning ('content-backed tags'), which reinforces rather than extends the schema. Per the baseline rule for high coverage, a 3 is correct.

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 verb and resource ('List the knowledge objects carrying a tag') and clarifies the semantics ('topics are content-backed tags'). It also differentiates from siblings by naming search and get_overview as the alternatives for different intents, so an agent can distinguish this tool without opening schemas.

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 routing is given: browse a known topic here, use search for a question rather than a tag, and use get_overview to discover which tags exist. The description also covers the edge case of an unknown tag and why it is still productive, leaving no ambiguity about when to invoke this tool versus its siblings.

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.

  1. 8 tool updates
    • Changedanswer1 field changed
      • addedInput schema / properties / question / description
        Added value: +"The question to answer, in the words the user asked it."
    • Changedget_entity3 fields changed
      • addedInput schema / properties / id / description
        Added value: +"The knowledge object's id, as returned by search, answer, get_topic or get_related — the last segment of its canonical URL."
      • addedOutput schema / properties / entity / properties / media
        Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "alt": {
+        "type": "string"
+      },
+      "caption": {
+        "type": "string"
+      },
+      "credit": {
+        "type": "string"
+      },
+      "height": {
+        "maximum": 9007199254740991,
+        "minimum": -9007199254740991,
+        "type": "integer"
+      },
+      "id": {
+        "type": "string"
+      },
+      "license_spdx": {
+        "type": "string"
+      },
+      "permissions": {
+        "additionalProperties": {
+          "type": "boolean"
+        },
+        "propertyNames": {
+          "type": "string"
+        },
+        "type": "object"
+      },
+      "supports": {
+        "type": "string"
+      },
+      "url": {
+        "type": "string"
+      },
+      "width": {
+        "maximum": 9007199254740991,
+        "minimum": -9007199254740991,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "id",
+      "url",
+      "alt",
+      "credit",
+      "license_spdx",
+      "permissions"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
      • changedOutput schema / properties / entity / required
        Previous value: -[
-  "id",
-  "type",
-  "name",
-  "summary",
-  "tags",
-  "evidence_tier",
-  "confidence",
-  "last_verified",
-  "canonical_url",
-  "api_url",
-  "questions",
-  "claims"
-]New value: +[
+  "id",
+  "type",
+  "name",
+  "summary",
+  "tags",
+  "evidence_tier",
+  "confidence",
+  "last_verified",
+  "canonical_url",
+  "api_url",
+  "questions",
+  "claims",
+  "media"
+]
    • Changedget_latest1 field changed
      • addedInput schema / properties / limit / description
        Added value: +"How many recently verified objects to return, newest verification first."
    • Changedget_overview2 fields changed
      • addedOutput schema / properties / total_media
        Added value: +{
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
      • changedOutput schema / required
        Previous value: -[
-  "instance",
-  "description",
-  "total_objects",
-  "by_type",
-  "tags",
-  "newest_verification",
-  "oldest_verification"
-]New value: +[
+  "instance",
+  "description",
+  "total_objects",
+  "by_type",
+  "tags",
+  "newest_verification",
+  "oldest_verification",
+  "total_media"
+]
    • Changedget_related1 field changed
      • addedInput schema / properties / id / description
        Added value: +"The knowledge object to walk out from, by id."
    • Changedget_sources1 field changed
      • addedInput schema / properties / object_id / description
        Added value: +"Restrict the answer to the sources cited by this knowledge object. Omit it to get the instance's whole source registry."
    • Changedget_topic1 field changed
      • addedInput schema / properties / tag / description
        Added value: +"The topic to list, spelled exactly as get_overview publishes it. Every published topic has objects under it, so an empty answer means the topic does not exist."
    • Changedsearch4 fields changed
      • addedInput schema / properties / limit / description
        Added value: +"How many ranked hits to return, best first."
      • addedInput schema / properties / query / description
        Added value: +"What to look for, in the user's own words. Matched against titles, questions, claim text and tags; accents and apostrophes are ignored, so 'jose' finds 'José'."
      • addedOutput schema / properties / results / items / properties / matched_fields / description
        Added value: +"Which fields the query hit: name, tags, content. Does NOT determine the score on its own."
      • addedOutput schema / properties / results / items / properties / score / description
        Added value: +"Text match, weighted by where the token hits (name 3, tags 2, content 1 per query token), plus a centrality bonus of up to 0.9 for objects that other objects point at. That bonus is why two hits can share matched_fields and still score differently: the decimal is inbound edges, not text relevance."
  2. 4 tool updates
    • Changedget_entity1 field changed
      • addedOutput schema / properties / recovery
        Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "available": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "available_count": {
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "available_truncated": {
+      "type": "boolean"
+    },
+    "did_you_mean": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "hint": {
+      "type": "string"
+    },
+    "next_tool": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "available_count",
+    "available",
+    "next_tool",
+    "hint"
+  ],
+  "type": "object"
+}
    • Changedget_related1 field changed
      • addedOutput schema / properties / recovery
        Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "available": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "available_count": {
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "available_truncated": {
+      "type": "boolean"
+    },
+    "did_you_mean": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "hint": {
+      "type": "string"
+    },
+    "next_tool": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "available_count",
+    "available",
+    "next_tool",
+    "hint"
+  ],
+  "type": "object"
+}
    • Changedget_sources1 field changed
      • addedOutput schema / properties / recovery
        Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "available": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "available_count": {
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "available_truncated": {
+      "type": "boolean"
+    },
+    "did_you_mean": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "hint": {
+      "type": "string"
+    },
+    "next_tool": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "available_count",
+    "available",
+    "next_tool",
+    "hint"
+  ],
+  "type": "object"
+}
    • Changedget_topic1 field changed
      • addedOutput schema / properties / recovery
        Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "available": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "available_count": {
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "available_truncated": {
+      "type": "boolean"
+    },
+    "did_you_mean": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "hint": {
+      "type": "string"
+    },
+    "next_tool": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "available_count",
+    "available",
+    "next_tool",
+    "hint"
+  ],
+  "type": "object"
+}
  3. 8 tool updates
    • First observedanswer
    • First observedget_entity
    • First observedget_latest
    • First observedget_overview
    • First observedget_related
    • First observedget_sources
    • First observedget_topic
    • First observedsearch

Frequently Asked Questions

Discussions

No comments yet. Be the first to start the discussion!

Login with GitHub to comment

Related MCP Connectors

Related MCP Servers

  • MatchBrief

    SpaceGravy
    A
    license
    Not graded
    quality
    C
    maintenance
    MCP server for retrieving World Cup match briefs, fixtures, and event explanations with sourced, plain-language context.
    MIT

  • football-api-mcp

    5dollarfootball-api
    A
    license
    A
    quality
    B
    maintenance
    Enables AI assistants to query live football data, including fixtures, live scores, standings, statistics, betting odds, and full odds movement history for corner and card lines.
    11
    506
    MIT
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Every tool targets a distinct retrieval mode: answer for direct questions, search for candidate discovery, get_entity for a single object, get_related for graph neighbours, get_topic for tag browsing, get_latest for freshness, get_sources for citations, and get_overview for corpus-level context. The descriptions also explicitly contrast each tool with the alternatives that might be confused with it.

Naming Consistency4/5

The majority of tools follow a clear get_<noun> pattern (get_entity, get_topic, get_sources, get_overview, get_related, get_latest), and all names are lowercase snake_case. The two query actions, answer and search, break the get_ prefix pattern slightly, but they are intentionally different entry-point verbs rather than resource fetches.

Tool Count5/5

Eight tools is well within the ideal range for a knowledge-graph query server. Each tool covers a distinct aspect of corpus exploration without feeling redundant or bloated.

Completeness5/5

The server covers the full read-only workflow for a football knowledge atlas: corpus overview, freshness, full-text search, direct question answering, entity lookup, relation traversal, topic browsing, and source verification. Gaps like create/update/delete are not needed for this domain, and the descriptions deliberately handle misses with near-miss suggestions.

Resources