Provides access to Backbone.js documentation chapters as readable resources and enables full-text search across all chapters with excerpt generation
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Backbone.js Documentation MCP Server search for how to handle model validation in Backbone.js"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Servidor MCP (Model Context Protocol) que expone capítulos Markdown de Backbone.js como recursos legibles y añade una tool para búsqueda full‑text sobre dichos capítulos.
name: Edwin Andrés Legro Agudelo
GitHub: https://github.com/elegroag
Related MCP server: SAP Fiori Jetpack Compose UI SDK Documentation MCP Server
Recursos por capítulo: cada capítulo Markdown se registra como recurso MCP con nombre y URI estable (backbone://chapter/NN).
Lectura de contenidos: devuelve el texto plano del capítulo solicitado.
Búsqueda: tool search-backbone que busca texto en todos los capítulos y devuelve enlaces a los recursos con coincidencias y un extracto.
Tipado y validación: Zod (v3) para validar argumentos de tools.
src/server.ts: arranque del servidor MCP, registro de recursos y tool search-backbone.
src/mcp-server.ts: utilidades para listar recursos (listResources), leer contenido (readResource) y buscar (searchResources).
src/markdown-reader.ts: lectura/normalización de archivos Markdown.
src/types.ts: tipos compartidos (por ejemplo, resultados de búsqueda).
docs/: capítulos Markdown de Backbone.js.
Node.js 18+ (recomendado 20+)
pnpm
pnpm install
pnpm buildModo desarrollo (STDIO):
pnpm startEsto lanza tsx ./src/server.ts y expone el servidor por STDIO.
Con MCP Inspector (UI web) usando STDIO del servidor:
npx @modelcontextprotocol/inspector npx -y tsx ./src/server.tsAbre el navegador con el Inspector. Desde ahí podrás listar recursos y ejecutar tools.
Por cada capítulo detectado en docs/:
Nombre: backbone-chapter-NN
URI: backbone://chapter/NN
mimeType: text/markdown (o el deducido por el lector)
Lectura (readResource): devuelve { contents: [{ uri, text }] } con el contenido del capítulo.
title: "Buscar en capítulos Backbone"
description: Busca texto en los capítulos Markdown y devuelve enlaces a los capítulos con coincidencias.
inputSchema:
query: string (mín. 2)
caseSensitive?: boolean
maxExcerpts?: number (1–5)
respuesta:
content: lista con un bloque text (resumen) y múltiples resource_link hacia backbone://chapter/NN con un primer extracto como description.
Tool: search-backbone
Arguments:
{
"query": "modelo",
"caseSensitive": false,
"maxExcerpts": 3
}Compilar TypeScript:
pnpm buildEjecutar pruebas manuales desde Inspector o cualquier cliente MCP compatible.
Configuración TS relevante (tsconfig.json):
module: nodenext, strict: true, skipLibCheck: true.
Error MCP error -32603: keyValidator._parse is not a function:
Causa: incompatibilidad entre Zod v4 y el SDK/zod-to-json-schema.
Solución aplicada: Zod fijado a v3 ("zod": "^3.23.8").
Ejecuta pnpm install && pnpm build tras el cambio.
pnpm build — compila TypeScript a dist/.
pnpm start — ejecuta el servidor MCP por STDIO con tsx.
Diseño modular: separación en server, services/utils (mcp-server.ts), readers, y types.
Validación a nivel de borde (Zod v3) para inputs de tools.
Código limpio y responsabilidad única por módulo.
MIT. Ver LICENSE.
Busca texto en los capítulos Markdown y devuelve enlaces a los capítulos con coincidencias.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Texto a buscar | |
| caseSensitive | No | Distinguir mayúsculas/minúsculas | |
| maxExcerpts | No | Número de fragmentos por capítulo |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions searching and returning links, but does not cover important aspects like whether this is a read-only operation, potential rate limits, authentication needs, or how results are formatted (e.g., pagination). For a search tool with zero annotation coverage, this is a significant gap.
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, efficient sentence that clearly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
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 moderate complexity (search with three parameters) and no output schema, the description is minimally adequate. It covers what the tool does but lacks details on behavioral traits and output format. With no annotations, it should do more to compensate, but the clear purpose and concise structure keep it from being lower.
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 description coverage is 100%, meaning all parameters are documented in the schema itself. The description does not add any additional meaning or context beyond what the schema provides (e.g., it doesn't explain how 'maxExcerpts' affects output or provide examples). Baseline 3 is appropriate when the schema does the heavy lifting.
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's purpose: 'Busca texto en los capítulos Markdown y devuelve enlaces a los capítulos con coincidencias' (Search text in Markdown chapters and returns links to chapters with matches). It specifies the verb (search), resource (Markdown chapters), and output (links to matching chapters). However, since there are no sibling tools mentioned, it cannot distinguish from alternatives, preventing a perfect score of 5.
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 no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or specific contexts for usage. With no sibling tools, there is no explicit comparison, but general usage context is still missing.
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.
search-backboneScored across 1 tool
With only one tool, there is no possibility of confusion or overlap between tools. The tool has a single, clearly defined purpose of searching text in Markdown chapters.
The single tool name 'search-backbone' follows a consistent verb-noun pattern (search-backbone), and with only one tool, there is no inconsistency to evaluate. The naming is clear and appropriate for its function.
A single tool is too few for a documentation server's apparent scope, which typically involves multiple operations like browsing, filtering, or retrieving specific sections. This minimal set limits functionality and may cause agent failures in complex tasks.
The tool surface is severely incomplete for a documentation server. While search is useful, there are obvious gaps such as retrieving chapter lists, accessing specific chapters by title or ID, or navigating documentation structure, which are essential for comprehensive documentation interaction.
Anonymous read and search over the published nowyourlink developer documentation.
Read-only search and Markdown access to liz's public docs, prompts, resources, and an MCP App.
Provides access to Google's public developer documentation.
Versioned documentation registry and semantic search for AI tools and coding assistants.