Skip to main content
Glama
bysonte

Outline MCP Server

by bysonte
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Outline MCP Server

Servidor Model Context Protocol para integrar Outline con clientes MCP. Permite que un asistente o agente compatible consulte, busque y gestione documentos de una instancia de Outline mediante su API.

Para Qué Sirve

Este servidor actúa como puente entre un cliente MCP y Outline. Una vez configurado, el cliente puede invocar herramientas para leer documentación interna, buscar contenido, crear notas, actualizar documentos y consultar colecciones.

Casos de uso típicos:

  • Consultar la base de conocimiento de Outline desde un asistente de IA.

  • Buscar documentación interna sin salir del cliente MCP.

  • Crear o actualizar documentos en Markdown desde flujos automatizados.

  • Usar Outline como memoria documental editable para agentes.

Related MCP server: Grist MCP Server

Características

  • Lectura de documentos por ID.

  • Búsqueda de texto en documentos de Outline.

  • Listado de documentos, con filtro opcional por colección.

  • Creación de documentos con contenido Markdown.

  • Actualización de título, contenido y estado de publicación.

  • Eliminación de documentos.

  • Listado de colecciones.

  • Consulta de información de una colección concreta.

  • Transporte MCP por stdio por defecto, ideal para clientes locales.

  • Transporte Streamable HTTP opcional para despliegues remotos.

  • Modo solo lectura para ocultar herramientas de escritura.

  • Timeout HTTP y reintentos acotados ante errores temporales de Outline.

  • Validación de argumentos con esquemas Zod mediante el SDK MCP actual.

Requisitos

  • Node.js >=18.

  • Una instancia de Outline accesible por URL.

  • Un token de API de Outline con permisos suficientes para las operaciones que quieras usar.

Instalación Rápida Con npx

La forma más sencilla es configurarlo directamente en tu cliente MCP usando npx:

{
  "mcpServers": {
    "outline": {
      "command": "npx",
      "args": ["-y", "getoutline-mcp-server"],
      "env": {
        "OUTLINE_BASE_URL": "https://tu-instancia-outline.com",
        "OUTLINE_API_KEY": "tu-token-de-api"
      }
    }
  }
}

Instalación Desde Código Fuente

npm install
npm run build
npm start

Para desarrollo:

npm run dev

Para recompilar automáticamente mientras editas:

npm run watch

Configuración

El servidor lee la configuración desde variables de entorno:

OUTLINE_BASE_URL=https://tu-instancia-outline.com
OUTLINE_API_KEY=tu-token-de-api
OUTLINE_READ_ONLY=false
MCP_TRANSPORT=stdio
MCP_HTTP_HOST=127.0.0.1
MCP_HTTP_PORT=3000
MCP_HTTP_PATH=/mcp
OUTLINE_MAX_RETRIES=2
OUTLINE_RETRY_BASE_DELAY_MS=100
# OUTLINE_HTTP_TIMEOUT_MS=10000

Puedes tomar env.example como referencia.

Variables disponibles:

Variable

Default

Descripción

OUTLINE_BASE_URL

requerido

URL base de tu instancia de Outline.

OUTLINE_API_KEY

requerido

Token de API de Outline. No se imprime en logs.

OUTLINE_READ_ONLY

false

Si es true, no registra outline_create_document, outline_update_document ni outline_delete_document.

MCP_TRANSPORT

stdio

Transporte MCP: stdio o http. Valores inválidos fallan al arrancar.

MCP_HTTP_HOST

127.0.0.1

Host de escucha para Streamable HTTP. Usa 0.0.0.0 solo si el despliegue lo protege correctamente.

MCP_HTTP_PORT

3000

Puerto HTTP cuando MCP_TRANSPORT=http.

MCP_HTTP_PATH

/mcp

Path HTTP del endpoint MCP. Debe empezar con /.

OUTLINE_MAX_RETRIES

2

Reintentos máximos por endpoint para 429, 5xx y errores transitorios de red. Usa 0 para desactivar.

OUTLINE_RETRY_BASE_DELAY_MS

100

Delay base para backoff acotado entre reintentos.

OUTLINE_HTTP_TIMEOUT_MS

sin valor

Timeout opcional en milisegundos para Axios.

