Document Extractor MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific operations: authentication, collection management, connection checks, CRUD operations (delete, get, list, search), and document extraction. No tools overlap in functionality, making selection straightforward for an agent.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., authenticate, collection_info, delete_document), with clear and descriptive naming. There are no deviations in style or convention across the set.
Tool Count5/5
With 9 tools, the server is well-scoped for document extraction and management, covering authentication, setup, CRUD operations, and search. Each tool serves a necessary function without bloat or redundancy.
Completeness4/5
The toolset provides strong coverage for core document workflows: authentication, collection setup, extraction, retrieval, listing, searching, and deletion. A minor gap exists in update functionality (e.g., update_document), but agents can work around this by deleting and re-extracting.
Average 3.3/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/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 fails to clarify whether 'Test' means validation-only (read-only) or if it establishes a persistent session/token for subsequent calls. No mention of return values, error conditions, or 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?
Extremely concise at 7 words with no redundancy. Information density is appropriate for the length, though brevity contributes to other gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As an authentication tool with no output schema and no annotations, the description should explain success indicators, return format (token?), and relationship to subsequent operations. Current description is insufficient for a security-critical operation.
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 schema documents all three parameters adequately. The description adds minimal semantic value beyond the schema, merely noting that email/password are 'credentials' and that PocketBase is the target system.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb (Test authentication), resource (PocketBase), and mechanism (provided credentials). However, it does not explicitly differentiate from the sibling 'connection_status' tool, which also relates to server connectivity verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus 'connection_status' or other prerequisites. It does not indicate whether this should be called before other operations or what indicates authentication success.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only mentions pagination behavior. Lacks disclosure on return format, whether results are ordered, authentication requirements, or handling of empty collections.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, seven words with no redundancy. 'Stored' is slightly redundant with 'from PocketBase' but overall efficient. Front-loaded with action verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for simple 2-parameter operation given good schema coverage, but gaps remain. No output schema exists yet description doesn't hint at return structure. Fails to clarify relationship with search_documents sibling, which is critical for tool selection.
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 coverage is 100% with detailed param descriptions (limit/page/range defaults). Description mentions 'pagination' which contextually maps to the parameters but adds no syntax or format details beyond what's in schema. Baseline 3 appropriate for high-coverage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource combination (List documents from PocketBase) and specifies pagination mechanism. However, it does not distinguish from sibling search_documents, which likely performs filtered queries while this returns unfiltered lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to prefer this over search_documents or get_document. Does not mention whether authentication is required (relevant given authenticate sibling) or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full behavioral burden. Merely restates the operation name 'Delete' without disclosing permanence, failure modes (e.g., if ID not found), or side effects. Lacks critical safety context for a destructive operation.
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?
Nine words, front-loaded with action verb, zero redundancy. Every word earns its place in conveying the essential operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a single-parameter operation with complete schema documentation, but minimum-viable given the destructive nature. Missing warnings about data loss that should compensate for lack of destructiveHint annotation.
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 coverage is 100% with clear parameter description ('Document ID to delete'). Main description腹adds 'by ID' which aligns with schema but doesn't add syntax details, validation behavior, or format requirements beyond what the schema already provides. Baseline 3 appropriate for high-coverage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb ('Delete'), resource ('document'), and scope ('from PocketBase by ID'). Implicitly distinguishes from read siblings (get_document, extract_document, etc.) by naming the destructive operation, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use versus alternatives, no warnings about permanent data loss, and no prerequisites (e.g., authentication requirements despite 'authenticate' sibling existing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions 'full-text search' indicating matching behavior, but lacks crucial behavioral details: result ranking/relevance, case sensitivity, partial vs exact matching, return format structure, or pagination behavior beyond the limit parameter.
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 efficient sentence (8 words) with front-loaded action verb. No redundant phrases or unnecessary padding; every word conveys search mechanism, target fields, and method.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple 2-parameter search tool with complete schema coverage. Missing output format description (relevant since no output schema exists), but tool name and 'search' verb sufficiently imply list return. Could benefit from mentioning result ranking or snippet inclusion.
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 coverage is 100%, establishing baseline 3. Description reinforces that query searches both 'title or content' (aligning with schema) and adds 'full-text search' context about query interpretation, but does not add syntax examples, query operators, or explain the default limit behavior beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb ('Search') and resource ('documents') with scope ('by title or content'). Mentions 'full-text search' mechanism, implying filtering capability that distinguishes it from list_documents (enumeration) and get_document (ID-based retrieval), though lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus list_documents (all documents) or get_document (specific ID lookup). Missing explicit when-to-use criteria or prerequisites like query syntax requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It adds valuable context that this retrieves 'full content' (implying complete payload vs. summaries), but omits error behavior (e.g., 404 handling), authentication requirements, and return format details expected for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Nine words with minimal waste. 'Specific' is slightly redundant with 'by ID' but helps emphasize single-item retrieval versus bulk operations. The structure front-loads the action and maintains readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity single-parameter retrieval tool, the description adequately covers the core operation. However, given the absence of output schema and annotations, it should disclose error conditions (e.g., 'returns error if document not found') to be complete.
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 coverage is 100% (the 'id' parameter is fully documented as 'Document ID to retrieve'). The description references 'by ID' but adds no additional semantic detail—such as ID format, where to obtain valid IDs, or validation rules—beyond what the schema explicitly states. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a clear verb ('Get'), resource ('document'), and scope ('by ID with full content'). The phrase 'by ID' effectively distinguishes this from siblings like search_documents (query-based) and list_documents (plural/enumeration), though it could explicitly contrast with extract_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While 'by ID' implies direct lookup when the identifier is known, the description fails to state when to prefer this over search_documents or handle cases where the ID is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions 'statistics' implying read-only metadata retrieval, but lacks disclosure on performance implications of 'detailed' queries, specific return structure, or confirmation of read-only status given no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single efficient sentence with strong verb front-loading ('Get'). No redundant text, though 'detailed information' is vague and could be more specific about what statistics are returned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a zero-parameter tool but vague on specific return values given no output schema exists. Mentions 'statistics' generally but doesn't clarify if this returns counts, sizes, timestamps, or schema info. Relationship to ensure_collection sibling remains unclear.
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?
Input schema contains zero parameters, triggering baseline score of 4 per rubric. No parameter documentation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('Get'), resource ('documents collection'), and scope ('detailed information', 'statistics'). It distinguishes from document-level siblings like get_document and delete_document by targeting collection-level metadata rather than individual documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus ensure_collection (likely for initialization/setup) or when to prefer this over list_documents for collection summaries. No prerequisites or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. 'Check' implies read-only/idempotent behavior, but description lacks disclosure of return format, error states when disconnected, or whether this operation itself can fail/timeout.
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 of appropriate length. Front-loaded with verb 'Check'. No redundancy or filler. Efficiently communicates scope without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet description only hints at return content ('status and configuration') without elaborating structure or key fields. For a diagnostic tool, adequate but gap remains regarding what specific status values/config keys are returned.
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?
Zero parameters present, meeting baseline expectation. Schema is empty object with 100% coverage (trivially). Description correctly implies no filtering or input is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific verb 'Check' with clear resource 'PocketBase connection status and configuration'. Mentions 'PocketBase' which distinguishes from generic connection tools, though could explicitly contrast with sibling 'authenticate' (which establishes sessions vs. this which queries state).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to invoke (e.g., before other operations vs. troubleshooting) or prerequisites. No mention of when to prefer over 'authenticate' or how it relates to the connection lifecycle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. While 'store' indicates a write operation, description lacks critical behavioral details: idempotency, overwrite behavior on duplicates, validation rules for URLs, error handling, or authentication requirements.
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 efficient sentence with zero waste. Front-loaded with action verbs ('Extract... and store') and immediately scopes inputs (specific URL types) and outputs (PocketBase destination).
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 single-parameter ingestion tool. Description covers source system (external URL) and target system (PocketBase), which is sufficient given no output schema exists and schema fully documents the input parameter.
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 coverage is 100%, establishing baseline 3. The parameter description in the schema already specifies 'Microsoft Learn or GitHub URL', so the main description adds minimal semantic value beyond repetition. No additional syntax details or examples provided.
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?
Clear specific verbs ('Extract' and 'store') with defined resource (document content from Microsoft Learn/GitHub) and destination (PocketBase). Effectively distinguishes from siblings like get_document (internal retrieval) and search_documents (querying) by specifying external URL sources.
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?
Provides implied usage scope by restricting to 'Microsoft Learn or GitHub URL', indicating when to use this over internal document tools. However, lacks explicit guidance on prerequisites (e.g., authentication) or when-not-to-use compared to siblings like ensure_collection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It successfully discloses the conditional mutation pattern (creates only if missing), which is critical. However, lacks disclosure of return values, error conditions, idempotency guarantees, or permission requirements—significant gaps for a state-mutating tool without output schema coverage.
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, 11 words, zero waste. Front-loaded with action verbs. Every word earns its place describing the dual check/create behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 0-parameter tool but gaps remain: no description of return values (success indicator, created vs existed status) despite mutation semantics and missing output schema. Error conditions and permission requirements also absent.
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?
Zero parameters present, setting baseline to 4 per rubric. Description correctly implies no resource identifiers needed (operates on implicit 'documents' collection), avoiding parameter misdirection.
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?
Specific verbs (Check/Create) + specific resource (documents collection) clearly distinguish this from siblings like delete_document or collection_info. The conditional 'if needed' precisely captures the idempotent ensure pattern.
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?
Implies usage (when collection might not exist) but lacks explicit when-to-use guidance, prerequisites, or distinction from collection_info. No mention that this should be called before document operations if uncertainty exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

documentation-mcp-using-pocketbase MCP server

Copy to your README.md:

[![documentation-mcp-using-pocketbase MCP server](https://glama.ai/mcp/servers/DynamicEndpoints/documentation-mcp-using-pocketbase/badges/card.svg)](https://glama.ai/mcp/servers/DynamicEndpoints/documentation-mcp-using-pocketbase)

Score Badge

Copy to your README.md:

[![documentation-mcp-using-pocketbase MCP server](https://glama.ai/mcp/servers/DynamicEndpoints/documentation-mcp-using-pocketbase/badges/score.svg)](https://glama.ai/mcp/servers/DynamicEndpoints/documentation-mcp-using-pocketbase)

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/DynamicEndpoints/documentation-mcp-using-pocketbase'

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