Grounded, citable access to declassified UAP/UFO government records — 13,929 documents from Project Blue Book, the FBI Vault and national-archive releases, with extracted PDF text, plus 28,314 geocoded sighting records drawn from the US National Archives, the UK National Archives, France's CNES/GEIPAN and the Hatch catalogue. Offers both keyword and embedding-based semantic search, cross-links between commentary and the primary sources behind it, and reported-entity profiles where every claim carries a citation into the archive. All 14 tools are read-only, and every result returns the URL of the record it came from, so an agent's answer can be checked against the original rather than taken on trust. Free tier: 50 calls per day, no card required.
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 3.7/5 across 14 of 14 tools scored. Lowest: 2.6/5.
Each tool targets a distinct resource and operation: get/list for singular/plural fetches, search for queries, and related for cross-links. The two related tools are clearly inverses, and the four search tools are differentiated by collection and query type (full-text, semantic, sighting-specific, video-specific). No tools appear to do the same thing.
Most tools follow a verb_noun pattern with get_, list_, and search_, but 'related_commentary' and 'related_documents' use a non-verb prefix and are inconsistently singular/plural. 'search_semantic' also uses an adjective instead of a noun, breaking the pattern. Overall the naming is readable but not uniformly structured.
14 tools is well within the ideal range for an archive server covering multiple resource types (beings, documents, news, sightings, videos) and their relationships. Each tool serves a distinct purpose, and the count is appropriate for the domain without being overwhelming.
The tool set provides comprehensive retrieval coverage: getters for all entities, listers for beings and news, search across all collections, and relationship navigation. The main gap is the lack of a list_all documents or videos, but this is a minor workaround since search functions can fulfill enumeration needs. Overall the archive's core workflows are well-supported.
get_beingAInspectFetch one entity profile with its full cited references ledger. Every claim in the profile is backed by a citation into the document or sighting archive.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It adds value by mentioning that every claim is backed by a citation, and the word 'fetch' implies a read-only operation. However, it does not specify whether authentication is required, how large the response might be, or whether it can fail for missing slugs, leaving gaps in transparency.
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-loaded with the primary action, and contains no extraneous words. Every sentence earns its place: the first defines the operation, the second clarifies the citation guarantee.
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 fetch tool with one parameter and no output schema, the description covers the core functionality but omits details about the response structure and how the slug maps to a specific being. Given the existing sibling tools and lack of annotations, the description is adequate but leaves some contextual gaps, especially regarding expected output format.
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 has only one required parameter 'slug' with no description, and schema coverage is 0%. The description does not mention 'slug' at all, failing to explain what it represents or how to construct it. Since the description must compensate for the lack of schema detail and does not, it adds minimal value beyond the parameter name itself.
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 states the tool fetches a single entity profile with a cited references ledger, using the specific verb 'fetch' and the resource 'entity profile'. This distinguishes it from sibling tools like list_beings or get_document, as it focuses on an individual entity with its full citation trail.
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 implies usage when you need a detailed entity profile with citations, but provides no explicit comparison to alternatives like search_documents or list_beings. It does not state when not to use this tool or mention any prerequisites or exclusions, making the usage guidance only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_documentAInspectFetch one archive document in full, including its attachment gallery. Supply either id, or both releaseProgram and externalId.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Internal document id. | |
| externalId | No | Document id within that release program. | |
| releaseProgram | No | Release program key, e.g. 'fbi_vault'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that the tool returns the full document including attachment gallery, and conveys the constraint that externalId requires releaseProgram. While it doesn't mention errors or authorization, the read-only behavior and key constraints are effectively communicated.
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?
A single, well-structured sentence conveys the primary action, scope, and identifier requirements without wasted words. It is front-loaded with the verb and object.
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 fetch tool, the description is sufficiently complete: it names the resource, specifies return content (full document + attachments), and how to identify the target. It doesn't address error cases or auth, but these are less critical given the tool's simplicity and lack of an output schema.
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?
Though the schema descriptions cover 100% of parameters, the description adds critical cross-parameter logic: 'either id, or both releaseProgram and externalId'. This is not inferable from individual parameter descriptions and significantly clarifies valid invocation patterns.
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 uses a specific verb ('Fetch') and resource ('archive document'), and explicitly notes it includes the attachment gallery. This clearly distinguishes it from sibling tools like get_news or get_video.
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 provides explicit guidance on parameter usage: 'Supply either id, or both releaseProgram and externalId.' This clarifies the valid identifier combinations. It does not explicitly discuss alternatives, but the context of fetching a single document is clear and distinct from search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_newsAInspectFetch one news article in full, including its related-commentary links.
| Name | Required | Description | Default |
|---|---|---|---|
| newsId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool returns the article 'in full' and includes related-commentary links, which is useful. However, it does not mention error handling, authentication, or what 'in full' entails beyond that (e.g., format, metadata). 'Fetch' implies read-only, but this is not explicitly stated.
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 a single, front-loaded sentence that clearly states the core action and a key feature. No filler or redundant information.
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 tool with one required parameter and no output schema, the description gives an idea of what is returned ('full article' and 'related-commentary links') but lacks detail on return format, possible errors, or how the response is structured. It is adequate but not thorough.
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 compensate. It does not mention the newsId parameter at all, leaving the agent to infer its purpose from the parameter name. There is no explanation of how to obtain the newsId or its expected format.
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 uses a specific verb ('Fetch') and resource ('one news article'), and explicitly states it includes related-commentary links. This distinguishes it from sibling tools like list_news (which likely lists multiple articles) and related_commentary (which focuses only on links).
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 implies the tool is for retrieving a full single news article by ID, but it does not explicitly state when to use it over alternatives like related_commentary or provide exclusion criteria. The usage context is clear from the wording ('Fetch one news article') but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sightingAInspectFetch one sighting record with its full media set, keyed by source and external id.
| Name | Required | Description | Default |
|---|---|---|---|
| sourceKey | Yes | ||
| externalId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds context like 'full media set' and the composite key, but it does not specify error handling, authentication requirements, or whether the record is returned in a specific format. This is adequate for a simple read but lacks depth.
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 a single sentence that packs all key information—action, resource, keying mechanism, and return contents—without unnecessary words. It is front-loaded and immediately understandable.
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 simplicity of the tool (two string parameters, no output schema, no annotations), the description covers the essential aspects: what it fetches, how it identifies the record, and what is included. It lacks some context like typical error cases, but for a straightforward get operation in a family of similar tools, this is reasonably complete.
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 provides only names and types with no descriptions (0% coverage), so the description must compensate. It does connect the two parameters as a composite key ('keyed by source and external id'), which gives them semantic meaning beyond the schema. However, it does not elaborate on allowed values or formats for either parameter.
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 states the tool fetches a single sighting record with its full media set, using a specific verb ('Fetch') and resource ('sighting record'). It also specifies the keying mechanism ('source and external id'), which distinguishes it from sibling getters for other entity types like get_being or get_document.
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 implies usage when you have a specific source and external ID to retrieve a single sighting. However, it does not explicitly state when to prefer this over search_sightings or list_sightings, nor does it mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_videoAInspectFetch one commentary video: title, channel, thumbnail, UAPDrop page and YouTube URLs, plus our written summary and analysis where this deployment allows it. Raw transcripts are never returned.
| Name | Required | Description | Default |
|---|---|---|---|
| videoId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well by disclosing that raw transcripts are never returned and that summary/analysis availability depends on deployment. This goes beyond basic fetch behavior and sets clear expectations about output limitations.
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?
One dense sentence that front-loads the purpose and packs essential information (fields, caveats, exclusions) without redundancy. Every clause adds value.
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 simplicity (one param, no output schema), the description lists all major return fields and a key exclusion. The deployment caveat adds nuance, though it could be clearer about how to obtain a videoId or handle missing data. Overall sufficient for the tool's complexity.
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%; the description fails to mention the videoId parameter at all. It doesn't explain what videoId represents, how to obtain it, or any format/constraints, leaving the agent without essential parameter context beyond the schema's bare existence.
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 states the tool fetches a single commentary video and enumerates the exact fields returned (title, channel, thumbnail, URLs, summary/analysis). The 'one' qualifier and focus on video distinguish it from siblings like get_being or get_document.
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?
No explicit guidance is given about when to use this tool vs alternatives such as search_videos or list_videos. The phrasing 'one commentary video' implies use with a specific videoId, but no when/when-not or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_beingsAInspectList reported non-human entity profiles (summary view), ordered by tier then name.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It adds useful information about ordering ('by tier then name') and the summary nature of the view, but it does not explicitly state whether the operation is read-only or mention any side effects or security considerations.
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 a single, front-loaded sentence that conveys the verb, resource, scope, and ordering without any filler. Every word 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?
Given the tool's low complexity (no parameters, no output schema), the description adequately covers the core purpose and ordering. It leaves the exact fields of the summary view undefined, but this is acceptable for a simple list tool with sibling context.
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 per the rubric a baseline of 4 is appropriate. The description adds no parameter information, but none is needed.
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 states the tool lists 'reported non-human entity profiles' in a summary view, with a specific verb 'List' and resource. It distinguishes itself from sibling tools like get_being (single entity) and list_news (news items) by explicitly describing the list scope and ordering.
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 clear context that this is a list operation for all entities, implying it is for overview purposes. However, it does not explicitly mention alternatives such as get_being for individual profiles, so it lacks a direct exclusion or when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_newsBInspectList UAPDrop news articles, newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It mentions 'newest first' ordering but does not state whether the operation is read-only, explain pagination behavior despite a page parameter, or describe the response format. This leaves significant behavioral unknowns.
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 a single, front-loaded sentence: 'List UAPDrop news articles, newest first.' It is concise and every word contributes useful information without unnecessary elaboration.
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 list tool, the description gives the core purpose and ordering, but it is incomplete because it omits pagination details, return format, and any guidance on choosing this over the get_news sibling. The presence of a page parameter and a close sibling tool suggests more context would be valuable.
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 page parameter is not mentioned in the description. Schema description coverage is 0%, and the description does not compensate by explaining that page controls pagination; the schema alone (with default and minimum) provides minimal meaning, but the description adds no semantic value.
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 states it lists UAPDrop news articles and specifies ordering as 'newest first,' making its purpose specific and distinct from sibling tools like get_news, which presumably fetches a single article.
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 implies its use for obtaining a collection of news articles, but it does not explicitly mention when to use it versus get_news or other list tools. No exclusions or alternatives are provided, so usage guidance is only implied, not clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sighting_sourcesAInspectList the archive source keys available to search_sightings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It clearly indicates a read-only list operation, adds context about the keys being for search_sightings, and has no contradictions, but does not disclose return format or edge cases beyond the implied list.
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?
One sentence, nine words, front-loaded with the action verb and resource. Every word is purposeful.
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 parameterless, no-output-schema tool, the description fully captures the purpose and context. No additional information is necessary to understand its function.
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 the schema is fully defined. The description does not need to add parameter semantics, hitting the baseline of 4.
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 uses a specific verb ('List') and clearly identifies the resource ('archive source keys') and its relationship to 'search_sightings,' distinguishing it from other list/search tools in the sibling set.
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 implicitly directs use before search_sightings by identifying the keys it makes available, but does not explicitly state when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_documentsAInspectFull-text search of the declassified UAP/UFO document archive (Project Blue Book, FBI Vault, national archives, and other government releases). Searches title, summary, incident text, tags, and extracted PDF text.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Require an exact phrase match on this tag. | |
| page | No | ||
| query | No | Free-text search terms. | |
| agency | No | Filter by releasing agency, e.g. 'FBI', 'CIA'. | |
| fileType | No | Filter by file type, e.g. 'pdf'. | |
| pageSize | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the search scope (full-text across specific fields and sources), which is useful. However, it omits behavioral details such as return format, pagination behavior, or any authentication/rate limits. For a read-only search tool, this is moderately transparent.
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-loaded with the core function, and contains no unnecessary words. It efficiently conveys the scope and searchable fields.
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?
The tool has 6 parameters, no output schema, and no annotations. The description covers what is searched and the archive scope, but does not explain how results are returned, pagination behavior, or the default result structure. Given the presence of page/pageSize parameters, some mention of result format would improve completeness.
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 coverage is 67%, with descriptions for tag, query, agency, and fileType. The description adds meaning by specifying the fields searched (title, summary, incident text, tags, extracted PDF text), which clarifies the query parameter. It does not add detail for page and pageSize, which lack schema descriptions, so the contribution is moderate.
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 states the tool performs full-text search over the declassified UAP/UFO document archive, names the specific sources (Project Blue Book, FBI Vault, etc.), and lists the fields searched. This distinguishes it from sibling tools like search_semantic, search_sightings, and search_videos.
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 implies usage for keyword-based search of documents, but does not explicitly state when to use this tool versus alternatives like search_semantic or search_sightings. No exclusions or clear when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_semanticAInspectSemantic search using embeddings — finds conceptually related material that keyword search misses. Searches declassified documents, news and the sighting archive by default. Commentary videos are searchable but excluded by default: their generated analysis is long enough to outrank terse archive records on almost any query. Pass kinds:["VIDEO"] to search commentary, or list it alongside the others to mix.
| Name | Required | Description | Default |
|---|---|---|---|
| kinds | No | Entity kinds to search. Defaults to DOCUMENT, NEWS and SIGHTING — the citable archive. VIDEO must be requested explicitly. | |
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It reveals the embedding-based behavior, default scope, and the rationale for excluding videos (their length tends to outrank archive records). This goes beyond trivial 'finds results' and helps the agent anticipate ranking quirks. It does not mention rate limits or pagination, but for a search tool these are not critical.
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, front-loaded with the core purpose. Every sentence adds value: purpose, default scope, and video exception with usage. No filler or repetition.
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 search tool with 3 params and no output schema, the description covers purpose, default behavior, and a key edge case (videos). It does not explain return format, but that is not required. It could mention that results are ordered by relevance, but the embedding description implies this. Overall, it is sufficiently complete for an agent to select and invoke 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 covers only 'kinds' (33%), but the description adds meaningful semantics: it explains the default kinds, why VIDEO is excluded, and exactly how to include it. It also hints at query semantics ('conceptually related material'), which helps agents craft better queries. 'limit' remains self-explanatory, so the description compensates well for low schema coverage.
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?
Description opens with 'Semantic search using embeddings' and specifically contrasts with keyword search, establishing a distinct tool. It further specifies default entity kinds (documents, news, sighting archive), making its scope clear and differentiating it from keyword-based siblings like search_documents and search_sightings.
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 explains when to use semantic search (when keyword search misses conceptually related material) and provides explicit guidance on including videos via kinds:["VIDEO"]. It does not name sibling tools directly but implies alternatives via 'keyword search misses'. Lacks an explicit 'when not to use' statement, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_sightingsAInspectSearch the consolidated, geocoded UFO/UAP sighting archive drawn from public government sources (NARA Project Blue Book, UK National Archives, CNES GEIPAN, and others). Supports date range and bounding-box filters.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Latest observation date, ISO yyyy-MM-dd. | |
| from | No | Earliest observation date, ISO yyyy-MM-dd. | |
| page | No | ||
| maxLat | No | ||
| maxLon | No | ||
| minLat | No | ||
| minLon | No | ||
| source | No | Source key, e.g. 'us_nara_bluebook'. | |
| pageSize | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It mentions the archive source and filter types, which is useful context, but it does not explain pagination behavior, default results, result ordering, or response format. This is a minimal level of transparency, lacking operational details.
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 exceptionally concise: two short sentences that front-load the core purpose (search archive), then add filter capabilities. Every phrase earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters, no output schema, and no annotations, yet the description only covers high-level search purpose and two filter types. It omits pagination, source selection details, default behavior, and any indication of what results look like. This is incomplete for a tool of this complexity.
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 only 33% (to, from, source have descriptions). The description mentions 'date range and bounding-box filters', which helps explain from/to and the lat/lon parameters, but it fails to mention pagination params (page, pageSize) or the source parameter behavior. With 9 params and low schema coverage, the description insufficiently compensates.
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 states a specific verb ('Search') and resource ('the consolidated, geocoded UFO/UAP sighting archive'), and further specifies the data sources and supported filters. This clearly distinguishes it from sibling tools like get_sighting or search_semantic, making the tool's purpose 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 provides clear context: it indicates the tool searches a specific consolidated archive with date range and bounding-box filters, implying use for structured filtering across sightings. It does not explicitly name alternatives or exclusions, but the scope is clear enough for an agent to infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_videosAInspectKeyword search over indexed UAP commentary videos. Returns the UAPDrop page URL, the YouTube URL, and — where this deployment allows it — our written summary, analysis and talking points. Raw transcripts are never returned. For conceptual rather than keyword matching, use search_semantic with kinds:["VIDEO"].
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | ||
| page | No | ||
| query | No | ||
| channel | No | Restrict to one channel name. | |
| pageSize | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the full burden and does well by disclosing return contents (UAPDrop URL, YouTube URL, and optional summaries) and a key limitation (transcripts never returned). However, it omits details like permissions or rate limits, but for a search tool, this is reasonably transparent.
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 three concise sentences: one for purpose, one for return details, and one for an alternative. Every sentence adds value with no fluff, and the key 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?
The description covers the main return format and a limitation, but with 5 parameters and no output schema, it leaves gaps such as what 'tag' means, pagination behavior, and the exact scope of the keyword search. It is adequate but not fully comprehensive.
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 only 20% schema description coverage (only 'channel' is described), the description fails to compensate. It does not explain the meaning or usage of 'query', 'tag', 'page', or 'pageSize', leaving the agent to infer critical parameter semantics.
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 states 'Keyword search over indexed UAP commentary videos' with a specific verb and resource, and explicitly differentiates from search_semantic by contrasting keyword vs. conceptual matching. It also outlines key return elements, making the tool's purpose 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 directs users to search_semantic with kinds:["VIDEO"] for conceptual matching, providing a clear alternative. It also sets expectations by stating raw transcripts are never returned, which informs when this tool is appropriate.
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!
