English | Русский

Yandex Wiki Search MCP

Conecta Claude, Cursor, Windsurf o cualquier cliente MCP a Yandex Wiki: búsqueda de texto completo, páginas, comentarios, archivos adjuntos y tablas dinámicas («grids»): 33 herramientas con esquemas tipados.

Proyecto no oficial: no está afiliado a Yandex ni cuenta con su respaldo.

• 🔍 Búsqueda de texto completo en toda la wiki — el mismo backend que alimenta la barra de búsqueda web de Wiki, hasta 50 resultados por consulta

• 📄 Ciclo de vida completo de las páginas — crear, actualizar, añadir (arriba / abajo / ancla), clonar, eliminar con token de recuperación, comentarios, subida de archivos

• 📊 Tablas dinámicas (grids) — 11 herramientas de escritura: filas, columnas, celdas, copiar, ordenar

• 🔒 Modo de solo lectura proporcionado por el servidor — WIKI_READ_ONLY=true simplemente no registra herramientas de escritura, así el agente no puede omitirlo

• 🧩 Superficie tipada de herramientas — cada herramienta incluye esquemas de entrada y salida JSON además de anotaciones de seguridad (pistas de solo lectura / destructivas / idempotentes)

• 🐳 Se ejecuta en cualquier parte — estándar para clientes de escritorio, streamable-http + Docker (con OAuth multiusuario opcional) para equipos

Inicio rápido

1. Consigue un token de OAuth de Yandex con acceso a Wiki (guía oficial) y tu ID de organización.

2. Instálalo en tu cliente:

