What can you do with this server?

This server exposes ProsodyAI documentation, SDK references, REST API specs, and implementation recipes to AI coding agents, enabling correct integrations without manual scraping or guessing API shapes. * Search documentation (search_docs): Full-text search across docs, SDK READMEs, recipes, and OpenAPI metadata — returns ranked results with snippets, optionally filtered by section (docs, sdks, recipes, api). * Browse all docs (list_docs): List every available document, optionally filtered by section. * Read full doc content (read_doc): Fetch the complete body of any doc, SDK README, or recipe by its stable ID (e.g. docs/STRUCTURE, sdks/typescript, recipes/livekit-realtime-agent). * List REST endpoints (list_endpoints): Browse ProsodyAI REST API endpoints from the bundled OpenAPI spec, filterable by tag (e.g. Analysis, Sessions) or URL path substring. * Get a specific endpoint (get_endpoint): Retrieve the full OpenAPI operation object — including parameters, request body, responses, and security — for a single endpoint by HTTP method and path. * Get the full OpenAPI spec (get_openapi): Download the entire bundled OpenAPI 3 specification (best used sparingly in favor of targeted endpoint lookups). * List implementation recipes (list_recipes): Browse curated end-to-end guides for common integrations such as LiveKit real-time agents, browser audio streaming, LangChain tool usage, and direct REST integration. * Get a platform overview (get_overview): Retrieve a single-page intro to ProsodyAI explaining its architecture and how SDKs, API, and recipes relate — recommended as the starting point for any new integration. * Access content as MCP resources at prosodyai:// / for clients that prefer resources over tools. Works via stdio (local agents like Cursor, Claude Code) or HTTP (remote deployments).

Which integrations are available for this server?

Provides a recipe for using ProsodyAI as a LangChain tool, enabling AI agents to incorporate prosody-driven adaptation into LangChain workflows. Provides a quickstart recipe to add ProsodyAI to a Next.js application, guiding integration with Node/Next.js/browser apps.

How do I use @prosodyai/mcp-docs?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@prosodyai/mcp-docs show me the TypeScript quickstart recipe" 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.

de en es ja ko ru zh

@prosodyai/mcp-docs

Official

by ProsodyAI

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

@prosodyai/mcp-docs

MCP server that exposes ProsodyAI documentation, SDK references, REST API reference (OpenAPI), and curated implementation recipes to AI coding agents.

Built so that an external coding agent can implement ProsodyAI integrations correctly the first time, without scraping the website or guessing API shapes.

Ships with two transports in a single TypeScript codebase:

stdio — for local agents (Cursor, Claude Code, Cline, etc.)
HTTP (Streamable HTTP) — for remote/hosted agents

Tools exposed

Tool	Purpose
`search_docs`	Search docs, SDK READMEs, recipes, and OpenAPI in one call
`list_docs`	Browse everything by section (`docs`, `sdks`, `recipes`, `api`)
`read_doc`	Fetch the full body of a doc / README / recipe by id
`list_recipes`	List end-to-end implementation guides
`list_endpoints`	List REST endpoints from the bundled OpenAPI spec, filterable by tag
`get_endpoint`	Full OpenAPI operation object for a single endpoint
`get_openapi`	The entire bundled OpenAPI 3 spec
`get_overview`	One-page intro — read this first when starting an integration

Every entry is also exposed as an MCP resource at prosodyai://<section>/<id> for clients that prefer resources over tools.

Related MCP server: openai-agents-sdk-mcp

Recipes that ship

recipes/sdk-typescript-quickstart — Add ProsodyAI to a Node / Next.js / browser app
recipes/livekit-realtime-agent — Real-time voice agent with prosody-driven adaptation
recipes/langchain-agent — Use prosody as a LangChain tool
recipes/browser-streaming — Stream mic audio from the browser
recipes/kpi-flow — Define custom KPIs and close the feedback loop
recipes/rest-api-integration — Direct REST integration without an SDK

Running locally

npm install
npm run build         # syncs content/ from the monorepo, then compiles
npm run start:stdio   # for stdio MCP clients
npm run start:http    # http on localhost:3333/mcp

npm run build:content rebuilds content/ from the parent monorepo. It locates the monorepo via PROSODYAI_REPO_ROOT or by walking up from this package's directory (works when mounted as packages/mcp-docs in the parent monorepo).