Modo Solo Lectura

Con OUTLINE_READ_ONLY=true, el servidor no expone las herramientas de escritura en tools/list. Las herramientas ocultas son outline_create_document, outline_update_document y outline_delete_document.

Aunque actives este modo, usa también un token de Outline con permisos mínimos de lectura siempre que tu instancia lo permita.

Transporte Streamable HTTP

stdio sigue siendo el transporte por defecto y no requiere configurar variables HTTP. Para exponer el servidor por Streamable HTTP:

MCP_TRANSPORT=http
MCP_HTTP_HOST=127.0.0.1
MCP_HTTP_PORT=3000
MCP_HTTP_PATH=/mcp
npm start

El endpoint queda disponible en http://127.0.0.1:3000/mcp con transporte Streamable HTTP del SDK MCP. Si necesitas exponerlo fuera de la máquina local, cambia MCP_HTTP_HOST, por ejemplo a 0.0.0.0, y protege el acceso desde la red o un proxy.

Este cambio no agrega autenticación propia al endpoint HTTP. En producción, publícalo solo detrás de una red confiable, VPN, reverse proxy con autenticación, reglas de firewall o controles equivalentes.

Timeout Y Reintentos

El cliente de Outline puede reintentar errores temporales: 429, 500, 502, 503, 504, ECONNRESET, ETIMEDOUT y ECONNABORTED. No reintenta errores permanentes como 400, 401 o 403.

Configura OUTLINE_MAX_RETRIES=0 para desactivar reintentos. Define OUTLINE_HTTP_TIMEOUT_MS solo si quieres imponer un timeout explícito a las llamadas HTTP hacia Outline.

Cómo Obtener El Token De Outline

  1. Entra en tu instancia de Outline.

  2. Abre Settings.

  3. Ve a API Tokens.

  4. Crea un token nuevo.

  5. Usa ese valor como OUTLINE_API_KEY.

Recomendación: crea un token con los permisos mínimos necesarios para tu caso de uso.

Configuración En Clientes MCP

Cliente Local Con npx

{
  "mcpServers": {
    "outline": {
      "command": "npx",
      "args": ["-y", "getoutline-mcp-server"],
      "env": {
        "OUTLINE_BASE_URL": "https://tu-instancia-outline.com",
        "OUTLINE_API_KEY": "tu-token-de-api"
      }
    }
  }
}

Cliente Local Desde Este Repositorio

Primero compila el proyecto:

npm run build

Luego apunta el cliente al archivo compilado:

{
  "mcpServers": {
    "outline": {
      "command": "node",
      "args": ["/ruta/absoluta/outline-mcp-server/dist/index.js"],
      "env": {
        "OUTLINE_BASE_URL": "https://tu-instancia-outline.com",
        "OUTLINE_API_KEY": "tu-token-de-api"
      }
    }
  }
}

En Windows, usa una ruta absoluta válida, por ejemplo:

"args": ["D:/work/outline-mcp-server/dist/index.js"]

OpenCode

OpenCode usa una forma de configuración distinta a otros clientes MCP: el comando va como un array único y las variables del proceso van en environment, no en env.

Ejemplo para C:\Users\gbaso\.config\opencode\opencode.json:

{
  "mcp": {
    "outline": {
      "type": "local",
      "command": [
        "node",
        "D:/work/outline-mcp-server/dist/index.js"
      ],
      "enabled": true,
      "environment": {
        "OUTLINE_BASE_URL": "https://tu-instancia-outline.com",
        "OUTLINE_API_KEY": "tu-token-de-api"
      }
    }
  }
}

Si usas env en OpenCode, el servidor puede arrancar sin OUTLINE_BASE_URL y OUTLINE_API_KEY, fallar al inicio y aparecer en logs como server unavailable key=outline type=local status=failed.

Los logs de OpenCode en Windows están en:

C:\Users\gbaso\.local\share\opencode\log\opencode.log

Después de modificar opencode.json, reinicia OpenCode. La configuración de MCP se carga al inicio y no se recarga en caliente.

Herramientas Disponibles

outline_get_document

Obtiene un documento por ID.

Parámetros:

  • id: ID del documento.

Ejemplo:

{
  "name": "outline_get_document",
  "arguments": {
    "id": "document-id"
  }
}

