Skip to main content
Glama
khalidsaidi

ragmap

by khalidsaidi
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

RAGMap (RAG MCP Registry Finder)

Release Deploy monitor-freshness Glama

Try it: https://ragmap-api.web.app/browse/ Start here: https://github.com/khalidsaidi/ragmap/discussions/17

RAGMap is a lightweight MCP Registry-compatible subregistry + MCP server focused on RAG-related MCP servers.

It:

  • Ingests the official MCP Registry, enriches records for RAG use-cases, and serves a subregistry API.

  • Exposes an MCP server (remote Streamable HTTP + local stdio) so agents can search/filter RAG MCP servers.

MapRag (RAGMap)

MapRag is a discovery + routing layer for retrieval. It helps agents and humans answer: which retrieval MCP server should I use for this task, given my constraints?

RAGMap does not do retrieval itself. It indexes and enriches retrieval-capable servers, then routes you to the right tool/server.

Related MCP server: RagDocs MCP Server

What you get after install (plain English)

  • You get discovery/routing tools (rag_find_servers, rag_get_server, rag_list_categories, rag_explain_score).

  • RAGMap helps you find the best retrieval server for your task and constraints.

  • Your agent then connects to that chosen server to do the actual retrieval.

RAGMap does not:

  • Ingest your private documents automatically.

  • Host your personal vector database.

  • Replace your end-to-end RAG pipeline.

If you need retrieval over your own data, use a retrieval server from RAGMap results (or your own server) that supports your ingest/index flow.

Freshness and ingest

  • Hosted RAGMap updates its index on a schedule. Newly published/changed servers may appear with some delay.

  • Most users do not run ingest themselves when using the hosted service.

  • If you need tighter freshness control or private indexing behavior, self-host and run your own ingest schedule (docs/DEPLOYMENT.md).

Features: Registry-compatible API; semantic + keyword search (when OPENAI_API_KEY is set, e.g. from env or your deployment’s secret manager); categories and ragScore; filter by hasRemote, reachable (probe-checked for streamable-http/SSE), citations, localOnly, transport, minScore, categories. Human browse UI at ragmap-api.web.app/browse — search, filter, copy Cursor/Claude config. MCP tools: rag_find_servers, rag_get_server, rag_list_categories, rag_explain_score.

Quickstart

Requirements: curl and jq

1) Top reachable retrievers (checked within 24h)

curl -s "https://ragmap-api.web.app/rag/top?hasRemote=true&reachable=true&reachableMaxAgeHours=24&serverKind=retriever&limit=25" | jq .

2) Search with trust filter (reachable recently)

curl -s "https://ragmap-api.web.app/rag/search?q=rag&hasRemote=true&reachable=true&reachableMaxAgeHours=24&limit=10" | jq .

3) Get install config for a server

Tip: URL-encode names that contain /.

curl -s "https://ragmap-api.web.app/rag/install?name=ai.filegraph%2Fdocument-processing" | jq .

4) Inspect freshness and coverage

curl -s "https://ragmap-api.web.app/rag/stats" | jq .

5) Usage telemetry summary

curl -s "https://ragmap-api.web.app/api/stats" | jq .

Full overview: docs/OVERVIEW.md
Release history: CHANGELOG.md

Architecture

RAGMap architecture diagram

