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., "@MCP Azure Documentation Server Search Azure documentation for how to deploy a virtual machine"
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.
An MCP (Model Context Protocol) server that provides search and retrieval tools for Azure documentation. This server enables AI assistants like Claude to search and read Azure documentation directly from the MicrosoftDocs/azure-docs repository.
Full-text search using SQLite FTS5 with BM25 ranking and Porter stemming
Section filtering to narrow search results by Azure service or product (e.g. azure-functions, storage, app-service)
Sparse checkout for efficient cloning of only the articles directory from azure-docs
Docker support for portable deployment across projects
STDIO transport for seamless MCP client integration
Related MCP server: Azure Updates MCP Server
The martoc/mcp-azure-documentation container image is published to Docker Hub with the documentation index pre-built. Available for linux/amd64 and linux/arm64.
# Pull and run the server
docker run -i --rm martoc/mcp-azure-documentation:latest# Build the Docker image (includes pre-indexed documentation)
make docker-build
# Test the server
make docker-run# Initialise the environment
make init
# Build the documentation index
make index
# Run the server
make runThe martoc/mcp-azure-documentation container image is published to Docker Hub. It includes the pre-built documentation index so the server is ready to use immediately.
Property | Value |
Registry | Docker Hub |
Image |
|
Platforms |
|
Base image |
|
Index | Pre-built at image build time from |
# Pull the latest image
docker pull martoc/mcp-azure-documentation:latest
# Run the MCP server
docker run -i --rm martoc/mcp-azure-documentation:latestAdd to your .mcp.json or global settings to use the published container image:
{
"mcpServers": {
"azure-documentation": {
"command": "docker",
"args": ["run", "-i", "--rm", "martoc/mcp-azure-documentation:latest"]
}
}
}For a locally built Docker image:
{
"mcpServers": {
"azure-documentation": {
"command": "docker",
"args": ["run", "-i", "--rm", "mcp-azure-documentation"]
}
}
}For local development without Docker:
{
"mcpServers": {
"azure-documentation": {
"command": "uv",
"args": ["run", "mcp-azure-documentation"],
"cwd": "/path/to/mcp-azure-documentation"
}
}
}Tool | Description |
| Search Azure documentation by keyword query with optional section filtering |
| Retrieve the full content of a specific documentation page |
Search Azure documentation using full-text search with stemming support.
Parameter | Type | Required | Default | Description |
| string | Yes | - | Search terms (supports stemming) |
| string | No | None | Filter by section (Azure service/product directory) |
| integer | No | 10 | Maximum results (1-50) |
Common Sections: azure-functions, app-service, storage, virtual-machines, aks, azure-sql, cosmos-db, active-directory, azure-monitor
Retrieve the full content of a documentation page.
Parameter | Type | Required | Description |
| string | Yes | Relative path to document (from search results) |
# Build/rebuild the documentation index
uv run azure-docs-index index
uv run azure-docs-index index --rebuild
uv run azure-docs-index index --branch main
# Show index statistics
uv run azure-docs-index statsmake init # Initialise development environment
make build # Run full build (lint, typecheck, test)
make test # Run tests with coverage
make format # Format code
make lint # Run linter
make typecheck # Run type checkerUSAGE.md - Detailed usage instructions
CODESTYLE.md - Code style guidelines
CLAUDE.md - Claude Code instructions
This project is licensed under the MIT Licence - see the LICENSE file for details.
Read the full content of a specific Azure documentation page.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | The relative path to the documentation file (e.g., 'azure-functions/consumption-plan.md'). This path is returned in search results. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior; 'Read' conveys that the operation is non-destructive, which is the key safety trait for tool selection. However, it does not disclose error behavior for invalid paths, auth requirements, or content format, though an output schema exists to cover the return shape.
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?
A single sentence that leads with the verb, names the object, and qualifies the scope; there is zero wasted text. This is appropriately sized for a one-parameter read tool.
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?
For a low-complexity read tool with a fully documented single parameter and an output schema, the essential information is present. The only gap is explicit routing guidance against the sibling search workflow, which is partially bridged by the schema hint that paths come from search results.
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?
Schema description coverage is 100%, so the single path parameter is already fully documented with an example and provenance ('returned in search results'). The description adds no parameter-level detail, but the baseline of 3 applies because 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 states a specific verb (read), a resource (an Azure documentation page), and scope ('full content' of a 'specific' page). This implicitly distinguishes it from the sibling search_documentation, which finds pages rather than returns their content, though the alternative is not named explicitly.
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 text gives no explicit when-to-use guidance, but the schema's path description ('This path is returned in search results') implies the intended workflow of searching first and then reading the chosen page. There are no exclusions or named alternatives, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Azure documentation by keyword query.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 10, max: 50). | |
| query | Yes | Search terms to find in the documentation. Supports full-text search with stemming (e.g., "deploy" matches "deploying", "deployment", "deployments"). | |
| section | No | Optional section to filter results, corresponding to an Azure service or product directory (e.g., 'azure-functions', 'app-service', 'storage', 'virtual-machines'). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 disclosing behavior. It only states the basic action without mentioning any behavioral traits such as result ordering, pagination, or read-only safety. The limit parameter in the schema hints at result control, but the description itself adds no behavioral transparency.
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 with no extraneous words. It front-loads the core purpose immediately and does not waste tokens. This is exemplary conciseness for a tool definition.
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?
While the schema and output schema provide structured details, the description lacks guidance on usage context relative to the sibling tool. For a search tool with three parameters, the description could mention the difference between searching and reading, or indicate the scope of the search. As is, it is minimally adequate but not fully complete.
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%, with detailed explanations for each parameter (e.g., query supports stemming, limit has default/max, section filters by service). Since the schema already provides thorough parameter semantics, the description adds no additional meaning, so a baseline score of 3 is appropriate.
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 function: 'Search Azure documentation by keyword query.' It specifies a concrete verb (search) and resource (Azure documentation), making the purpose evident. However, it does not differentiate this tool from its sibling 'read_documentation,' so while it is not a tautology, it misses an opportunity to clarify the distinction.
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 the sibling 'read_documentation' or any conditions that would favor searching over direct reading. The schema offers details on parameters but no contextual usage direction.
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.
v0.1.0read_documentationsearch_documentationScored across 2 tools
The two tools have clearly distinct purposes: one retrieves full page content for a specific document, while the other searches for relevant documents by keyword. There is no overlap or ambiguity between them.
Both tools follow the exact same verb_noun pattern with snake_case naming (read_documentation, search_documentation). The convention is consistent and predictable.
With only two tools, the surface feels thin for a documentation server. It covers the core lookup workflow, but a browse or list operation would make it feel less minimal and more complete.
Search and read form a complete loop for finding and consuming documentation. Minor gaps include lack of browsing, metadata retrieval, or version selection, but agents can work around these using search.
Versioned documentation registry and semantic search for AI tools and coding assistants.
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
Docs Q&A: search 169 data and AI guides, fetch any page as markdown. Read-only, keyless.
Search and query nTop's knowledge base and engineering guides from AI applications.
