Skip to main content
Glama
Sign In

Cotlet

by dev.cotlet
OverviewDiscussionsAdmin

Cotlet: save an automation

cotlet_automation_save

Saves a tested script as an automation on a schedule, or with automation as its new version. Show the user the rows, schedule and cost first. A script with writes waits until the user allows them in the console: give them the link this answers.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "script": "<script>",
      "schedule": "<schedule>",
      "explain": "<explain>"
    },
    "name": "cotlet_automation_save"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesShort name, e.g. Lotto monitor.
noteNoFor a new version: what changed, one line.
scriptYesThe Python script: `def run(ctx):` with the cotlet SDK (see the guide).
explainYesHow it works, for the user: {summary: 1-3 plain sentences, nodes: [{id, kind: trigger|read|ai|write|output|step, label, site?}], edges: [[from, to, label?]]}. A write node for every ctx.write.
outputsNoWhere new rows go besides the dataset: {email: off|each_run|daily, email_hour: 0-23, webhook_url: https URL or null}. Default: email off.
scheduleYesCron (*/15 * * * *) or words: every 15 minutes, every 2 hours, daily at 8:00.
automationNoThe automation's id from cotlet_automation_list.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover the safety profile (not read-only, not destructive, open-world), and the description adds behavior they can't express: saving with `automation` creates a new version rather than overwriting, writes are gated on user approval in the console, and the call yields a link to hand over. It does not explain what happens to prior versions after a save, or what the response contains.

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

Conciseness4/5

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

Three short sentences, front-loaded with the action and versioning branch, with no filler. The final clause 'give them the link this answers' is awkward and cryptic, costing some clarity, though the overall length is well matched to the tool.

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

Completeness3/5

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

Covers purpose, versioning, workflow prerequisites and the consent gate for a fairly complex 7-parameter tool with nested objects. However, with no output schema, the description should explain what a save returns — an automation id, the approval link, a cost figure — and instead leaves this to the garbled 'the link this answers'. The undefined 'cost' the user must be shown is also unexplained.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all seven parameters including the nested `explain` and `outputs` shapes. The description's only added semantic is that `automation` selects update-as-new-version mode, which is genuinely useful but minimal. Baseline 3 applies since the schema carries the parameter burden.

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

Purpose4/5

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

States a specific verb and resource: save a script as an automation, with an explicit create-vs-new-version branch keyed on the `automation` parameter. The phrase 'a tested script' also implies the prerequisite test step. It doesn't name `cotlet_automation_test` or any sibling directly, so differentiation is inferential rather than explicit.

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

Usage Guidelines4/5

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

Gives a concrete workflow ordering ('Save... a tested script', 'Show the user the rows, schedule and cost first') and a conditional path for scripts containing writes that need console consent. What's missing is an explicit pointer to the sibling that produces the tested script and the rows/cost being shown, which matters given ~30 siblings.

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

All Cotlet toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources