Click on "Install 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-a2a-documentation search for 'agent card' in topics"
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 the Agent2Agent (A2A) protocol documentation. This server enables AI assistants like Claude to search and read A2A documentation directly from the upstream repository.
This server indexes documentation from the a2aproject/A2A repository's docs/ directory, which powers a2a-protocol.org.
Related MCP server: openground
Full-text search using SQLite FTS5 with BM25 ranking and Porter stemming
Section filtering to narrow search results by documentation category (root, topics, tutorials, sdk)
Sparse checkout for efficient cloning of only the required docs/ directory
Docker support for portable deployment across projects
STDIO transport for seamless MCP client integration
The martoc/mcp-a2a-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-a2a-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-a2a-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 the |
# Pull the latest image
docker pull martoc/mcp-a2a-documentation:latest
# Run the MCP server
docker run -i --rm martoc/mcp-a2a-documentation:latestAdd to your .mcp.json or global settings to use the published container image:
{
"mcpServers": {
"a2a-documentation": {
"command": "docker",
"args": ["run", "-i", "--rm", "martoc/mcp-a2a-documentation:latest"]
}
}
}For local development without Docker:
{
"mcpServers": {
"a2a-documentation": {
"command": "uv",
"args": ["run", "mcp-a2a-documentation"],
"cwd": "/path/to/mcp-a2a-documentation"
}
}
}Tool | Description |
| Search A2A documentation by keyword query with optional section filter |
| Retrieve the full content of a specific documentation page |
Search A2A protocol 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 ( |
| string | No | None | Filter by source ( |
| integer | No | 10 | Maximum results (1-50) |
Available sections: root (specification, community, roadmap, partners, etc.), topics (core protocol concepts), tutorials (the Python quickstart), sdk (SDK overview).
Retrieve the full content of a documentation page.
Parameter | Type | Required | Description |
| string | Yes | Source-prefixed path to the document (e.g., |
# Build/rebuild the documentation index
uv run a2a-docs-index index
uv run a2a-docs-index index --rebuild
uv run a2a-docs-index index --branch main
# Show index statistics
uv run a2a-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 A2A protocol documentation page.
Args: path: The relative path to the documentation file, prefixed with the source name (e.g., 'a2a/topics/what-is-a2a.md' or 'a2a/specification.md'). This path is returned in search results.
Returns: The full markdown content of the documentation page, or an error message if the page is not found.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| 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 full burden. It discloses the return value (full markdown content) and error behavior (error message if not found). This is adequate transparency for a simple read tool, though it does not address permissions or other potential side effects.
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 well-structured with Args and Returns sections. It is concise, front-loaded with the main purpose, and every sentence adds value without unnecessary fluff.
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 single-parameter tool with an output schema, the description is complete. It explains the path parameter, the return value, and error handling, covering all relevant aspects for effective invocation. There is no missing critical information.
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 provides only a bare 'path' string with no description (0% coverage). The description compensates fully by explaining the path format (relative, prefixed with source name) and giving concrete examples, adding significant meaning beyond the schema.
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 verb ('Read') and resource ('full content of a specific A2A protocol documentation page'). It distinguishes itself from the sibling tool 'search_documentation' by focusing on reading a specific page by path rather than searching.
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 clear context for usage by noting that the path is returned in search results, implying a workflow of search-then-read. However, it does not explicitly state when not to use this tool or mention alternatives beyond this implicit connection, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search A2A (Agent2Agent) protocol documentation by keyword query.
Args:
query: Search terms to find in the documentation. Supports
full-text search with stemming (e.g., "authenticate" matches
"authentication", "authenticated").
section: Optional section to filter results. Common sections
include 'root' (top-level pages such as the specification
and community pages), 'topics' (core concepts), 'tutorials',
and 'sdk'.
source: Optional documentation source to filter results. Currently
only 'a2a' (a2aproject/A2A docs/ directory) is indexed.
limit: Maximum number of results to return (default: 10, max: 50).
Returns: JSON-formatted search results with title, URL, snippet, and relevance score.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| source | No | ||
| section | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses stemming behavior, the limitation that only 'a2a' is indexed, the maximum limit of 50, and the return format. This is solid transparency, though it could explicitly state that it is a read-only operation, which is implied by 'search'.
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 concise and well-structured: a one-sentence summary, then a clear 'Args' section, and a 'Returns' section. Every sentence adds value, and the information is front-loaded.
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 search tool with no annotations and a simple schema, the description is complete. It covers purpose, all parameters, return format, and a key limitation (source only a2a). The presence of an output schema is noted, but the description still adequately describes the expected result fields.
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 description thoroughly explains each parameter beyond what the schema provides: query supports stemming, section has common values, source is currently only 'a2a', and limit has default/max. This fully compensates for the 0% schema description coverage.
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 searches A2A protocol documentation by keyword, using a specific verb and resource. It distinguishes itself from the sibling read_documentation by focusing on searching rather than reading, making the purpose unmistakable.
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 usage is implied: search when you need to find documentation by keyword. However, it does not explicitly compare with read_documentation or state when not to use this tool. The description offers context about sections and source, but lacks explicit exclusions or alternative guidance.
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. Dates show when Glama detected each change.
v0.1.0read_documentationsearch_documentationThe two tools are completely distinct: one searches for relevant documentation pages, the other retrieves the full content of a specific page. There is no overlap in their functionality.
Both tool names follow a consistent verb_noun pattern: search_documentation and read_documentation. The naming style is uniform and predictable.
With only two tools, the server feels somewhat sparse. However, search and read are the core operations for documentation access, so the count is reasonable even though it falls at the low end of the typical range.
The tool surface covers the main workflow: discover pages via search, then fetch full content via read. A minor gap is the lack of a direct way to list all documents without performing a search, but this can be worked around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search and fetch AgendaForge public documentation and marketing content. No authentication needed.
Search the Anthid trading API reference, schemas, and product pages.
Agentic search over your Dewey document collections from any MCP-compatible client.
Search and read the public Applivery docs (MDM & app distribution). Read-only, no auth.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/martoc/mcp-a2a-documentation'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