%%{init: {"theme":"base","themeVariables":{"primaryColor":"#ffffff","primaryTextColor":"#000000","primaryBorderColor":"#000000","lineColor":"#000000","secondaryColor":"#ffffff","tertiaryColor":"#ffffff","clusterBkg":"#ffffff","clusterBorder":"#000000","edgeLabelBackground":"#ffffff"},"flowchart":{"curve":"linear","nodeSpacing":75,"rankSpacing":70}}}%%
flowchart TB
  %% Concept-only diagram (product value; no deployment/framework/datastore details)

  classDef mono fill:#ffffff,stroke:#000000,color:#000000,stroke-width:1px;

  subgraph Inputs[" "]
    direction LR

    subgraph Query["Agent-native interface"]
      direction TB
      Users["Agents + humans"]:::mono
      subgraph Tooling["Tool call"]
        direction LR
        Criteria["Routing constraints<br/>domain, privacy, citations,<br/>freshness, auth, limits"]:::mono
        Tools["MCP tools<br/>rag_find_servers<br/>rag_get_server<br/>rag_list_categories<br/>rag_explain_score"]:::mono
      end
      Users --> Criteria --> Tools
    end

    subgraph Subregistry["Subregistry (read-only)"]
      direction TB
      subgraph Ingest["Ingest"]
        direction LR
        Sources["Upstream MCP registries<br/>(official + optional)"]:::mono
        Sync["Sync + normalize<br/>(stable schema)"]:::mono
        Catalog["Enriched catalog<br/>(servers + versions)"]:::mono
        Sources --> Sync --> Catalog
      end

      subgraph Enrich["Enrich (adds value)"]
        direction LR
        Cap["Structured metadata<br/>domain: docs|code|web|mixed<br/>retrieval: dense|sparse|hybrid (+rerank)<br/>freshness: static|continuous (max lag)<br/>grounding: citations|provenance<br/>privacy/auth: local|remote + req|optional<br/>limits: top_k|rate|max ctx"]:::mono
        Trust["Trust signals (lightweight)<br/>status, reachability,<br/>schema stability, reports"]:::mono
      end

      Catalog --> Cap
      Catalog --> Trust
    end
  end

  subgraph Selection["Selection (the added value)"]
    direction LR
    Router["Router<br/>match + rank + explain"]:::mono
    Ranked["Ranked candidates<br/>+ reasons + connect info"]:::mono
    Retrieval["Chosen retrieval MCP server(s)<br/>(do retrieval)"]:::mono
    Router --> Ranked --> Retrieval
  end

  Tools --> Router
  Catalog --> Router

  %% Keep the layout without adding a third visible "box" around Inputs.
  style Inputs fill:#ffffff,stroke:#ffffff,stroke-width:0px

Monorepo layout

  • apps/api: REST API + MCP registry-compatible endpoints + ingestion worker

  • apps/mcp-remote: Remote MCP server (Streamable HTTP)

  • packages/mcp-local: Local MCP server (stdio)

  • packages/shared: Zod schemas + shared types

  • docs: docs + Firebase Hosting static assets

Local dev

cp .env.example .env
corepack enable
pnpm -r install
pnpm -r dev

Optional: set OPENAI_API_KEY in .env (see .env.example) to enable semantic search locally; GET /health will show "embeddings": true.

API: http://localhost:3000 MCP remote: http://localhost:4000/mcp

Ingest

curl -X POST http://localhost:3000/internal/ingest/run \
  -H "Content-Type: application/json" \
  -H "X-Ingest-Token: $INGEST_TOKEN" \
  -d '{"mode":"full"}'

MCP usage

Remote (Streamable HTTP):

claude mcp add --transport http ragmap https://<your-mcp-domain>/mcp

Local (stdio, npm):

npx -y @khalidsaidi/ragmap-mcp@latest

Local (stdio):

pnpm -C packages/mcp-local dev

Key endpoints

  • GET /embed — embeddable “Search RAG MCP servers” widget (iframe; query params: q, limit)

  • GET /health (includes embeddings: true|false when semantic search is on/off)

  • GET /readyz

  • GET /v0.1/servers

  • GET /v0.1/servers/:serverName/versions

  • GET /v0.1/servers/:serverName/versions/:version (supports latest)

  • GET /rag/search

  • GET /rag/top (default sorted recommendations; limit max 50)

  • GET /rag/install

  • GET /rag/stats

  • GET /rag/categories

  • GET /api/stats (public usage aggregates; no PII)

  • GET /api/usage-graph (HTML chart of usage)

  • POST /internal/ingest/run (protected)

