Skip to main content
Glama

Kamy

by dev.kamy.mcp

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?

The description adds significant behavioral details beyond the sparse annotations: it explains that the cron expression is evaluated in a given IANA timezone, that firing intervals are plan-gated with specific minimums (Free: 60 min, Starter: 15, Pro+: 5), that invalid intervals are rejected with a validation error naming the limit, and that each firing consumes a monthly quota. It also mentions the return value (id and next_run_at). No contradiction with annotations.

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

Conciseness5/5

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

The description is a single paragraph that is dense yet well-structured. It front-loads the core purpose, then provides usage guidance, then behavioral details. Every sentence adds unique information (cron, timezone, plan limits, quota, channel options, return value). There is no wasted word—it earns its length through efficient conveyance of critical information.

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's complexity (9 parameters, 4 required, nested objects, no output schema, 44 sibling tools), the description covers all essential aspects: purpose, when to use vs. render_pdf, channel specifics, plan constraints, quota impact, default value for 'enabled', and return value. It even mentions validation errors. The description is self-contained and provides enough context for an agent to decide when and how to invoke the 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?

The input schema has 100% description coverage, so the baseline is 3. The description adds value beyond the schema by explaining the plan-gating for the 'schedule' parameter (specific intervals per plan) and the quota implications. It also reinforces the conditional nature of 'recipients' based on the channel. While the schema already describes the enums and requirements, the description provides richer operational context, earning a 4.

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's purpose: 'Set up a recurring render: a cron expression, a template, and where each document goes.' It immediately distinguishes this from the sibling render_pdf by stating 'Use this instead of render_pdf when the user wants a document produced repeatedly on a calendar.' This provides a specific verb+resource and differentiates it from alternatives.

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 explicitly tells when to use this tool ('instead of render_pdf'), provides examples ('weekly report, monthly invoice run'), and details the channel options with their requirements ('email' and 'whatsapp' require recipients; 'download' does not). It also warns about plan-gated intervals and quota consumption, giving clear context for when to use and what constraints apply.

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

All Kamy toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with detailed descriptions that differentiate similar tools (e.g., render_pdf vs render_async vs render_batch, create_signature_request vs create_envelope). No two tools overlap in a way that would cause confusion.

Naming Consistency5/5

All tool names follow a consistent lower_snake_case verb_noun pattern (e.g., attest_artifact, convert_document, list_renders). No mixing of conventions or ambiguous verb choices.

Tool Count4/5

47 tools is high but reflects the broad scope of the platform (document generation, signing, auditing, scheduling, webhooks, verification). Some informational tools could be merged, but the count is still reasonable for the domain.

Completeness3/5

The tool set covers the core document lifecycle well but has notable gaps: no tool to delete renders, no tool to void/cancel signature requests, and no CRUD for templates (only list and schema). The inability to pause schedules via MCP is also a gap.

Resources