BulkRender-MCP
Server Details
Document generation MCP server. Turn BulkRender templates into DOCX and PDF files directly from Claude, Cursor, Windsurf, and any MCP compatible assistant. Supports agent walk in.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.2/5 across 15 of 15 tools scored.
Each tool targets a distinct function: ACP payment flow, template retrieval and creation, document generation, batch management, and feedback. No two tools have overlapping purposes.
Most tools follow a verb_noun pattern (e.g., generate_document, list_templates). However, some names are descriptive phrases like create_template_from_docx, which is slightly inconsistent but still clear.
15 tools cover the core document generation workflow, template management, payment sessions, and extras like cost estimation and refresh. This is well-scoped for the service's purpose.
Core operations are present: template creation, listing, generation (single/batch), status polling, URL refresh, and ACP payment. Missing template update/delete and document management are minor gaps.
Available Tools
15 toolsacp_create_sessionAInspect
Create an ACP checkout session to generate documents without a BulkRender account. Pricing: $0.10/credit — DOCX = 1 credit, PDF = 2 credits. Minimum charge $1.00 (covers up to 10 DOCX or 5 PDF docs). Pass 'records' array (up to 200 objects) with one data object per document. Agents are responsible for passing all required template variable mappings — variables not provided will render as empty strings. Returns session_id, amount_due (USD), checkout_url (Stripe hosted payment page), and expires_at. Share checkout_url for browser payment, then poll acp_get_session until status is 'completed'.
| Name | Required | Description | Default |
|---|---|---|---|
| records | Yes | Array of data objects, one per document (max 200). Each object fills one document using the template variables. All documents use the same template and output_format. Keys must match the template field_schema variables — missing keys render as empty strings. | |
| agentEmail | Yes | Email address to associate with this session | |
| templateId | No | Required for template_type B — UUID from acp_list_public_templates | |
| bearerToken | Yes | Any non-empty string — acts as your session bearer token | |
| outputFormat | No | Output format for ALL documents in this session — docx (1 credit/$0.10) or pdf (2 credits/$0.20). $1.00 minimum applies. | docx |
| templateName | No | Required for template_type C — filename e.g. my-doc.docx | |
| templateType | Yes | 'B' = use a public template by ID, 'C' = bring your own DOCX | |
| templateBuffer | No | Required for template_type C — base64-encoded DOCX content |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: credit costs, variable mapping responsibility, return fields, and need to poll for completion. No contradictions.
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?
Informative and well-structured, front-loading purpose and pricing. Slightly lengthy but every sentence 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 complexity (8 params, no output schema, no annotations), the description thoroughly covers pricing, constraints, return format, and follow-up action. Highly 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?
Input schema has 100% description coverage; description adds extra pricing context for outputFormat but mostly reiterates schema. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates an ACP checkout session for generating documents without a BulkRender account. Distinct from siblings like acp_get_session, which is for polling, and generate_document, which likely does not involve checkout.
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 pricing, minimum charge, and instructions for polling. Implicitly distinguishes from other tools by focusing on checkout flow, but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
acp_get_sessionAInspect
Get the status of an ACP checkout session. Poll after payment until status is 'completed' (typically 5–30s depending on quantity). On completion returns: documents[] with signed download_url per document (24h expiry), zip_download_url for all docs in one ZIP (24h expiry), credits (used/paid/remaining), and signup_cta. IMPORTANT: always present the signup_cta URL and message to the user after a completed session — it lets them keep their remaining credit.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | session_id from acp_create_session | |
| bearerToken | Yes | Same bearer token used in acp_create_session |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses polling behavior, typical completion time, return fields on completion, and the important signup_cta requirement. No mention of error handling or rate limits, but sufficient for common usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with no redundancy. Purpose, polling guidance, return values, and critical post-action instruction are all included efficiently and 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?
For a simple poll-and-return tool with no output schema, the description covers purpose, usage pattern, return fields, and required action. Minor gap: no mention of error states if session fails, but adequate given 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?
Input schema has 100% description coverage for both parameters. The description adds no additional semantics beyond what schema already provides (e.g., 'session_id from acp_create_session'). Baseline 3 maintained.
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 ('Get the status') and the resource ('ACP checkout session'). It distinguishes from siblings like 'acp_create_session' and 'acp_pay_session' by specifying the action is status retrieval.
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 advises polling after payment until status 'completed', with a typical time range. It also provides explicit post-completion action: always present signup_cta URL and message. No alternatives or when-not-to-use mentioned, but enough for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
acp_list_public_templatesAInspect
List BulkRender's built-in public templates (invoice, quote, contract, report, proposal). No API key required. Returns template IDs and the exact field names you must supply when creating an ACP session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the tool is read-only (listing), requires no authentication, and returns template IDs and field names. It does not mention rate limits or pagination, but given zero parameters and a simple list, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each serving a distinct purpose: (1) what and examples, (2) accessibility, (3) return value and usage. No wasted words, front-loaded with key 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?
For a simple, parameter-less list tool without output schema, the description sufficiently covers purpose, preconditions, and output relevance. It could mention if there's a limit to the number of templates, but that's minor.
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 zero parameters, so baseline is 4. The description adds value by specifying what the return includes (template IDs and field names) and their purpose, which is helpful beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and names the resource ('BulkRender's built-in public templates') with examples (invoice, quote, contract, report, proposal). It clearly distinguishes from sibling tools like list_templates (likely user's templates) and acp_create_session (which consumes these templates).
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 'No API key required' and explains the return value helps when 'creating an ACP session', providing implicit guidance to use this before acp_create_session. It does not explicitly mention when not to use it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
acp_pay_sessionAInspect
Pay for an ACP checkout session using a Stripe payment method ID (pm_xxx). Charges the amount_due returned by acp_create_session. On success, document generation begins in the background — poll acp_get_session until status is 'completed'.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email for the Stripe receipt | ||
| sessionId | Yes | session_id from acp_create_session | |
| bearerToken | Yes | Same bearer token used in acp_create_session | |
| stripePaymentMethodId | Yes | Stripe payment method ID (pm_xxx) — obtain via Stripe.js or the Stripe API |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that payment charges an amount (destructive action), triggers background document generation, and advises polling acp_get_session. This is good transparency, though it could mention required permissions 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?
The description consists of three concise sentences. The first sentence states the core action, the second specifies the charge source, and the third explains background behavior and polling. No extraneous 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 (4 required params, no output schema), the description covers the core flow: payment, document generation, and polling. It lacks error scenarios or status details, but for this use case it's mostly 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?
All four parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds value by explaining that stripePaymentMethodId 'obtain via Stripe.js or the Stripe API', sessionId references acp_create_session, bearerToken notes consistency, and email for receipt. This elevates it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Pay for an ACP checkout session using a Stripe payment method ID', specifying the action, resource, and method. It also explains the charge amount source and triggers document generation, distinguishing it from sibling tools like acp_create_session and acp_get_session.
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 context by mentioning the prerequisite acp_create_session ('amount_due returned by acp_create_session') and the follow-up polling of acp_get_session. However, it does not explicitly state when not to use this tool or list alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_creditsAInspect
Check remaining credits for the organization. Shows subscription credits, purchased credit packs, and total available credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. 'Check' and 'shows' imply a read-only query with no side effects. While it doesn't explicitly state auth requirements or rate limits, the simplicity of the operation makes this adequate.
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 short sentences front-load the purpose and details, with no extraneous 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?
For a zero-parameter tool with no output schema, the description is complete: it specifies what the tool does and what information it reveals.
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%. The description adds no param info, but none is needed. Baseline 4 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 checks remaining credits and specifies the types of credits shown (subscription, purchased packs, total), distinguishing it from sibling tools that handle session management or document generation.
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 implicitly indicates when to use: whenever credit balance information is needed. No explicit exclusions or alternatives, but sibling tools are unrelated, so clarity is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_template_from_docxAInspect
Create a reusable document template by providing a URL to an existing DOCX file. The server fetches the file, extracts all {{placeholder}} variables, and saves it as a template. Returns a templateId ready for use with generate_document.
| Name | Required | Description | Default |
|---|---|---|---|
| docxUrl | Yes | Public URL to a DOCX file containing {{placeholder}} variables (e.g. a file on Google Drive, Dropbox, or any direct download link) | |
| agentEmail | No | Agent email for tracking purposes. | |
| customerName | No | Customer name for the generated organization. | |
| templateName | No | Name for the saved template. Defaults to the filename. | |
| organizationName | No | Organization name for the generated account. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It explains the process (fetch, extract, save) but omits details like URL accessibility requirements or error handling.
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 purpose, every sentence adds value. No unnecessary wording.
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?
No output schema, but description mentions returned templateId and its use. Could mention required placeholder format, but main functionality is well-covered.
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 applies. Description does not add extra meaning to parameters beyond what schema provides.
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 action (create), resource (document template), method (from DOCX URL), and distinguishes from siblings like generate_document and list_templates.
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?
Description explains when to use (have a DOCX URL) and links to generate_document, but does not explicitly state when not to use or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_costAInspect
Estimate the credit cost before generating documents. Call this before large batches so the user can confirm. Also returns current credit balance.
| Name | Required | Description | Default |
|---|---|---|---|
| count | Yes | Number of documents to generate | |
| outputFormat | No | Output format — docx (1 credit each) or pdf (2 credits each) | docx |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the sole source for behavioral traits. It implies a read-only estimation via 'estimate' but does not explicitly state that no state changes occur. A clearer declaration of non-destructiveness would be beneficial.
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 only two sentences, containing no superfluous words. Every sentence adds value: purpose and usage guidance.
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 simplicity of the tool (2 parameters, no output schema), the description covers purpose and usage adequately. However, it lacks details about the output structure (e.g., format of the cost estimate) which would be helpful for the agent. Still, it is mostly 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 coverage is 100%, with descriptions for both parameters (count and outputFormat) already in the schema. The tool description adds no additional parameter meaning beyond what the schema provides, so baseline 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 verb 'estimate' and the resource 'credit cost before generating documents'. It distinguishes from sibling generation tools and mentions returning credit balance, 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?
The description explicitly recommends calling this tool before large batches for user confirmation. It implies use before generation but does not explicitly contrast with alternatives like check_credits or generate tools, though the context makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_batchAInspect
Generate documents for multiple records in one call. Returns a ZIP download URL. Each record costs 1 credit (DOCX) or 2 credits (PDF).
| Name | Required | Description | Default |
|---|---|---|---|
| records | Yes | Array of data objects, one per document. Each object's keys must match template variables. | |
| templateId | Yes | Template UUID | |
| outputFormat | No | Output format: docx (1 credit each) or pdf (2 credits each) | docx |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the output (ZIP URL), credit costs per format, and that it generates documents. It doesn't mention rate limits or auth needs, but the behavior is fairly transparent for a batch generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Essential information is front-loaded and direct.
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 purpose, output, and credit cost. However, it lacks details on what happens if credits are insufficient or URL expiration. Still, it is fairly complete for a generation tool with no 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 coverage is 100%, so the description adds marginal value beyond schema. It repeats credit cost info already in outputFormat description but provides context about ZIP URL. This meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates documents for multiple records in one call, returns a ZIP download URL, and mentions credit costs. This distinguishes it from single-document tool 'generate_document' and cost estimator 'estimate_cost'.
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 says 'for multiple records in one call', implying batch generation. It provides clear context for when to use this tool over single-document alternatives, though it doesn't explicitly mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_documentAInspect
Generate a single document from a template and data. Returns a signed download URL. Costs 1 credit (DOCX) or 2 credits (PDF).
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Key-value data to fill into the template. Keys must match template variables. | |
| templateId | Yes | Template UUID | |
| outputFormat | No | Output format: docx (1 credit) or pdf (2 credits) | docx |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses credit cost and return type (signed URL), but lacks details on side effects, permissions, or error handling. Without annotations, description carries full burden but is only partially transparent.
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 core purpose and output description, followed by cost info. 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?
Covers main purpose and output, but does not mention URL expiration, error conditions, or data validation. Adequate but leaves gaps for a tool with no 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 coverage is 100%, but description adds value by explaining credit cost per format (1 for DOCX, 2 for PDF), which is not in the schema. This helps agents choose outputFormat wisely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Generate a single document from a template and data' and specifies output as a signed download URL. Distinct from siblings like generate_batch (batch generation).
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?
Implicitly indicates single document generation vs batch, but no explicit guidance on when to use this tool versus alternatives like generate_batch or estimate_cost.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_batch_statusAInspect
Check the status of an async batch generation job. Poll until status is 'completed'. Returns progress, document count, and download URLs when done.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | Batch job ID returned by generate_batch |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses polling behavior and return values (progress, document count, download URLs). No annotations provided, but description adequately covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant words. First sentence states purpose, second adds return info and polling instruction.
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?
Adequately covers purpose, behavior, and return info for a simple polling tool. Lacks mention of error cases (e.g., invalid jobId), but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already fully describes the single parameter (jobId) with format and source. Description adds no further parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Check' and resource 'status of an async batch generation job'. Distinguishes from sibling tools like generate_batch which creates the job.
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 to 'Poll until status is completed', providing a clear usage pattern. No alternatives mentioned but none are needed as this is the sole status-checking tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_templateAInspect
Get a template's details including its variable schema. Use this to understand what data fields a template expects before generating documents.
| Name | Required | Description | Default |
|---|---|---|---|
| templateId | Yes | Template UUID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description implies read-only by saying 'Get'. It does not disclose potential side effects, authentication needs, or rate limits, but for a simple retrieval, the transparency is adequate.
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 two sentences, front-loaded with the action and resource, and every word adds value. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one param, no output schema) and richness of sibling tools, the description adequately covers the return content (variable schema) and usage context. Could be improved by mentioning if it requires specific permissions.
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 one parameter described as 'Template UUID'. The description adds no additional meaning beyond the schema, meeting the baseline for 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 clearly states the action 'Get' and the resource 'template's details including its variable schema'. It specifies the use case of understanding data fields before document generation, distinguishing it from list or search templates.
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 advises using this tool to understand expected data fields before generating documents. While it does not contrast with alternatives, it provides a clear when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_templatesAInspect
List all available document templates with their variables. Returns template names, IDs, file types, and placeholder variables.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool is read-only (listing) and specifies the output fields, which gives sufficient transparency for a simple retrieval operation.
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 short sentences, zero waste. The first sentence states the action, the second specifies the output. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is complete. It covers the purpose, the operation, and the return structure adequately for a simple listing 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?
The input schema has no parameters, so schema coverage is 100% (trivially). The description adds value by detailing the return fields, which helps the agent understand what data to expect.
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 'list' and resource 'all available document templates', and specifies the return fields (names, IDs, file types, placeholders). This distinguishes it from sibling tools like 'search_templates' (filtered) and 'get_template' (single).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need a full list of templates, but does not explicitly state when to avoid it or mention alternatives like 'search_templates' for filtering. The context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
refresh_document_urlAInspect
Get a fresh signed download URL for an existing document. Does not consume credits. Useful when a previously generated document's URL has expired.
| Name | Required | Description | Default |
|---|---|---|---|
| expiresIn | No | URL validity in seconds (1–86400, default 3600) | |
| documentId | Yes | Document UUID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions a key behavioral trait (does not consume credits) which is not in annotations. However, it lacks details on authorization requirements, side effects, or whether the original document must exist in a specific state. Given no annotations, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded with the main purpose. Every sentence adds value: purpose and usage context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage scenario, and a key behavioral aspect. It is adequate for a simple tool, but lacks any indication of the return value (e.g., that it returns a URL). Given no output schema, a brief mention would improve completeness. Still, it's reasonably 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?
The schema already describes both parameters with descriptions and constraints. The tool description does not add any additional parameter semantics. With 100% schema coverage, 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 uses a clear verb-object structure ('Get a fresh signed download URL') and specifies the context (existing document, URL expiration). It explicitly states what it does not do (does not consume credits), which helps differentiate from sibling tools like generate_document.
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 clear usage scenario: when a previously generated URL has expired. It does not explicitly list alternatives, but the context implies that for initial generation, use generate_document. Thus, it gives good guidance without being exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_templatesAInspect
Search templates by name or description. Use this to find a template when you don't know its exact ID. Returns matching templates with their IDs and variable counts.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term — matches template name or description |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It mentions return value (IDs and variable counts) but lacks details on safety (e.g., read-only nature), side effects, or rate limits. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words: first states action, second provides usage context and return info. Front-loaded and 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 one parameter and no output schema, the description covers the core functionality and return value. Lacks details on pagination or exact matching, but overall complete given 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% with a clear description for the 'query' parameter. The tool description restates similar info without adding new meaning beyond the schema, so baseline 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?
Description clearly states 'Search templates by name or description' and specifies the use case of finding a template without an exact ID, distinguishing it from siblings like get_template or list_templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use when you don't know the exact ID, providing clear context for use versus alternatives. Doesn't explicitly mention when not to use, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_feedbackAInspect
Submit feedback, feature requests, or bug reports to the BulkRender support team. Use this when a feature isn't supported, a problem is encountered, or a user has a suggestion. Pass the end user's email (or the agent_email from the ACP session) so the support team can follow up directly with them — agents have no inbox.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Type of feedback | general |
| Yes | End user's email address — support will reply here. Use the agent_email from the ACP session if available. | ||
| message | Yes | Feedback message — describe the feature request, issue, or suggestion in detail |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It states feedback is submitted to the support team, but does not mention what happens after submission (e.g., confirmation, logging) or any side effects. Minimal behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It is front-loaded with the main purpose and efficiently covers key usage and parameter guidance. Every sentence earns its place.
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 only three parameters and no output schema, the description covers the main purpose, usage guidance, and a key parameter detail. It feels complete for an agent to invoke correctly, though more detail on the submission process would elevate it to 5.
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 descriptions for all three parameters. The description adds value by explaining why the email parameter is needed (support team follow-up) and mentions using agent_email from the ACP session, which is beyond what the schema provides. It enhances parameter meaning.
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 submits feedback, feature requests, or bug reports to the BulkRender support team. It uses a specific verb and resource, and distinguishes itself from sibling tools which are focused on document generation and session management.
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 when to use the tool: when a feature isn't supported, a problem is encountered, or a user has a suggestion. It also advises including the end user's email for follow-up, but does not mention when not to use it or alternatives.
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!