A
licenseNot graded
qualityC
maintenanceMCP server for Outline knowledge base implemented on Rust as one statically linked executable file for Linux/MacOS/Windows.
7
MIT
outline-wiki-mcp
by mnbro
Provides tools for interacting with Outline Wiki's API, enabling management of documents, collections, and other resources in an Outline instance, with support for agentic and read-only modes.
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., "@outline-wiki-mcpvalidate my Outline connection"
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.
outline-wiki-mcp
Safe, control-plane-aware MCP server bootstrap for Outline Wiki.
Current status: implementation-start only. This repository does not claim production readiness, W3/W4/W5 workflow maturity, or C5 conformance.
Scope
TASK-001 implements the project skeleton and initial diagnostics surface:
outline_validate_connectionoutline_capability_reportoutline_diagnostics
Full Outline API coverage, uploads, semantic search, and cross-document analysis are intentionally not implemented in this task.
Related MCP server: Linux MCP Server
Configuration
OUTLINE_BASE_URL=https://outline.example.com
OUTLINE_API_TOKEN=...
OUTLINE_MCP_MODE=agentic
OUTLINE_READ_ONLY=trueSafe defaults:
agentic mode is the default
read-only mode is the default
secrets are redacted from diagnostics and errors
Outline content is treated as untrusted data when content tools are added
MCP Client
{
"mcpServers": {
"outline-wiki-mcp": {
"command": "uv",
"args": ["run", "outline-wiki-mcp"],
"env": {
"OUTLINE_BASE_URL": "https://outline.example.com",
"OUTLINE_API_TOKEN": "..."
}
}
}
}Development
uv lock
uv run ruff check .
uv run pytest
uv run python -m mypy src tests
uv build
uv pip check
uv run mkdocs build --strictLicense
This project is licensed under the PolyForm Internal Use License 1.0.0.
You may use the software for internal business purposes, including internal commercial operations. You may not distribute, sublicense, transfer, resell, or include the software in custom solutions, hosted services, managed services, SaaS offerings, or packaged products sold or delivered to third parties unless a separate commercial license is granted.
See the LICENSE file for the full legal terms.
Available Tools
3 toolsoutline_capability_reportARead-onlyIdempotent
Return v0.2 control-plane capability metadata.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, covering safety and behavior. The description adds only the version hint ('v0.2'), which provides minor additional context beyond the annotations.
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, self-contained sentence that is front-loaded and contains no unnecessary words. It is highly concise.
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?
Given zero parameters and the presence of an output schema, the description is adequate but could be slightly more informative about what 'capability metadata' entails. It is nearly complete for a simple metadata retrieval tool.
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?
The input schema has zero parameters, so the description does not need to add parameter meaning. Baseline for 0 parameters is 4, and no further elaboration is required.
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 ('Return') and resource ('control-plane capability metadata') with versioning ('v0.2'), clearly distinguishing it from siblings like outline_diagnostics and outline_validate_connection.
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. The description does not mention any context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
outline_diagnosticsARead-onlyIdempotent
Return safe runtime diagnostics without secrets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds the important caveat 'without secrets', providing additional transparency beyond annotations.
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?
Single sentence, no unnecessary words, front-loaded with the core function. Every element is essential.
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?
Given zero parameters, comprehensive annotations (readOnly, idempotent, etc.), and existence of an output schema, the description is complete. It succinctly covers the behavioral and safety aspects needed for an agent to invoke correctly.
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?
Input schema has zero parameters, so schema coverage is 100% trivially. With no parameters to describe, the description adds no param info, but per rules baseline is 4.
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 returns safe runtime diagnostics without secrets. It is specific and concise, but does not differentiate from sibling tools like outline_capability_report or outline_validate_connection.
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 obtaining runtime diagnostics, but provides no explicit guidance on when to use this tool versus alternatives 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_validate_connectionARead-onlyIdempotent
Validate Outline token and API connectivity safely.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which cover safety and idempotency. The description adds the word 'safely', but no additional behavioral traits beyond what annotations provide.
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 with no wasted words. It efficiently communicates the tool's purpose.
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 simple validation tool with no parameters and an existing output schema, the description sufficiently covers what the tool does. No additional context is needed.
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?
The tool has no parameters, so the description does not need to explain parameter semantics. Baseline score of 4 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 validates an Outline token and API connectivity, using a specific verb and resource. It distinguishes itself from siblings like outline_capability_report and outline_diagnostics.
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 description implies this is a safe check to perform before other operations, but it does not explicitly state when to use it versus alternatives, nor does it mention exclusions. The straightforward nature of the tool makes this a minor gap.
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.
3 tool updates
v0.1.0- First observed
outline_capability_report - First observed
outline_diagnostics - First observed
outline_validate_connection
TDQS
A4.2/5.0
Scored across 3 tools
Disambiguation5/5
Each tool has a distinct purpose: capability report for metadata, diagnostics for runtime info, and connection validation. No overlap.
Naming Consistency5/5
All tools follow a consistent 'outline_X' snake_case pattern, making them predictable.
Tool Count5/5
With only 3 tools, the scope is narrow but well-defined for a health-check server; each tool is necessary.
Completeness5/5
The tool set covers all essential aspects of server capability reporting, diagnostics, and connection validation without missing operations.
Maintenance
ActivitySlowing
ResponsivenessSyncing
Related MCP Connectors
Read-only MCP server: let AI agents read your ORANO saved-video library, tasks, and memory.
1Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
Read-only MCP server exposing a user ORANO library to their own AI agent.
Related MCP Servers
- AlicenseAqualityAmaintenanceAn MCP server for read-only Linux system administration and diagnostics on RHEL-based systems via SSH. It enables users to troubleshoot remote hosts by accessing system information, services, logs, and network configurations through natural language.19615 PyPI299Apache 2.0
- AlicenseNot gradedqualityDmaintenanceThis MCP server provides read-only Linux system diagnostics tools for inspecting system information, processes, and log snapshots. It enables AI models to analyze Linux system health, troubleshoot issues, and review security through workflow prompts and HTTP transport with API key authentication.MIT
- AlicenseNot gradedqualityCmaintenanceA read-only MCP server for AI coding agents to inspect repositories, audit code quality, route engineering skills, and plan safe issue/PR workflows.1MIT