outline_search_documents

Busca documentos en Outline.

Parámetros:

  • query: texto de búsqueda.

  • limit: número máximo de resultados. Por defecto 25, máximo 100.

Ejemplo:

{
  "name": "outline_search_documents",
  "arguments": {
    "query": "documentación del proyecto",
    "limit": 10
  }
}

outline_list_documents

Lista documentos, opcionalmente filtrados por colección.

Parámetros:

  • collectionId: ID opcional de la colección.

  • limit: número máximo de resultados. Por defecto 25, máximo 100.

outline_create_document

Crea un documento con contenido Markdown.

Parámetros:

  • title: título del documento.

  • text: contenido en Markdown.

  • collectionId: ID opcional de la colección.

  • parentDocumentId: ID opcional del documento padre.

  • publish: si debe publicarse inmediatamente. Por defecto false.

Ejemplo:

{
  "name": "outline_create_document",
  "arguments": {
    "title": "Plan del proyecto",
    "text": "# Plan\n\nContenido inicial del documento.",
    "collectionId": "collection-id",
    "publish": true
  }
}

outline_update_document

Actualiza un documento existente.

Parámetros:

  • id: ID del documento.

  • title: nuevo título, opcional.

  • text: nuevo contenido Markdown, opcional.

  • publish: cambia el estado de publicación, opcional.

outline_delete_document

Elimina un documento por ID.

Parámetros:

  • id: ID del documento.

outline_list_collections

Lista todas las colecciones disponibles.

No requiere parámetros.

outline_get_collection

Obtiene información de una colección por ID.

Parámetros:

  • id: ID de la colección.

Desarrollo

Estructura principal:

src/
├── index.ts           # Servidor MCP y registro de herramientas
└── outline-client.ts  # Cliente HTTP para la API de Outline

Scripts disponibles:

  • npm run build: compila TypeScript en dist/.

  • npm test: ejecuta la suite Vitest sin credenciales reales de Outline.

  • npm run test:coverage: ejecuta tests con cobertura global mínima del 85%.

  • npm start: ejecuta dist/index.js.

  • npm run dev: compila y ejecuta el servidor.

  • npm run watch: recompila al detectar cambios.

Seguridad

  • No incluyas OUTLINE_API_KEY en commits, logs ni documentación pública.

  • Usa variables de entorno o el sistema de secretos de tu cliente MCP.

  • Evita tokens con permisos excesivos si el cliente solo necesita lectura.

  • Ten cuidado con herramientas de escritura o borrado: el servidor puede modificar tu instancia de Outline.

  • Si usas MCP_TRANSPORT=http, protege el endpoint con controles externos; el servidor no implementa autenticación HTTP propia.

Limitaciones Actuales

  • No implementa rate limiting interno; si haces muchas llamadas, depende de los límites de Outline.

  • Las respuestas de Outline se devuelven como JSON de la API, con tipos TypeScript pragmáticos pero sin validación runtime exhaustiva de cada campo.

  • El transporte HTTP es stateless; no agrega sesiones persistentes ni autenticación propia.

Licencia

MIT. Consulta LICENSE para más detalles.

Available Tools

8 tools
outline_create_documentCrear documento en OutlineC

Crea un documento en Outline con contenido Markdown.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleYesTítulo del documento
textYesContenido del documento en Markdown
collectionIdNoID opcional de la colección
parentDocumentIdNoID opcional del documento padre
publishNoPublica el documento inmediatamente

TDQS

C2.8/5.0
Behavior2/5

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

No annotations are present, and the description adds no behavioral context beyond the schema. It does not disclose authentication needs, side effects, or return behavior, which is critical for a tool with no output schema.

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, making it concise, but it lacks structure and additional context that would justify a higher score.

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 lack of an output schema and no annotations, the description should provide more context about return values or post-creation behavior. It is incomplete for a creation tool.

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?

Schema coverage is 100% with descriptions for all 5 parameters. The tool description adds no additional parameter meaning, meeting the baseline expectation but not exceeding it.

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 ('creates'), resource ('document in Outline'), and content type ('Markdown'). It implicitly distinguishes from siblings like outline_update_document and outline_delete_document by specifying creation.

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. There is no mention of prerequisites, context, or when not to use it.

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