For hosted ragmap-api.web.app, /internal/* routes are not exposed publicly.

GET /rag/search query params:

  • q (string)

  • categories (comma-separated)

  • minScore (0-100)

  • transport (stdio or streamable-http)

  • registryType (string)

  • hasRemote (true or false — only servers with a remote endpoint)

  • reachable (true — only servers that were recently probe-checked as reachable via streamable-http/SSE)

  • reachableMaxAgeHours (optional, only with reachable=true — keep only results checked within N hours)

  • citations (true — only servers that mention citations/grounding in metadata)

  • localOnly (true — only stdio, no remote)

Smoke tests

API_BASE_URL=https://ragmap-api.web.app ./scripts/smoke-public.sh
MCP_URL=https://ragmap-api.web.app/mcp ./scripts/smoke-mcp.sh

Docs

  • docs/DISCOVERY-LINK-CONVENTION.md — optional discoveryService in server.json so clients can show “Discover more”

  • docs/AGENT-USAGE.md — for agents: discovery, REST API, MCP install (no human intervention)

  • docs/DEPLOYMENT.md

  • docs/OVERVIEW.md

  • docs/DATA_MODEL.md

  • docs/PRIVACY.md

  • docs/PUBLISHING.md

  • docs/GLAMA-CHECKLIST.md

  • docs/GLAMA-DOCKERFILE.md

  • scripts/glama-score-status.sh — print public Glama score flags (inspectable/release/usage)

Available Tools

6 tools
rag_explain_scoreExplain scoreB

Explain RAGMap scoring for a server. Use the registry server name, e.g. io.github.khalidsaidi/ragmap for RAGMap.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of disclosing side effects and constraints. It characterizes the tool as 'Explain', implying a read-only operation, but does not confirm safety, mention any required permissions, or specify behavior on invalid input (e.g., missing server). The description lacks behavioral depth.

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 extremely brief at two sentences, with no superfluous words. The first sentence states the purpose, and the second adds a practical usage hint. Every word earns its place, making it ideal for quick comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema), the description is still incomplete. It fails to describe what the tool returns (e.g., a score breakdown, textual explanation) or how errors are handled (e.g., server not found). Users would need to guess the output format or rely on external documentation.

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 sole parameter 'name' is described only by schema (type string, minLength 1). The description adds an example ('io.github.khalidsaidi/ragmap'), which clarifies the expected format but does not cover other possible naming conventions or validation rules. Schema description coverage is 0%, so the example provides helpful but incomplete guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the verb 'Explain' and the resource 'RAGMap scoring for a server', making the purpose clear. It also provides an example of the expected registry server name. However, it does not elaborate on what the 'explanation' entails (e.g., breakdown of scoring factors), which slightly reduces specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description suggests using a registry server name and gives an example, but it does not compare this tool to its siblings (e.g., rag_get_server, rag_find_servers). No explicit guidance on when to use this tool versus alternatives is provided, leaving the agent to infer from the tool's purpose alone.

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

rag_find_serversFind RAG MCP serversC

Search/filter RAG-related MCP servers from the RAGMap subregistry.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryNo
categoriesNo
minScoreNo
transportNo
registryTypeNo
hasRemoteNo
reachableNo
reachableMaxAgeHoursNo
citationsNo
localOnlyNo
serverKindNo
limitNo

TDQS

C2.6/5.0
Behavior2/5

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

With no annotations, the description should disclose behavioral traits, but it only says 'search/filter' and omits details like default behavior, ordering, or pagination, making it insufficient for safe invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, but given the tool's complexity (12 parameters), it may be too terse. It is front-loaded but lacks necessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description fails to provide essential context for a tool with many optional parameters, no output schema, and no annotations. The agent lacks information on parameter relationships or result structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description does not explain any of the 12 parameters. The agent cannot infer how to use filters like 'query', 'categories', or 'minScore' from the description alone.

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 action (Search/filter) and the resource (RAG-related MCP servers from the RAGMap subregistry), effectively distinguishing it from siblings like rag_top_servers and rag_get_server.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions, leaving the agent without enough context to decide.

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

rag_get_install_configGet install configC

Get copy-ready Claude Desktop and generic MCP host config for a server.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes

TDQS

C2.6/5.0
Behavior2/5

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

No annotations provided, and the description does not mention side effects, read-only nature, authorization needs, or what the config contains, leaving the agent uninformed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but sacrifices necessary detail; it could be restructured to include key points without extra length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema or annotations, the description fails to explain what the config includes or its format, leaving the agent to guess about the return value.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single 'name' parameter is not described in the schema (0% coverage) and the description only implies it refers to the server name without further specifics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'install config for a server', distinguishing it from sibling tools like rag_find_servers or rag_explain_score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives; lacks context about prerequisites or typical use cases.

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

rag_get_serverGet serverA

Fetch a server record by registry name (latest version). Use the exact name from the registry, e.g. io.github.khalidsaidi/ragmap for RAGMap.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes

TDQS

A4.1/5.0
Behavior3/5

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

No annotations provided; description implies read-only but doesn't explicitly state behavioral traits like auth or side effects. Adequate for a simple fetch.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no fluff: first defines action, second gives usage guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers basics for a simple one-param tool with no output schema, but lacks mention of return format or fields.

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?

Adds meaning beyond schema by specifying 'registry name' and giving an example, compensating for 0% schema description coverage.

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?

Clearly states it fetches a server record by registry name (latest version), distinguishing it from sibling tools like rag_find_servers or rag_top_servers.

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?

Provides explicit direction to use exact registry name with an example, but lacks explicit when-not-to-use or alternatives.

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

rag_list_categoriesList categoriesA

List all RAG categories known to RAGMap.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description must bear the full burden of explaining behavior. It states a read-only listing operation, which is appropriate, but omits details about output format or potential side effects, though none are expected.

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 a single, front-loaded sentence that directly states the tool's purpose. Every word earns its place; no wasted content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and annotations, the description could be more complete by specifying the output format (e.g., list of strings or objects). However, for a simple listing tool, the current description is adequate but leaves room for ambiguity.

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?

There are no parameters, so the baseline is 4 per rubric. The description does not add parameter information, but none is needed. Schema coverage is trivially 100%.

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 action ('List') and the target resource ('RAG categories'), making the tool's purpose unmistakable. It implicitly distinguishes from siblings by focusing on a different entity (categories vs. scores, servers, etc.).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description does not provide explicit guidelines on when to use this tool versus alternatives. Usage is implied by the title and description, but there is no context about prerequisites or exclusions.

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

rag_top_serversTop recommended serversC

Get top recommended retriever MCP servers with smart defaults.

ParametersJSON Schema
NameRequiredDescriptionDefault
categoriesNo
minScoreNo
hasRemoteNo
reachableNo
reachableMaxAgeHoursNo
localOnlyNo
serverKindNo
limitNo

TDQS

C2.4/5.0
Behavior2/5

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

No annotations exist, so the description must disclose behavior. It only states 'get top recommended' but does not confirm read-only, mention side effects, permissions, rate limits, or return format. 'Smart defaults' is vague and unhelpful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, short sentence (8 words), which is efficient but lacks front-loaded key details. It communicates the basic purpose but omits critical information, making it borderline under-specified rather than concisely informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 8 optional parameters, no output schema, and no annotations, the agent needs extensive context. The description provides none about output format, parameter roles, or expected behavior. It fails to equip an agent for reliable invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, yet the description provides no parameter explanations. The 8 parameters (categories, minScore, etc.) are completely undocumented in the description. 'Smart defaults' does not clarify parameter purpose or interaction.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description includes a clear verb ('Get') and resource ('top recommended retriever MCP servers'), indicating a retrieval operation. However, it does not differentiate from sibling tools like rag_find_servers, which also retrieves servers. The mention of 'smart defaults' hints at automated filtering but lacks specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as rag_find_servers. There are no exclusions, prerequisites, or context for optimal usage. The description is insufficient for choosing between tools.

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.

  1. 3 tool updatesv1.0.0
    • Changedrag_find_servers2 fields changed
      • addedInput schema / properties / reachableMaxAgeHours
        Added value: +{
+  "maximum": 8760,
+  "minimum": 1,
+  "type": "integer"
+}
      • addedInput schema / properties / serverKind
        Added value: +{
+  "enum": [
+    "retriever",
+    "evaluator",
+    "indexer",
+    "router",
+    "other"
+  ],
+  "type": "string"
+}
    • Addedrag_get_install_config
    • Addedrag_top_servers
  2. 4 tool updatesv0.1.3
    • First observedrag_explain_score
    • First observedrag_find_servers
    • First observedrag_get_server
    • First observedrag_list_categories
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: explaining scoring, searching servers, getting config, fetching server details, listing categories, and retrieving top servers. No overlap despite similar domains.

Naming Consistency5/5

All tools follow a consistent 'rag_<verb>_<noun>' pattern, making it easy to predict functionality. The naming is uniform and intuitive.

Tool Count5/5

6 tools is a well-scoped set for a registry service, covering essential operations without being excessive or insufficient.

Completeness5/5

The tool surface covers all typical registry use cases: search, browse, get details, get config, and top recommendations. No obvious gaps for a read-only consumer-facing registry.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/khalidsaidi/ragmap'

If you have feedback or need assistance with the MCP directory API, please join our Discord server