Enables payment processing for document generation via Stripe in the walk-in (ACP) flow, with no account required.
BulkRender MCP server. Generate DOCX and PDF documents from Claude, Cursor, Windsurf, Cline, and any other MCP-compatible AI assistant.
Sign up at bulkrender.com
Go to Settings, Integrations, AI Assistants (MCP)
Click Generate MCP URL — copy it immediately, shown once
Paste into your AI assistant (see below)
Related MCP server: AI Answer Copier
Settings, Integrations, Add custom integration, paste your MCP URL.
Add to your MCP config file:
{
"mcpServers": {
"bulkrender": {
"url": "YOUR_MCP_URL"
}
}
}claude mcp add bulkrender --scope user -- npx mcp-remote YOUR_MCP_URLVerify:
claude mcp list
# bulkrender ✓ ConnectedTool | Description | Credits |
| List all templates | 0 |
| Get template details and variable schema | 0 |
| Search templates by name or tag | 0 |
| Generate a single document (DOCX or PDF) | 1–2 |
| Generate documents for multiple records (up to 500) | 1–2 each |
| Poll batch job status and get download URLs | 0 |
| Check remaining credits | 0 |
| Get a fresh signed URL for an existing document | 0 |
| Estimate credit cost before generating | 0 |
| Create a reusable template from a DOCX URL | 0 |
| Submit feedback or a bug report | 0 |
Credit costs: DOCX = 1 credit, PDF = 2 credits.
For agents acting on behalf of end users who have no BulkRender account. Pay per session via Stripe.
Tool | Description | Cost |
| List built-in templates (invoice, quote, contract, report, proposal) | Free |
| Create a checkout session and get a Stripe payment URL | — |
| Charge a Stripe payment method directly (developer path) | Min $1.00 |
| Poll session status, get download URLs when complete | Free |
Walk-in minimum charge: $1.00 (covers up to 10 DOCX or 5 PDF docs).
Public MCP URL (no account, walk-in tools only): https://mcp.bulkrender.com/mcp/acp
List templates:
"List my BulkRender templates"
Generate a document:
"Generate an invoice using the Invoice Template for Acme Corp, invoice #1234, dated 2025-01-15, amount $5,000"
Batch generation:
"Generate invoices for these 3 clients: Acme Corp ($5,000), Beta Inc ($3,200), Gamma LLC ($7,800)"
Problem | Solution |
Server not connecting | Regenerate your MCP URL from Settings, Integrations |
| Use |
Timeout on large batch | Batches over 10 records process async — poll |
| Rate limit hit — retry after a short pause |
Endpoint | Limit |
Document generation | 30 requests / minute per organisation |
Template reads, credits | 30 requests / minute per organisation |
generate_batch counts as one request regardless of record count.
The standalone npm package (npx bulkrender-mcp with BULKRENDER_API_KEY) is no longer supported. Use the hosted MCP URL instead — no install, no env vars, just paste the URL from your dashboard.
If you have the old config:
{
"mcpServers": {
"bulkrender": {
"command": "npx",
"args": ["-y", "bulkrender-mcp"],
"env": { "BULKRENDER_API_KEY": "br_live_..." }
}
}
}Replace it with:
{
"mcpServers": {
"bulkrender": {
"url": "YOUR_MCP_URL"
}
}
}Get your MCP URL from Settings, Integrations, AI Assistants (MCP) in your BulkRender dashboard.
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 |
|---|---|---|---|
| bearerToken | Yes | Any non-empty string — acts as your session bearer token | |
| templateType | Yes | 'B' = use a public template by ID, 'C' = bring your own DOCX | |
| templateId | No | Required for template_type B — UUID from acp_list_public_templates | |
| templateBuffer | No | Required for template_type C — base64-encoded DOCX content | |
| templateName | No | Required for template_type C — filename e.g. my-doc.docx | |
| 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 | |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers critical behavioral details: pricing, credit consumption, minimum charge, maximum records, variable handling, return fields, and the need to poll acp_get_session. It does not mention potential side effects like credit reservation, but overall transparency is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, presenting pricing, usage flow, agent responsibilities, and return values in two clear paragraphs. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description comprehensively covers input requirements, conditional logic, pricing model, return fields, and post-creation polling. It fully equips an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds little to parameter semantics beyond what the schema already provides (e.g., conditional requirements for templateId/templateBuffer are already described in schema). No new parameter-level insights are offered.
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 'Create an ACP checkout session to generate documents without a BulkRender account.' It outlines the tool's primary function, pricing, and return values, distinguishing it from siblings like acp_get_session or generate_batch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (for generating documents without an account) and provides pricing details. However, it does not explicitly contrast with sibling document generation tools (e.g., generate_batch, generate_document), leaving some ambiguity about optimal use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
|---|---|---|---|
| bearerToken | Yes | Same bearer token used in acp_create_session | |
| sessionId | Yes | session_id from acp_create_session |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses polling duration (5-30s), return values (documents, zip, credits, signup_cta), URL expiry (24h), and the required action of presenting signup_cta. This is comprehensive behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, information-dense paragraph front-loaded with purpose, then polling guidance, then return details, then key instruction. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description fully explains return data: documents, signed_urls, expiry, zip, credits breakdown, signup_cta. Covers essential behavioral context (polling, expiry, user action needed) for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage on both parameters. Description adds cross-reference: 'Same bearer token used in acp_create_session' and 'session_id from acp_create_session,' clarifying tool interdependence beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool's function: 'Get the status of an ACP checkout session.' It differentiates from sibling tools like acp_create_session (which creates) and acp_pay_session (which pays) by focusing on status retrieval and polling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Poll after payment until status is completed' with typical timing. Also instructs to present signup_cta URL after completion. Does not explicitly state when not to use, but the polling guidance implies alternatives like waiting for completion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description implies a read-only list operation with no side effects. It states returns template IDs and field names. Could be more explicit about being idempotent, but sufficient for a simple list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, includes key details without waste. Highly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers what it does, any requirements, and what it returns. Complete for its simplicity.
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 no parameter description needed. Baseline 4 per instructions 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 it lists built-in public templates with specific examples (invoice, quote, contract, report, proposal). It distinguishes from sibling tools like list_templates (likely user's own) and acp_create_session (session creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'No API key required' which is a usage condition, and indicates the returned data is needed for creating an ACP session. However, it doesn't explicitly exclude other use cases or compare to alternatives like list_templates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
|---|---|---|---|
| bearerToken | Yes | Same bearer token used in acp_create_session | |
| sessionId | Yes | session_id from acp_create_session | |
| stripePaymentMethodId | Yes | Stripe payment method ID (pm_xxx) — obtain via Stripe.js or the Stripe API | |
| Yes | Email for the Stripe receipt |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effect (background document generation) and async polling requirement. No annotations provided, so description covers main behavioral traits well, though could mention idempotency or failure modes.
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 plus one follow-up instruction. Front-loaded with purpose, every sentence earns its place. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description explains success behavior (document generation) and polling instruction. Covers main flow well, but could mention error handling or response format for slight improvement.
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 has 100% coverage, but description adds valuable context: bearerToken reused, sessionId provenance, Stripe PM acquisition method, and email purpose. Goes beyond schema repetition.
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 action ('Pay for an ACP checkout session'), specific resource, and distinguishes from siblings like acp_create_session and acp_get_session. It also notes the follow-up action (polling).
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?
Specifies when to use (after acp_create_session), how to obtain Stripe PM ID, and next step (poll acp_get_session). Missing explicit when-not-to-use or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check remaining credits for the organization. Shows subscription credits, purchased credit packs, and total available credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description discloses read-only behavior (shows credits) with no hidden traits. Does not contradict any annotations (none provided).
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 wasted words, front-loaded with purpose and detail. Excellent 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 no-parameter tool without output schema, description fully explains input (none) and output (credit breakdown). Complete and self-contained.
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; schema coverage 100% automatically. Description adds full meaning beyond empty schema, justifying baseline of 4.
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 verb 'check' and resource 'credits' for the organization, breaking down into subscription credits, purchased packs, and total. Distinguishes from siblings as no other credit-related tool exists.
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 clear when to use (need to check credits), but lacks explicit when-not or alternatives. Adequate given simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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) | |
| templateName | No | Name for the saved template. Defaults to the filename. | |
| agentEmail | No | Agent email for tracking purposes. | |
| customerName | No | Customer name for the generated organization. | |
| organizationName | No | Organization name for the generated account. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the fetch process, placeholder extraction, and return value. However, it omits details like authentication requirements for the URL, file size limits, 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 with the purpose, no wasted words. Efficient and clear.
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 5 parameters, no output schema, and no annotations, the description covers the main process and return value. It lacks details on error conditions or constraints (e.g., public URL requirement).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add significant new meaning to parameters beyond what the schema provides, e.g., docxUrl is already described as a URL to a DOCX file.
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 specifies the action (create template), resource (DOCX URL), and outcome (templateId, ready for generate_document). It clearly distinguishes from sibling tools like generate_document 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?
The description implies when to use (when you have a DOCX URL to create a template) but does not explicitly exclude alternatives or state when not to use. It points to generate_document as the consumer, which is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the burden for behavioral disclosure. It states the tool returns current credit balance and is an estimation, implying no side effects. However, it does not explicitly confirm idempotency or safety, leaving some ambiguity.
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, using only three short sentences to convey purpose, usage guidance, and return information. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers purpose and usage well. It does not detail the return value structure, but for an estimation tool this may be 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 coverage is 100% with detailed parameter descriptions, so the description adds little beyond reinforcing that outputFormat affects cost. Baseline 3 is appropriate as the description does not introduce new parameter insights.
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 estimates credit cost before document generation, distinguishing it from sibling tools that actually generate documents or check credits. It specifies the resource (credit cost) and action (estimate), making the purpose 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 advises calling this tool before large batches for user confirmation, providing a clear use case. It lacks explicit when-not-to-use guidance but is still strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
|---|---|---|---|
| templateId | Yes | Template UUID | |
| records | Yes | Array of data objects, one per document. Each object's keys must match template variables. | |
| outputFormat | No | Output format: docx (1 credit each) or pdf (2 credits each) | docx |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return of ZIP URL and credit costs, but lacks deeper behavioral details like error handling, prerequisites, or side effects. No annotations to fall back on.
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 concise sentences with front-loaded purpose and result. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch generation tool without output schema, it mentions return type and costs but could include more on URL lifecycle or error handling.
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 description's credit cost info adds marginal value beyond the schema's enum description. 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?
Clearly states it generates documents for multiple records in one call, returns a ZIP download URL, and distinguishes from sibling tools like generate_document (single record).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for batch generation but does not explicitly state when not to use or provide alternatives. No exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
|---|---|---|---|
| templateId | Yes | Template UUID | |
| data | Yes | Key-value data to fill into the template. Keys must match template variables. | |
| outputFormat | No | Output format: docx (1 credit) or pdf (2 credits) | docx |
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 the credit cost and output format options, and that a signed download URL is returned. It does not mention idempotency, expiration, or failure modes, but the provided information is sufficient for basic understanding.
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. The core purpose is front-loaded first, followed by specifics. Every sentence contributes essential 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 tool with 3 parameters and no output schema, the description covers purpose, output type, and cost. It does not explain edge cases like missing template variables or retry behavior, but it is sufficiently complete for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter has a description. The description adds context about credits and the signed URL, which enhances understanding beyond the schema. The cost-per-format detail is particularly useful for the outputFormat parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (generate), the resource (single document from template and data), and the outcome (returns signed download URL). It effectively distinguishes from siblings like generate_batch by specifying 'single 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 notes the credit cost per format, which aids in cost-aware selection, but does not explicitly state when to use this tool versus alternatives like generate_batch or check_credits. It implies usage for single document generation without providing exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses polling behavior, return fields, and job lifecycle info. Could mention possible statuses like 'failed', but still good for a simple status 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 concise sentences front-loading purpose and usage. 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 simple status tool with one parameter and no output schema, description covers key aspects: async nature, polling, return fields. Could add which statuses exist, but sufficient for typical use.
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% (jobId with description). Description adds no extra meaning beyond schema. 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?
Description clearly states it checks status of async batch generation job, explicitly mentions polling until 'completed', and lists return fields (progress, document count, download URLs). Distinguishes from generate_batch which starts 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?
Description tells agent to poll until completed, implying usage after generate_batch. No explicit when-not or alternatives, but siblings make the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It explains the tool returns details including variable schema, which implies a read operation. However, it does not disclose error behavior, required permissions, or specific response structure, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the action 'Get a template's details' and immediately providing the use case. 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?
The tool is simple (1 required param, no output schema). The description covers the main purpose and use case. It could optionally mention return format or error handling, but this is sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the parameter templateId is described as 'Template UUID'. The description adds no additional parameter-level meaning beyond the schema, so baseline score 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?
The description clearly states the tool retrieves a template's details including variable schema, and explicitly mentions its use case (understanding expected data fields before generating documents). It distinguishes itself from sibling tools like list_templates and search_templates by focusing on a single template's details.
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 context: use this before generating documents to understand expected data fields. It does not specify when not to use it or mention alternatives, but the guidance is sufficient for the intended use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available document templates with their variables. Returns template names, IDs, file types, and placeholder variables.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies read-only listing, but no explicit statement about side effects or permissions. With no annotations, the description adequately conveys the operation but lacks depth.
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, front-loaded with action and result.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple list tool with no parameters; explains what it does and returns. Could mention that it returns templates for the current context, but not necessary.
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; baseline for 0 params is 4. Schema coverage is 100% trivially, and description adds nothing extra, 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?
Clear verb 'List', resource 'available document templates', and specific return fields (names, IDs, file types, placeholder variables). Distinguishes from siblings like acp_list_public_templates by implying scope is all 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?
No guidance on when to use this tool vs search_templates or acp_list_public_templates. No context on prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
|---|---|---|---|
| documentId | Yes | Document UUID | |
| expiresIn | No | URL validity in seconds (1–86400, default 3600) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses a key behavioral trait: 'Does not consume credits.' However, it does not mention other traits like idempotency, required permissions, or error conditions (e.g., document not found). The disclosure is helpful but incomplete.
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 long, front-loaded with the main purpose, and includes a crucial secondary detail (credit usage) in the second sentence. Every word earns its place with 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 tool's simplicity, the description covers the essential purpose and usage. However, it lacks details about return format (a signed URL) and possible errors, but these are not critical for a basic URL refresh tool. With no output schema, the description could do slightly more, but it is still 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 description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema for either parameter. It does not elaborate on 'documentId' or 'expiresIn' beyond what the schema already 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?
The description clearly states the tool's function: 'Get a fresh signed download URL for an existing document.' It explicitly distinguishes from sibling tools like 'generate_document' by noting that it does not create a new document, and the credit-saving behavior further differentiates it.
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 explicit context for when to use the tool: 'Useful when a previously generated document's URL has expired.' While it does not explicitly state when not to use it or suggest alternatives, the usage context is clear and sufficient for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states that the tool returns matching templates with IDs and variable counts. For a read-only search, this is sufficient, though it could mention any result limits or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose, no wasted words. 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?
For a simple search tool with one parameter and no output schema, the description fully covers purpose, usage, and return value. It is complete given 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?
With 100% schema description coverage for the single parameter, the description does not add significant new meaning beyond the schema. The baseline of 3 is appropriate; the description adds minor context about what is returned but not about the parameter itself.
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 'Search templates by name or description' with a specific verb and resource. It distinguishes from siblings like 'get_template' and 'list_templates' by emphasizing finding templates when ID is unknown.
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 'Use this to find a template when you don't know its exact ID', providing clear context for when to use. It implicitly excludes cases where ID is known, though it does not name alternative tools directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
|---|---|---|---|
| message | Yes | Feedback message — describe the feature request, issue, or suggestion in detail | |
| Yes | End user's email address — support will reply here. Use the agent_email from the ACP session if available. | ||
| type | No | Type of feedback | general |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden of behavioral disclosure. It explains the rationale for including the email (support follow-up, agents have no inbox) but does not mention other traits such as whether the action is destructive, rate limits, or expected response. For a simple submission tool, the coverage 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 three sentences long, each serving a clear purpose: stating the action, indicating when to use it, and providing critical parameter guidance. No extraneous words are present.
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, the description covers its purpose, usage context, and key parameter. It does not specify the outcome (e.g., confirmation or ticket ID) or error handling, but this is minimal given no output schema is expected.
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 has 100% description coverage, but the description adds significant value for the 'email' parameter by explaining why it is needed and providing guidance to use the agent_email from the ACP session. This context goes beyond the schema's format and description.
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 support team. It identifies the specific verb 'submit' and resource 'feedback' to the BulkRender support team, distinguishing its purpose from sibling tools that handle document generation, batch processing, or 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 provides clear context, though it does not list alternative tools for similar tasks, which are not needed as no sibling shares this purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.1.1acp_create_sessionacp_get_sessionacp_list_public_templatesacp_pay_sessioncheck_creditscreate_template_from_docxestimate_costgenerate_batchgenerate_documentget_batch_statusget_templatelist_templatesrefresh_document_urlsearch_templatessubmit_feedbackEach tool has a clearly distinct purpose: ACP session management, credit/cost operations, document generation (single/batch), template management (create, get, list, search), URL refresh, and feedback. There is no ambiguity or overlap between tools.
All tools use a consistent verb_noun pattern in snake_case. ACP-related tools are prefixed with 'acp_' for clarity. The naming scheme is predictable and makes it easy to infer each tool's function.
With 15 tools, the server is well-scoped. It covers all core functionalities (template management, document generation, ACP checkout, credits, batch operations, and feedback) without being overwhelming or trivial.
The tool surface covers the main lifecycle: template creation (via DOCX), listing/searching, generation (single/batch), ACP session handling, credit checks, cost estimation, and URL refresh. Minor gaps exist (e.g., no template deletion or update), but agents can work around them.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
Generate PDFs from templates via AI chat. Works with Claude, ChatGPT, Cursor, and any MCP client.
Use your own Word templates to convert Markdown → DOCX/PDF/HTML from any MCP-compatible AI.
DocBase MCP server for AI agents
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ayo-nci/bulkrender-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
