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., "@Agno Docs MCP Server show me how to create an agent"
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.
A Model Context Protocol (MCP) server that provides access to Agno framework documentation. Enables developers to easily access Agno docs through coding agents like Claude Code, Cursor, and other MCP-compatible tools.
Python 3.10 or higher
Git
Access to the agno-docs repository (for documentation source)
git clone https://github.com/agno-agi/agno-docs-mcp
cd agno-docs-mcppython3 -m venv .venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate# Upgrade pip first (required for pyproject.toml editable installs)
pip install --upgrade pip
# Install the package in editable mode with dev dependencies
pip install -e ".[dev]"# Clone the agno-docs repository (adjust path as needed)
git clone https://github.com/agno-agi/agno-docs ~/Work/agno-docs# Set the path to your agno-docs repository
export AGNO_DOCS_PATH=~/Work/agno-docs
# Run the preparation script to copy and index docs
python -m agno_docs_mcp.prepareYou should see output like:
Preparing Agno documentation...
Source: /Users/you/Work/agno-docs
Output: /Users/you/Work/agno-docs-mcp/.docs
Copying documentation files...
Copied 596 files from basics/
Copied 148 files from reference/
Copied 74 files from reference-api/
...
Copied OpenAPI spec (openapi.json)
Building search index...
Indexed 1851 files in 10 categories
Done!Add to ~/.claude.json or your project's .claude/settings.json:
{
"mcpServers": {
"agno-docs": {
"command": "/path/to/agno-docs-mcp/.venv/bin/python",
"args": ["-m", "agno_docs_mcp"]
}
}
}Add to your Cursor MCP settings (.cursor/mcp.json):
{
"mcpServers": {
"agno-docs": {
"command": "/path/to/agno-docs-mcp/.venv/bin/python",
"args": ["-m", "agno_docs_mcp"]
}
}
}{
"mcpServers": {
"agno-docs": {
"url": "http://localhost:8000/mcp",
"transport": "streamable-http"
}
}
}# Test the server directly
python -c "from agno_docs_mcp.tools.api import agno_api; print(agno_api('memory')[:200])"
# Or start the HTTP server
python -m agno_docs_mcp --transport http --port 8000
# In another terminal, test with curl
curl -X POST http://localhost:8000/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'Related MCP server: MCP Framework Documentation Server
7 Specialized Tools for navigating Agno documentation:
agno_docs - SDK conceptual documentation (agents, teams, workflows, basics)
agno_reference - SDK class and method reference
agno_examples - Code snippets and usage examples
agno_integrations - Database, VectorDB, and model provider guides
agno_agentos - AgentOS runtime documentation
agno_api - REST API endpoints from OpenAPI spec
agno_migration - Migration guides, FAQs, and troubleshooting
OpenAPI Integration - Parses the OpenAPI spec for accurate REST endpoint docs
Keyword-based search across all documentation
Path-based navigation for exploring docs structure
Offline support - docs are preprocessed and bundled locally
Multiple transports - stdio (local) and HTTP (remote) support
# Activate venv first
source .venv/bin/activate
# Run with stdio transport (for Claude Code, Cursor)
python -m agno_docs_mcp# Run HTTP server on port 8000
python -m agno_docs_mcp --transport http --port 8000
# Server available at http://localhost:8000/mcp
# Health check at http://localhost:8000/health# Using uvicorn directly
uvicorn agno_docs_mcp.app:app --host 0.0.0.0 --port 8000
# Using Docker
docker build -t agno-docs-mcp .
docker run -p 8000:8000 agno-docs-mcpGet AgentOS REST API endpoints from the OpenAPI specification.
agno_api(resource="memory")Parameters:
resource (str) - API resource: memory, agents, teams, workflows, sessions, knowledge, evals, traces, metrics, database, playground
Use for: REST API endpoints, HTTP methods, request/response schemas
Get SDK conceptual documentation and guides for writing agent code.
agno_docs(path="basics/agents/")Parameters:
path (str) - Documentation path (e.g., "basics/", "basics/agents/", "basics/memory/")
Use for: How to write Python code with Agno SDK
Get SDK class and method reference (parameters, signatures, options).
agno_reference(topic="agents")Parameters:
topic (str) - Reference topic: agents, teams, workflows, tools, models, memory, knowledge, storage, hooks, compression, reasoning, agent-os
Use for: Agent() constructor parameters, method signatures, configuration options
Get SDK code examples for building agents.
agno_examples(category="agents")Parameters:
category (str) - Category: agents, teams, workflows, tools, memory, knowledge, models, database, evals, guardrails, hitl, multimodal, reasoning, sessions, tracing
Get integration documentation for databases, vector stores, and models.
agno_integrations(integration_type="database", name="postgres")Parameters:
integration_type (str) - Type: database, vectordb, models, toolkits
name (str, optional) - Specific integration name
Get AgentOS runtime and deployment documentation.
agno_agentos(path="features/memories")Parameters:
path (str) - Path within AgentOS docs (e.g., "api/", "features/", "security/")
Use for: Deployment docs, runtime features, authentication, middleware
Get migration guides and FAQ documentation.
agno_migration(topic="v2-migration")Parameters:
topic (str) - Migration topic or FAQ topic
Question Type | Use This Tool |
"What REST API endpoints for memory?" |
|
"How to create an agent in Python?" |
|
"What parameters does Agent() accept?" |
|
"Show me agent code examples" |
|
"How to connect to Postgres?" |
|
"How to deploy agents?" |
|
"How to migrate from v1?" |
|
agno-docs-mcp/
├── pyproject.toml
├── README.md
├── .venv/ # Virtual environment
├── src/
│ └── agno_docs_mcp/
│ ├── __init__.py
│ ├── __main__.py
│ ├── server.py # Main MCP server with tool registration
│ ├── app.py # FastAPI/ASGI app for HTTP
│ ├── tools/ # Tool implementations
│ │ ├── docs.py
│ │ ├── reference.py
│ │ ├── examples.py
│ │ ├── integrations.py
│ │ ├── agentos.py
│ │ ├── api.py # NEW: OpenAPI parser
│ │ └── migration.py
│ ├── utils/ # Utility modules
│ │ ├── search.py
│ │ ├── paths.py
│ │ └── content.py
│ └── prepare/ # Doc preparation
│ └── prepare_docs.py
├── .docs/ # Preprocessed docs (generated)
│ ├── raw/ # Copied MDX files
│ ├── snippets/ # Snippet files
│ ├── index.json # Search index
│ └── openapi.json # OpenAPI spec
└── tests/When the agno-docs repository is updated:
# Pull latest docs
cd ~/Work/agno-docs
git pull
# Re-run preparation
cd ~/Work/agno-docs-mcp
source .venv/bin/activate
python -m agno_docs_mcp.prepareRun the prepare script:
export AGNO_DOCS_PATH=~/Work/agno-docs
python -m agno_docs_mcp.prepareMake sure you're using the virtual environment:
source .venv/bin/activate
which python # Should show .venv/bin/pythonCheck the path in your MCP config points to the venv Python:
"command": "/absolute/path/to/agno-docs-mcp/.venv/bin/python"Test the server manually:
/path/to/agno-docs-mcp/.venv/bin/python -m agno_docs_mcpMIT
Get AgentOS runtime and deployment documentation (REST APIs, endpoints, hosting).
Args: path: Path within AgentOS docs. Leave empty for overview.
AgentOS Sections: - "api/" - REST API authentication and endpoint usage - "features/" - Runtime features: memories, sessions, knowledge, tracing - "features/memories" - Memory API endpoints for deployed agents - "security/" - RBAC, authentication, authorization - "middleware/" - JWT auth, custom middleware - "interfaces/" - Slack, WhatsApp, A2A protocol integrations - "client/" - AgentOS Python client for calling deployed agents
USE THIS TOOL for questions about:
Deployed agent REST API endpoints
Memory/session/knowledge endpoints in production
Authentication and security for hosted agents
Runtime features and middleware
For SDK code usage (writing agents), use agno_docs or agno_reference instead.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No |
| 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. It explains what the tool retrieves (documentation) but does not disclose behavioral traits such as whether it makes network calls, caching behavior, response format, or whether it is real-time. A 3 is appropriate because it covers basic purpose but lacks deeper behavioral context.
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 bullet points for sections and usage guidelines. It is front-loaded with the main purpose and uses concise sentences. Every sentence serves a clear function without redundancy.
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 simple documentation retrieval tool with one optional parameter, the description covers all essential aspects: purpose, usage context, parameter guidance, and exclusion criteria. Despite having an output schema not detailed, the description is sufficient for an agent to correctly select and invoke the tool.
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 adds significant meaning beyond the schema: it explains the 'path' parameter with practical examples like 'api/', 'features/memories', etc., and advises 'Leave empty for overview.' This compensates for the 0% schema description coverage, making the parameter highly actionable.
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 'Get AgentOS runtime and deployment documentation' and lists specific sections, distinguishing it from sibling tools like agno_docs and agno_reference. The verb 'Get' and resource 'AgentOS runtime and deployment documentation' make the purpose specific and unambiguous.
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 explicitly states 'USE THIS TOOL for questions about...' and provides a list of use cases, followed by 'For SDK code usage, use agno_docs or agno_reference instead.' This gives clear when-to-use and when-not-to-use guidance with named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get AgentOS REST API endpoints from the OpenAPI specification.
Args: resource: API resource to look up. One of: memory, agents, teams, workflows, sessions, knowledge, evals, traces, metrics, database, playground Leave empty to list all available API resources.
Returns detailed REST API endpoint documentation including:
HTTP method and path (e.g., GET /memories, POST /memories)
Request parameters and their types
Request body schema
Response codes and descriptions
USE THIS TOOL when the user asks about:
REST API endpoints for deployed AgentOS
HTTP methods for interacting with AgentOS
API schemas and parameters
How to call AgentOS programmatically via HTTP
For SDK/Python code (classes, methods), use agno_reference instead. For conceptual docs about features, use agno_agentos instead.
| Name | Required | Description | Default |
|---|---|---|---|
| resource | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains return format (method, path, parameters, body, response codes) and input options. Does not mention side effects, but as a read-only documentation tool, no further disclosure needed.
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?
Well-structured with Args, Returns, and usage guidance sections. Every sentence adds value; no redundancy or 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?
With one parameter fully documented and return values explained, description is complete. Sibling differentiation and output schema mention ensure no gaps.
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 has 0% description coverage, but description adds significant meaning: lists valid resource values and explains default behavior. This compensates fully for the missing schema descriptions.
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?
Description clearly states it gets AgentOS REST API endpoints from OpenAPI spec, with specific verb and resource. Differentiates from siblings by referencing agno_reference for SDK and agno_agentos for conceptual docs.
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?
Explicitly states when to use (REST API queries) and when not (SDK or conceptual), providing alternative tools. Also specifies that leaving resource empty lists all resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Agno SDK conceptual documentation and guides for writing agent code.
Args: path: Documentation path. Use "basics/" to see all topics.
SDK Documentation Paths: - "basics/agents/" - How to create and configure agents in code - "basics/tools/" - How to create custom tools for agents - "basics/memory/" - How to use memory in your agent code - "basics/knowledge/" - Knowledge bases and RAG implementation - "basics/teams/" - Multi-agent team coordination - "basics/workflows/" - Workflow orchestration patterns
This is for SDK/library usage (writing Python code with Agno). For deployed agent REST APIs and runtime features, use agno_agentos instead.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| 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 burden of behavioral disclosure. It implies a safe, read-only operation by describing the tool as getting documentation. It does not explicitly mention non-destructiveness, but the nature of a doc retrieval tool makes it obvious. Could mention that no side effects occur.
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: it starts with a clear one-sentence purpose, then breaks into an Args section with a list of example paths. Every sentence adds value without redundancy.
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 that an output schema exists (not shown), the description does not need to explain return values. It covers what the tool does, how to use the parameter, when to use this tool vs. alternatives, and provides a complete set of example paths. No gaps.
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 single parameter 'path' has 0% schema coverage, meaning the schema provides no description. The full description compensates by listing example paths (e.g., 'basics/agents/', 'basics/tools/') and explaining the path structure, adding 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 retrieves Agno SDK documentation for writing agent code. It distinguishes itself from the sibling tool 'agno_agentos' by specifying that tool covers deployed agent REST APIs and runtime features, while this tool is for SDK/library usage.
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?
Explicit guidance is provided: 'This is for SDK/library usage... For deployed agent REST APIs and runtime features, use agno_agentos instead.' Additionally, it suggests using 'basics/' to see all topics and provides a list of example paths for common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get SDK code examples for building agents with Agno.
Args: category: Example category. One of: agents, teams, workflows, tools, memory, knowledge, models, database, evals, guardrails, hitl, multimodal, reasoning, sessions, tracing Leave empty to list all available categories.
Returns complete, runnable Python code examples with imports and setup. These are SDK examples for writing agent code, not deployment examples.
For deployment and hosting examples, use agno_agentos instead.
| Name | Required | Description | Default |
|---|---|---|---|
| category | 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 full burden. It states the tool returns complete, runnable Python examples and clarifies these are SDK examples for writing agent code, not deployment. This is sufficient for a read-only retrieval tool, though it omits potential side effects or auth requirements.
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 an Args section and a clear return statement. Every sentence is informative and earns its place; no wasted words.
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 simplicity (one optional parameter, outputs examples) and presence of an output schema, the description covers the essentials. It explains what the tool returns and its scope, though it could mention error handling or pagination, but that is not critical for this use case.
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 coverage is 0%, so the description fully explains the single parameter 'category', listing all valid values and the effect of leaving it empty. This adds critical meaning beyond the bare schema definition.
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?
Clearly states it gets SDK code examples for building agents with Agno. The description specifies the return value (complete, runnable Python code) and distinguishes from sibling tool agno_agentos for deployment examples. No ambiguity.
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?
Explicitly tells when to use this tool ('for SDK examples') and when to use the alternative ('agno_agentos for deployment and hosting'). Also instructs to leave category empty to list all categories, providing clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get integration documentation for databases, vector stores, and models.
Args: integration_type: Type of integration. One of: database, vectordb, models, toolkits name: Specific integration name. Leave empty to list all of that type. Database: postgres, mongodb, sqlite, mysql, redis, dynamodb, firestore VectorDB: pinecone, qdrant, chroma, weaviate, milvus, lancedb Models: openai, anthropic, google, azure, bedrock
Examples: - integration_type="database", name="postgres" - integration_type="vectordb", name="pinecone" - integration_type="models" (lists all providers)
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| integration_type | Yes |
| 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 full burden. It only describes basic functionality and valid parameter values, but lacks disclosure of authentication needs, rate limits, error handling, or potential side effects. This is minimal for a read tool.
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: a brief purpose statement, followed by well-structured Args and Examples sections. Every sentence adds value with no redundancy.
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?
The description covers the input parameters sufficiently with valid values and examples. However, it does not describe the output format or what the returned documentation looks like, though an output schema is present (not shown). Slightly incomplete without output details.
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?
With 0% schema coverage, the description adds significant meaning: it explains the integration_type enum, provides specific name values, and gives examples. This fully compensates for the missing schema descriptions.
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 'gets integration documentation for databases, vector stores, and models,' specifying the verb and resource. It lists integration types and examples, distinguishing it from sibling tools like agno_agentos or agno_api.
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 guidance on parameter values (e.g., integration_type options, name options) and examples. However, it does not explicitly state when to use this tool over siblings or when not to use it, but the context is self-explanatory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get migration guides and FAQ documentation.
Args: topic: Topic to fetch. Leave empty to list all available topics. Migration guides: v2-migration, workflows-migration, installation, changelog FAQ topics: environment, openai-key, structured-outputs, docker-connection, agentos-connection, rbac-auth, switching-models, tpm, tableplus
Use for upgrading Agno versions, installation issues, and common errors.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No |
| 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. It accurately states the tool fetches guides and FAQ, implying a read operation, but it does not explicitly state that it is read-only, safe, or free of 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 front-loaded with the primary purpose and usage. The Args list is clear but somewhat long; could be condensed without losing information.
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?
The description covers purpose, parameters, and usage guidance. Given the presence of an output schema (not shown), explanation of return values is unnecessary. The tool is a simple documentation lookup, and the description adequately addresses its context.
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?
With 0% schema description coverage, the description adds significant value by listing concrete topic values ('v2-migration, workflows-migration, ...') and explaining the default behavior ('Leave empty to list all available topics'). This far exceeds the schema's minimal definition.
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 'Get migration guides and FAQ documentation.' It lists specific topics which distinguishes it from sibling documentation tools (agno_docs, agno_reference), but could be more explicit about how it differs from those.
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 explicitly states 'Use for upgrading Agno versions, installation issues, and common errors.' This gives clear context for when to invoke this tool, though it does not list 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.
Get Agno SDK class and method reference (parameters, signatures, options).
Args: topic: Reference topic. One of: agents, teams, workflows, tools, models, memory, knowledge, storage, hooks, compression, reasoning, agent-os
This provides SDK CLASS documentation (e.g., Agent() constructor parameters, MemoryManager methods, Tool decorator options).
For runtime REST API endpoints (deployed agent APIs), use agno_agentos instead.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains it is a read-only reference tool that returns documentation. It does not specify side effects, but that is appropriate. Provides good behavioral context.
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?
Short, front-loaded description with no wasted words. Uses a clear structure: purpose, args, and differentiation.
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 one parameter and no annotations, the description covers purpose, parameter semantics, and usage context completely. Output schema exists but is not needed for completeness.
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?
Despite 0% schema coverage, the description adds a clear list of allowed topics and explains that the topic selects the SDK class documentation. This compensates well.
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 it gets Agno SDK class and method reference, with specific examples of what it returns (Agent() constructor parameters, etc.). It distinguishes from sibling agno_agentos by noting the latter is for runtime REST API endpoints.
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?
Explicitly mentions when to use this tool for SDK docs and when to use agno_agentos for runtime API endpoints. Also lists allowed values for the topic parameter.
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.0agno_agentosagno_apiagno_docsagno_examplesagno_integrationsagno_migrationagno_referenceEach tool targets a distinct documentation domain (runtime APIs, SDK concepts, code examples, integrations, migration, class reference, and API endpoints). Descriptions include explicit guidance on when to use which tool, minimizing confusion.
All tool names follow the 'agno_' prefix plus a clear, descriptive topic in snake_case (e.g., agno_docs, agno_api, agno_reference). The pattern is uniform and predictable.
With 7 tools, the server covers the full scope of documentation needs for the Agno ecosystem without being overwhelming or sparse. Each tool serves a well-defined purpose.
The server covers most major documentation areas: SDK concepts, examples, reference, API endpoints, integrations, migration, and runtime. Minor gaps like advanced troubleshooting beyond migration could exist, but the coverage is comprehensive for typical use cases.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Knowledge base MCP for AI agents on iknow.dev. Search, read, and maintain via OAuth.
MCP server for uagents documentation, generated by doc2mcp.
MCP server for agentverse documentation, generated by doc2mcp.
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/uzaxirr/agno-docs-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
