Skip to main content
Glama
AlexPerez7

idiradocs-mcp

by AlexPerez7
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

idiradocs-mcp

Servidor MCP que le da a Claude acceso a la documentación oficial de CyberArk / Idira (docs.cyberark.com), para que pueda responder preguntas citando contenido real de la doc en lugar de inventar o alucinar información.

Sin bases de datos vectoriales, sin pipelines de embeddings y sin ninguna API de pago: la búsqueda corre sobre un índice local generado por un crawler propio, y la lectura de páginas se hace en vivo contra el sitio real.

Índice

Related MCP server: local-document-rag-agent

Por qué existe esto

Preguntarle a un LLM sobre productos específicos de CyberArk (PAM, CPM, PSM, etc.) sin darle acceso a la documentación real tiene un riesgo alto de respuestas plausibles pero incorrectas. Este servidor MCP resuelve eso dándole a Claude dos herramientas concretas: buscar en la doc y leer una página puntual, siempre citando la fuente.

Cómo funciona

                 ┌──────────────────────┐
                 │   npm run crawl      │   (una vez, o para refrescar el índice cuando sea necesario)
                 └──────────┬───────────┘
                             │  recorre docs.cyberark.com
                             ▼
                 ┌──────────────────────┐
                 │ data/docs-index.json │   índice local (una entrada por sección de cada página)
                 └──────────┬───────────┘
                             │  MiniSearch
                             ▼
   Claude ──▶ search_cyberark_docs ──▶ lista de secciones candidatas (título, URL#anchor, snippet)
                             │
                             ▼
   Claude ──▶ get_cyberark_doc_page ──▶ fetch en vivo + Markdown limpio de esa URL

  • search_cyberark_docs: busca por palabras clave en el índice local generado por el crawler. Rápido, sin llamadas externas.

  • get_cyberark_doc_page: trae la página real desde docs.cyberark.com en el momento de la consulta, limpia el HTML de navegación y la devuelve en Markdown con los links resueltos a URLs absolutas. Siempre refleja el contenido actual del sitio, aunque el índice esté desactualizado.

El índice no guarda la página completa como un solo bloque: la divide por encabezado (cada <h1>-<h6> con id, que en el sitio coincide con el anchor de navegación) y guarda cada sección por separado. Esto hace que un resultado de búsqueda apunte directo a .../pagina.htm#SeccionEspecifica en lugar de a la página entera, y que el snippet devuelto sea del fragmento relevante y no de un promedio de toda la página.

El flujo esperado es que el modelo primero busque, elija la página más relevante, y después la lea completa antes de responder.

Instalación

Requiere Node.js 18 o superior.

git clone https://github.com/AlexPerez7/idiradocs-mcp.git
cd idiradocs-mcp
npm install
npm run build

Generar el índice de búsqueda

search_cyberark_docs necesita un índice previo — sin este paso no tiene nada para buscar:

npm run crawl

Por defecto arranca desde la página de inicio de la doc y se detiene a las 150 páginas, para que la primera corrida sea rápida. Para un índice más completo, se puede ajustar el alcance con variables de entorno:

# Ejemplo: indexar 2000 páginas de PAM - Self-Hosted en particular
CRAWL_SEEDS=https://docs.cyberark.com/pam-self-hosted/latest/en/content/resources/_topnav/cc_home.htm CRAWL_MAX_PAGES=2000 npm run crawl

Es necesario volver a ejecutar npm run crawl para refrescar el índice — la documentación cambia con el tiempo y el índice no se actualiza solo.

Conectarlo a Claude

Claude Desktop

Agregar el servidor en claude_desktop_config.json:

En instalaciones desde Microsoft Store, este archivo suele estar en %LOCALAPPDATA%\Packages\Claude_<id>\LocalCache\Roaming\Claude\claude_desktop_config.json en vez del %APPDATA%\Claude\ habitual.

{
  "mcpServers": {
    "idiradocs": {
      "command": "node",
      "args": ["/ruta/absoluta/a/idiradocs-mcp/dist/index.js"]
    }
  }
}

Es necesario reiniciar Claude Desktop por completo (no alcanza con minimizar) para que tome el nuevo servidor.

Claude Code

Se puede registrar como servidor MCP de usuario o de proyecto:

claude mcp add idiradocs -- node /ruta/absoluta/a/idiradocs-mcp/dist/index.js

Herramientas expuestas

search_cyberark_docs

Busca en el índice local.

Parámetro

Tipo

Descripción

query

string

Términos de búsqueda, en español o inglés

count

number (opcional, default 5)

Cantidad máxima de resultados (1-10)

Devuelve título (página — sección), URL (con anchor a la sección específica cuando existe) y un fragmento de texto por cada resultado.

get_cyberark_doc_page

Trae y limpia el contenido de una página puntual.

Parámetro

Tipo

Descripción

url

string

URL completa, debe pertenecer a https://docs.cyberark.com/

Devuelve el contenido en Markdown, con título y URL fuente al inicio. Rechaza cualquier URL fuera de ese dominio.

Configuración

No hay ninguna variable obligatoria. Estas solo afectan a npm run crawl:

Variable

Default

Descripción

CRAWL_SEEDS

página de inicio de la doc

URLs separadas por coma desde donde arrancar el crawl

CRAWL_MAX_PAGES

150

Tope de páginas a visitar

CRAWL_CONCURRENCY

3

Requests en paralelo

CRAWL_DELAY_MS

150

Pausa entre lotes de requests, para no sobrecargar el sitio

Estas variables pueden definirse en un archivo .env (ver .env.example) o pasarse inline al comando.

Detalles de implementación

  • Las páginas de docs.cyberark.com son HTML estático generado por MadCap Flare. El contenido real de cada página vive en <div id="mc-main-content">, y los elementos de navegación/chrome llevan class="nocontent" — esa es la convención que se usa tanto para indexar como para leer una página.

  • El sitio devuelve una página 404 personalizada a requests cuyo User-Agent no parece un navegador (mitigación anti-bot); por eso tanto el crawler como el fetch de páginas envían un User-Agent de Chrome.

  • La búsqueda usa MiniSearch con boost en el título de página y de sección, y coincidencia difusa (fuzzy) y por prefijo — no es una búsqueda semántica, es coincidencia de palabras con tolerancia a errores de tipeo. Se evaluó agregar una capa de embeddings locales, pero se descartó: la librería estándar para eso en Node (transformers.js) trae dependencias transitivas (sharp/libvips, adm-zip) con vulnerabilidades altas sin parche disponible.

  • get_cyberark_doc_page valida que la URL sea https://docs.cyberark.com/* antes de hacer el fetch, para que el servidor no pueda usarse como proxy hacia otros dominios.

Limitaciones conocidas

  • El índice de búsqueda es una foto del momento del crawl — no se actualiza solo. Si la doc cambia, hay que volver a correr npm run crawl.

  • La relevancia de search_cyberark_docs es por palabras clave, no semántica: sinónimos o paráfrasis pueden no encontrar la página correcta aunque exista.

  • El crawler solo sigue links dentro de docs.cyberark.com y con extensión .htm/.html; no cubre PDFs, videos embebidos ni contenido cargado dinámicamente con JavaScript.

Scripts disponibles

Comando

Qué hace

npm run build

Compila TypeScript a dist/

npm start

Corre el servidor MCP (dist/index.js) sobre stdio

npm run dev

Compila en watch mode

npm run crawl

Compila y corre el crawler, genera/actualiza data/docs-index.json

Available Tools

2 tools
get_cyberark_doc_pageLeer una página de la documentación de CyberArk/IdiraA

Trae y limpia el contenido de una página de docs.cyberark.com (solo ese dominio) y lo devuelve en Markdown, para responder preguntas citando la documentación oficial real en vez de inventar respuestas.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesURL completa de la página en https://docs.cyberark.com/...

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description discloses the domain restriction ('solo ese dominio') and behavioral actions (fetching, cleaning, converting to Markdown). It does not discuss error handling or edge cases, but for a simple read-only fetch tool, this is adequate transparency.

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 sentence, front-loaded with the action, resource, and output. Every phrase serves a purpose, and there is no redundant padding.

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

Completeness5/5

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

For a one-parameter tool with no output schema, the description adequately covers what the tool does, the domain constraint, the return format (Markdown), and the intended use. No significant missing information is apparent.

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 schema already fully describes the URL parameter with 100% coverage, including the domain. The description adds context about output format and purpose, but the domain restriction is already present in the schema, so the added semantic value is limited.

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

Purpose5/5

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

The description uses a specific verb ('Trae y limpia') and identifies the resource (docs.cyberark.com pages) and output (Markdown). It clearly distinguishes from the sibling tool by targeting a specific page rather than searching.

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

Usage Guidelines4/5

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

It provides a clear use case: to answer questions by citing official documentation instead of inventing answers. However, it does not explicitly mention the sibling search tool or state when not to use this tool, so it lacks explicit alternatives.

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

search_cyberark_docsBuscar en la documentación de CyberArk/IdiraA

Busca páginas relevantes en un índice local de la documentación oficial de CyberArk/Idira (docs.cyberark.com), generado con 'npm run crawl'. Devuelve título, URL y snippet de cada resultado. Usa get_cyberark_doc_page para leer el contenido completo y actualizado de una URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
countNoCantidad máxima de resultados (1-10)
queryYesTérminos de búsqueda, en español o inglés

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the search is performed on a local index generated with 'npm run crawl', implying it may be a snapshot, and specifies the return format. However, it does not explicitly state staleness or update behavior, which is a minor gap.

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

Conciseness5/5

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

The description is two short sentences, front-loaded with the core purpose, and mentions the sibling tool without unnecessary fluff. Every sentence earns its place.

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

Completeness4/5

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

For a search tool with no output schema, the description adequately explains the return fields (title, URL, snippet) and the source. It lacks minor details like no-results handling or query language nuances, but the essentials are covered for a straightforward use case.

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

Parameters3/5

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

The input schema already covers both parameters with descriptions (query and count). The tool description does not add parameter-specific meaning beyond the schema, so it meets the baseline for high schema coverage but adds no extra value.

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 tool searches a local index of official CyberArk/Idira documentation and lists the return fields (title, URL, snippet). It distinguishes itself from the sibling tool get_cyberark_doc_page by explicitly directing users to that tool for reading full page content.

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

Usage Guidelines5/5

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

It provides explicit guidance: use this tool for searching relevant pages, and get_cyberark_doc_page for reading full, up-to-date content of a URL. This clearly indicates when to use which tool.

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.

  1. 2 tool updatesv1.0.0
    • First observedget_cyberark_doc_page
    • First observedsearch_cyberark_docs
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored across 2 tools

Disambiguation5/5

The two tools are clearly distinct: one searches an index, the other retrieves a specific page's content. There is no functional overlap or ambiguity between them.

Naming Consistency5/5

Both tools follow the same verb_noun pattern with the 'cyberark_docs' domain prefix: 'search_cyberark_docs' and 'get_cyberark_doc_page'. Consistency is perfect.

Tool Count3/5

With only 2 tools, the server is minimal and might feel thin for broader documentation workflows, but it covers the core search-and-retrieve pattern adequately. It is slightly under the typical well-scoped range.

Completeness4/5

The domain is documentation lookup, and search + fetch provides a complete read-only workflow. Missing features like browsing sections or listing all pages are minor gaps that agents can work around.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • LlamaCloud MCP Server

    run-llama
    A
    license
    Not graded
    quality
    F
    maintenance
    A local MCP server that integrates with Claude Desktop, enabling RAG capabilities to provide Claude with up-to-date private information from custom LlamaCloud indices.
    225
    MIT

  • claude-rag-mcp

    VXConsulting
    A
    license
    Not graded
    quality
    C
    maintenance
    MCP server providing RAG context and failure capture for Claude Code, enabling semantic search across project knowledge and storing/analyzing failures.
    1
    MIT