A
licenseNot graded
qualityB
maintenanceAn observable autonomy harness for AI coding agents that enables long task execution without drift or cheating, while recording all actions for cost and quality steering.
MIT
Agent Reliability
Server Details
Testing, benchmarking and auditing autonomous AI agents — methods, harnesses, evidence
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/agentreliability-mcp
- GitHub Stars
- 0
- Server Listing
- Agent Reliability MCP server
Available Tools
8 toolsanswerAnswer a question about Agent ReliabilityARead-onlyIdempotentInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The question to answer, in the words the user asked it. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| claims | No | |
| entity | No | |
| answered | Yes | |
| matched_question | No |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as read-only, idempotent, and non-destructive. The description adds meaningful behavioral guarantees beyond those annotations: it returns claims with sources and confidence, and explicitly states it 'never' returns an unsourced answer. 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 efficient sentences: the first states the action and output guarantee, the second provides routing guidance. Every sentence earns its place 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?
With one well-described parameter, an output schema, clear annotations, and explicit sibling differentiation, the description is complete for an agent to select and invoke the tool correctly. No critical behavioral or usage detail 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% for the single parameter, so the baseline is 3. The description adds value by instructing the agent to use the question 'in the words the user asked it,' which preserves important original phrasing and prevents paraphrasing. This is useful semantic guidance 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 states a specific action ('Answer a question from the corpus') and clearly specifies the output ('matched object's claims with sources and confidence'). It distinguishes itself from the 'search' sibling by positioning this as the direct-answer tool while search shows 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 tells the agent when to use this tool ('when the user asked a question in words') and when to use the alternative ('use search when you want to see the candidates yourself'). This removes ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_entityGet one Agent Reliability knowledge objectARead-onlyIdempotentInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The 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
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| entity | No | |
| recovery | No |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds a useful behavioral trait: an unknown id is not a dead end, and the answer provides near-miss ids to retry. This exceeds what annotations convey.
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 action, followed by a clear usage condition and a helpful edge-case note. No waste; every clause 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 description tells the agent what the tool returns, when to call it, and how to recover from an unknown id. The output schema covers the return shape, so nothing critical is missing for a one-parameter read-only 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 coverage is 100%, and the schema already explains the id parameter including how to obtain it and the canonical URL hint. The description merely says 'by id' and adds an error-recovery note for unknown ids, which adds little semantic detail 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: 'Fetch one knowledge object by id', and names the payload ('with its claims and the sources each claim cites'). It also implicitly distinguishes from siblings by noting when it applies ('Use this once search, answer or get_topic has given you an id'), making it clear this is the targeted retrieval step.
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 the tool: 'Use this once search, answer or get_topic has given you an id.' It gives clear context, though it doesn't explicitly list when not to use it or name a sibling alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_latestLatest verified Agent Reliability objectsARead-onlyIdempotentInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many recently verified objects to return, newest verification first. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| results | Yes |
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, covering safety. The description adds behavioral context beyond annotations by specifying the ordering logic (by verification date) and the fact that topic is ignored. This helps the agent understand what to expect from the results.
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 long with no wasted words. It front-loads the core purpose and freshness signal, then immediately covers use cases and exclusions. 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?
Given the single optional parameter, output schema presence, rich annotations, and sibling tool context, this description is complete. It explains what the tool returns, how results are ordered, when to use it, and when to use alternatives. Nothing essential 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%, so the single 'limit' parameter is already fully documented. The description reinforces the recency/verification-date concept but does not add substantial meaning beyond the schema. Baseline 3 is appropriate given the schema handles 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 uses a specific verb and resource: 'Most recently verified knowledge objects' ranked by verification date. It explicitly distinguishes itself from search and get_topic by noting it ignores topic relevance entirely. This makes the tool's purpose unambiguous and easily differentiated from siblings.
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 provides explicit use cases: judge corpus currency or see what changed since last read. It also gives a clear when-not-to-use instruction, directing agents to search or get_topic for relevance-based retrieval. This is strong guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_overviewOverview of Agent ReliabilityARead-onlyIdempotentInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| tags | Yes | |
| by_type | Yes | |
| instance | Yes | |
| description | Yes | |
| total_media | Yes | |
| total_objects | Yes | |
| newest_verification | Yes | |
| oldest_verification | Yes |
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, non-destructive behavior. The description adds useful context about the tool's role as a preliminary orientation step and discloses the nature of its outputs (counts, tags, freshness), which goes beyond the annotations 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?
Two sentences, no fluff. The first sentence front-loads the tool's content and scope, and the second immediately gives actionable usage guidance. Every word 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?
For a parameterless overview tool with a rich output schema and safety-oriented annotations, the description fully covers purpose, usage, and context. Nothing essential is missing for an agent to decide when to invoke it.
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 input schema has zero parameters, so parameter semantics are not applicable. Per the rubric, a 0-parameter tool receives a baseline of 4; the description appropriately focuses on the tool's output rather than parameters.
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 resource ('Corpus overview') and the specific content returned: counts by type, published tags, freshness. It distinguishes itself from siblings by positioning this as the first-stop tool for assessing corpus knowledge, which separates it from query tools like answer or search.
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 gives explicit when-to-use guidance: 'Use this first when you land here and do not yet know whether this corpus can answer your question.' It implies when not to use it (when you already know the corpus can answer), but it does not explicitly name alternatives or exclusion conditions, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sourcesSources behind Agent ReliabilityARead-onlyIdempotentInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
| object_id | No | Restrict the answer to the sources cited by this knowledge object. Omit it to get the instance's whole source registry. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| sources | Yes | |
| recovery | No |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already show readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context about what the returned entries contain (evidence tier, reliability, access date) and that omitting the parameter returns the full registry, which goes beyond 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, front-loads the core behavior and return contents, and includes the usage guidance and sibling differentiation without any filler. 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?
Given a single optional parameter, rich annotations, and an output schema, the description fully equips an agent to invoke the tool correctly. It clarifies the default behavior, what data to expect, and when to choose the tool over a sibling, so nothing essential 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 input schema already documents object_id completely, including its optionality and semantics, and schema description coverage is 100%. The description restates the omit-to-get-whole-registry behavior but does not add meaning beyond what the schema already provides, 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 exactly what the tool returns: the source registry, optionally restricted to sources cited by one object, with evidence tier, reliability, and access date. It clearly distinguishes itself from get_entity by noting that get_entity already reports which sources a claim cites, so an agent can tell the tools apart.
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 when to use this tool: when you need the registry entry behind a citation, or when you want the whole registry to judge the corpus before trusting it. It also names the relevant sibling alternative, get_entity, and explains how that other tool differs, giving 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 Agent Reliability by topicARead-onlyIdempotentInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| tag | Yes | |
| total | Yes | |
| results | Yes | |
| recovery | No |
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, and non-destructive behavior, so the bar is lower. The description adds valuable non-obvious edge-case behavior: an unknown tag returns the topics that do exist, so a miss still yields useful output. It also clarifies that an empty answer means the topic does not exist, which complements the read-only trust profile.
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 wasted words: action and scope first, then routing guidance, then the unknown-tag fallback behavior. 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?
For a single-parameter, read-only tool with a rich parameter description, safety annotations, and an output schema, the description fully covers purpose, when-to-use, and edge-case behavior. Nothing an agent needs to select and invoke this 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?
Schema description coverage is 100%, and the tag parameter's schema description already explains exact spelling requirements and the empty-answer meaning. The tool description adds usage context ('browse a known topic') but no additional parameter-format details, so the baseline 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?
States a specific verb ('List') and resource ('knowledge objects') filtered by a tag, with the clarifying note that topics are content-backed tags. Explicitly distinguishes this tool from search and get_overview, so an agent can identify it correctly 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?
Provides explicit guidance: use this to browse a known topic, use search for question-based queries, and use get_overview to enumerate existing tags. This fully routes the agent among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch Agent ReliabilityARead-onlyIdempotentInspect
Full-text search over the knowledge graph. Matching ignores accents and apostrophes, so query in the user's own words; every hit carries the fields it matched and a score. 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. Use this whenever you have a question rather than an id, then follow up with get_entity.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many ranked hits to return, best first. | |
| query | Yes | 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é'. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| results | Yes |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds substantial context: accent/apostrophe matching, per-field token weights, the centrality bonus, and why identical matched_fields can yield different scores. This goes well beyond what annotations provide.
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 dense but every sentence earns its place: purpose, matching behavior, scoring mechanics, and usage guidance are all present without redundancy. The critical usage guidance is placed near the end but clearly stated, and the overall length is appropriate for the tool's complexity.
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 search tool with an output schema and only two well-documented parameters, the description is fully sufficient. It explains how queries are matched, how results are ranked, what the score means, and when to use the tool, leaving no significant gap for an agent to call it incorrectly.
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. The description adds useful nuance about querying in the user's own words and how hits are scored, and it reinforces the accent-ignoring behavior already present in the schema. It enriches the query semantics without needing to restate the full 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 ('Full-text search over the knowledge graph') and separates itself from id-based lookup by telling the agent to use it when there is a question rather than an id. This clearly distinguishes it from siblings like get_entity.
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 this tool: 'Use this whenever you have a question rather than an id', and even names the follow-up tool get_entity. This is direct, actionable guidance that leaves no ambiguity about the primary use case.
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.
8 tool updates
- Changed
answer1 field changed- added
Input schema / properties / question / descriptionAdded value: +"The question to answer, in the words the user asked it."
- Changed
get_entity3 fields changed- added
Input schema / properties / id / descriptionAdded value: +"The knowledge object's id, as returned by search, answer, get_topic or get_related — the last segment of its canonical URL." - added
Output schema / properties / entity / properties / mediaAdded 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" +} - changed
Output schema / properties / entity / requiredPrevious 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" +]
- Changed
get_latest1 field changed- added
Input schema / properties / limit / descriptionAdded value: +"How many recently verified objects to return, newest verification first."
- Changed
get_overview2 fields changed- added
Output schema / properties / total_mediaAdded value: +{ + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" +} - changed
Output schema / requiredPrevious 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" +]
- Changed
get_related1 field changed- added
Input schema / properties / id / descriptionAdded value: +"The knowledge object to walk out from, by id."
- Changed
get_sources1 field changed- added
Input schema / properties / object_id / descriptionAdded value: +"Restrict the answer to the sources cited by this knowledge object. Omit it to get the instance's whole source registry."
- Changed
get_topic1 field changed- added
Input schema / properties / tag / descriptionAdded 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."
- Changed
search4 fields changed- added
Input schema / properties / limit / descriptionAdded value: +"How many ranked hits to return, best first." - added
Input schema / properties / query / descriptionAdded 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é'." - added
Output schema / properties / results / items / properties / matched_fields / descriptionAdded value: +"Which fields the query hit: name, tags, content. Does NOT determine the score on its own." - added
Output schema / properties / results / items / properties / score / descriptionAdded 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 tool updates
- Changed
get_entity1 field changed- added
Output schema / properties / recoveryAdded 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" +}
- Changed
get_related1 field changed- added
Output schema / properties / recoveryAdded 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" +}
- Changed
get_sources1 field changed- added
Output schema / properties / recoveryAdded 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" +}
- Changed
get_topic1 field changed- added
Output schema / properties / recoveryAdded 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" +}
8 tool updates
- First observed
answer - First observed
get_entity - First observed
get_latest - First observed
get_overview - First observed
get_related - First observed
get_sources - First observed
get_topic - First observed
search
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
Decision-assurance for AI agents: an auditable action boundary + receipt before it acts.
MERCATOR Verify: evidence-backed verification and decision support for autonomous agents.
Six-gate governance for AI agents: PROCEED/PAUSE/HALT decisions with hash-chained audit trails.
Reproducible benchmarks and reliability evidence for agent tools.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceLocal security layer for AI coding agents: MCP policy proxy, kernel sandbox, tamper-evident audit logMIT
- AlicenseNot gradedqualityDmaintenanceVerifiable action receipts for AI agents — agents sign claims locally, an independent witness countersigns and timestamps, anyone can verify offline.14MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to conduct evidence-grounded forensic triage of compromised hosts, with architectural safeguards against evidence spoliation and hallucinated findings, supporting self-correction and chain of custody.MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.6/5.0
Disambiguation5/5
Each tool targets a distinct retrieval mode: question answering, text search, entity fetch, topic browse, related traversal, source inspection, freshness, and corpus overview. The descriptions explicitly contrast overlapping pairs like answer vs search and get_topic vs search, so an agent can reliably choose.
Naming Consistency4/5
The dominant get_<noun> pattern is clear and consistent for six of eight tools, while answer and search are plain verbs that still convey their action. This is a minor deviation rather than a mixed convention.
Tool Count5/5
Eight tools is well within the ideal range for a knowledge-corpus query server. Each tool covers a distinct retrieval need with no redundancy or bloat.
Completeness5/5
The read-side lifecycle is complete: discover via overview, search, answer, topic, and latest; drill in via entity and related; and verify via sources. The descriptions explicitly handle misses with near-miss ids and existing topics, so agents are not left at dead ends.