Use it from any MCP client

Stdio (local)

Add to your client's mcp.json:

{
  "mcpServers": {
    "prosodyai-docs": {
      "command": "npx",
      "args": ["-y", "@prosodyai/mcp-docs"]
    }
  }
}

Or run from a checkout:

{
  "mcpServers": {
    "prosodyai-docs": {
      "command": "node",
      "args": ["/abs/path/to/mcp-docs/dist/stdio.js"]
    }
  }
}

HTTP (remote)

Once deployed (see below), point your client at the public URL:

{
  "mcpServers": {
    "prosodyai-docs": {
      "url": "https://prosodyai-docs.vercel.app/mcp"
    }
  }
}

Deployment

The HTTP entrypoint is a plain express app that listens on PORT (default 3333) at path /mcp. It works on any Node host:

Vercel / Cloud Run / Fly / Railway: deploy as a Node service with npm run build as the build step and npm run start:http as the start command.
Docker: see Dockerfile (single-stage Node 20-slim image).

/healthz returns a JSON heartbeat for container orchestrators.

Updating content

Whenever the parent monorepo's docs, SDK READMEs, or OpenAPI spec change:

cd packages/mcp-docs    # or wherever this is mounted
npm run build:content
git add content/ && git commit -m "Sync docs from monorepo"

