Skip to main content
Glama

Football Atlas

by app.futbolatlas
OverviewDiscussionsAdmin

Server Details

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

Ownership verified
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL
Repository
citarium/futbolatlas-mcp
GitHub Stars
0
Server Listing
Football Atlas

TDQS

A4.5/5.0

Scored across 9 tools

Disambiguation5/5

Each tool occupies a distinct query mode — question answering (answer), keyword search (search), id lookup (get_entity), tag browsing (get_topic), graph traversal (get_related), comparison (compare), and corpus metadata (overview/latest/sources). Every description includes explicit 'use this when...' guidance and cross-references to the alternative tool, so even the close pairs like answer/search and get_topic/search are fully disambiguated.

Naming Consistency4/5

Six of nine tools follow a consistent get_<object> convention (get_entity, get_topic, get_related, get_sources, get_overview, get_latest), and the three bare-verb tools (answer, compare, search) all compute a result rather than fetch a stored object, giving the deviation an internal logic. All names are short, lowercase, verb-initial, and predictable, but the get_/bare-verb split keeps this from a perfect 5.

Tool Count5/5

Nine tools is squarely in the well-scoped range for a knowledge-graph corpus server. Each tool earns its place: search and answer handle question entry, get_entity and get_topic retrieve, get_related traverses the graph, compare handles multi-object queries, and get_overview, get_latest, and get_sources handle orientation, freshness, and source verification. There is no redundancy and no bloat.

Completeness5/5

For a read-only knowledge-graph corpus, the surface is comprehensively covered: get_overview orients the agent, search/answer handle question entry, get_entity gets details, get_topic/get_related expand outward, compare handles multi-object queries, and get_sources/get_latest provide verification and freshness. Dead ends are designed out — unknown ids return near-miss suggestions, unknown tags return existing topics, and refusals explain missing coverage.

Available Tools

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

Answer a question from the corpus, or refuse. Returns only the claims that bear on the question, each with the sources it cites and its editorial confidence. When the corpus cannot answer, answered is false and abstention_reason plus missing_topics say what was not covered — a refusal is a real result here, not an error. 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
marginNoRelative gap between the best candidate and the runner-up. A small margin means the corpus cannot tell them apart.
answeredYes
coverageNoShare of the question's information the winning object accounts for, weighted by term rarity.
candidatesYesNear misses, so a refusal is still a lead. Present whether or not the question was answered.
match_scoreNo
matched_fieldsNo
missing_topicsYesMeaningful words in the question that appear nowhere in the winning object — the gap, named.
match_thresholdYesThe coverage this corpus requires before it will answer at all.
match_confidenceNoHow well the answer fits the QUESTION — retrieval confidence, not editorial. Never confuse it with a claim's own confidence, which is how much the corpus stands behind the statement.
matched_questionNoThe stored question this was matched to, when the answer came from one.
abstention_reasonNoWhy the corpus declined: empty_query, no_candidates, below_coverage, ambiguous_candidates or no_intent_match.

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond the annotations by explaining the refusal behavior, the abstention fields (answered false, abstention_reason, missing_topics), and that a refusal is a valid result rather than an error. This clarifies important non-obvious behavior without contradicting any 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 concise, front-loaded with the core behavior, and every sentence adds value: the primary function, the return semantics, the refusal outcome, and the routing guidance versus search. 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 single-parameter tool with an output schema and clear annotations, the description is fully complete. It covers what to return, how refusal is signaled, and when to choose this tool over a sibling, leaving no critical gap for the agent.

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 the single parameter already described as 'The question to answer, in the words the user asked it.' The description reinforces the 'in words' phrasing but does not add substantial new parameter meaning beyond the 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 opens with a specific verb and resource: 'Answer a question from the corpus, or refuse.' It also differentiates from the search sibling by stating when this tool is appropriate versus search, making the purpose easy to distinguish.

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 usage guidance is provided: 'Use this when the user asked a question in words; use search when you want to see the candidates yourself.' This names the alternative and gives a clear selection condition.

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

compareCompare Football Atlas objects side by sideA
Read-onlyIdempotent
Inspect

Two to six knowledge objects side by side: their cards, every indexed attribute as a matrix (the same fields api/index.json publishes, null where an object does not say), the tags they share, the relations that run between them, the neighbours they have in common, and each one's claims with sources and confidence. Use this when the question is 'X vs Y', 'is X the same as Y' or 'how does X differ from Y' — search or get_topic first if you only have names, then pass the ids. An unknown id lands in missing with a near-miss suggestion and the rest are still compared.