outline_delete_documentEliminar documento de OutlineB

Elimina un documento de Outline por ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesID del documento a eliminar

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations and minimal description, the tool does not disclose behavioral traits such as whether deletion is permanent, requires confirmation, or impacts related resources. The description only states what it does, not its consequences.

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

Conciseness4/5

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

The description is a single, front-loaded sentence with no wasted words. However, it could be slightly expanded to include key behavior points without losing conciseness.

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?

For a simple delete operation with one parameter and no output schema, the description is minimally adequate but lacks context on error handling, return values, or side effects. It suffices for basic use but leaves gaps.

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?

Schema coverage is 100% (one parameter with description). The description adds marginal value by restating the parameter's purpose ('por ID'), but does not provide format details or constraints beyond the schema.

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 'Elimina' (delete) and the resource 'documento de Outline', distinguishing it from sibling tools like outline_create_document or outline_update_document.

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, nor any prerequisites or restrictions. The agent is left to infer context from the tool name alone.

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

outline_get_collectionObtener colección de OutlineB

Obtiene información de una colección concreta de Outline.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesID de la colección a recuperar

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states 'gets info' with no mention of side effects, auth needs, rate limits, or what information is returned. This is insufficient for a read operation.

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

Conciseness4/5

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

The description is very short and efficient, with no wasted words. It is appropriate for a simple retrieval tool, though slightly more detail could be added without losing conciseness.

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?

The tool is simple with one parameter and no output schema, but the description lacks information about the output format or any constraints. It is minimally complete but could be improved.

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?

Schema coverage is 100%, and the parameter 'id' is already described in the input schema. The description does not add any meaning beyond the schema, so baseline 3 is appropriate.

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 obtains information of a specific Outline collection, using the verb 'obtiene' and specifying 'colección concreta', which distinguishes it from list_collections and other sibling tools.

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?

No explicit guidance on when to use this tool versus alternatives like outline_list_collections or outline_get_document. The purpose implies use for a specific collection, but no when-not or prerequisites are mentioned.

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

outline_get_documentObtener documento de OutlineB

Obtiene un documento concreto de Outline por ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesID del documento a recuperar

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as idempotency, authentication requirements, or error conditions. The description is too minimal to inform the agent about side effects or constraints.

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

Conciseness4/5

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

The description is concise and front-loaded with the key action and resource. One sentence suffices for a simple retrieval tool, though it lacks structural elements like usage notes or examples.

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 low complexity (one param, no output schema, no nested objects), the description is minimally adequate. It could be improved by mentioning that it returns the full document object or by noting if the tool is read-only.

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?

Schema coverage is 100% for the single parameter 'id', which has a clear description. The tool description adds little beyond restating that it retrieves by ID, so it meets the baseline without providing extra context.

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 verb 'obtiene' (gets) and the resource 'documento concreto de Outline por ID' (specific document by ID), which effectively distinguishes it from sibling tools like outline_list_documents and outline_search_documents.

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?

No explicit guidance is provided on when to use this tool versus alternatives. However, the name and context of sibling tools imply it is for retrieving a single document by its ID when the ID is known, which is a common pattern.

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

outline_list_collectionsListar colecciones de OutlineA

Lista todas las colecciones disponibles en Outline.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states a read operation but fails to mention any behavioral traits such as authentication requirements, pagination, return format, or performance implications for large datasets.

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

Conciseness4/5

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

The description is a single concise sentence that is front-loaded with the action. It is appropriately sized for a zero-parameter tool, with no wasted words.

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 no output schema, the description should explain what is returned (e.g., list of collection names or metadata). It does not, leaving gaps about the response format. For a simple tool, it is adequate but not fully complete.

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?

Schema coverage is 100% (empty schema), so baseline is 3. The description adds essential meaning by explaining the tool's effect (listing all collections), which is not captured in the empty schema. It provides value beyond the structured fields.

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 provides a specific verb 'listar' (list) and resource 'colecciones' (collections), clearly indicating the tool's function. It effectively distinguishes from sibling tools that deal with single collections or documents.

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 implies usage for listing all collections but offers no explicit guidance on when to use this tool versus alternatives like outline_get_collection or outline_list_documents. No exclusions or context are provided.

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

