Live public demo: query one person's learning and work history as a knowledge graph via MCP.
Returns the COMPLETE, exact set of entries for one type, with no similarity ranking, no relevance cutoff, and no cap on count. Use this instead of query_knowhow whenever the question requires an exhaustive or countable answer ('list all my certifications', 'how many courses have I completed'). Deterministic ordering (sorted by label) -- repeated calls with the same type return the same list in the same order.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Exact entry type to list in full |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that results are complete, exact, have no relevance cutoff, no count cap, and are deterministically sorted by label. It also guarantees repeated calls return the same list in the same order, which is valuable context for multi-step agent workflows.
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 efficiently front-load the core behavior, then provide usage guidance and ordering guarantees. Every sentence adds unique information with no filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only listing tool with complete enum documentation, the description covers completeness, use cases, ordering, and determinism. The lack of an output schema is acceptable because the return shape—an exhaustive list of entries of the specified type—is clear from the description.
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 already fully documents the single 'type' parameter with an enum and the description 'Exact entry type to list in full', so schema coverage is 100%. The description adds no parameter-level detail beyond referring to 'one type' and 'same type', meeting the baseline but not exceeding it.
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 ('Returns') and a precise resource ('complete, exact set of entries for one type'), and explicitly contrasts with query_knowhow's relevance-based behavior. Its function is unmistakable and well-differentiated from the primary sibling.
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 directs agents to use this tool instead of query_knowhow whenever an exhaustive or countable answer is needed, with concrete examples ('list all my certifications', 'how many courses have I completed'). The deterministic ordering statement further clarifies when repeated reliable results matter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search this person's real, grounded skills/experience graph for a topic using semantic search. Returns only entries with real evidence -- never guesses. Every entry here represents something actually done or completed (project, certification, position, course, or education) -- this public dataset never includes saved-but-not-worked jobs or applications. This is SEMANTIC search ranked by relevance and capped at 10 results -- it is NOT exhaustive. For 'list every X' or 'how many X' questions, use list_by_type instead -- it returns the complete, uncapped set with no similarity ranking involved. Clearing the similarity floor means 'closest available match', not 'confirmed match' -- read each result's actual label/description/type before citing it as evidence for the specific topic queried. Each result also carries source_url/captured_at/provider (the real evidence behind it, when available) and source_note (explaining why not, when the underlying source has no link) -- use these to answer a disputed claim with actual backing evidence rather than just the description text. Embeddings can rank a topically-adjacent-but-wrong entry above the floor (e.g. a course on a different cloud data-warehouse tool, or a different framework in the same category) for a term it isn't actually about; if a result isn't genuinely on topic, treat the query as unmatched rather than reporting it as a match. For 'what else is connected to this' or 'what shares a skill/provider with this specific entry' questions, call related_entries with a result's id instead of re-querying by topic.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | A skill, technology, or topic to check, e.g. 'django' or 'aws' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, but the description adds substantial behavior: semantic ranking, a 10-result cap, non-exhaustive results, evidence-only dataset content, source fields, and the risk of topically-adjacent wrong matches. This goes well beyond what annotations provide and contains no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but purpose-first: it front-loads the core action, then gives boundaries, evidence handling, and failure modes. Each sentence earns its place, though there is slight redundancy around 'real evidence' and the caveats could be tightened without losing 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?
With no output schema, the description still covers result caps, result fields (source_url/captured_at/provider/source_note), false-positive behavior, and alternative tool routing. An agent has everything needed to call it correctly and interpret results safely.
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 already documents the single topic parameter with examples, so the baseline is 3. The description adds meaning by clarifying that topic matching is semantic rather than literal, ranked by relevance, and may return adjacent-but-wrong entries — important context for interpreting results.
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 a specific verb ('Search ... using semantic search') and names the exact resource ('person's real, grounded skills/experience graph'). It also distinguishes itself from siblings by stating it is capped at 10 results and only returns evidence-backed entries.
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 when NOT to use this tool: for exhaustive 'list every X'/'how many X' questions, use list_by_type; for relationship questions, use related_entries. It also instructs treating off-topic semantic matches as unmatched, providing clear decision rules for ambiguous results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given an exact tag/skill (e.g. 'docker', 'gcp'), returns EVERY entry with that tag, uncapped, grouped by type with a real count per type. Unlike related_entries (capped at 15, requires a starting entry id) or query_knowhow (semantic, ranked, may over- or under-include), this is an EXACT tag match against every entry -- the right tool for 'how many X have I completed/done' or 'do I have any real evidence for X at all'. Tags are exact strings from a prior list_by_type/related_entries/query_knowhow result's tags array -- this is NOT semantic search; a tag never assigned during ingest returns found:false, try query_knowhow instead. Each type's entries sort by captured_at ascending (oldest first); entries with no captured_at are moved to the end and counted in undated_count, never silently sorted as if their date were known.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | An exact tag from a prior result's tags array, e.g. 'python', 'docker', 'gcp' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses exact-match semantics, uncapped results, grouping by type with real counts, sorting behavior by captured_at, undated_count handling, and the found:false response for unmatched tags. This is rich behavioral context that annotations alone 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?
Every sentence delivers essential information: main behavior, sibling contrasts, usage guidance, exact-match caveats, and sorting/undated_count semantics. The description is dense but focused, front-loading the core behavior before differentiation and edge cases.
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 no output schema, the description compensates by explaining return semantics: grouped entries, counts, sorting, undated_count, and found:false. It covers the main usage scenarios and edge cases effectively, leaving no critical gap for an agent to call 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 100%, so baseline is 3. The description adds extra meaning by emphasizing that the tag must be an exact string from a prior result's tags array and explicitly warns 'this is NOT semantic search', reinforcing correct parameter usage beyond 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?
The description states a specific action and resource: 'returns EVERY entry with that tag, uncapped, grouped by type with a real count per type.' It clearly distinguishes itself from siblings by naming related_entries and query_knowhow and explaining their differing behavior.
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?
Explicit when-to-use guidance is provided: 'the right tool for "how many X have I completed/done" or "do I have any real evidence for X at all".' It also names alternatives and their limitations, and tells the agent to try query_knowhow if an exact tag returns found:false.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
list_by_typequery_knowhowrelated_entriesskill_evidenceClaiming 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 as io.github.acme/server also 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.json on 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.
No comments yet. Be the first to start the discussion!
Personal knowledge graph as an AI memory layer over MCP - read, save, and link your memories.
Human Lineage MCP server — search and query the public genealogical graph of all humanity
DBpedia MCP — SPARQL + Lookup over Wikipedia-derived structured data
Open Targets MCP — disease/target/drug knowledge graph.
Add one secure layer between your agents and this server.
Each tool targets a clearly distinct retrieval mode: exhaustive listing by type, semantic ranked search, relationship traversal by ID, and exact tag matching. The descriptions actively cross-reference each other to prevent confusion, making misselection very unlikely.
All names are snake_case and readable, but the pattern is mixed: list_by_type and query_knowhow are imperative verb phrases, while related_entries and skill_evidence are noun phrases. A more consistent set would use verbs throughout, such as get_related_entries and get_skill_evidence.
Four tools is well-scoped for a read-only personal knowledge graph. Each tool covers a necessary and non-redundant query path, and none feel like filler or missing from the core set.
The set covers the main query needs: exhaustive lookup by type, semantic search, related entries, and exact skill evidence. Minor gaps exist, such as no direct get-entry-by-id tool and no way to enumerate all available types or tags without first running a search, but these are workable.