Provides local-first access to Pydantic documentation with BM25 full-text search, enabling retrieval of documentation pages, sections, and API references via MCP tools.
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., "@pydantic-docs search for BaseModel usage with examples"
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 providing local-first access to Pydantic and Pydantic AI documentation with BM25-powered full-text search.
Local-first architecture - Offline-only mode by default
BM25 full-text search - Fast semantic search across all docs
Git-based extraction - Direct from source repositories (no HTML scraping)
Pre-processed data - JSONL files included for instant setup
Auto-initialization - Builds indices automatically on first run
Complete coverage - Pydantic v2 and Pydantic AI documentation
Related MCP server: MPC Docs Server
Python 3.12+
uv package manager
~15MB disk space (with indices)
# Clone and install
git clone <repository-url>
cd mcp_pydantic_docs
uv sync
# Server auto-builds indices on first run
uv run mcp-pydantic-docsAdd to your MCP settings (e.g., cline_mcp_settings.json):
{
"mcpServers": {
"pydantic-docs": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/mcp_pydantic_docs",
"run",
"mcp-pydantic-docs"
]
}
}
}Source Extraction (source_extractor.py) - Clones Pydantic repos, extracts documentation from markdown/docstrings → JSONL
Index Building (indexer.py) - Processes JSONL files → BM25 search indices
MCP Server (mcp.py) - Serves documentation via MCP tools
Shared Utilities (utils.py) - HTML/text processing, normalization
mcp_pydantic_docs/
├── mcp_pydantic_docs/ # Source code
│ ├── mcp.py # MCP server
│ ├── source_extractor.py # Git-based doc extraction
│ ├── indexer.py # BM25 index builder
│ ├── utils.py # Shared utilities
│ └── setup.py # Setup CLI
├── data/ # Search data
│ ├── pydantic.jsonl # Pydantic docs (2.9MB, in git)
│ ├── pydantic_ai.jsonl # Pydantic AI docs (3.3MB, in git)
│ ├── *_bm25.pkl # BM25 index (generated)
│ └── *_records.pkl # Document records (generated)
└── docs_raw/ # Source repos (not in git)
├── pydantic/ # Cloned from GitHub
└── pydantic_ai/ # Cloned from GitHubGitHub Repos → source_extractor.py → JSONL files → indexer.py → BM25 indices → mcp.py → MCP Clientpydantic_search(query, k=10) - Full-text search with BM25 ranking
pydantic_get(path_or_url, max_chars=None) - Fetch full documentation page
pydantic_section(path_or_url, anchor) - Extract specific section
pydantic_api(symbol, anchor=None) - Jump to API documentation
health_ping() - Server health check
health_validate() - Validate search indices
pydantic_mode() - Server configuration
admin_cache_status() - Detailed cache status
admin_rebuild_indices() - Rebuild search indices
uv run python -m mcp_pydantic_docs.indexer# Check status
uv run python -m mcp_pydantic_docs.setup --status
# Download and extract from GitHub
uv run python -m mcp_pydantic_docs.setup --download --build-index
# Clean cache
uv run python -m mcp_pydantic_docs.setup --cleanPDA_DOC_ROOT - Pydantic v2 source path
PDA_DOC_ROOT_AI - Pydantic AI source path
PDA_DATA_DIR - Data directory path
Default: Enabled (OFFLINE_ONLY = True in mcp.py)
Blocks remote requests
Validates file paths
All content from local cache
uv run pytestuv run black mcp_pydantic_docs/ # Format
uv run ruff check . # Lint
uv run mypy mcp_pydantic_docs/ # Type checkSearch indices not found:
uv run python -m mcp_pydantic_docs.indexerWrong Python version:
uv python install 3.12Server won't start:
# Test standalone
uv run mcp-pydantic-docs
# Check indices
uv run python -m mcp_pydantic_docs.setup --statusMIT License - see LICENSE file.
See CONTRIBUTING.md for:
Development setup
Code style
Testing requirements
Pull request process
Get detailed status of documentation cache including file counts and sizes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description indicates a read-only operation (get status). It does not disclose potential performance impact or auth requirements, but the simplicity limits risk.
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?
Single sentence, no wasted words. Purpose is front-loaded and clearly communicated.
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?
Tool has no parameters and output schema exists. Description fully covers what the tool does; no additional context needed.
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?
No parameters exist; schema coverage is 100%. Baseline score of 4 applies as description adds no parameter information but is not needed.
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 the tool retrieves detailed status of documentation cache, specifying file counts and sizes. It is distinct from siblings like admin_rebuild_indices and health_ping, which have different purposes.
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 implies use when needing cache status, but lacks explicit guidance on when not to use or alternatives. However, the tool is self-explanatory given its simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rebuild BM25 search indices from JSONL files. Use when indices are missing or corrupted.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 implies a destructive rebuild but does not disclose permissions, reversibility, idempotency, or side effects (e.g., service impact). Minimal detail beyond the action.
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?
Two tightly written sentences: first states purpose, second gives usage context. 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?
Simple tool with no parameters and no annotations, but output schema exists and is not described. Missing info like operation duration, result format, or whether it blocks other operations.
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?
0 parameters with 100% schema coverage. Baseline 4 applies; description adds no param info, but none needed.
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 verb 'Rebuild' and resource 'BM25 search indices', specifies source 'JSONL files'. Distinguishes from sibling tools like health checks and pydantic tools.
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: 'Use when indices are missing or corrupted.' Does not mention when not to use or alternatives, but siblings are sufficiently different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns simple pong
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 of behavioral disclosure. It only states the output ('returns simple pong') but does not explicitly confirm it is non-destructive, has no side effects, or any rate limits. The behavior beyond the output is unclear.
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 sentence, concise and front-loaded. No unnecessary 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?
Given the tool's simplicity (no parameters, clear purpose), the description is adequate. It could mention it is a liveness check, but it still conveys the core functionality. The presence of an output schema (not shown) likely complements this.
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?
There are no parameters (schema description coverage 100%), so the baseline is 4. The description adds no parameter-specific meaning, but none is needed. It briefly explains what the tool does.
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 'Returns simple pong' clearly states the tool's action (returns) and resource (pong), which is a standard health check response. It distinguishes itself from sibling tools like health_validate (validation) and admin operations.
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 such as health_validate or admin_cache_status. No explicit context for usage is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate search indices and data integrity
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits (e.g., read-only vs destructive, permissions, side effects). It only says 'validate', which implies a non-destructive read operation, but this is not explicit. No mention of whether it modifies indices or requires special access.
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, well-formed sentence that efficiently communicates the tool's purpose. No unnecessary words or repetition. It is perfectly concise for a zero-parameter 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?
Given the tool has no parameters and no output schema, the description is minimally adequate but lacking. It does not explain what the tool returns (e.g., success/failure, details of integrity check) or how to interpret the result. For a validation tool, more context on output would be helpful.
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 input schema has no parameters, and schema description coverage is 100%. The description adds no parameter information, which is acceptable given zero parameters. Baseline score of 4 applies.
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 'Validates search indices and data integrity', which clearly identifies the action and resources. It is specific enough to distinguish from sibling tools like health_ping (health check) or admin_rebuild_indices (index rebuilding). However, it could be more precise by specifying what the validation entails (e.g., consistency checks).
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?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives such as health_ping or admin_cache_status. No prerequisites, exclusions, or contextual advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Jump to an API page by symbol name. Optional anchor.
| Name | Required | Description | Default |
|---|---|---|---|
| anchor | No | ||
| symbol | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It only states the action (jump) but does not disclose whether read-only, error behavior, authentication needs, or side effects. Minimal 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?
Single sentence with no wasted words. 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?
Low complexity tool with output schema present. Description is minimally complete for basic navigation but lacks context on when to use, behavioral details, and parameter clarification. Could be improved with moderate expansion.
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. Description adds meaning to 'symbol' (symbol name) and 'anchor' (optional), but does not explain what the anchor does or what constitutes a valid symbol. Adds basic but not rich semantics.
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 uses a specific verb (Jump) and resource (API page) with a clear parameter (symbol name). It distinguishes from sibling tools like pydantic_search and pydantic_get by indicating navigation rather than searching or retrieving.
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?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites, context, or when not to use it. Sibling tools exist but no differentiation cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a local doc page and return plain text + html. Supports chunking for large documents via max_chars parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| max_chars | No | ||
| path_or_url | Yes |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| html | Yes | |
| path | Yes | |
| text | Yes | |
| max_chars | No | |
| truncated | No | |
| html_length | No | |
| text_length | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes output format and chunking feature, but lacks details on idempotency, error behavior, or permissions; no annotations to offset.
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?
Two concise sentences with front-loaded main action and 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?
Covers core functionality and chunking, but misses explanation of path_or_url format or limitations; output schema exists but not referenced.
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?
Adds context for max_chars (chunking large documents), but path_or_url remains unexplained; schema has 0% parameter 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?
Clearly states 'Fetch a local doc page and return plain text + html', specifying both the action and output format, distinguishing it from siblings like pydantic_search.
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?
No guidance on when to use this tool versus alternatives like pydantic_search or pydantic_section; only mentions chunking support but without conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report data roots and offline mode.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'report' without disclosing behavioral traits like side effects, read-only nature, or output characteristics. More detail is needed for safe usage.
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 concise sentence that front-loads the action. It is efficient but could benefit from slight expansion for clarity without losing conciseness.
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 no parameters or output schema, the description is minimal. It does not specify the return format or how the tool produces its report, leaving some gaps for an agent.
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?
There are zero parameters, so the description does not need to explain parameter semantics. The baseline is 4, though it could clarify the meaning of 'data roots' and 'offline mode' further.
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 'Report' and resource 'data roots and offline mode', clearly indicating the tool's purpose. It implicitly distinguishes from siblings like pydantic_get and pydantic_api, which are likely for other operations.
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 like admin_cache_status or other pydantic tools. No when/when-not or context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search local Pydantic + Pydantic-AI docs with filters.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| site | No | ||
| query | Yes | ||
| heading | No | ||
| keywords | No |
| Name | Required | Description |
|---|---|---|
| results | 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 only states 'Search ... docs with filters' without disclosing whether it is read-only, required authentication, rate limits, or any side effects. Basic behavioral context is missing.
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 extremely concise—one sentence with no fluff. It is front-loaded with the key verb and resource, making it efficient for agents to parse.
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 presence of an output schema (true), return values are covered. However, with 5 parameters and no parameter descriptions, and minimal usage guidance, the description is incomplete for a search tool with multiple filters. The complexity requires more detail than provided.
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 0%, and the description does not explain any of the 5 parameters (k, site, heading, keywords, query) beyond the generic term 'filters'. The description adds very little meaning to the parameter names and defaults.
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 verb 'Search', the resource 'local Pydantic + Pydantic-AI docs', and mentions filters, which distinguishes it from sibling tools like pydantic_get, pydantic_section, etc.
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 implies usage for filtered searches but provides no explicit guidance on when to use this tool versus alternatives like pydantic_api or pydantic_get. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract a section by anchor from a local page.
| Name | Required | Description | Default |
|---|---|---|---|
| anchor | Yes | ||
| path_or_url | Yes |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| path | Yes | |
| anchor | Yes | |
| section | Yes | |
| truncated | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'extract' without indicating whether it is read-only, if it requires permissions, or what happens on missing anchor. No side effects or limitations are mentioned.
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 concise sentence, which is front-loaded. However, it is too terse, sacrificing necessary detail for brevity. Every sentence should earn its place, but here it leaves gaps that reduce overall effectiveness.
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 has an output schema, return values are covered. However, with 2 required parameters and no parameter descriptions, and no usage guidance, the description is incomplete for an agent to understand the tool's full role within the pydantic family.
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 0%, yet the description adds no explanation for the two parameters. 'path_or_url' could be a file path or URL, but this is not clarified. 'anchor' is left completely undefined. The description fails to compensate 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 verb 'Extract', resource 'section', and context 'by anchor from a local page'. It differentiates from sibling tools like pydantic_get (retrieves pages) and pydantic_search (searches). However, the term 'section' is ambiguous—could mean an HTML anchor or a code section—but the anchor parameter clarifies it.
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?
No guidance on when to use this tool versus alternatives like pydantic_get or pydantic_search. It does not mention prerequisites, when not to use it, or provide examples. The description is purely declarative.
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.0admin_cache_statusadmin_rebuild_indiceshealth_pinghealth_validatepydantic_apipydantic_getpydantic_modepydantic_searchpydantic_sectionTools are mostly distinct: admin and health tools handle backend tasks, while pydantic tools handle content retrieval. pydantic_get and pydantic_section could be confused (both fetch page content), but descriptions clarify that get returns full text and section extracts a specific anchor.
Naming follows a clear 'category_verb' pattern: admin_*, health_*, pydantic_*. Within pydantic, verb_s are used (api, get, mode, search, section). This consistency helps agents predict tool behavior.
9 tools is an appropriate size for a documentation server. It covers admin operations, health checks, and core doc retrieval/search without being too sparse or overwhelming.
The tool set covers essential doc operations: search, fetch page, extract section, jump to API. However, missing a tool to list available pages or get a table of contents, which would be useful for discovery.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Read-only MCP server for the OrchestKit docs: full-text search + Markdown fetch. No auth.
MCP server for querying Forkast documentation
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Magic-Man-us/mcp_pydantic_docs'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
