Extract PDFs to Markdown, RAG chunks and cited tables; publish tracked Doc Links with read stats.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.1/5 across 7 of 7 tools scored.
Each tool targets a distinct operation: PDF extraction, table extraction, chunking, link creation, listing, stats, and revocation. No overlapping purposes.
All tools follow a consistent verb_noun pattern with lowercase and underscores, e.g., create_doc_link, extract_pdf, list_tables.
Seven tools is an appropriate scope for a PDF extraction and link management server, covering both processing and lifecycle operations without excess.
Covers core extraction (text, tables, chunks) and link management (create, list, stats, revoke). Minor gap: no update operation for doc links, but not critical.
create_doc_linkAInspectPublish a PDF as a tracked doc.page Doc Link and get back a shareable URL. The link belongs to the API key's account and also appears in its doc.page library. Requires an API key. Free plan: up to 3 active links; custom vanity slugs are premium-only. Optional expiry and open-notification toggle.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | http(s) URL of the PDF to publish (max 25 MB). | |
| name | No | Display name in the library. Defaults to the filename. | |
| slug | No | Custom vanity slug (premium plans only). Lowercase letters, digits and hyphens. | |
| expiresAt | No | ISO 8601 date-time after which the link stops working. Omit for no expiry. | |
| notifyOnOpen | No | Email the account owner on the first open. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses behavioral traits: link ownership (API key's account), library appearance, plan limits, and optional expiry/notifications. This is transparent but could mention rate limits or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two clear sentences plus clauses), front-loaded with the main purpose, and every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return value (shareable URL), creation behavior, plan context, and optional parameters. It covers all key aspects for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds context beyond schema by mentioning the premium restriction for slug and default behavior for name and notifyOnOpen. This adds moderate value.
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 action ('Publish a PDF as a tracked doc.page Doc Link') and the return value ('get back a shareable URL'). It distinguishes this tool from siblings like revoke_doc_link and list_doc_links.
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 mentions account requirements (API key), plan limitations (Free plan: 3 active links, premium vanity slugs), but does not explicitly state when not to use this tool or compare it to alternatives like get_doc_link_stats or list_doc_links.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_pdfAInspectExtract a PDF into clean Markdown and structured elements (headings, paragraphs). Returns the canonical ExtractedDocument object. mode "hybrid" runs a heavier semantic engine that also reconstructs tables and bounding boxes; the default "fast" engine is prose-only (low confidence.tables).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | http(s) URL of the PDF to extract. | |
| mode | No | fast = prose engine. hybrid = semantic engine with tables + bounding boxes when deployed; falls back to fast with a warning otherwise. | |
| outputs | No | Subset of outputs to include. Default: markdown and elements. | |
| chunkTokens | No | Target chunk size in tokens (when chunks are requested). Default 512. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It discloses the return type (ExtractedDocument), mode differences, and fallback behavior for hybrid. However, it does not mention error handling or side effects, which is a minor gap.
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 three sentences, front-loading the core purpose and return type, then details on modes. Every sentence adds critical information with zero redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description clarifies the return value is the canonical ExtractedDocument object and lists structural elements. It lacks explanation of error conditions or input constraints like file size, but covers the main use case well.
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?
All parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds significant value for the 'mode' parameter by explaining engine differences and fallback behavior, slightly elevating it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts a PDF to clean Markdown and structured elements, with a specific verb ('Extract') and resource ('PDF'). It distinguishes from siblings like list_tables and get_chunks by focusing on full document extraction.
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 explains when to use fast vs hybrid mode, but it does not provide explicit guidance on when to use this tool versus alternatives like list_tables for table extraction. This lack of cross-tool comparisons leaves usage partially ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_chunksAInspectSplit a PDF into semantic chunks ready for embeddings (RAG). Each chunk carries its text, estimated tokens, starting page, section heading and the source element ids for citation.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | http(s) URL of the PDF to chunk. | |
| maxTokens | No | Target chunk size in tokens. Default 512. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully describes what the output contains (text, tokens, page, heading, element IDs). However, it does not mention required permissions, destructive effects, or operational constraints (e.g., file size limits).
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 sentences, no wasted words, front-loaded with the core action (split PDF into chunks) followed by output details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema is absent, but the description compensates by detailing chunk contents. Lacks error conditions, limits, or prerequisites. For a simple two-parameter tool, it is largely complete.
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 100% (both url and maxTokens have descriptions). The tool description adds context about output but no additional meaning to the parameters beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Split' and resource 'PDF into semantic chunks'. It explicitly states the RAG/embeddings use case and distinguishes from siblings like extract_pdf (raw text) and list_tables (tables).
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 RAG embeddings but does not provide explicit when-to-use, when-not-to-use, or alternatives. No comparison with sibling tools like extract_pdf.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_doc_link_statsAInspectReading analytics for one Doc Link of the API key's account, by id or slug. Always returns the summary (total views, unique visitors, last visit). Premium plans additionally get countries, visitor companies (as_org) and per-page views + average dwell time; pass include:["visits"] for the recent visit rows. Requires an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Doc Link item id (from create_doc_link or list_doc_links). | |
| slug | No | Doc Link slug — alternative to id. | |
| include | No | Extra sections. "visits" adds the recent visit rows (enriched on premium plans). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses read-only behavior ('Reading analytics'), API key requirement, and return structure (summary vs premium extras, include parameter). It does not cover rate limits or error handling, but the core behavior is well communicated.
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?
Three tightly written sentences: first sets the action, second details default returns, third covers premium and special parameter. Every sentence is essential, no redundancy, and the most critical info 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?
Given no output schema and simple parameter set, the description covers purpose, parameters, return values, authentication, and tiered functionality. It does not mention error cases or id/slug mutual exclusivity, but overall it's sufficient for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds beyond schema by explaining premium plan enrichments, how 'include' adds recent visit rows, and the context for id/slug alternatives. This adds meaningful practical guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: reading analytics for a single Doc Link by id or slug. It specifies the return values (summary always, premium extras) and distinguishes itself from siblings by focusing on analytics rather than creation, extraction, or listing.
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 context: for a specific Doc Link using id or slug, and requires an API key. It does not explicitly state when not to use or name alternatives, but the sibling tools list and the 'by id or slug' phrasing provide implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_doc_linksAInspectList the Doc Links of the API key's account (id, slug, URL, name, disabled/expiry state, total views, last view). Use this to recover links created in earlier sessions before querying stats. Requires an API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it lists links and requires an API key, but doesn't disclose potential pagination, rate limits, or whether results are all links at once. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with the action and key details. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, description covers purpose and usage well. Could mention return format or pagination, but overall sufficient.
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 in schema, so description doesn't need to add param info. Mentions filtering by account implicitly. Baseline score of 4 for zero-parameter tools.
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 'List' and resource 'Doc Links' with specific fields (id, slug, URL, etc.). Distinguishes from siblings like create_doc_link and get_doc_link_stats by focusing on listing all links.
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 says to use this tool to recover links from earlier sessions before querying stats, providing clear context. Missing explicit when-not-to-use or mention of alternatives like get_doc_link_stats for specific stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tablesBInspectReturn every table in a PDF as structured JSON (reconstructed rows and columns) with page and bounding box for verifiable citations. Uses the semantic (hybrid) engine.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | http(s) URL of the PDF. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should fully disclose behavioral traits. While it mentions the output format and engine type, it omits critical details such as whether it is read-only, authentication needs, rate limits, error handling (e.g., PDF with no tables), and the extent of PDF support (e.g., scanned vs. text-based).
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 (two sentences) with the main action front-loaded. Every sentence provides essential information without waste.
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 (single required parameter) and lack of output schema, the description provides adequate context about the output (structured JSON with page and bounding box). However, it does not explain error scenarios, limitations (e.g., PDF accessibility, image-based tables), or contrast with similar sibling tools, leaving gaps for an AI 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?
The input schema has high coverage (100%) and includes a description for the only parameter (url). The tool description adds no extra meaning beyond the schema, adhering to the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns every table in a PDF as structured JSON with rows, columns, page, and bounding box. It uses a specific verb ('Return') and resource ('every table in a PDF'), but does not explicitly differentiate from sibling tools like extract_pdf.
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 explicit guidance on when to use this tool versus alternatives (e.g., extract_pdf). It does not mention when not to use it or prerequisites, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
revoke_doc_linkAInspectDisable a Doc Link of the API key's account (by id or slug) so the public URL stops serving. The item and its stats remain in the library; on the free plan this frees an active-link slot. Requires an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Doc Link item id. | |
| slug | No | Doc Link slug — alternative to id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that item/stats remain and free plan effect, compensating for absent annotations. Could add reversibility info.
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?
Three concise sentences, each adding value: action, side effects, requirement.
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?
Missing output schema, description does not indicate response format or error conditions, and does not clarify that at least one parameter is 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?
Schema already describes id and slug; description reiterates they are alternatives without adding new semantic details.
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 (disable) and resource (Doc Link), explains effect (stops serving), and distinguishes from siblings like create_doc_link and list_doc_links.
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?
Implies use case by stating when it frees a slot and requiring API key, but lacks explicit comparison to alternatives like get_doc_link_stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
