Skip to main content
Glama

Create a schedule

create_schedule

Set up a recurring render: a cron expression, a template, and where each document goes. Use this instead of render_pdf when the user wants a document produced repeatedly on a calendar — a weekly report, a monthly invoice run — so nothing has to stay running. Delivery channel is 'email' or 'whatsapp' (recipients required) or 'download' (stored only; retrieve later with list_renders). The cron is evaluated in the given IANA timezone, and how often it may fire is plan-gated: at least 60 minutes apart on Free, 15 on Starter, 5 on Pro and above — a tighter expression is rejected with a validation error naming the limit. Every firing spends one render from the monthly quota, so a frequent schedule can exhaust a small plan on its own. Returns the created schedule including its id and next_run_at.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNoTemplate data, used verbatim on every firing. Defaults to {}.
nameYesHuman label for this schedule, shown in the dashboard.
channelYesWhere each rendered document goes. 'download' just stores it (find it later with list_renders); 'email' and 'whatsapp' require recipients.
enabledNoDefaults to true. Create it disabled to set it up now and start it later.
optionsNoRender options passed straight through to the render, in the nested /v1/render shape, e.g. { format: 'letter', margin: { top: '20mm' } }.
scheduleYesStandard 5-field cron expression, e.g. '0 9 * * 1' for 09:00 every Monday. Rejected with a validation error if it fires more often than the plan's minimum interval.
templateYesTemplate slug or UUID rendered on every firing. Same values render_pdf accepts.
timezoneNoIANA timezone the cron expression is evaluated in, e.g. 'Asia/Dubai'. Defaults to UTC.
recipientsNoEmail addresses or phone numbers, matching the channel. Required and non-empty for email and whatsapp; ignored for download.

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are minimal (readOnlyHint=false, etc.), but the description fully compensates by disclosing key behaviors: every firing consumes a render quota, plan-gated minimum intervals, rejected expressions produce validation errors, and the return includes id and next_run_at. This is comprehensive for a creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured paragraph that front-loads the core purpose ('Set up a recurring render') and progressively adds details. Every sentence conveys essential information without redundancy, earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 9 parameters, 4 required, nested objects, and no output schema, the description is remarkably complete. It covers when to use the tool, how parameters interact, plan limits, quota implications, and what the response contains. No critical gaps are present for an agent to use this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 value beyond the schema by explaining the frequency limitations in context (plan-gated intervals), the relationship between channel and recipients, and the behavior of enabled (create disabled to start later). Minor deduction because the description doesn't elaborate on the options parameter's nested structure beyond what the schema says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a recurring render with a cron expression, template, and delivery configuration. It explicitly distinguishes itself from render_pdf by specifying when to use this tool instead, making the purpose highly specific and actionable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool ('when the user wants a document produced repeatedly on a calendar') and contrasts it with the sibling render_pdf. It also explains delivery channel options, plan-gated frequency limits, and quota implications, helping the agent decide correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct action or resource with minimal ambiguity. For example, `render_pdf`, `render_docx`, `render_xlsx`, and `pptx` are clearly different output formats, while `merge_pdfs`, `split_pdf`, and `edit_pdf` target different PDF operations. The signature tools (`create_signature_request`, `get_signature_request`, etc.) are also clearly separated by lifecycle stage. No two tools appear to do the same thing.

Naming Consistency5/5

Tool names follow a highly consistent `verb_noun` pattern throughout, such as `create_signature_request`, `get_signature_request`, `list_signature_requests`, and `remind_signature`. This pattern is applied uniformly across all major domains (render, signature, template, webhook, trace), making the API predictable and easy for an agent to navigate.

Tool Count4/5

With 59 tools, this is a large surface area, but it is justified by the breadth of functionality: document rendering in multiple formats, e-signatures, template management, webhooks, scheduling, and a crypto/audit trail. While large, each tool has a distinct purpose, and the count feels appropriate for the scope of a comprehensive document automation API. A surface this large risks being overwhelming, but the internal organization is logical.

Completeness5/5

The tool surface is remarkably complete, covering the full lifecycle for multiple domains. For e-signatures, there are tools for CRUD (requests, templates), sending (individual, bulk, envelope), monitoring (get, list), reminders, and certificates. For documents, it covers creation, conversion, editing, merging, splitting, and verification. The inclusion of utility tools like `get_started`, `validate_payload`, and the audit trail tools further solidifies this as a well-considered, production-ready API surface.