ParametersJSON Schema
NameRequiredDescriptionDefault
idsYesTwo to six knowledge object ids, as returned by search, get_topic or get_related, in the order you want the columns.

Output Schema

ParametersJSON Schema
NameRequiredDescription
foundYesTrue only when every id resolved.
claimsYesEvery compared object's claims, keyed by object id.
facetsYes
missingYesThe ids that resolved to nothing, in the order asked.
objectsYes
recoveryNo
shared_tagsYes
relations_betweenYes
shared_neighboursYes

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds valuable behavioral context beyond those flags: unknown ids land in a `missing` field, a near-miss suggestion is provided, and the remaining objects are still compared. It also explains that missing attributes appear as null in the matrix. This is meaningful behavior an agent could not infer from annotations or schema alone.

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 dense and well-organized. The core function is front-loaded, followed by when-to-use guidance, and then the edge-case behavior for missing ids. Every sentence contributes substantive information; the length is justified by the complexity of the comparison output. It could be slightly more concise, but it is not padded.

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 comparison tool taking 2–6 ids, the description covers the input contract, the full output shape, the intended question types, the prerequisite lookup workflow, and the failure mode for unknown ids. An output schema exists to handle formal return-value details, so the description need not list every field. The combination of annotations, schema, and description leaves no critical gap for an agent deciding to call this 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%: the `ids` parameter is described as 'Two to six knowledge object ids, as returned by search, get_topic or get_related, in the order you want the columns.' The tool description only says 'pass the ids' and repeats the two-to-six range, adding no new meaning. Baseline 3 is appropriate because the schema carries the parameter semantics.

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 ('Compare') and resource ('Football Atlas knowledge objects') and gives a detailed inventory of what is produced: cards, attribute matrices, shared tags, inter-object relations, common neighbours, and claims with sources and confidence. It is clearly distinct from get_entity (single entity) and search (find by name), so an agent can tell it apart from siblings 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use it: for questions like 'X vs Y', 'is X the same as Y', or 'how does X differ from Y'. It also gives a concrete prerequisite workflow: use search or get_topic first if you only have names, then pass the ids. It stops short of enumerating when-not-to-use alternatives such as get_entity or get_related, but the guidance is clear enough to route an agent correctly.

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 convey read-only, idempotent, non-destructive behavior; the description adds value by disclosing the return structure (claims and cited sources) and the near-miss retry behavior for unknown ids. There is no mention of rate limits or auth, but these are less relevant given the 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 first sentence states the function and the second gives actionable retry guidance. It is front-loaded and every clause adds information.

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 one fully-documented parameter, a rich output schema, and annotations covering the safety profile, the description covers the essential usage flow and even handles the error case. Nothing an agent needs to call it 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?

Schema coverage is 100%, and the schema's description of the id parameter explicitly states its provenance and the canonical URL segment. The description adds no further parameter-level detail, so the 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?

The description opens with a specific verb and resource: 'Fetch one knowledge object by id', and specifies what is included (claims and the sources each claim cites). This clearly distinguishes it from sibling tools like get_topic and get_related, which center on different or broader scopes.

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 provides explicit sequencing guidance: 'Use this once search, answer or get_topic has given you an id.' This establishes the correct workflow context, though it does not name alternative tools to use for other situations or explicitly 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_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 declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context: results are ranked by verification date and are topic-independent. It does not contradict annotations and adds meaningful ordering/scope semantics.

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 with no filler: the core behavior, use cases, and exclusions are all front-loaded and clearly separated. 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?

The tool is simple, has one fully documented optional parameter, robust annotations, and an output schema. The description also names relevant sibling alternatives, so an agent has everything needed to select and 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?

Schema description coverage is 100%, and the limit parameter is already fully documented with range, default, and ordering ('newest verification first'). The description reinforces the ordering behavior but does not add substantial meaning beyond the 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?

States a specific verb and resource ('Most recently verified knowledge objects') and identifies it as a 'freshness signal'. It clearly distinguishes itself from topic-relevant siblings by saying it 'ignores your topic entirely.'

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 gives intended use cases: judging corpus currency and seeing what changed. It also names alternatives ('use search or get_topic when you want objects that are relevant rather than recent'), 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_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 source registry — each entry with its evidence tier, reliability and access date. PAGED: 25 entries by default, 200 at most, and a response budget of about 64 KB per call — a page over budget comes back shorter WITH a next_cursor, never truncated. Read next_cursor and call again to continue; its absence means you have the last page. Filter by object_id, tier, host or accessed_since to avoid paging through a registry you do not need. Use this when you need the registry entry behind a citation, or a sample of the whole registry to judge the corpus before trusting it; get_entity already tells you which sources a claim cites.