The next deploy serves the new content. (CI on ProsodyAI/prosodyai's master branch should run this automatically — see .github/workflows/sync.yml if present.)

License

MIT

Available Tools

8 tools

get_endpointGet a REST endpointA

Get the full OpenAPI operation object (parameters, request body, responses, security) for a single REST endpoint.

ParametersJSON Schema

Name	Required	Description	Default
`method`	Yes	HTTP method, e.g. `POST`.
`path`	Yes	OpenAPI path template, e.g. `/v1/analyze/audio`.

TDQS

A3.8/5.0

Behavior3/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 describes the return content but does not explicitly confirm read-only behavior, authentication needs, or any 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.

Conciseness5/5

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

The description is a single sentence that efficiently communicates the tool's purpose and return value without any redundancy or unnecessary detail.

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?

The description mentions the key components of the return object (parameters, request body, responses, security). While no output schema exists, this is sufficient for a simple retrieval 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?

The input schema already provides 100% coverage with descriptions for both parameters. The description adds no additional semantic information beyond implying the parameters.

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 retrieves the full OpenAPI operation object for a single REST endpoint, specifying included components. This distinguishes it from siblings like list_endpoints (list all) and get_openapi (full spec).

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 use for a single endpoint but does not explicitly state when to use this vs alternatives like list_endpoints for discovery or get_openapi for the full spec.

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

get_openapiGet the full OpenAPI specA

Return the full bundled OpenAPI 3 spec for the ProsodyAI REST API. Use sparingly — prefer list_endpoints + get_endpoint for targeted lookups.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It hints at potential performance cost with 'use sparingly' but does not disclose other traits like read-only nature, rate limits, or response size.

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?

Two sentences efficiently cover purpose and usage guidelines with no extraneous information. Every sentence adds value.

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 tool with no parameters and no output schema, the description adequately specifies the return value (full bundled OpenAPI 3 spec) and provides usage advice, covering essential context.

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 no parameters (100% coverage), so the baseline is high. The description adds no parameter details because none exist, but this is appropriate given the zero-parameter 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 tool returns the full bundled OpenAPI 3 spec for the ProsodyAI REST API. It distinguishes from siblings by recommending `list_endpoints` and `get_endpoint` for targeted lookups.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises to 'Use sparingly' and provides an alternative approach—prefer `list_endpoints` + `get_endpoint` for targeted lookups—making the usage context and exclusions clear.

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

get_overviewPlatform overviewA

Return a single-page overview of the ProsodyAI platform: what it is, what to use, and how the SDKs/API/recipes relate. Read this first when starting an integration.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description fully conveys the tool's read-only nature and safe behavior. It doesn't list pitfalls, but for a simple overview with no parameters, the behavioral disclosure is sufficient.

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?

Two sentences, front-loaded with action and concise elaboration. Every sentence adds value with no waste.

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?

Despite no output schema, the description fully explains the content of the return value (what it is, what to use, relationships), making it complete for the tool's simple purpose.

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?

Tool has zero parameters, so baseline is 4. The description adds no parameter info, but none is needed.

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?

Description clearly states the action 'Return' and the resource 'single-page overview of the ProsodyAI platform'. It defines the scope (what it is, what to use, relationships) and implicitly distinguishes from siblings by being the high-level initial overview.

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?

Explicitly advises 'Read this first when starting an integration', giving clear when-to-use context. While it doesn't list alternatives, the sibling tools imply that for specific details other tools are appropriate.

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

list_docsList all docsA

List every document in this server. Useful for browsing without a search query.

ParametersJSON Schema

Name	Required	Description	Default
`section`	No	Filter to a single section.

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, but the description indicates a simple read operation with no side effects mentioned. It lacks details on pagination or rate limits but is straightforward.

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?

Two concise sentences, front-loaded with clear purpose, no wasted words.

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?

Adequate for a simple listing tool with one optional filter; could mention output format but not essential given sibling tools.

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 little beyond the schema. It mentions 'every document' but does not elaborate on parameter behavior.

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 ('List every document in this server') and distinguishes from siblings like search_docs by noting it's for browsing without a query.

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 provides context ('useful for browsing without a search query') implying use for broad exploration, but does not explicitly name alternatives or when not to use.

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

list_endpointsList REST endpointsA

List ProsodyAI REST API endpoints from the bundled OpenAPI spec. Optional filters by tag or path substring.

ParametersJSON Schema

Name	Required	Description	Default
`tag`	No	Filter by OpenAPI tag (e.g. `Analysis`, `Sessions`).
`pathContains`	No	Substring filter on the URL path (e.g. `analyze`).

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It implies a read operation but does not disclose potential pagination, rate limits, or whether the entire spec is returned. Adequate but not detailed.

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, front-loaded with purpose, and efficiently mentions filters. No unnecessary words.

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?

Low complexity (2 params, no output schema). Description explains purpose and filters but does not specify return format (full definitions vs. names). Minor gap but overall sufficient.

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% for both parameters. Description only restates filter options without adding new meaning beyond the schema. Baseline score of 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?

Description clearly states the verb (List), resource (REST API endpoints), and source (bundled OpenAPI spec). Optional filters are mentioned, distinguishing it from siblings like get_endpoint or get_openapi.

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?

Description implies use for listing endpoints with optional filtering, but does not explicitly mention when to use alternatives like get_endpoint for a single endpoint. Given sibling context, it's fairly clear.

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

list_recipesList implementation recipesA

List curated end-to-end implementation recipes for common ProsodyAI integration tasks (e.g. add prosody to a LiveKit agent, stream from a browser, wire the LangChain tool, define KPIs).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/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 behavioral traits such as authorization needs, rate limits, or whether the list is cached. It only states it 'lists' recipes, offering minimal insight into 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.

Conciseness5/5

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

Single sentence, front-loaded with verb and resource, includes relevant examples in parentheses. No wasted words.

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?

For a simple list tool with no parameters, the description adequately explains the content and provides examples. Could mention output structure but is sufficiently 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?

There are no parameters, so the description adds value by explaining what the tool returns. With 100% schema coverage and no params, the baseline is 4.

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 'List' and the resource 'recipes', specifying they are curated for common ProsodyAI integration tasks with concrete examples. This distinguishes it from siblings like list_docs and list_endpoints.

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 through examples of tasks, but does not explicitly state when to use this tool over alternatives or provide any exclusions.

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

read_docRead a docA

Fetch the full content of a doc, SDK README, recipe, or other entry by id (as returned by search_docs or list_docs).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Stable id returned by search/list, e.g. `docs/STRUCTURE`, `sdks/typescript`, `recipes/livekit-realtime-agent`.

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description bears the full burden. It states the tool 'fetches full content', implying a safe read operation, but does not elaborate on side effects, permissions, or rate limits. This is adequate but lacks depth.

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 unnecessary words. It efficiently conveys the tool's purpose and usage context.

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 tool with one parameter, no annotations, and no output schema, the description is fully complete. It states what the tool does, what it returns, and how to get the required parameter.

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 covers the single parameter `id` with a description and examples, achieving 100% coverage. The tool description reinforces the parameter's source, adding value 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 verb 'Fetch', the resource 'full content', and the scope 'doc, SDK README, recipe, or other entry'. It also references sibling tools `search_docs` and `list_docs` for obtaining the `id`, distinguishing its purpose.

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 explicitly mentions that the `id` should come from `search_docs` or `list_docs`, providing clear context for when to use this tool. It does not explicitly state when not to use it, but the guidance is effective.

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

search_docsSearch ProsodyAI docsA

Search ProsodyAI docs, SDK READMEs, recipes, and OpenAPI metadata. Returns a ranked list of matches with snippets and stable ids. Follow up with read_doc to fetch full content.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Free-text search query.
`section`	No	Restrict to a single section: docs \| sdks \| recipes \| api.
`limit`	No	Max results (default 10).

TDQS

A4/5.0

Behavior3/5

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

With no annotations, description must disclose behavior. It mentions returned items are 'ranked list with snippets and stable ids,' giving output structure. However, it does not detail pagination, rate limits, or error handling, leaving gaps for a search tool.

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?

Two sentences: first defines purpose and scope, second explains output and next step. No filler, essential information front-loaded.

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?

For a search tool with 3 simple params, description covers purpose, output format, and follow-up. Missing details on pagination or result ordering, but overall complete given tool simplicity and sibling differentiation.

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 covers all three parameters (query, section, limit) with descriptions. The tool description adds context about return format and follow-up but does not enhance parameter meaning beyond the schema, earning baseline score of 3.

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?

Description starts with 'Search ProsodyAI docs, SDK READMEs, recipes, and OpenAPI metadata.' This clearly states the action (search), the resource (multiple doc types), and is distinct from sibling tools like list_docs and read_doc.

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?

Explicitly directs to 'Follow up with read_doc to fetch full content,' providing clear context for when to use this tool and suggesting a complementary tool. Lacks explicit when-not-to-use scenarios but adequately guides usage.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: getting specific endpoint details, full spec, overview, listing various resources, searching, and reading. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (e.g., get_endpoint, list_docs, search_docs) with underscores, making them predictable and easy to use.

Tool Count5/5

8 tools are appropriate for a documentation server: they cover browsing (list), searching, and reading, with specialized tools for API details and overview. No redundancy or inadequacy.

Completeness5/5

The tool surface is complete for the domain: it allows listing all resources, searching, and retrieving full content, plus targeted access to API spec and overview. No dead ends for typical documentation workflows.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Knowa
com.knowalabs
Team docs served to AI agents over MCP - search, Markdown reads, version pinning, read audit.
Documentation Access Knowledge & Memory Search
2
mcp
com.skopik
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Agent Orchestration Knowledge & Memory Search
2
ainote A
io.github.seunghan91
Agent-native notes, tasks, dev-docs, vaults, sync & handoffs. MCP + OpenAPI dual surface.
Note Taking Developer Tools Knowledge & Memory
353
Frenchie A
io.github.Lab94
OCR, transcription, file extraction, and image generation for AI agents via MCP.
AI & Machine Learning Image & Video Processing Speech Processing
72

Related MCP Servers

agentic-patterns
Autonomous Agents Knowledge & Memory Documentation Access
agentpatternscatalog
A
license
A
quality
D
maintenance
Exposes the Agentic Patterns Catalog as MCP resources and tools for AI coding agents to search, retrieve, and recommend patterns, recipes, frameworks, methodologies, and anti-patterns.
Updated 3 months ago (2026-05-28 07:41 UTC)
12
MIT
openai-agents-sdk-mcp
Documentation Access Search
gavinz0228
A
license
Not graded
quality
D
maintenance
Provides MCP tools to list and search OpenAI Agents SDK documentation, enabling LLMs to retrieve documentation topics and content via natural language queries.
Updated 9 months ago (2025-12-18 03:49 UTC)
MIT
okfy
Documentation Access Search
0dust
A
license
Not graded
quality
B
maintenance
Enables AI agents to search, read, and traverse documentation bundles in Open Knowledge Format via MCP tools.
Updated 17 days ago (2026-08-17 16:42 UTC)
733
66
MIT
docrag
RAG Systems Documentation Access
ryan-m-bishop
A
license
Not graded
quality
D
maintenance
Provides RAG (Retrieval Augmented Generation) access to technical documentation through MCP, enabling LLMs to search and retrieve relevant documentation on-demand.
Updated 8 months ago (2026-01-13 15:18 UTC)
4
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ProsodyAI/mcp-docs'

If you have feedback or need assistance with the MCP directory API, please join our Discord server