Convert files, run PDF/image tools, create billing links, and report feedback.
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 3.6/5 across 17 of 17 tools scored. Lowest: 2.9/5.
Each tool has a clearly distinct purpose, covering different file operations (compress, convert, extract, merge, split, etc.) and billing management. No two tools overlap in functionality.
Most tool names follow a verb_noun pattern (compress_image, protect_pdf), but a few deviate (images_to_pdf, list_supported_conversions) causing minor inconsistency. The pattern is largely predictable.
17 tools is slightly above the typical well-scoped range, but still reasonable given the breadth of file manipulation and billing operations. Each tool serves a distinct need.
The file conversion and PDF manipulation operations are well-covered (compress, convert, extract, merge, split, protect, etc.). The billing tools are complete for subscription and credit management. Minor gaps exist, such as batch operations or image format conversions.
compress_imageBCompress an image to reduce file size, optionally capping dimensions.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format (jpeg, png, webp, ...). Defaults to source format. | |
| quality | No | Compression quality 1-100. | |
| max_width | No | Optionally cap the width in pixels. | |
| max_height | No | Optionally cap the height in pixels. | |
| source_url | No | Public URL of the image. | |
| file_base64 | No | Base64-encoded image. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and openWorldHint=true, so the tool is safe and non-destructive. The description adds minimal behavioral context beyond the core function, not disclosing details like output format handling or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no unnecessary words. It effectively communicates the core 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 and full schema parameter coverage, the description provides minimal added context. It lacks usage guidance and behavioral nuances, but for a straightforward operation it is adequate.
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% (all 6 parameters have descriptions in the schema). The description mentions optional dimension capping, which aligns with max_width and max_height, but adds no new nuance 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 it compresses an image to reduce file size with optional dimension capping. It distinguishes from siblings like compress_pdf by specifying 'image', but does not explicitly differentiate from resize_image which is a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like resize_image or compress_pdf. There is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compress_pdfBReduce the file size of a PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| quality | No | Compression preset. | medium |
| source_url | No | Public URL of the PDF. | |
| file_base64 | No | Base64-encoded PDF. | |
| remove_metadata | No | Strip PDF metadata to reduce size further. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint and openWorldHint, but the description only states the goal. It does not disclose potential quality loss, file size limits, or that compression may be destructive depending on quality level. The description adds little beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous words. It is front-loaded but could benefit from additional context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and 4 parameters, the description is minimal. It does not specify what the tool returns (e.g., a compressed PDF file or bytes) or mention that either source_url or file_base64 must be provided. The description is adequate but not comprehensive.
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 parameters are well-documented in the schema. The description does not add extra meaning beyond the schema, such as explaining how quality presets affect output or the mutual exclusivity of source_url and file_base64.
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 action ('Reduce the file size') and resource ('a PDF'). However, it does not differentiate this tool from sibling tools like compress_image or extract_pdf_text, leaving ambiguity about when to choose this over others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives (e.g., compress_image for images, merge_pdfs for combining). There is no mention of prerequisites, such as needing a PDF input, or when not to use it (e.g., for lossy vs lossless compression).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_fileBConvert a document, spreadsheet, presentation, image, PDF, or data file.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | Original filename (with extension); used to detect the source format and name the output. | |
| source_url | No | Public URL to the source file or webpage (preferred). For a webpage to PDF, point at the page and use target_format='pdf'. | |
| file_base64 | No | Base64-encoded source file. Use only when there is no URL. | |
| source_format | No | Source format token (e.g. 'docx', 'pdf', 'png', 'html', 'url'). Inferred from filename/URL if omitted. | |
| target_format | Yes | Desired output format, e.g. 'pdf', 'csv', 'png'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds little beyond stating the conversion capability. Annotations indicate openWorldHint and idempotentHint, but the description does not clarify potential side effects (e.g., file creation) or safety. 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 a single, concise sentence that efficiently conveys the core purpose without unnecessary words. It is well 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 the tool's complexity (5 parameters, multiple file sources, output schema present), the description is too minimal. It omits details about source handling (URL vs base64), format inference, and output behavior, which are available in the schema but not summarized.
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 each parameter already has detailed descriptions. The tool description adds no additional parameter-level meaning beyond the schema, warranting the baseline score 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 verb 'Convert' and lists the types of files (document, spreadsheet, presentation, image, PDF, data file). However, it does not differentiate from sibling tools like compress_image, compress_pdf, merge_pdfs, etc., which are more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling tools that offer specific conversions (e.g., images_to_pdf, split_pdf). The description does not mention alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_billing_portal_linkBInspectCreate a Stripe Billing Portal link for payment method and subscription management.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-idempotency and open-world side effects. Description adds only that it creates a Stripe link, but not details like authentication needs or 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?
Single sentence, no fluff. Could add more context, but remains 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?
Despite no parameters and an output schema (unseen), the description lacks context on how this tool fits with sibling tools like create_subscription_checkout. An agent may need more details on return values or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Per guidelines, 0 params baseline is 4. Description adds no parameter info, which is acceptable.
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 it 'Create[s] a Stripe Billing Portal link' with a specific purpose ('for payment method and subscription management'). This distinguishes it from sibling tools like create_subscription_checkout and get_billing_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?
No guidance on when to use this tool vs. alternatives (e.g., create_subscription_checkout). No prerequisites or conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_credit_pack_checkoutAInspectCreate a Stripe-hosted checkout link for one-time extra credits.
| Name | Required | Description | Default |
|---|---|---|---|
| pack_id | Yes | Credit pack to buy: pack_1000 or pack_10000. | |
| currency | No | Preferred checkout currency. | usd |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate openWorldHint=true and idempotentHint=false. The description adds useful context: it creates a Stripe-hosted checkout link for one-time credits, implying external payment processing. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 10 words. Every word is necessary and contributes to understanding the tool's purpose. No wasted verbiage.
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 core purpose adequately. Given the presence of a detailed input schema and output schema, the description need not elaborate further. Minor gap: it does not mention any prerequisites or that the returned link initiates a payment flow.
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 documents the parameters. The description does not add any additional meaning beyond what the schema provides, thus the 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 action ('Create'), the resource ('Stripe-hosted checkout link'), and the specific purpose ('for one-time extra credits'). This effectively distinguishes it from sibling tools like create_subscription_checkout and create_billing_portal_link.
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 clear context by specifying 'one-time extra credits', which implies usage for credit purchases rather than subscriptions or billing management. However, it does not explicitly mention when not to use the tool or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_subscription_checkoutAInspectCreate a Stripe-hosted checkout link for a Pro or Scale subscription.
| Name | Required | Description | Default |
|---|---|---|---|
| annual | No | Use annual billing instead of monthly. | |
| plan_id | Yes | Plan to subscribe to: pro or scale. | |
| currency | No | Preferred checkout currency. | usd |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate openWorldHint=true and idempotentHint=false, so the description correctly implies an external side effect (creating a Stripe Checkout Session). However, it does not explicitly mention that calling the tool multiple times creates multiple checkouts (non-idempotent) or that it interacts with Stripe's API, which would be helpful for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded and efficiently conveys the tool's 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 is simple with 3 fully described parameters and an output schema, the description is mostly complete. It could mention that the returned value is a checkout link, but the output schema covers that. Minor gap for a straightforward 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 coverage is 100%, so the input schema already fully describes the parameters. The description adds no extra meaning beyond saying 'Pro or Scale subscription', which aligns with plan_id enum. This is adequate but not additive.
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 function: 'Create a Stripe-hosted checkout link for a Pro or Scale subscription.' The verb 'Create' and resource 'checkout link' are specific, and the mention of 'Pro or Scale' distinguishes it from sibling tools like create_credit_pack_checkout or create_billing_portal_link.
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 subscription checkout but provides no explicit when-to-use or when-not-to-use guidance, nor references to alternatives like create_billing_portal_link for managing existing billing or create_credit_pack_checkout for credit packs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_pdf_textAExtract text and optional tables from a PDF as structured JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| pages | No | Optional pages/ranges to extract, e.g. '1-5'. | |
| source_url | No | Public URL of the PDF. | |
| file_base64 | No | Base64-encoded PDF. | |
| extract_tables | No | Whether to extract tables too. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool extracts text and optionally tables as structured JSON, which adds behavioral context beyond the annotations (idempotentHint and openWorldHint). The annotations already indicate read-only, idempotent behavior, and the description aligns with that. No contradictions, and it provides useful output format details.
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?
A single, clear sentence with no unnecessary words. It is front-loaded with the main action and result. Every part adds value.
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 and simple parameters, the description is reasonably complete. It conveys the core functionality and output format. A minor gap: it does not mention that one of source_url or file_base64 must be provided, but that is covered in the schema.
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 all parameters are documented in the schema. The description adds minimal extra meaning (e.g., 'optional tables' is also in the schema). Baseline of 3 is appropriate since the description does not need to compensate.
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 ('extract'), the resource ('text and optional tables from a PDF'), and the output format ('structured JSON'). It is specific and distinguishes the tool from its siblings, which are primarily for compression, conversion, or PDF manipulation, none of which extract text.
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 does not explicitly state when to use or not use this tool versus alternatives. However, the purpose is clear, and the sibling tools are sufficiently different (e.g., compress_pdf, split_pdf) that no confusion is likely. A small deduction for lack of explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_billing_statusAReturn current plan, subscription status, and remaining credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotent and open world; description adds return details but no extra behavioral context beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no unnecessary words, directly conveying 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 zero parameters and presence of output schema, the description fully captures what the tool does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; description adds value by stating output fields without needing to explain inputs.
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 states 'Return current plan, subscription status, and remaining credits' with a specific verb and resource, clearly distinguishing from sibling tools that handle billing actions.
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?
Implied usage as a read-only status check, but no explicit when/ when-not or alternative guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
images_to_pdfACombine multiple images into one multi-page PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| filenames | No | Optional filenames matching files_base64, with extensions. | |
| page_size | No | Page size: fit, A4, or letter. | fit |
| output_name | No | Name for the output PDF. | images.pdf |
| source_urls | No | Public image URLs to combine into a multi-page PDF, in order. | |
| files_base64 | No | Base64-encoded image files to combine, in order. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint and openWorldHint, indicating safe and idempotent behavior. The description adds no extra context (e.g., no mention of image resizing, file handling, or output behavior). With annotations present, a score of 3 is appropriate as the description does not contradict them but adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant words, front-loaded with the key action. 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 tool with an output schema and annotations, the description is nearly complete. It covers the core function without missing critical aspects. One minor gap is no mention of output format or success criteria, but this is mitigated by the output schema.
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 input schema already documents all parameters. The description does not add any parameter-level meaning beyond what is in the schema. Baseline 3 is correct.
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 'Combine multiple images into one multi-page PDF.' clearly states the function: verb (combine), resource (images), and outcome (multi-page PDF). It distinguishes from siblings like merge_pdfs (which combines PDFs) and compress_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it's for converting images to PDF, but does not mention when to prefer it over merge_pdfs or other sibling tools. Context is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_supported_conversionsAList every conversion slug supported by the MCP server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include 'openWorldHint' (list may not be exhaustive) and 'idempotentHint'. The description claims to list 'every' slug, which slightly contradicts the open world hint. It does not elaborate on dynamic nature or other behaviors.
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?
A single, clear sentence with no wasted words. Perfectly concise for a simple listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema (not shown) and straightforward purpose, the description is mostly sufficient. However, it could mention the open-ended nature hinted by the annotation, but overall complete for a list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is complete. The description adds no param info, but none is needed. Baseline 4 applies 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?
The description clearly states the tool lists every conversion slug supported by the MCP server, using a specific verb ('List') and resource ('conversion slug'). It distinguishes itself from sibling tools like 'convert_file' which perform conversions, not list 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?
The purpose is clear—use this to discover available conversion slugs. However, no explicit guidance on when not to use it or alternatives is provided, though the context strongly implies its usage before conversion operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
merge_pdfsAMerge multiple PDFs into a single PDF, preserving the given order.
| Name | Required | Description | Default |
|---|---|---|---|
| output_name | No | Name for the merged PDF. | merged.pdf |
| source_urls | No | Public URLs of the PDFs to merge, in order (minimum 2). | |
| files_base64 | No | Base64-encoded PDFs to merge, in order (minimum 2). Use when there are no URLs. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotent and open-world behavior, which are consistent. The description adds that order is preserved, but does not disclose error handling, required minimum count (2 PDFs), or whether the result is a file or path. The value added beyond annotations is modest.
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?
A single, front-loaded sentence that captures all essential information without wasted words. Every part adds value.
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 an output schema exists (context signal), the description adequately covers the core function. It is missing minor context about source selection and prerequisites, but is sufficient for a simple 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 coverage is 100%, so the schema already documents all three parameters. The description provides no additional parameter-level details beyond what is in the schema descriptions; 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 uses a specific verb ('merge') and resource ('PDFs'), states the outcome ('single PDF'), and adds the key behavior of preserving order, which clearly distinguishes it from sibling tools like split_pdf or compress_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 implies the tool is for merging PDFs but provides no explicit guidance on when to use it vs alternatives, nor does it explain when one parameter source (URLs vs base64) is preferred over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
protect_pdfBAdd password protection (encryption) to a PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | Password to set on the PDF. | |
| source_url | No | Public URL of the PDF. | |
| file_base64 | No | Base64-encoded PDF. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond the annotations. Annotations indicate idempotentHint=true and openWorldHint=true, but the description fails to explain that the operation is idempotent (applying same password again yields same result) or that openWorldHint may imply external dependencies (e.g., fetching from URL). No mention of side effects like overwriting original file or performance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 6 words, highly concise with no superfluous content. Every word is necessary, and the key action 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 the presence of annotations and an output schema, the description is minimally adequate. However, it lacks any mention of expected output format (even though output schema exists) or guidance on parameter precedence (e.g., if both source_url and file_base64 are provided, which one is used).
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 the baseline is 3. The description does not add any additional meaning beyond the schema definitions for the three parameters (password required, source_url or file_base64 optional).
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: 'Add password protection (encryption) to a PDF.' It uses a specific verb ('Add'), resource ('PDF'), and method ('password protection/encryption'), distinguishing it clearly from sibling tools like unlock_pdf, merge_pdfs, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when or when not to use this tool, nor does it mention alternatives. Agents have no context about prerequisites (e.g., the PDF must be accessible via URL or base64) or situations where this tool is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
report_feedbackAInspectReport a bug, missing conversion, or quality issue to the ConvertFileFast team.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | No | Tool or conversion involved, e.g. 'convert_file pdf-to-docx'. | |
| context | No | Extra detail: error message, input format, expected vs actual. | |
| summary | Yes | Short description of what went wrong or what is missing. | |
| category | No | Feedback category. | other |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the side effect of sending feedback, consistent with idempotentHint false. However, it does not explain what happens after reporting (e.g., confirmation, response) or elaborate on the openWorldHint annotation. The output schema may cover return values, but the description could add 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?
The description is a single sentence with no wasted words. It is front-loaded with the purpose and immediately actionable. Perfect 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 feedback tool with full schema coverage and an output schema, the description is mostly complete. It lacks usage guidelines and behavioral details, but these are minor gaps given the tool's straightforward nature. Slight improvement possible.
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 documents all parameters. The description adds no extra meaning beyond the schema. Baseline 3 is appropriate as the description does not degrade but adds no 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 verb 'Report' and the resource: bugs, missing conversions, or quality issues to the ConvertFileFast team. It distinguishes from sibling tools that focus on file operations, making the purpose specific and unambiguous.
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?
While not explicitly stating when to use this tool vs alternatives, the sibling context (all file processing tools) makes it obvious that this is for reporting issues. A clear when-not statement is missing but not critical given the clear domain separation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resize_imageCResize an image to the given width/height.
| Name | Required | Description | Default |
|---|---|---|---|
| fit | No | How to fit within width/height. | contain |
| width | No | Target width in pixels. | |
| format | No | Output format (jpeg, png, webp, ...). Defaults to source format. | |
| height | No | Target height in pixels. | |
| source_url | No | Public URL of the image. | |
| file_base64 | No | Base64-encoded image. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint and openWorldHint, but the description adds no behavioral context (e.g., side effects on source image, auth requirements).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded, but could include key parameter details without much bloat.
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 output schema and annotations, the description omits details like optional parameters, fit mechanics, or that both width/height can be null.
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 set to 3. Description adds minimal extra meaning beyond the schema, e.g., does not explain fit modes or format behavior.
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 resizes an image to given width/height, but does not differentiate from sibling tools like compress_image or convert_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, e.g., compress_image for size reduction or convert_file for format changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rotate_pdfARotate pages in a PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| angle | Yes | Rotation in degrees (clockwise). | |
| pages | No | Pages to rotate, e.g. '1,3,5-7'. Omit to rotate all pages. | |
| source_url | No | Public URL of the PDF. | |
| file_base64 | No | Base64-encoded PDF. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotency and open-world behavior, but the description does not elaborate on whether the operation modifies the original file or returns a new PDF. It adds limited behavioral context beyond the 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 extremely concise with a single, clear sentence. It is front-loaded and contains 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?
Given the presence of a detailed input schema and an output schema (not shown), the description need not explain return values. However, it omits the requirement to provide a file source (source_url or file_base64), which is a minor gap. Overall, the context is nearly 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%, and the description does not add extra meaning beyond the schema. The baseline is 3 due to full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Rotate pages in a PDF.' clearly specifies the verb (rotate) and the resource (pages in a PDF). It distinguishes the tool from siblings like compress_pdf, protect_pdf, etc., which perform different actions on 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?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as the need to provide a source URL or base64-encoded file. The schema details parameters, but the description itself lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
split_pdfAExtract specific pages/ranges from a PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| pages | Yes | Pages/ranges to extract, e.g. '1,3,5-7' or '1-5'. | |
| source_url | No | Public URL of the PDF. | |
| file_base64 | No | Base64-encoded PDF. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint and openWorldHint, but the description adds no behavioral context beyond that—e.g., no mention of output format or side effects. It 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?
A single, concise sentence with no wasted words. The front-loaded structure is 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?
Given the simple tool with 3 parameters and the presence of an output schema, the description is largely complete. However, it could note that source_url or file_base64 must be provided, but the schema indicates only pages is required, so it is acceptable.
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 adds no additional meaning beyond the schema's parameter 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 'Extract specific pages/ranges from a PDF' clearly states the verb (extract) and resource (pages from a PDF), and distinguishes it from sibling tools like compress_pdf, merge_pdfs, and rotate_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 implies usage for extracting pages but provides no explicit guidance on when to use this tool versus alternatives such as extract_pdf_text or split_pdf (no explicit when-not or alternative references).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unlock_pdfBRemove password protection from a PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | Current password of the PDF. | |
| source_url | No | Public URL of the PDF. | |
| file_base64 | No | Base64-encoded PDF. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not clarify behavioral details beyond annotations, such as what happens to the original file, whether a new PDF is returned, or that the password must match. Annotations include idempotentHint but the description offers no context on 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 a single, front-loaded sentence with no unnecessary words, but it is perhaps too brief, omitting important context that could be included without verbosity.
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 having an output schema (not shown) and complete parameter coverage, the description fails to mention that the tool returns the unlocked PDF or modifies it, leaving the agent without full context for a mutation operation.
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 adequate descriptions for all parameters; the description adds no additional meaning beyond the schema, meriting a baseline score 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 uses a specific verb 'Remove' and identifies the resource 'password protection from a PDF,' clearly distinguishing it from the sibling 'protect_pdf' 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?
No guidance is provided on when to use this tool versus alternatives like protect_pdf, or prerequisites (e.g., file must be password-protected).
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!
