Skip to main content
Glama

Zyte MCP Server

scrapy_cloud_create_periodic_job

Create a recurring schedule that runs one or more spiders (or scripts) on a cron expression, in UTC. Cron fields must be numbers or '*': no ranges, steps or lists; use several schedules for several times. This changes what runs on the account on an ongoing basis; confirm spider and schedule with the user first. Returns the new periodic job with its id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cronYesSchedule in UTC as 5 cron fields, each a number or '*'. Example: '0 9 * * 1' is Mondays 09:00 UTC. No ranges, steps or lists.
tasksYesSpiders or scripts to run on each tick, in order.
addtagsNoTags added to every job this schedule starts.
disabledNoCreate the schedule paused.
project_idYesScrapy Cloud project id (the numeric id in the dashboard URL).
descriptionNoHuman-readable purpose of the schedule.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does disclose the important traits: the effect is ongoing/persistent on the account, UTC is the timezone, cron syntax is restricted (no ranges/steps/lists), and it returns the new periodic job with its id. It omits permission/auth requirements and what happens on cron conflicts, so it is not exhaustive.

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?

Four tight sentences, each earning its place: purpose, cron constraint, mutation warning, return value. The most decision-relevant content (what it creates and that it changes ongoing behavior) is front-loaded.

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

Completeness4/5

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

No output schema exists, and the description compensates by stating the return ('the new periodic job with its id'). Combined with the mutation warning and the cron-format constraint, an agent has what it needs to call it correctly; only secondary details like permissions are missing.

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 description coverage is 100%, so every parameter (cron, tasks, project_id, disabled, addtags, description) is already documented inline with examples and defaults. The description restates the cron constraint and the spider-or-script notion already present in the schema, adding no new parameter semantics beyond the baseline.

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?

Specific verb+resource: 'Create a recurring schedule that runs one or more spiders (or scripts) on a cron expression, in UTC.' The word 'recurring' plus the cron mechanism separates it from one-off siblings like scrapy_cloud_run_spider and from the update/delete periodic-job siblings, so an agent can place it without opening another schema.

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 explicit conditions and a caution: 'This changes what runs on the account on an ongoing basis; confirm spider and schedule with the user first.' It also explains how to express multiple run times ('use several schedules for several times'), which is a usage workaround for the cron limitation. It does not name a sibling alternative (e.g. run_spider for one-off runs), so it stops 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources