ProLevelMax

Schedule a repeating run (paid per run)

procli_schedule_create

Run a source automatically every day or every week at a set time (Beijing time), e.g. when the user asks "check Xiaohongshu for my brand every day". Each run is charged like procli_run, never more than runCap. Use procli_inspect first to pick the source and input. Call this first WITHOUT confirmed: it returns a preview (cost cap per run, most per month, first run time) and saves nothing. Tell the user the cost per run and how often it runs, and ask them to confirm. Only after they agree, call again with the same arguments and confirmed=true. The user can see, pause and delete schedules in the console (dashboard → Schedules).

Input Schema

TableJSON Schema

Name	Required	Description
`time`	Yes	Time of day, 24-hour "HH:MM", Beijing time (UTC+8), e.g. "09:00"
`input`	Yes	Input fields for this source (see procli_inspect)
`runCap`	No	Most one run may cost, in USD. Default: the source's quote for this input
`scraper`	Yes	Source id from procli_discover
`weekday`	No	Weekly only: the day to run
`maxItems`	No	Per-result sources: most results per run (default 100)
`confirmed`	No	true only after the user agreed to the cost shown in the preview
`frequency`	Yes	How often to run
`monthlyCap`	No	Optional: most this schedule may spend per calendar month, in USD
`notifyEmail`	No	Email the user when each run finishes (count, cost, link to the run)

Output Schema

TableJSON Schema

Name	Required	Description
`next`	No	What to do next
`saved`	Yes	false = preview only, ask the user and call again with confirmed=true; true = saved
`manage`	No	Where to manage schedules
`preview`	No	What would be saved, with summary
`schedule`	No	A repeating run

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 16, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "manage": {
+      "description": "Where to manage schedules",
+      "type": "string"
+    },
+    "next": {
+      "description": "What to do next",
+      "type": "string"
+    },
+    "preview": {
+      "description": "What would be saved, with summary",
+      "type": "object"
+    },
+    "saved": {
+      "description": "false = preview only, ask the user and call again with confirmed=true; true = saved",
+      "type": "boolean"
+    },
+    "schedule": {
+      "description": "A repeating run",
+      "properties": {
+        "enabled": {
+          "description": "Whether the schedule is active",
+          "type": "boolean"
+        },
+        "frequency": {
+          "description": "daily or weekly",
+          "type": "string"
+        },
+        "id": {
+          "description": "Schedule id",
+          "type": "string"
+        },
+        "input": {
+          "description": "Input sent on every run",
+          "type": "object"
+        },
+        "monthlyCap": {
+          "description": "Most all runs can cost per month, in USD",
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "nextRunAt": {
+          "description": "Next run, Unix time in ms",
+          "type": [
+            "integer",
+            "null"
+          ]
+        },
+        "pausedReason": {
+          "description": "Why it is paused",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "runCap": {
+          "description": "Most one run can cost, in USD",
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "scheduleText": {
+          "description": "The schedule in words",
+          "type": "string"
+        },
+        "scraper": {
+          "description": "Source id",
+          "type": "string"
+        },
+        "spentThisMonth": {
+          "description": "Spent this month, in micro-USD",
+          "type": "number"
+        },
+        "time": {
+          "description": "Time of day, HH:MM",
+          "type": "string"
+        },
+        "timezone": {
+          "description": "IANA time zone",
+          "type": "string"
+        },
+        "title": {
+          "description": "Source name",
+          "type": "string"
+        },
+        "weekday": {
+          "description": "0-6 for weekly schedules (0 = Sunday)",
+          "type": [
+            "integer",
+            "null"
+          ]
+        }
+      },
+      "required": [
+        "id"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "saved"
+  ],
+  "type": "object"
+}

First observedOct 16, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds substantial behavioral context: the first call saves nothing and returns a preview with cost caps and first run time, each run is charged like procli_run, spending is bounded by runCap/monthlyCap, and users can manage schedules in the console.

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 appropriately sized for a multi-step, cost-incurring workflow. It front-loads the purpose and cost model, then lays out the confirmation sequence and user-management context without filler.

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?

An output schema exists, so return values need not be explained. The description fully covers the cost, preview, confirmation, scheduling cadence, caps, and console management needed for an agent 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?

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that runCap bounds per-run cost and that confirmed=true should only be used after the user agrees to the previewed cost, though it does not individually redefine every parameter.

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 states a specific verb and resource: scheduling a source to run automatically daily or weekly at a set Beijing time. It clearly differentiates from procli_run by describing repeat scheduling, and from schedule_list/delete by focusing on creation.

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?

It gives explicit when-to-use guidance: use procli_inspect first to pick source and input, call without confirmed to get a preview, tell the user the cost and cadence, then call again with confirmed=true only after agreement. This covers both the workflow and the alternatives for inspecting or one-off runs.

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

All ProLevelMax tools Inspect

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

Need Help?