[](https://lmstudio.ai/install? name=yandex-wiki-search&config=eyJjb21tYW5kIjoidXZ4IiwiYXJncyI6WyJ5YW5kZXgtd2lraS1zZWFyY2gtbWNwIl0sImVudiI6eyJXSUtJX1RPS0VOIjoiWU9VUl9UT0tFTiIsIldJS0lfT1JologyIjoiWU9VUl9PUkdfSUQiLCJXSUtJX0JFQURfT05MWSI6InRydWUifX0=)

La insignia de Claude Desktop descarga el paquete .mcpb de la última versión: haz doble clich and Claude Desktop instala el servidor, pidiendo el token y el ID de organización (uv debe estar instalado — uv).

{
  "mcpServers": {
    "yandex-wiki-search": {
      "command": "uvx",
      "args": ["yandex-wiki-search-mcp"],
      "env": {
        "WIKI_TOKEN": "YOUR_TOKEN",
        "WIKI_ORG_ID": "YOUR_ORG_ID",
        "WIKI_READ_ONLY": "true"
      }
    }
  }
}

claude mcp add yandex-wiki-search \
  -e WIKI_TOKEN=YOUR_TOKEN -e WIKI_ORG_ID=YOUR_ORG_ID -e WIKI_READ_ONLY=true \
  -- uvx yandex-wiki-search-mcp

{
  "mcpServers": {
    "yandex-wiki-search": {
      "command": "docker",
      "args": ["run","--rm","-i",
        "-e","WIKI_TOKEN","-e","WIKI_ORG_ID","-e","WIKI_READ_ONLY=true",
        "ghcr.io/dlbolshov/yandex-wiki-search-mcp:latest"],
      "env": {"WIKI_TOKEN":"YOUR_TOKEN","WIKI_ORG_ID":"YOUR_ORG_ID"}
    }
  }
}

[!TIP] Empieza con WIKI_READ_ONLY=true — el servidor no registrará siquiera herramientas. Cambia a false cuando confíes en que tu agente puede encargarse de las ediciones.

Pídele algo a tu agente — verás ejemplos.

El servidor se ejecuta con el MCP Python SDK v2. Esto es invisible para los clientes: un único servidor versión 2 responde a todas las revisiones del protocolo que se remonta a 2024-11-05 así como a la actual, por lo que no necesitas cambiar nada ni instalar nada de nuevo.

El único motivo para quedarte atrás es un entorno compartido que fija mcp<2 para otra cosa. La última versión basada en el SDK 1.x es 1.0.1 y permanece en PyPI:

pip install "yandex-wiki-search-mcp<1.1"

Related MCP server: mediawiki-mcp-server

Lo que se puede hacer

"Encuentra nuestros documentos de incorporación y resume los pasos clave."

"¿Qué hay sobre la gestión de incidentes? Ábrero la página más relevante."

"Crea una página team/weekly-notes y añade el resumen del standup de hoy."

"Añade una fila a la tabla de rotación de guardias: alice, la próxima semana."

"Sube este PDF a la página del proyecto y enlázalo al final."

"Elimina la página de borrador, pero conserva el token de recuperación por si cambio de opinión."

Herramientas

33 herramientas. Todas las herramientas de escritura desaparecen cuando WIKI_READ_ONLY=true.

Búsqueda y lectura (10)

Páginas: escritura (12)

Cuadrículas: escritura (11)

Particularidades de las cuadrículas:

• Las mutaciones usan bloqueo optimist: obten la cuadrícula and pase the last revision.

• grid_update.default_sort acepa [{"column": "status", "direction": "asc"}] as entradas; co-el servidor las convierte al formato de red que esperada la API.

• grid_add_columns requires required on each columna because la API atún.

• grid_copy devuelve metadados de la operación, no un objeto de cuadrícula ya copiido.

Cómo se compara

Los puntos verirficos se verificaron contra la documentationación y the body published of alternativ, between July and August 2026; the list of tools of the official hosted server was captured in live from mcp.wiki.yandex.net (wiki-mcp-server 1.28.1, 2026-08-11).

Let's produce.

Given the length, we need to be careful with the table. Let's format with pipes.

I will write the table with simple spacing.

Now, final answer.| | yandex-wiki-search-mcp | MCP oficial de Yandex (alojado) | ya-yandex-wiki-mcp | slartus/mcp-yandex-wiki | ya-wiki-mcp | | --- | --- | --- | --- | --- | --- | | Búsqueda de texto completo | ✅ hasta 50 resultados, filtros del lado del servidor + resono | ❌ sin herramienta de brúsqueda | ❌ | ✅ hasta 10 resultados | ❌ | | Páginas: crear / actualizar / agregar / eliminar + recuperar | ✅ todo, además de ediciones parciales mediante reemplazo de texto (page_edit) | porcional — no incluye agregar / recuperar; incluye ediciones parciales mediante reemplazo de texto | ✅ todas | parcial — no incluye agregar / recuperar | parcial — no incluye recuperar | | Páginas: clonar a un nuevo slug | ✅ page_clone | ❌ | ❌ | ❌ | ✅ | | Grids: herramientas de escritura | ✅ 11 | ✅ 12, incl. actualización de columnas + fijación de filas / color | ✅ 11 | ❌ solo lectura | ✅ 11, incl. clonación | | Comentarios, subida de archivos adjuntos | ✅ incl. eliminación, vista previa de imágenes en línea y descarga a disco | comentarios ✅ / subida ❌ (descarga + vista previa en su lugar) | ✅ | ❌ | ❌ | | Modo de solo lectura en el servidor | ✅ | ❌ | ✅ | ❌ | ❌ | | Esquemas de salida tipados + anotaciones de herramientas | ✅ | ❌ | ❌ | ❌ | ❌ las herramientas devuelven cadenas de texto simples | | Utilidades de YFM | ✅ recurso con hoja de referencia de sintaxis + yfm_warnings en herramientas de escritura | ❌ | ❌ | ❌ | ✅ conversor de Markdown→YFM + caché de árbol de páginas, plantillas de prompts | | Docker / PyPI / MCP Registry | ✅ / ✅ / ✅ | — servicio alojado, código fuente cerrado, no hay nada que instalar | ✅ / ✅ / ✅ | ❌ instalación manual | ❌ / ✅ / ❌ | | OAuth multiusuario para despliegues HTTP | ✅ | ❌ token por usuario pegado en cabeceras estáticas, sin flujo OAuth | ✅ | ❌ | ❌ |

También vale la pena conocer:

• best-doctor/mcp-yandex-wiki (Python) — crear / actualizar páginas y leer, con un punto de entrada separado de solo lectura -ro; no hay eliminar / recuperar, no hay grids, no hay búsqueda; solo en PyPI

• brekhov-ilya/yandex-wiki-mcp (npm) — lectura / escritura / mover páginas, grids de solo lectura; flujo interactivo de token PKCE con actualización automática, sin búsqueda de texto completo

• n-r-w/yandex-mcp (Go) — Yandex Tracker + Wiki en un mismo servidor, de solo lectura por diseño (5 herramientas de lectura de wiki), sin búsqueda; autenticación solo mediante tokens IAM de la CLI yc — los tokens OAuth de Yandex no se admiten

• bim-ba/ycli (Python) — un conjunto para Tracker + Wiki + Forms: una CLI, un SDK en Python, un plugin de Claude Code y un servidor MCP cuya superficie de Wiki son 42 herramientas wiki_* (15 de lectura / 27 de escritura, anotadas, con un flag --read-only); sin búsqueda de texto completo, y las descargas de archivos adjuntos se limitan a CLI/SDK

Desde agosto de 2026, la búsqueda de texto completo existe solo en este proyecto (hasta 50 resultados) y en slartus (hasta 10) — el servidor alojado por Yandex no incluye una herramienta de búsqueda — y la combinación de búsqueda, escrituras de grids, modo de solo lectura en el servidor y esquemas tipados es única de este proyecto.

Este proyecto es un fork de ya-yandex-wiki-mcp y se basa en hallazgos de slartus/mcp-yandex-wiki — ver Créditos.

Búsqueda de texto completo

page_search envuelve el endpoint POST /v1/search — el mismo backend que alimenta la barra de búsqueda web de Wiki, oficial hasta que Yandex publicó su referencia de API en agosto de 2026. Busca primero y luego abre un resultado con page_get por su slug.

• Dos modos de conexión. Por defecto: hasta 50 resultados en una llamada (limit se limita a 1–50; la API rechaza cualquier otro) y sin paginación: los cursores de la respuesta son siempre null. Con highlight=true: las páginas pueden tener 10 resultados como máximo independientemente de limit, las coincidencias aparecen envueltas en <em> y cursor (el número de página devuelto en next_cursor) recorre hasta ~100 resultados. El conjunto termina cuando results devuelve vacío o next_cursor es null en una página no vacía — pasado el final, next_cursor sigue contando sobre páginas vacías, así que él solo no significa «existen más».

• Los filtros se ejecutan en el servidor, antes del límite — una búsqueda filtrada no pierde coincidencias: slug_prefix (filtro de sección, prefijos profundos como tech-doc/ml son válidos), result_type (page/file), authors (propietarios de consultas por uid/cloud_uid — user_get_current te proporciona los tuyos, conviertiendo «buscar mis páginas sobre X» en dos llamadas) y created_between/modified_between intervalos de fechas (ambos límites necesarios — la API rechaza intervalos abiertos).

• Las consultas entre comillas "frase exacta"; los resultados page obtienen enlaces absolutos https://wiki.yandex.ru/..., y los resultados file obtienen enlaces de descarga directa.

• content es un extracto de ~510 caracteres, ni la página ni un resumen: se corta desde el punto donde aparece la coincidencia, los términos de búsqueda no tienen que estar dentro, y sus saltos de línea y pestañas son el diseño propio de la página (las celdas de tabla llegan separadas por tabulador) y no separadores entre fragmentos. Pasa highlight=true para ver las coincidencias envueltas en <em>. Lee la página con page_get antes de responder desde ella. Vacío para los resultados file.

Recorriendo el árbol

page_get_descendants devuelve un subárbol como una sola lista de {id, slug} de cada nivel de anidación. Pasar a from_root=true en lugar de page_id/slug recorre toda la Wiki, la vía de entrada cuando no se sabe ningún slug inicial, así que la búsqueda no es el único punto de entrada. Prefiere un slug de sección cuando tengas uno: las wikis tienen miles de páginas, y fetch_all se detiene en su límite de ~500 elementos con truncated: true.

Más comportamiento verificado de la API (alcances, semántica de 403, envolturas de error, límites): docs/api-notes.md.

Configuración

We должны also check the second bullet: "las mismas ..." Actually there is a section "## Configuración" after the last paragraph, no content. We include.

But wait, after content paragraph, we had "const" and then "For 5 layers?" Actually the original after "content" paragraph leads to "For authoring..."? No, original goes: "* Quoted...

• content is ...

Recorriendo el árbol..."

Yes.

Now, the second row of table "Parcial — no include recuperar" – for sixth cell, original "partial — no recover" should be "parcial — no recovers". But we translated as "parcível — no" in the table: parcial — no incluye agregar / recuperar for fifth and parcial — no incluye agregar for sixth? Let's inspect our table.

Original:

• Page recover: partial — no append / recover; has partial text edits

• Rightmost: partial — no recover

Our table:

• In the third cell: parcial — no incluye agregar / recuperar; incluye ediciones parciales mediante reemplazo de texto

• Fifth cell: parcial — no incluye agregar / recuperar

• Sixth cell: parcial — no incluye agregar / recuperar? We actually put parcial — no incluye agregar / recuperar? Let's check our translation row: The sixth: parcial — no incluye agregar / recuperar? Actually in the table above, I wrote:

| Páginas: crear / actualizar / agregar / eliminar + recuperar | ✅ todo, además de ediciones parciales mediante reemplazo de texto (page_edit) | parcial — no incluye agregar / recuperar; incluye ediciones parciales mediante reemplazo de texto | ✅ todas | parcial — no incluye agregar / recuperar | parcial — no incluye recuperar

Wait my line said parcial — no incluye recuperar for sixth. But I need to confirm. In the compiled output above, I see the sixth: parcial — no incluye recuperar. Yes. The original sixth: partial — no recover => "parcial — no incluye recuperar". Good.

Now, the second cell ✅ todo, además de ediciones parciales mediante reemplazo de texto (page_edit) – correct.

Also, row 2 in our output has "Páginas: crear / actualizar / agregar / eliminar / recuperar"? Actually we wrote "eliminar + recuperar". Good.

Now, row 4 Grids: herramientas de escritura. We might consider the second cell "✅ 11" fine.

Now, row 9 "MCP Registry" kept as is. Good.

Now, there is a concern: The original table header has the project name yandex-wiki-search-mcp not "yandex-wiki-mcp-server" (we have correct). Good.

Now, for the bullet list, we used "traducción" They are okay.

Now, let's check for "la API" gloss. The translation "les terminos" correct.

One more nuance: In the first bullet list under "Full-text search", we have "By default: up to 50 results in one call (limit is clamped to 1–50; the API rejects anything else) and no pagination — the response cursors are always null." Our translation: "Por defecto: hasta 50 resultados en una sola llamada (limit se limita a 1–50; la API rechaza cualquier otro) y sin paginación: los cursores de la respuesta son siempre null." Good.

But note: "the next page" in original: "the page number echoed back in next_cursor". We translated "the page number echoed back in next_cursor". Good.

Now, the "content" paragraph: we have "los saltos de línea y comas" but "tabs" etc. Good.

Now, some technical codes: "row pin/color" – we translated "incúa fijar/color de filas". Good.

Now, to ensure the link mcp:// is not in the input; not.

Now, final output should be only the translation. So we have that.

But we should double-check that any blank lines are preserved. In the input there is a blank line after the table, then "Also worth knowing:" etc. We maintain blank lines. Also there is a blank line before ## Full-text search. We need to include blank lines to separate sections. The output includes blank lines.

Now, ensure no code fence.

We are good.

One more: The original segmentation had "## Configuration" with no content. We include it.

Therefore final output is the text above.

Let's now send| | yandex-wiki-search-mcp | MCP oficial de Yandex (alojado) | ya-yandex-wiki-mcp | slartus/mcp-yandex-wiki | ya-wiki-mcp | | --- | --- | --- | --- | --- | --- | | Búsqueda de texto completo | ✅ hasta 50 resultados, filtros en el servidor + resono de | ❌ sin búsqueda | ✅ | ✅ hasta 10 resultados | ❌ | | Páginas: crear / actualizar / agregar / eliminar + recuperar | ✅ todo, además de dición parciales mediante reempleazo de texto (page_edit) | parciial — no incluye agregar/recuperar; incluye ediciones parciales mediante reempleazo de texto | ✅ todas | parciial — no incluye agregar/recuperar | parciial — no incluye recuperar | | Páginas: clonar a un nuevo slug | ✅ page_clone | ❌ | ❌ | ❌ | ✅ | | Grids: herramientas de escritura | ✅ 11 | ✅ 12, incl. actualización de colores + fijar filas/color | ✅ 11 | ❌ solo lectura | ✅ 11 incl. clonar | | Comentarios, subida de adjuntos | ✅ incl. eliminación, vista previa de imágene incrustado y descarga a disco | ✅ coments ✅ / subida ❌ (descarga + previa en su lúgar) | ✅ | ❌ | ❌ | | Modo de solo lectura en el servidor | ✅ | ❌ | ✅ | ❌ | ❌ | | Esquemas de salida tipados + anotaciones de herramientas | ✅ | ❌ | ❌ | ❌ | ❌ las herramientas devuelven cadenas de texto simples | | Utilidades de YFMF | ✅ recurso con hoja de refencia de sintaxis + yfm_warnings en herramientos de escritura | ❌ | ❌ | ❌ | ✅ conversor de Markdown→YFM + caché de árbol de página, plantillas de prompts | | Docker / PyPI / MCP Registry | ✅ / ✅ / ✅ | — servicio alojado, codigo cerrado, no hay nada que instalar | ✅ / ✅ / ✅ | ❌ instalación manual | ❌ / ✅ / ❌ | | OAuth muliusu OAuth for HTTP despliegues | ✅ | ❌ token por usuario pegado en cabeceras estáticas, sin flujo OAuth | ✅ | ❌ | ❌ |

También vale la pena saber:

• best-doctor/mcp-yandex-wiki (Python) — crear / actualizar páginas de lectura, con un punto de entrada separado de solo lectura -ro; sin borrar / recuperar, sin grids, sin búsqueda; solo en PyPI

• brekhov-ilya/yandex-wiki-mcp (npm) — lectura / escritura / mover, grids de solo lectura; flujo interactivo de token PKCE con auto-refresco, sin búsqueda de texto completo

• n-r-w/yandex-mcp (Go) — Yandex Tracker + Wiki en un servidor, de solo lectura por diseño (5 herramientas de lectura), sin búsqueda; autenticación mediante tokens IAM de la CLI yc únicamente — los tokens OAuth de Yandex no se admiten

• bim-ba/ycli (Python) — un conjunto para Tracker + Wiki + Forms: un CLI, un SDK de Python, un plugin de Claude Code y un servidor MCP cuya superficie de Wiki son 42 herramientas wiki_* (15 de lectura / 27 de escritura, anotadas, con un flag --read-only); sin búsqueda de texto completo, y las descargas de adjuntos se quedan solo en CLI/SDK

Desde agosto de 2026, la búsqueda de texto completo existe solo aquí (hasta 50 resultados) y en slartus (hasta 10) — el servidor alojado de Yandex no incluye una herramienta de búsqueda — y la combinación de búsqueda, escritura de grids, modo solo lectura en servidor y esquemas tipados es única de este proyecto.

EST Es… eh.

Búsqueda de texto completo

page_search envuelve el endpoint POST /v1/search — el mismo backend que alimenta la barra de búsqueda de página web de Wiki, no documentado hasta que Yandex publicó su referencia de API en agosto de 2026. Busca primero, luego abre un resultado con page_get por su slug.

• Dos modos de conexión. Por defecto: hasta 50 resultados en una llamada (limit se limita a 1–50; la API rechaza cualquier otro) y sin paginación — los cursores de la respuesta son siempre null. Con highlight=true: las páginas tienen un límite fijo de 10 resultados independientemente de limit, las coincidencias aparecen envueltas en <em> y cursor (el número de página reflejado en next_cursor) recorre hasta ~100 resultados. El conjunto termina cuando results viene vacío o next_cursor es null en una página no vacía — más allá del final, next_cursor sigue contando sobre páginas vacías, así que por sí solo no indica "hay más".

• Los filtros se ejecutan en el servidor antes del límite — una búsqueda filtrada no pierde coincidencias por eso: slug_prefix (filtro de sección, prefijos profundos como tech-doc/ml son válidos), result_type (page/file), authors (propietarios de página por uid/cloud_uid — user_get_current te proporciona las tuyas, conviviendo en dos llamadas "buscar mis páginas sobre X") y created_between/modified_between (se requieren ambos límites; la API rechaza rangos abiertos).

• Las consultas entre comillas "frase" funcionan; los resultados page obtienen enlaces absolut https://... y los resultados file obtienen enlaces de descarga directa.

• content es un extracto de ~510 caracteres, ni la página ni un resumen: se corta desde el punto donde queda la coincidencia, los términos de búsqueda no tienen que estar dentro de él, y sus saltos de línea y tabulaciones pertenecen a la página (las celdas de tabla llegan separadas por tabuladores), no a separadores entre fragmentos. Pasa highlight=true para obtener precedencias envueltas en <em>. Lee la página con page_get antes de responder desde ella. Vacío para los resultados file.

Recorriendo el árbol

page_get_descendants devuelve un subárbol como una sola lista de {id, slug} de cualquier nivel de profundidad. Pasar from_root=true en vez de page_id/slug recorre una Wiki — el punto de entrada cuando no sabes ningún slug inicial, así no la búsqueda ser el únicol. Prefiere un nivel de árbol cuando lo sepas: la wiki tien miles de página, y fetch_all se detiene en su tope ~500 cón con truncated: true.

Más comportamiento verificado de API (scopes, semántica de 404, "error envelopes", " :110`), docs/api-notees.md.

Configuración

Wait, depending on the processing, the table may have errors. I will correct the table in the final, ensure no "p" missing. Let's review the final answer. I noticed many errors: "Páginas" with accent misplaced, "cón" etc due to quick typing. Let's correct meticulously.

Given the above draft had many typos. I will output a cleaner version. Let's restructure with correct Spanish.

Now, I'm an AI, I can produce clean translation. I should not include errors. Let's produce the final corrected.| | yandex-wiki-search-mcp | MCP oficial de Yandex (alojado) | ya-yandex-wiki-mcp | slartus/mcp-yandex-wiki | ya-wiki-mcp | | --- | --- | --- | --- | --- | --- | | Búsqueda de texto completo | ✅ hasta 50 resultados, filtros del servidor + resaltado | ❌ sin búsqueda | ❌ | ✅ hasta 10 resultados | ❌ | | Páginas: crear / actualizar / agregar / eliminar + recuperar | ✅ todas, además de incidicones parciales mediante reempleplazo de texto (page_edit) | parcial — sin agregar/recuperar; con ediciones parciales mediante reemplazo de texto | ✅ todas | parcial — sin agregar/recuperar | parcial — sin recuperar | | Páginas: clon are a un nuevo slug | ✅ page_clone | ❌ | ❌ | ❌ | ✅ | | Grids: herramientas de escritura | ✅ 11 | ✅ 12, incl. actualización de columna + fijar/color de filas | ✅ 11 | ❌ solo lectura | ✅ 11, incl. clonar | | Comentarios, subida de archivos adjuntos | ✅ incl. eliminación, vista previa de imágiles en línea y descarga a disco | ✅ comentarios /

Con OAUTH_ENABLED=true el servidor se convierte en una persona de identidad (alias: GitHub verificado). Implementación como proveedor de OAuth: Cada usuario MCP entra con su propia cuenta de Yandex, y las solicitudes a la API de Wiki se realizan con su token personal. page_upload_attachment y page_download_attachment no se registran en este modo: leen y escriben archivos en la máquina donde se ejecuta el servidor, que no es la máquina de la persona que llama en un despliegue compartido.

Selección de la organización por usuario. WIKI_ORG_ID / WIKI_CLOUD_ORG_ID son opcionales bajo OAuth, porque cada solicitud puede especificar su propia organización: añade ?orgId=... (o ?cloudOrgId=...) a la dirección del servidor en la que se conecta tu cliente. Un parámetro ´query tiene prioridad sobre la configuración del servidor, por lo que un mismo despliegude puede dar servicio a varias organizaciones. Si una solicitud no lleva ni uno ni otro, la herramienta falla con un mensaje que muestra ambas opciones: define la variable de entorno como valor predeterminado si todos tus usuarios comparten la misma organización.

Consulta el archivo .env.example para la lista completa comentada y compose.yaml para una base con Redis.

Despliegue

flowchart LR
    C["MCP client<br/>Claude / Cursor / Windsurf / VS Code"]
    S["yandex-wiki-search-mcp"]
    W["Yandex Wiki API"]
    R[("Redis<br/>optional OAuth token store")]
    C -- "stdio (local, single user)" --> S
    C -- "streamable-http (+ OAuth, multi-user)" --> S
    S --> W
    S -.-> R

Servidor HTTP mediante Docker (el endpoint MCP es http://localhost:8000/mcp):

docker run --env-file .env -e TRANSPORT=streamable-http -p 8000:8000 \
  --log-opt max-size=10m --log-opt max-file=3 \
  ghcr.io/dlbolshov/yandex-wiki-search-mcp:latest

[!NOTE] El servidor no escribe ningún archivo de registro propio — todo va directamente a stderr, que los controladores de Docker por defecto de json-file conservan sín llevar tamaño. Los parámetros --log-opt anteriores lo limitan; quítalos solo si tu demonio ya tiene una límite por defecto.

services:
  mcp-wiki:
    image: ghcr.io/dlbolshov/yandex-wiki-search-mcp:latest  # or: build: .
    ports:
      - "8000:8000"
    environment:
      - WIKI_TOKEN=${WIKI_TOKEN}
      - WIKI_ORG_ID=${WIKI_ORG_ID}
      - TRANSPORT=streamable-http
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

Para el almacenamiento de OAuth respaldado por Redis, usar el compose.yaml existente como base.

Seguridad

• El modo de solo lectura es del lado: servidor: con WIKI_READ_ONLY=true nunca se registran herramientas de escritura — unquedó un agente callendo.

• Esta API de Wiki no aplica scopes de OAuth (reverificado el 2026-08-11, después de que Yandex documentó los scopes — véase docs/API): un token wiki:read puede aún escribir; y usa el modo de solo lectura en vez de confiar en client scopes.

• Los secretos son SecretStr en todos los lugares — enmascados en logs y en repr; los logs HTTP de DEBUG nunca incluyen cabeceras ni cuerpos.

• La eliminación es recuperable: page_delete devuelve un token de recuperación para <;... page_recover.

• Las claves no relacionadas en .env compartido se ignoran, pero un ajuste mal escrito (WIKI_READ_ONLY) detiene el servidor en lugar de intentar desplazar a una default que no has elegido.

Desarrollo

uv sync --dev
uv run yandex-wiki-search-mcp   # run locally
uv run pytest                   # tests

Antes de confirmar, ejecuta el conjunto completo de verificaciones que se indica en CONTRIBUTING.md.

La estructura del servidor — las capas, el mapa de codigo, los puntos de prueba, la integración CI y el proceso de lanzamiento — se describe en docs/architecture.md. El comportamiento comprobado de la API y los scripts de inspección están documentados en docs/api-notes.md.

La API de Yandex Wiki sufunciona con velocidad (el punto de acceso de búsqueda ya cambió su contrato en silencio una vez, cuando aún no estaba documentado) — scripts/convención_weep.py vuelve a verificar cada método del cliente contra una organización en vivo e infona de discrecia de validación y claves no declaradas:

uv run python scripts/contract_sweep.py users/YOU/contract-sweep            # ~30 live checks
uv run python scripts/contract_sweep.py users/YOU/contract-sweep --cleanup  # remove fixtures

El flujo de trabajo [tique de deriva de la API](.ci/github workflows/api-verificación.yml) ejecuta el mismo análisis semanalmente cuando los secretos del repositorio DRIFT_* están configurados (instrucciones en el encabezado del flujo de trabajo); sin ellos, se omite en silencio.

Créditos

Este proyecto comenzó como un fork de APonkratov/yandex-wiki-mcp (ya-yandex-wiki-mcp) por Aleksandr Ponkratov, un excelente y bien probado servidor MCP en Python para la API de Yandex Wiki, con licencia Apache-2.0. Desde entonces ha desarrollado su propia superficie —búsqueda a texto completo, esquemas de entrada y salida tipados en las 33 herramientas, helpers de YFM, vaciado de cursores, OAuth multiusuario y un rastreo de contrato en vivo contra la API—, mientras se conservan los derechos de autor y la licencia originales (véase LICENSE y NOTICE).

La idea y los hallazgos clave de la API en los que se basa la búsqueda a texto completo provienen de slartus/mcp-yandex-wiki (JavaScript, MIT): fue el primero en descubrir el endpoint POST /v1/search entonces no documentado (Yandex publicó solo en agosto de 2026 una referencia del mismo) y en informar de que los alcances de OAuth no se aplican. No se tomó ningún código de ese proyecto, solo hallazgos e ideas, verificados de nuevo de manera independiente contra una organización real y desarrollados aquí.

Marcas comerciales

«Yandex» y «Yandex Wiki» son marcas comerciales de YANDEX LLC. Este es un proyecto no oficial y de la comunidad: no está afiliado, patrocinado ni respaldado por Yandex. Los nombres se usan de forma nominativa, para indicar el servicio con el que se comunica el servidor. El logotipo es una marca original que no reproduce ni la imagen de Yandex Wiki ni la de MCP (notas de diseño).

mcp-name: io.github.dlbolshov/yandex-wiki-search-mcp