KDAN PDF
Server Details
Upload, edit, compress, protect, redact, and compare PDFs with KDAN PDF in Claude and ChatGPT.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- KDAN-PDF/KDAN-PDF-MCP
- GitHub Stars
- 17
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.
Tool Definition Quality
Average 4.4/5 across 13 of 15 tools scored. Lowest: 3.3/5.
Each tool targets a distinct operation: uploading (single vs batch), status checking (upload vs job), compression, page deletion, info extraction, image inspection, redaction workflow, password management, and viewing. No two tools overlap in purpose.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., batch_upload_pdf, check_upload_status, compress_pdf). There is no mixing of conventions or ambiguous verbs.
15 tools cover the core PDF operations: upload, status, compare, compress, page deletion, info, images, redaction, password, and view. This count is well-scoped for the domain, not too few or too many.
The tool set provides a comprehensive surface for PDF manipulation, including upload, compression, page management, redaction, and password protection. Minor gaps exist, such as missing merge or split PDF operations, but the core workflows are covered.
Available Tools
15 toolsbatch_upload_pdfBatch Upload PDFsAInspect
Upload multiple PDF files from ChatGPT file attachments (download URLs).
Use this when the user provides multiple file attachments in ChatGPT. Downloads each PDF from its signed URL and stores it. Returns session_id and a list of job_ids.
MANDATORY WORKFLOW before calling this tool:
ALWAYS call check_upload_status FIRST — even if you think the files are new.
Only include files confirmed absent from check_upload_status. If ALL files are already uploaded, skip batch_upload_pdf entirely and reuse the existing job_ids.
Reuse job_ids from already_uploaded — do NOT re-upload those files. Skipping step 1 and calling batch_upload_pdf directly is FORBIDDEN.
After batch_upload_pdf completes: if the user requested a comparison, call 'compare_pdfs' with the returned job_ids immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| pdf_files | Yes | List of file objects from ChatGPT, each containing download_url (and optionally name/filename). | |
| session_id | No | Existing session ID to group these files. If omitted, a new session is created. |
Output Schema
| Name | Required | Description |
|---|---|---|
| jobs | Yes | |
| file_count | Yes | |
| reply_note | Yes | |
| session_id | Yes | |
| instructions | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states it 'Downloads each PDF from its signed URL and stores it' and returns session_id and job_ids. This matches annotations (readOnlyHint=false, destructiveHint=false) and adds context that it's a write operation that stores files. No contradiction.
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?
Description is longer but well-structured: purpose first, then usage, mandatory workflow in clear steps, and post-action. Every sentence adds value, though the workflow details could be slightly more concise. Front-loaded with purpose.
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, the description adequately covers what the tool does, preconditions, workflow, and post-actions. It mentions return values (session_id, job_ids). No gaps for the complexity of multiple files and dependency on check_upload_status.
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 covers 100% of parameters, so baseline is 3. Description adds minor context (e.g., 'file objects from ChatGPT, each containing download_url' for pdf_files, and session_id for grouping). However, it doesn't provide significant additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Upload multiple PDF files from ChatGPT file attachments (download URLs)'. It uses a specific verb 'upload' and resource 'multiple PDF files from ChatGPT', distinguishing it from sibling tools like 'upload_pdf' (single file) and 'check_upload_status'.
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 'Use this when the user provides multiple file attachments in ChatGPT.' Provides a mandatory pre-workflow: always check_upload_status first, only include absent files, and skip if all are already uploaded. Also specifies post-action: call compare_pdfs if comparison requested.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
change_passwordChange PDF PasswordADestructiveInspect
Change the password of an already-protected PDF file.
Creates a NEW job_id (with parent_job_id linking to the source). After the operation completes, call 'view_pdf' with the new job_id to display the result. Do NOT call this on an unprotected PDF — use set_password instead.
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | New owner password. | |
| job_id | Yes | Job ID of the password-protected PDF (use the latest job_id). | |
| password | Yes | New user password. | |
| session_id | Yes | Session ID that the job belongs to. | |
| old_password | Yes | The current user password needed to unlock the PDF. |
Output Schema
| Name | Required | Description |
|---|---|---|
| job_id | Yes | |
| filename | Yes | |
| mime_type | Yes | |
| reply_note | Yes | |
| session_id | Yes | |
| download_url | Yes | |
| instructions | Yes | |
| parent_job_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true), the description reveals that a new job_id is created with parent_job_id linking back, and that the result is viewable via view_pdf. This adds valuable 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?
Three concise sentences: first states core purpose, second provides behavioral details, third gives usage constraints and alternatives. No unnecessary 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?
With 5 parameters fully described in schema, output schema present, annotations provided, and description covering key behaviors and constraints, the tool definition is complete and clear 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?
Input schema covers all 5 parameters with descriptions (100% coverage). The description does not add additional semantic detail beyond confirming the roles of old_password and new passwords, so baseline score of 3 is appropriate.
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 changes the password of an already-protected PDF file. It distinguishes from sibling tool set_password by specifying it is for already-protected PDFs.
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 instructs not to call on unprotected PDFs and directs to use set_password instead. Also provides post-operation guidance to call view_pdf with the new job_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_upload_statusCheck Upload StatusARead-onlyIdempotentInspect
Check existing uploads and determine which files still need uploading.
Call this BEFORE upload_pdf or create_upload_page to avoid duplicate uploads. Also call it after the user uploads via the widget to discover the new file and its job_id.
Returns 'session_id' (always — store it!), plus:
'already_uploaded': files found in this session with reusable job_ids
'needs_upload': files not yet in this session (must be uploaded)
You MUST call this tool before any upload, and you MUST act on its result immediately:
'needs_upload' is non-empty → call upload_pdf (single) or batch_upload_pdf (multiple) with ONLY the files listed in 'needs_upload'. Pass the same session_id. Do NOT upload files in 'already_uploaded'.
'needs_upload' is empty → skip uploading entirely; use the job_ids from 'already_uploaded'.
When pending_filenames is omitted, returns all jobs currently in the session.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | Session ID from a previous upload_pdf or create_upload_page call. If omitted, a new session_id is generated and ALL pending files are treated as needs_upload (new workflow). | |
| pending_filenames | No | Bare filenames to check, e.g. ['FileA.pdf', 'FileB.pdf']. Never include directory paths like '/mnt/data/FileA.pdf'. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe, idempotent operation. Description adds behavioral details: returns session_id always, plus already_uploaded/needs_upload lists, and requires immediate action on result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured and front-loaded, but somewhat verbose with detailed workflow. Slightly could be shortened without losing clarity.
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?
Complete description covering purpose, workflow, return values, and prerequisites. Output schema exists so return details are handled. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100%). Description adds context: session_id from previous calls generates new if omitted; pending_filenames are bare filenames without directory paths.
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 checks upload status and determines which files need uploading. It distinguishes from siblings like upload_pdf and create_upload_page by specifying it should be called before them.
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 call (before upload_pdf/create_upload_page, after user uploads via widget) and what to do based on result (call upload_pdf/batch_upload_pdf with needs_upload, skip if empty). Provides clear workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_pdfsCompare PDFsARead-onlyIdempotentInspect
MANDATORY for all document comparison requests. Compare two PDFs side-by-side.
When the user asks to compare, diff, or find differences between two PDFs, you MUST call this tool — NEVER attempt to compare documents using text analysis. Displays an interactive side-by-side visual diff widget with colored highlights: red = deleted, yellow = replaced, green = inserted. The widget IS the comparison result — do NOT re-summarize the differences after calling.
Before calling, confirm both job_ids exist via check_upload_status.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id_a | Yes | Job ID for the first (original) PDF. | |
| job_id_b | Yes | Job ID for the second (modified) PDF. | |
| session_id | Yes | Session ID that both jobs belong to. |
Output Schema
| Name | Required | Description |
|---|---|---|
| pages | Yes | |
| totals | Yes | Aggregate counts for word-level differences. Args: TypedDict: Total difference counts. |
| pages_a | Yes | |
| pages_b | Yes | |
| job_id_a | Yes | |
| job_id_b | Yes | |
| pdf_url_a | Yes | |
| pdf_url_b | Yes | |
| session_id | Yes | |
| total_pages | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) are consistent. Description adds context: displays an interactive side-by-side widget with colored highlights (red=deleted, yellow=replaced, green=inserted) and states the widget IS the result – no re-summarization needed. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the mandatory instruction and key behavior. While slightly verbose, each sentence adds value. Could be trimmed slightly, but overall effective.
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 complexity (visual widget) and presence of an output schema, the description covers behavior, result interpretation, and prerequisite check. It is complete enough for an agent to 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 already present. The description doesn't add significant extra meaning beyond what the schema provides, so baseline 3 is appropriate.
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 it compares two PDFs side-by-side using a visual diff widget, with specific verb 'compare' and resource 'PDFs'. It distinguishes from sibling tools like 'batch_upload_pdf' or 'compress_pdf' by being the only comparison tool.
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 marks itself as MANDATORY for all document comparison requests, instructs when to call (user asks to compare/diff/find differences), and provides what NOT to do (never use text analysis). It also includes a prerequisite to check job IDs via check_upload_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compress_pdfCompress PDFAIdempotentInspect
Compress a PDF to reduce its file size and return a new versioned file.
MANDATORY: Before calling this tool, call 'check_upload_status' with the session_id to confirm the file exists and retrieve the latest job_id. Skipping this check and calling compress_pdf directly is FORBIDDEN.
Each call creates a NEW job_id (with parent_job_id linking to the source). The original PDF version is preserved unchanged — previous versions remain accessible. After compression completes, call 'view_pdf' with the new job_id to display the result.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job ID of the PDF to compress (use the latest job_id from check_upload_status). | |
| session_id | Yes | Session ID that the job belongs to. |
Output Schema
| Name | Required | Description |
|---|---|---|
| job_id | Yes | |
| filename | Yes | |
| mime_type | Yes | |
| reply_note | Yes | |
| session_id | Yes | |
| download_url | Yes | |
| instructions | Yes | |
| original_size | Yes | |
| parent_job_id | Yes | |
| compressed_size | Yes | |
| size_reduction_percent | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states 'Each call creates a NEW job_id', implying non-idempotent behavior, but annotation declares idempotentHint=true. This is a direct contradiction, requiring score 1 per rubric.
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?
Every sentence serves a purpose: core action, mandatory prerequisite, versioning behavior, and post-compression step. No wasted text.
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?
Comprehensive coverage: prerequisites, versioning, and follow-up actions. Output schema exists, so return values are not needed. Complete for this tool's complexity.
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. Description adds usage context for job_id (use latest from check_upload_status), improving semantics 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?
Clear verb and resource: 'Compress a PDF to reduce its file size and return a new versioned file.' Distinguishes from siblings by specifying compression and versioning behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit prerequisite: mandatory call to check_upload_status before using this tool. Also states that each call creates a new job_id, guiding proper usage sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_upload_pageCreate PDF Upload PageAInspect
Display an interactive PDF upload widget directly in the chat.
Use this when the user wants to upload a local PDF file from their device. This is the standard upload method for MCP clients (e.g. Claude) where file attachments with download URLs are not available.
Do NOT call upload_pdf when using this tool — the widget handles the upload automatically. The widget renders inline and the PDF viewer appears after the user selects a file. Do NOT call view_pdf after this tool; the widget manages the UI. Never tell the user the file is still uploading; the widget handles the spinner.
After the user uploads via the widget and notifies you, call check_upload_status(session_id=) to discover the uploaded file and its job_id before proceeding with any operation.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | Existing session ID to continue an ongoing workflow. If omitted, a new session is created. Always pass the same session_id throughout the entire conversation to keep all files grouped together. |
Output Schema
| Name | Required | Description |
|---|---|---|
| job_id | Yes | |
| reply_note | Yes | |
| session_id | Yes | |
| upload_url | Yes | |
| instructions | Yes | |
| upload_token | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description details widget behavior: automatic upload handling, inline rendering, spinner management, and user notification protocol. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose and clear sections. Slightly verbose but every sentence earns its place. Could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the entire workflow: when to use, what it does, what not to do, and what to do next. Given the complexity and presence of output schema, it is fully complete for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds practical context for the session_id parameter: 'Always pass the same session_id throughout the entire conversation to keep all files grouped together.' Schema coverage is 100% but description enhances understanding.
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: 'Display an interactive PDF upload widget directly in the chat.' It distinguishes from sibling tools like upload_pdf and view_pdf by explicitly instructing not to call them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance: 'Use this when the user wants to upload a local PDF file from their device.' Includes clear 'do NOT' instructions for sibling tools and post-usage steps like calling check_upload_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_pdf_pageDelete PDF PagesADestructiveInspect
Delete one or more pages from a PDF and return a new versioned file.
MANDATORY: Before calling this tool, call 'check_upload_status' with the session_id to confirm the file exists and retrieve the latest job_id. Skipping this check and calling delete_pdf_page directly is FORBIDDEN.
Each call creates a NEW job_id (with parent_job_id linking to the source). The original PDF version is preserved unchanged — previous versions remain accessible. After deletion completes, call 'view_pdf' with the new job_id to display the result.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job ID of the PDF to modify (use the latest job_id from check_upload_status). | |
| session_id | Yes | Session ID that the job belongs to. | |
| page_numbers | Yes | 1-based page numbers to delete. Duplicates are ignored. |
Output Schema
| Name | Required | Description |
|---|---|---|
| job_id | Yes | |
| filename | Yes | |
| mime_type | Yes | |
| reply_note | Yes | |
| session_id | Yes | |
| download_url | Yes | |
| instructions | Yes | |
| deleted_pages | Yes | |
| parent_job_id | Yes | |
| remaining_pages | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides important behavioral details: each call creates a new job_id with parent linking, original version preserved, and the need to call view_pdf after. Annotations merely indicate destructive, but description adds nuance.
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 with only essential information. The first sentence clearly states the tool's action. The mandatory prerequisite is highlighted. 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?
The description covers the main workflow (prerequisite, action, post-condition) and key behavioral aspects. However, it does not mention what happens on error (e.g., invalid page numbers) or describe the output (which is covered by output schema). Slightly incomplete for a destructive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to compensate. The description does not add further parameter semantics beyond what the schema already provides (e.g., format, constraints). Baseline 3 is appropriate.
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 opens with a clear verb+resource: 'Delete one or more pages from a PDF and return a new versioned file.' This is specific and distinguishes from other PDF manipulation tools like compress_pdf or redact_by_text_range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the mandatory prerequisite (call check_upload_status) and post-condition (call view_pdf), which guides proper usage. However, it does not discuss when not to use this tool or compare it to alternatives like compress_pdf or redact_by_text_range.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pdf_infoGet PDF InfoARead-onlyIdempotentInspect
Use this when you need to read the text content of each page to decide which pages to delete. Returns page count and a text preview of every page. Use for text-based identification: table of contents, blank pages, cover page, etc. For visual content (logos, images, photos), use get_pdf_page_images instead.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job ID of the PDF to inspect. | |
| session_id | Yes | Session ID that the job belongs to. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare 'readOnlyHint: true' and 'destructiveHint: false', covering safety. The description adds that it returns 'page count and a text preview of every page', which is useful but does not disclose additional behavioral traits beyond what annotations provide.
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, front-loaded with the primary purpose and use case, followed by a clear alternative. Efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, read-only, no output schema), the description covers the key points: what it returns, when to use, and the alternative. It could mention that text extraction is performed, but that is implied.
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%, so the schema already fully describes both parameters. The description does not add any new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('read the text content') and resource ('each page to decide which pages to delete'). It distinguishes itself from the sibling tool 'get_pdf_page_images' by specifying 'text-based identification' versus 'visual content'.
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 when to use: 'when you need to read the text content of each page to decide which pages to delete.' Also provides an exclusion: 'For visual content (logos, images, photos), use get_pdf_page_images instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pdf_page_imagesGet PDF Page ImagesARead-onlyIdempotentInspect
Use this when you need to visually inspect PDF pages to identify content that cannot be detected from text alone — for example, pages containing a logo, a photograph, a watermark, a QR code, or any visual element. Returns rendered JPEG screenshots as images you can see. Returns at most 10 pages per call. ALWAYS start from start_page=1 and paginate through the ENTIRE document: check 'has_more' in structuredContent — if true, call again with start_page=next_start_page. Repeat until has_more is false. You must finish scanning all pages before answering the user's question or performing any action (e.g. deletion). Requires: pip install pymupdf
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of pages to render per call (capped at MAX_IMAGE_PAGES). | |
| job_id | Yes | Job ID of the PDF to render. | |
| session_id | Yes | Session ID that the job belongs to. | |
| start_page | No | 1-based page number to start from (default 1). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds that it returns JPEG screenshots, limits to 10 pages per call, and details pagination behavior. No contradiction with annotations.
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 clear and well-structured, with a specific use case, output type, and step-by-step pagination instructions. It is slightly verbose but efficient, earning a 4.
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 complexity, the description covers purpose, usage, and behavioral details. No output schema exists, but the description explains the output (JPEG images). Provides sufficient context for an agent to use it 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%, so baseline is 3. The description adds context about the page limit (10) and proper start_page usage, but does not add significant meaning beyond the schema's property descriptions. A score of 3 is appropriate.
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 is for visually inspecting PDF pages to identify non-textual content like logos, photographs, watermarks, and QR codes. It distinguishes from sibling tools (e.g., compare_pdfs, get_pdf_info) by focusing on visual inspection and rendering images.
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?
Provides explicit instructions: use when visual inspection needed, always start at page 1, paginate using 'has_more' and 'next_start_page', and finish scanning all pages before answering. Also notes the required dependency (pymupdf).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pdf_statusGet PDF StatusBRead-onlyInspect
Return current status of a PDF viewer job. Used internally by the viewer widget.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | No | Job ID of the PDF to check. | |
| session_id | No | Session ID of the job. |
Output Schema
| Name | Required | Description |
|---|---|---|
| job_id | Yes | |
| status | Yes | |
| pdf_url | Yes | |
| filename | Yes | |
| session_id | Yes | |
| session_status | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds 'Return current status' which aligns with read-only but does not disclose any behavioral traits beyond what annotations provide, such as whether the job is still running or rate 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 efficiently state purpose and context with no wasted words. However, the description is very brief and could include a bit more detail without harming 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?
For a simple status-check tool with annotations and an output schema already documenting return values, the description is sufficiently complete. It covers the core purpose and internal usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both job_id and session_id described. The description does not add meaning beyond the schema, so baseline score of 3 is appropriate.
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 it returns the current status of a PDF viewer job, specifying the verb 'return' and the resource 'status'. It distinguishes from sibling tools like batch_upload_pdf or compress_pdf, which perform actions rather than checking status.
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 says 'Used internally by the viewer widget,' hinting at limited use cases but providing no explicit guidance on when to use this tool versus alternatives like get_pdf_info or check_upload_status. No when-not-to-use 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.
list_redactable_line_textList Redactable Text LinesARead-onlyIdempotentInspect
Return per-page, per-line text for identifying redaction targets.
Read-only: does not modify job state. ALWAYS call this before redact_by_text_range. The returned 'text' field for each line is the source of truth — you MUST use it to count exact character positions. Character positions within each line are 0-based from the start of that line.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job ID of the PDF to inspect (use the latest job_id). | |
| session_id | Yes | Session ID that the job belongs to. |
Output Schema
| Name | Required | Description |
|---|---|---|
| pages | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description reinforces 'Read-only: does not modify job state' and adds crucial details: 'The returned text field... is the source of truth — you MUST use it to count exact character positions. Character positions within each line are 0-based from the start of that line.' This exceeds annotation coverage. No contradiction.
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?
Five sentences, all relevant and front-loaded. No fluff. Immediately states purpose, then read-only hint, usage order, and data semantics. Efficient and well-structured.
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 purpose, behavior, usage order, and key data semantics (0-based indexing, source of truth). Output schema exists but not shown; description mentions 'text' field. Minor lack of handling for edge cases like empty results, but overall complete for the tool's complexity.
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%, so baseline is 3. The description does not add extra semantics beyond the schema. The schema already includes guidance like 'use the latest job_id' for the job_id parameter.
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 'Return per-page, per-line text for identifying redaction targets.' This clearly specifies the verb (return) and resource (per-page, per-line text). It distinguishes from sibling tools like redact_by_text_range which performs actual redaction.
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 'ALWAYS call this before redact_by_text_range,' providing clear usage ordering. Also states 'Read-only: does not modify job state,' implying safe to call anytime. No explicit when-not, but the sibling tools cover different actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
redact_by_text_rangeRedact PDF TextADestructiveInspect
Redact PDF text by specifying the exact text to remove on each line.
MANDATORY WORKFLOW — follow every step in order before calling this tool:
Step 1 — Retrieve line text: Call list_redactable_line_text and note the exact 'text' string and 'line_index' for every line you intend to redact.
Step 2 — Identify the text to redact: Provide the exact substring to remove. The value must appear verbatim in the line's 'text' field. - Non-CJK text (e.g. English): whole-word matching is enforced. "the" will NOT redact text inside "then", "there", or "either". - CJK text (e.g. Chinese): substring matching — "王大明" will match wherever it appears in the line.
Step 3 — Build the content payload: Group redaction targets by page. Each page entry contains a list of { line_index, text } pairs.
Example:
content = [
{
"page_index": 1,
"lines": [
{"line_index": 3, "text": "John Doe"},
{"line_index": 7, "text": "confidential"}
]
}
]Step 4 — Verify and re-redact if needed: After this tool returns, you MUST call list_redactable_line_text again with the NEW job_id to verify that all intended targets have been removed. If any target text still appears in the result, call redact_by_text_range again immediately with the remaining targets. Repeat until all targets are gone — do NOT report success until the verification confirms zero remaining targets.
Creates a NEW job_id (with parent_job_id linking to the source). After redaction completes, call 'view_pdf' with the new job_id to display the result.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job ID of the PDF to redact (use the latest job_id). | |
| content | Yes | List of pages to redact. Each item must include: - page_index (int): 1-based page number. - lines (list): each entry contains: - line_index (int): line index from list_redactable_line_text. - text (str): exact text to redact from that line. | |
| session_id | Yes | Session ID that the job belongs to. |
Output Schema
| Name | Required | Description |
|---|---|---|
| job_id | Yes | |
| filename | Yes | |
| mime_type | Yes | |
| reply_note | Yes | |
| session_id | Yes | |
| download_url | Yes | |
| instructions | Yes | |
| parent_job_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds valuable context: it creates a new job_id, links to a parent_job_id, and requires verification. No contradictions with annotations.
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 comprehensive and well-structured with numbered steps and examples. While a bit lengthy, every sentence adds value; one could argue it is slightly verbose, but the detail is justified by the tool's complexity.
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 complexity (redaction with verification), the description covers all necessary aspects: workflow, matching rules, content construction, verification loop, and post-redaction viewing. The output schema exists, so return values are not needed in the description.
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?
Input schema has 100% coverage, but the description adds crucial meaning: exact text matching rules (whole-word for non-CJK, substring for CJK) and explains the content structure with a clear example. This goes beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Redact PDF text by specifying the exact text to remove on each line.' It distinguishes itself from sibling tools like list_redactable_line_text (for retrieval) and view_pdf (for display), providing a specific verb and resource.
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 a mandatory step-by-step workflow, including prerequisites (calling list_redactable_line_text), exact text matching rules, building the content payload with an example, and a verification loop. It explicitly states when to use this tool and when to re-redact, with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_passwordSet PDF PasswordADestructiveInspect
Add password protection to an unprotected PDF file.
Creates a NEW job_id (with parent_job_id linking to the source). After the operation completes, call 'view_pdf' with the new job_id to display the result. Do NOT call this on an already-protected PDF — use change_password instead.
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | Owner password (grants full PDF permissions). | |
| job_id | Yes | Job ID of the unprotected PDF to protect (use the latest job_id). | |
| password | Yes | User password (required to open the PDF). | |
| session_id | Yes | Session ID that the job belongs to. |
Output Schema
| Name | Required | Description |
|---|---|---|
| job_id | Yes | |
| filename | Yes | |
| mime_type | Yes | |
| reply_note | Yes | |
| session_id | Yes | |
| download_url | Yes | |
| instructions | Yes | |
| parent_job_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. Description adds valuable context: creates a new job_id with parent_job_id linking to source. Does not contradict annotations.
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, front-loaded with purpose, no extraneous 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?
Tool is simple; description covers purpose, usage constraints, and post-action behavior. Output schema exists so return values not 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 covers all parameters with descriptions (100% coverage). Description does not add significant new meaning beyond schema, meeting 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?
Description clearly states 'Add password protection to an unprotected PDF file' with a specific verb and resource, and distinguishes from the sibling tool 'change_password'.
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 when to use ('unprotected PDF') and when not ('Do NOT call on an already-protected PDF'), providing the alternative 'change_password'. Also guides post-action: call 'view_pdf' with new job_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upload_pdfUpload PDFAInspect
Upload a PDF from a ChatGPT file attachment (download URL).
MANDATORY WORKFLOW — follow EVERY step in order:
ALWAYS call check_upload_status FIRST — even if you think the file is new.
If a job with the same filename already exists, reuse its job_id — do NOT call upload_pdf.
Only call upload_pdf if the file is confirmed absent from check_upload_status. Skipping step 1 and calling upload_pdf directly is FORBIDDEN.
Use this when the user provides a file attachment in ChatGPT. The tool downloads the PDF from the signed URL in the pdf_file parameter and stores it immediately. Returns session_id and job_id for use in all subsequent tool calls.
For MCP clients where no file attachment is available (e.g. Claude), use create_upload_page instead to display an upload widget.
| Name | Required | Description | Default |
|---|---|---|---|
| pdf_file | Yes | File object from ChatGPT containing download_url (and optionally name/filename). Passed automatically from the file attachment. | |
| session_id | No | Existing session ID to group this file with previous uploads. If omitted, a new session is created. Always pass the same session_id throughout the entire conversation. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare non-readonly, non-destructive, etc. The description discloses that the tool downloads from a signed URL and stores immediately, and returns session_id and job_id. It adds context beyond annotations, such as the mandatory workflow and that it stores the file. A minor gap: no mention of what happens if file already exists (but workflow covers that via `check_upload_status`).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, a bulleted mandatory workflow, and a note on alternatives. It is front-loaded. The workflow is detailed but necessary for correct usage, so length is justified. Could be slightly tightened, but no excess.
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 role in a multi-step process (with `check_upload_status` as prerequisite) and the availability of output schema, the description fully covers what the agent needs: input, behavior, output, and alternatives. No gaps identified.
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%, so baseline is 3. The description adds value by explaining that `pdf_file` is a file object from ChatGPT containing download_url, and that `session_id` is for grouping uploads. This goes beyond the schema's property 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 specifies the action: upload a PDF from a ChatGPT file attachment. It uses the specific verb 'upload' and resource 'PDF', and distinguishes from sibling tool `create_upload_page` which is for non-ChatGPT clients.
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 an explicit mandatory workflow with numbered steps, including precondition (call `check_upload_status` first) and when to reuse vs. call. It also states when to use this tool (file attachment in ChatGPT) vs. alternative (`create_upload_page` for Claude). No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
view_pdfView PDFARead-onlyIdempotentInspect
Display an already-uploaded PDF in an interactive viewer widget.
Call this after delete_pdf_page, set_password, change_password, redact_pii, and redact_by_text_range to show the updated PDF. Also call when the user explicitly asks to (re-)display a specific PDF. Do NOT call this after upload_pdf (the widget handles it automatically). Before calling, confirm the job_id exists via check_upload_status.
MANDATORY after this tool returns:
Render a markdown download link so the user can save the file: Download {filename}
Follow cta_instruction and append cta_text at the end of your reply.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | No | Job ID of the PDF to display (use the latest job_id). | |
| session_id | No | Session ID that the job belongs to. |
Output Schema
| Name | Required | Description |
|---|---|---|
| job_id | Yes | |
| status | Yes | |
| pdf_url | Yes | |
| cta_text | Yes | |
| filename | Yes | |
| reply_note | Yes | |
| session_id | Yes | |
| download_url | Yes | |
| instructions | Yes | |
| cta_instruction | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds mandatory post-invocation actions (render download link, follow cta_instruction) and dependency on job_id existence, increasing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with purpose, then usage rules, then mandatory post-actions. It is concise but includes necessary details 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 the tool's simplicity, output schema existence, and clear annotations, the description covers all essential aspects: purpose, usage conditions, required pre-checks, and expected follow-up actions.
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%, so baseline is 3. The description does not add additional parameter semantics beyond what the input schema provides, but the usage guidelines implicitly reinforce job_id's role.
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: 'Display an already-uploaded PDF in an interactive viewer widget.' This verb+resource specification distinguishes it from sibling tools like upload_pdf or delete_pdf_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to call (after modification tools or when user requests display) and when not to call (after upload_pdf). It also advises checking job_id status beforehand, providing clear usage context.
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.
Discussions
No comments yet. Be the first to start the discussion!