ParametersJSON Schema
NameRequiredDescriptionDefault
hostNoOnly sources whose URL is served by this host, compared without a leading www. A source with no URL never matches.
tierNoOnly sources of this evidence tier, spelled exactly as get_sources reports it.
limitNoHow many entries to return. Defaults to 25.
cursorNoContinue from a previous call: pass the next_cursor it returned. Opaque; do not construct one.
object_idNoRestrict the answer to the sources cited by this knowledge object. Omit it to page the whole registry.
accessed_sinceNoOnly sources accessed on or after this ISO date (YYYY-MM-DD).

Output Schema

ParametersJSON Schema
NameRequiredDescription
foundYes
totalYesHow many sources matched the filters, before paging.
sourcesYes
recoveryNo
returnedYes
next_cursorNoPass to the next call to continue. ABSENT means this was the last page.

TDQS

A4.7/5.0
Behavior5/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 rich behavior beyond that: paging defaults (25/200), the 64 KB response budget, the non-truncation guarantee, and the cursor semantics ('its absence means you have the last page'). This is exactly the kind of behavioral context an agent needs.

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?

Every sentence earns its place: registry purpose, paging behavior, cursor continuation, filter advice, and use-case routing. The core purpose and scoping constraint are front-loaded before the usage guidance, and there is no filler or repetition of schema content.

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 moderate complexity, the description is complete: paging, budget, cursor, filters, and use cases are all covered, annotations carry the safety profile, and an output schema exists so return values need no explanation. Nothing an agent needs to invoke this 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?

Schema description coverage is 100% and every parameter is well-documented, so the baseline of 3 applies. The description's paging narrative adds mild context to cursor/limit (e.g., 'Read next_cursor and call again to continue'), but it doesn't substantially extend individual 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 identifies the exact resource ('The instance's source registry') and states what each entry contains (evidence tier, reliability, access date). It differentiates from the closest sibling by noting 'get_entity already tells you which sources a claim cites,' so an agent can tell the two apart without inspecting 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?

Provides explicit when-to-use guidance: 'Use this when you need the registry entry behind a citation, or a sample of the whole registry to judge the corpus before trusting it.' It also names the alternative (get_entity) and clarifies the boundary, implicitly telling the agent when NOT to use this tool. Filter advice ('Filter by object_id, tier, host or accessed_since') reinforces appropriate call patterns.

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). PAGED: 25 objects by default, 200 at most, and a response budget of about 64 KB per call — a page over budget comes back shorter WITH a next_cursor, never truncated. Read next_cursor and call again to continue, and its absence means you have the last page. 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.
limitNoHow many objects to return. Defaults to 25.
cursorNoContinue from a previous call: pass the next_cursor it returned. Opaque; do not construct one.

Output Schema

ParametersJSON Schema
NameRequiredDescription
tagYes
totalYesHow many objects carry this tag, before paging.
resultsYes
recoveryNo
returnedYes
next_cursorNoPass to the next call to continue. ABSENT means this was the last page.

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the read-only, idempotent annotations, the description discloses pagination behavior, the next_cursor contract, the 64 KB response budget, the fact that pages are never truncated, and the fallback behavior for unknown tags. This gives an agent strong expectations about how the tool behaves at runtime.

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 and front-loaded: the core definition comes first, followed by pagination, usage routing, and miss behavior. Every sentence contributes distinct value with no filler or repetition.

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 rich annotations, full parameter schema, and existing output schema, the description covers the remaining operational context: pagination mechanics, alternative tool selection, budget limits, and unknown-tag handling. Nothing important 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real parameter-relevant meaning: it explains what the absence of next_cursor means, that pages over budget return shorter with a cursor, and that an unknown tag returns existing topics. This goes beyond the schema's field descriptions.

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 opens with a specific verb and resource: 'List the knowledge objects carrying a tag', and clarifies that topics are content-backed tags. It clearly distinguishes itself from siblings by explaining when to use search and get_overview instead.

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?