outline_list_documentsListar documentos de OutlineC

Lista documentos de Outline, opcionalmente filtrados por colección.

ParametersJSON Schema
NameRequiredDescriptionDefault
collectionIdNoID opcional de la colección
limitNoNúmero máximo de resultados

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries full burden but only states basic filtering. It omits behavioral traits like pagination (implied by limit parameter), ordering, error handling, and whether it returns all documents or just metadata.

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

Conciseness4/5

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

The description is a single concise sentence with no wasted words. However, it could be restructured to front-load the key action and include critical usage hints without losing brevity.

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?

Lacks explanation of return values (no output schema), pagination behavior, and guidance relative to outline_search_documents. The description is too minimal for a tool with no output schema and several siblings.

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?

Schema description coverage is 100%, so the description adds no additional meaning beyond 'filtered by collection.' Baseline 3 is appropriate as the description does not clarify when to use each parameter or provide extra context.

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 tool lists Outline documents with optional collection filtering. The verb 'list' distinguishes it from create, delete, update, and search siblings, though it doesn't explicitly contrast with outline_search_documents.

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 vs alternatives like outline_search_documents, and no prerequisites or limitations mentioned. The description only states what it does without context for selection.

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

outline_search_documentsBuscar documentos de OutlineA

Busca documentos en toda la instancia de Outline.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesTexto de búsqueda
limitNoNúmero máximo de resultados

TDQS

A3.6/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits like idempotency, authentication needs, or that it is a read-only operation. The agent lacks critical safety information.

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

Conciseness4/5

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

The description is a single sentence conveying the core purpose. It is concise but could be slightly more informative without becoming verbose.

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?

With full schema parameter coverage but no output schema or description of return value format, the description lacks completeness. Missing details like response structure (e.g., list of document IDs vs full documents) and pagination behavior.

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?

Schema description coverage is 100% with clear parameter descriptions ('search text', 'max results'). The tool description adds no extra parameter meaning, so baseline 3 is appropriate.

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 'search documents across the entire Outline instance', specifying verb (search), resource (documents), and scope (entire instance). This distinguishes it from sibling tools like get_document or list_documents.

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?

The verb 'search' implies use when needing to find documents by query. While not explicitly stating when-not or alternatives, it is clear enough for selecting this tool over others.

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

outline_update_documentActualizar documento de OutlineB

Actualiza el título, contenido o estado de publicación de un documento de Outline.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesID del documento a actualizar
titleNoNuevo título del documento
textNoNuevo contenido del documento en Markdown
publishNoPublica el documento

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the burden. It states the tool updates title, content, or publication status, which is clear but lacks details on idempotency, side effects, or whether updates are partial. This is adequate but minimal.

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

Conciseness4/5

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

The description is a single concise sentence with no wasted words. It is front-loaded and efficient, though it could benefit from brief expansion.

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 no annotations and no output schema, the description provides basic purpose but lacks details on behavior (e.g., response, partial updates). It is complete enough for a simple update but could be improved for a mutation tool.

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?

Schema coverage is 100%, so the description adds no additional meaning beyond the parameter descriptions. The description lists the fields but does not enrich the semantics.

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 updates title, content, or publication status of an Outline document. It uses specific verbs and resources, and distinguishes from sibling tools like outline_create_document and outline_delete_document.

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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. It simply states what it does without usage context.

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. 8 tool updatesv1.0.0
    • First observedoutline_create_document
    • First observedoutline_delete_document
    • First observedoutline_get_collection
    • First observedoutline_get_document
    • First observedoutline_list_collections
    • First observedoutline_list_documents
    • First observedoutline_search_documents
    • First observedoutline_update_document
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Scored across 8 tools

Disambiguation5/5

Each tool targets a distinct resource (document or collection) and action (create, delete, get, list, search, update), with no overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent 'outline_verb_noun' pattern using snake_case, making the naming predictable and easy to understand.

Tool Count5/5

8 tools are well-scoped for an Outline knowledge base server, covering essential document operations and collection queries without unnecessary bloat.

Completeness4/5

Document CRUD and search are complete, but collection management is limited to get and list, missing create/update/delete for collections, which is a minor gap.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers