Spain's contributions to world science, exploration and culture, rigorously sourced
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 8 of 8 tools scored. Lowest: 3.9/5.
answer and search both retrieve corpus knowledge but at different levels: answer directly returns a matched object with sources, while search returns ranked hits for follow-up. get_entity and get_related are also distinct. Minor overlap between search and answer is delineated by their descriptions.
Naming mixes a get_* prefix with bare verbs (search, answer) and uses get_latest, where 'latest' is an adjective, not a noun. The pattern is readable but not fully consistent.
8 tools in a knowledge graph covering search, entity resolution, relation traversal, sources, topics and freshness is well-scoped for a simple read-only kurplat. Count is neither excessive nor minimal.
Core retrieval operations exist: search, entity claims, related relations, sources, overview/topics, and freshness. Missing creation/update operations appear intentional if the source is externally maintained, but no direct way to iterate all entities is a minor gap.
answerAnswer a question about Hispanic LegacyAAnswer 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.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes |
| Name | Required | Description |
|---|---|---|
| claims | No | |
| entity | No | |
| answered | Yes | |
| matched_question | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive behavior. The description goes beyond by revealing the return shape ('claims with sources and confidence') and a policy ('never an unsourced answer'), which helps set expectations for the agent. It does not address edge cases like insufficient confidence, but the annotations lower the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying distinct value: purpose, behavioral guarantee, and usage routing. Information is front-loaded and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with rich annotations and an output schema present, the description covers purpose, behavior, and usage alternatives. Nothing critical is missing for an agent 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning to the single 'question' parameter, and it does: it frames the parameter as a natural-language question ('when the user asked a question in words') rather than a keyword search. This is the key semantic the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Answer a question from the corpus') and differentiates itself from the sibling search tool. It also specifies the output nature ('matched object's claims with sources and confidence'), which makes the tool's role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: 'Use this when the user asked a question in words', and contrasts it with an alternative: 'use search when you want to see the candidates yourself'. This is clear conditional routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_entityGet one Hispanic Legacy knowledge objectAFetch 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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| entity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only, idempotent, non-destructive behavior. The description adds non-obvious compositional detail about nested claims and cited sources, plus the expected id source. This adds value 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core action and return composition are front-loaded, and the usage instruction is compactly appended.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup with one parameter and a rich output schema, the description is complete. It covers what is returned and when to call it, while annotations handle safety and idempotency and the output schema handles return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the meaning. It does so by explaining that id selects a knowledge object and can be obtained from search, answer, or get_topic. With only one self-explanatory parameter, this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Fetch'), a specific resource ('one knowledge object by id'), and clarifies the return content ('claims and the sources each claim cites'). This clearly distinguishes it from sibling tools like get_sources or get_related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent to use the tool after search, answer, or get_topic has produced an id, giving clear contextual guidance. It does not explicitly list exclusions or alternatives, so it stops 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_latestLatest verified Hispanic Legacy objectsAMost 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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds a meaningful usage frame ('freshness signal', 'what changed') but does not disclose additional behaviors such as ordering guarantees or whether read state is tracked. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core definition front-loaded and a practical use case following. Every word earns its place; no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with an output schema and strong annotations, the description provides sufficient context. The phrase 'since you last read it' is slightly ambiguous about statefulness, but overall the agent can select and call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, limit, but the description does not mention it at all. Schema description coverage is 0%, so the description was expected to compensate; the schema's property name and constraints carry the meaning, but the description adds no parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('most recently verified knowledge objects') and its role as a freshness signal, which distinguishes it from the sibling lookup/search tools. The verb 'get' plus the title make the operation unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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: to judge corpus currency or see what changed since last read. It does not provide exclusions or name alternative tools, but the context is clear enough for a simple read operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_overviewOverview of Hispanic LegacyACorpus 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tags | Yes | |
| by_type | Yes | |
| instance | Yes | |
| description | Yes | |
| total_objects | Yes | |
| newest_verification | Yes | |
| oldest_verification | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds meaningful behavioral context by disclosing the tool's scope: what the instance knows, counts by type, published tags, and freshness, plus its intended first-stop usage. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, the first front-loading the tool's purpose and core content, the second giving actionable usage guidance. Every clause carries information and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, zero-parameter tool with an output schema present, the description is complete. It tells the agent what information is available, when to invoke it, and the annotations cover the safety and idempotency profile. No critical missing context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter documentation burden on the description. Schema coverage is trivially complete, and the description appropriately focuses on output content rather than arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a corpus overview, specifying that it provides what the instance knows, counts by type, published tags, and freshness. The name and title align with this, and the content distinguishes it from singular lookup tools like get_entity or search, though it does not explicitly name those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The guidance is explicit: 'Use this first when you land here and do not yet know whether this corpus can answer your question.' This clearly communicates the intended when-to-use scenario. It implies not using it once you know the corpus can answer, but it does not explicitly name alternatives or describe when to skip this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sourcesSources behind Hispanic LegacyAThe instance's whole source registry, or just the sources cited by one object. Use this to check what a claim rests on, or to judge the corpus before trusting it.
| Name | Required | Description | Default |
|---|---|---|---|
| object_id | No |
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| sources | Yes |
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 the conditional behavior around optional object_id (whole registry vs one object's sources), but it does not disclose potential size, pagination, or how results are ordered — minor gaps for this simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the functional behavior is front-loaded and the usage rationale follows immediately. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool with an output schema present, the description covers the main behavioral distinction and provides clear use cases. It does not discuss edge cases like extremely large source registries, but nothing essential for invoking the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description is the only source of parameter meaning. It maps object_id to choosing 'sources cited by one object' and implies omitting it returns the whole registry. It could be more explicit about the ID format, but the optional single parameter is adequately explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the instance's source registry and distinguishes the two main modes (whole registry vs sources cited by one object). It lacks an explicit retrieval verb, but 'Use this to check' makes the operation clear and differentiates it from sibling tools like get_entity, get_related, and search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete use cases: verifying what a claim rests on and judging corpus trustworthiness. It does not explicitly name alternative tools or exclusion conditions, but the contexts are specific enough for an agent to decide when get_sources is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_topicBrowse Hispanic Legacy by topicAList 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.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes |
| Name | Required | Description |
|---|---|---|
| tag | Yes | |
| total | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar for additional disclosure is lower. The description adds useful context that topics are content-backed tags, clarifying the tool's domain without contradicting 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core action ('List the knowledge objects carrying a tag'), and packs usage guidance into the second sentence with no wasted words. Perfectly sized and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one simple parameter, an output schema, and no nested objects, the description covers the essentials: what it does, when to use it, and how to find alternatives. Nothing critical is missing for a call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema for the single 'tag' parameter has no description (0% coverage), so the description carries the burden. It indicates that the parameter is a topic/tag and points to get_overview as the way to discover valid tags, adding semantic meaning beyond the bare schema type constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List the knowledge objects carrying a tag', which specifies a clear verb and resource. It also differentiates the tool from siblings by referencing search and get_overview, making the distinct purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Use this to browse a known topic' and contrasts with 'use search when you have a question rather than a tag, and get_overview to see which tags exist.' This gives direct when-to-use guidance and names the alternative tools, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch Hispanic LegacyAFull-text search over the knowledge graph. Matching ignores accents and apostrophes, so query in the user's own words; every hit carries its relevance score and the fields it matched. Use this whenever you have a question rather than an id, then follow up with get_entity.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, idempotent, non-destructive), the description discloses meaningful behavior: matching "ignores accents and apostrophes," and every hit carries "its relevance score and the fields it matched." This adds genuinely useful operational context that the annotations and schema do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first states the core operation, the second adds matching behavior, and the third provides usage and follow-up guidance. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter schema, rich annotations, and an output schema, the description covers everything needed for correct selection and invocation: scope, matching behavior, result contents, and when to use it. No critical guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden for parameter meaning. It compensates for the required query parameter with actionable guidance: query in the user's own words, since accents and apostrophes are ignored. The limit parameter is not mentioned, but its default, min, and max are already fully expressed in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Full-text search over the knowledge graph" names a specific verb, resource, and operation, and the distinction from id-based retrieval is clear: "Use this whenever you have a question rather than an id, then follow up with get_entity." This lets an agent differentiate search from its siblings 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.
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 whenever you have a question rather than an id," and even gives the recommended follow-up action with get_entity. This is direct usage guidance rather than inferred context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.