The description explicitly says '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.' This is direct, actionable guidance that tells an agent exactly when to select this tool over alternatives.

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.

  1. 1 tool update
    • Changedget_related5 fields changed
      • addedInput schema / properties / cursor
        Added value: +{
+  "description": "Continue from a previous call: pass the next_cursor it returned. Opaque; do not construct one.",
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}
      • addedInput schema / properties / limit
        Added value: +{
+  "description": "How many relations to return, across both directions. Defaults to 25.",
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}
      • addedOutput schema / properties / next_cursor
        Added value: +{
+  "description": "Pass to the next call to continue. ABSENT means this was the last page.",
+  "type": "string"
+}
      • addedOutput schema / properties / returned
        Added value: +{
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
      • addedOutput schema / properties / total
        Added value: +{
+  "description": "How many relations this object has in both directions, before paging.",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
  2. 8 tool updates
    • Changedanswer14 fields changed
      • addedOutput schema / properties / abstention_reason
        Added value: +{
+  "description": "Why the corpus declined: empty_query, no_candidates, below_coverage, ambiguous_candidates or no_intent_match.",
+  "type": "string"
+}
      • addedOutput schema / properties / candidates
        Added value: +{
+  "description": "Near misses, so a refusal is still a lead. Present whether or not the question was answered.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "coverage": {
+        "type": "number"
+      },
+      "id": {
+        "type": "string"
+      },
+      "score": {
+        "type": "number"
+      }
+    },
+    "required": [
+      "id",
+      "score",
+      "coverage"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
      • addedOutput schema / properties / claims / items / properties / relevance
        Added value: +{
+  "type": "number"
+}
      • changedOutput schema / properties / claims / items / required
        Previous value: -[
-  "text",
-  "confidence",
-  "sources"
-]New value: +[
+  "text",
+  "confidence",
+  "sources",
+  "relevance"
+]
      • addedOutput schema / properties / coverage
        Added value: +{
+  "description": "Share of the question's information the winning object accounts for, weighted by term rarity.",
+  "type": "number"
+}
      • addedOutput schema / properties / entity / properties / x
        Added value: +{
+  "additionalProperties": {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  "description": "Indexed instance-specific attributes, grouped by namespace — the same fields api/index.json publishes. Absent when the instance declares none.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}
      • addedOutput schema / properties / margin
        Added value: +{
+  "description": "Relative gap between the best candidate and the runner-up. A small margin means the corpus cannot tell them apart.",
+  "type": "number"
+}
      • addedOutput schema / properties / match_confidence
        Added value: +{
+  "description": "How well the answer fits the QUESTION — retrieval confidence, not editorial. Never confuse it with a claim's own confidence, which is how much the corpus stands behind the statement.",
+  "type": "number"
+}
      • addedOutput schema / properties / match_score
        Added value: +{
+  "type": "number"
+}
      • addedOutput schema / properties / match_threshold
        Added value: +{
+  "description": "The coverage this corpus requires before it will answer at all.",
+  "type": "number"
+}
      • addedOutput schema / properties / matched_fields
        Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
      • addedOutput schema / properties / matched_question / description
        Added value: +"The stored question this was matched to, when the answer came from one."
      • addedOutput schema / properties / missing_topics
        Added value: +{
+  "description": "Meaningful words in the question that appear nowhere in the winning object — the gap, named.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
      • changedOutput schema / required
        Previous value: -[
-  "answered"
-]New value: +[
+  "answered",
+  "match_threshold",
+  "missing_topics",
+  "candidates"
+]
    • Addedcompare
    • Changedget_entity1 field changed
      • addedOutput schema / properties / entity / properties / x
        Added value: +{
+  "additionalProperties": {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  "description": "Indexed instance-specific attributes, grouped by namespace — the same fields api/index.json publishes. Absent when the instance declares none.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}
    • Changedget_latest1 field changed
      • addedOutput schema / properties / results / items / properties / x
        Added value: +{
+  "additionalProperties": {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  "description": "Indexed instance-specific attributes, grouped by namespace — the same fields api/index.json publishes. Absent when the instance declares none.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}
    • Changedget_related2 fields changed
      • addedOutput schema / properties / incoming / items / properties / entity / properties / x
        Added value: +{
+  "additionalProperties": {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  "description": "Indexed instance-specific attributes, grouped by namespace — the same fields api/index.json publishes. Absent when the instance declares none.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}
      • addedOutput schema / properties / outgoing / items / properties / entity / properties / x
        Added value: +{
+  "additionalProperties": {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  "description": "Indexed instance-specific attributes, grouped by namespace — the same fields api/index.json publishes. Absent when the instance declares none.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}
    • Changedget_sources10 fields changed
      • addedInput schema / properties / accessed_since
        Added value: +{
+  "description": "Only sources accessed on or after this ISO date (YYYY-MM-DD).",
+  "maxLength": 10,
+  "minLength": 4,
+  "type": "string"
+}
      • addedInput schema / properties / cursor
        Added value: +{
+  "description": "Continue from a previous call: pass the next_cursor it returned. Opaque; do not construct one.",
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}
      • addedInput schema / properties / host
        Added value: +{
+  "description": "Only sources whose URL is served by this host, compared without a leading www. A source with no URL never matches.",
+  "maxLength": 120,
+  "minLength": 1,
+  "type": "string"
+}
      • addedInput schema / properties / limit
        Added value: +{
+  "description": "How many entries to return. Defaults to 25.",
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}
      • changedInput schema / properties / object_id / description
        Previous value: -"Restrict the answer to the sources cited by this knowledge object. Omit it to get the instance's whole source registry."New value: +"Restrict the answer to the sources cited by this knowledge object. Omit it to page the whole registry."
      • addedInput schema / properties / tier
        Added value: +{
+  "description": "Only sources of this evidence tier, spelled exactly as get_sources reports it.",
+  "maxLength": 60,
+  "minLength": 1,
+  "type": "string"
+}
      • addedOutput schema / properties / next_cursor
        Added value: +{
+  "description": "Pass to the next call to continue. ABSENT means this was the last page.",
+  "type": "string"
+}
      • addedOutput schema / properties / returned
        Added value: +{
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
      • addedOutput schema / properties / total
        Added value: +{
+  "description": "How many sources matched the filters, before paging.",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
      • changedOutput schema / required
        Previous value: -[
-  "found",
-  "sources"
-]New value: +[
+  "found",
+  "sources",
+  "total",
+  "returned"
+]
    • Changedget_topic7 fields changed
      • addedInput schema / properties / cursor
        Added value: +{
+  "description": "Continue from a previous call: pass the next_cursor it returned. Opaque; do not construct one.",
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}
      • addedInput schema / properties / limit
        Added value: +{
+  "description": "How many objects to return. Defaults to 25.",
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}
      • addedOutput schema / properties / next_cursor
        Added value: +{
+  "description": "Pass to the next call to continue. ABSENT means this was the last page.",
+  "type": "string"
+}
      • addedOutput schema / properties / results / items / properties / x
        Added value: +{
+  "additionalProperties": {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  "description": "Indexed instance-specific attributes, grouped by namespace — the same fields api/index.json publishes. Absent when the instance declares none.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}
      • addedOutput schema / properties / returned
        Added value: +{
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
      • addedOutput schema / properties / total / description
        Added value: +"How many objects carry this tag, before paging."
      • changedOutput schema / required
        Previous value: -[
-  "tag",
-  "results",
-  "total"
-]New value: +[
+  "tag",
+  "results",
+  "total",
+  "returned"
+]
    • Changedsearch5 fields changed
      • addedOutput schema / properties / results / items / properties / coverage
        Added value: +{
+  "description": "Share of the question's information this object accounts for, weighted by term rarity. 1 means every meaningful word in the query is present; a low value with a high score means the object matched common words only.",
+  "type": "number"
+}
      • changedOutput schema / properties / results / items / properties / matched_fields / description
        Previous value: -"Which fields the query hit: name, tags, content. Does NOT determine the score on its own."New value: +"Which fields the query hit: name, tags, questions, summary, claims. Does NOT determine the score on its own."
      • changedOutput schema / properties / results / items / properties / score / description
        Previous 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."New value: +"BM25 relevance: each query term is weighted by how RARE it is in this corpus and by where it hits (name 3, tags 2, questions 2, body 1). A hit must also cover a minimum share of the question's information, measured in the same rarity weights — matching only common words does not qualify. Centrality (how many objects point at this one) breaks TIES ONLY and is never part of the score, so it cannot make an irrelevant object rank. Two hits with the same matched_fields can still differ: the score is rarity-weighted, so matching a rare term is worth more than matching a common one."
      • addedOutput schema / properties / results / items / properties / x
        Added value: +{
+  "additionalProperties": {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  "description": "Indexed instance-specific attributes, grouped by namespace — the same fields api/index.json publishes. Absent when the instance declares none.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}
      • changedOutput schema / properties / results / items / required
        Previous value: -[
-  "id",
-  "type",
-  "name",
-  "summary",
-  "tags",
-  "evidence_tier",
-  "confidence",
-  "last_verified",
-  "canonical_url",
-  "api_url",
-  "score",
-  "matched_fields"
-]New value: +[
+  "id",
+  "type",
+  "name",
+  "summary",
+  "tags",
+  "evidence_tier",
+  "confidence",
+  "last_verified",
+  "canonical_url",
+  "api_url",
+  "score",
+  "matched_fields",
+  "coverage"
+]
  3. 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."
  4. 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"
+}
  5. 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

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.

Resources