Schedule HTTP requests from an agent: once at an exact time or on cron, with retries and run logs.
Scored across 8 tools
Each tool maps to a distinct action on a distinct resource: create (schedule_request), read one (get_schedule), read many (list_schedules), delete, pause, resume, trigger now (run_now), and account info. The potentially confusable pair run_now vs. schedule_request is explicitly separated by description (trigger an existing schedule vs. create a new one), and pause vs. delete is clarified with a pointer to each other.
Nearly all tools follow a consistent snake_case verb_noun pattern (get_schedule, list_schedules, delete_schedule, pause_schedule, resume_schedule, schedule_request). Minor deviations: account_status is noun-only with no verb, and run_now is verb_adverb rather than verb_noun, but both remain readable and predictable.
Eight tools is well-scoped for a scheduling service; each earns its place by covering a lifecycle action plus account status, with no filler or redundant variants. Nothing feels thin or bloated for the stated purpose.
The surface covers create, read (single and list), delete, pause, resume, immediate run, and account/usage status — a full lifecycle except editing. There is no update_schedule to change a URL, time, or cron without deleting and recreating, and run history is only visible per-schedule via get_schedule. These are workaroundable gaps rather than dead ends.
Show this workspace's plan, trial end date, limits and usage this month. With no plan yet, it includes the link where the 14-day trial starts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds genuinely new behavior: it states the returned content set (plan, trial end date, limits, month-scoped usage) and a conditional branch for the no-plan-yet case, including that a trial-start link is returned. It could go further on what happens outside trial, but this is solid added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, with the primary purpose front-loaded and the edge case (no plan yet) placed second. Every clause carries information an agent would otherwise have to guess at.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must carry the return-value burden – and it does, naming the four data categories returned plus the trial-link fallback. With no parameters and annotations covering the safety profile, there is no meaningful gap left for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters and the schema is empty, so there is nothing for the description to clarify. Baseline for a zero-parameter tool is 4, and nothing in the description introduces confusion about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ("Show this workspace's plan") and enumerates exactly what the response covers: plan, trial end date, limits, and monthly usage. None of the sibling tools (all schedule CRUD operations) touch account or plan data, so an agent can route here without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the subject matter – an agent infers 'call this when you need to know the plan or remaining limits.' There is no explicit when-to-use condition, no exclusion, and no alternative named, though for a zero-parameter read tool the risk of mis-invocation is low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a scheduled request for good. It stops running and cannot be restored. To stop it for a while, use pause_schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Schedule id, from schedule_request or list_schedules |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is supplied structurally. The description adds the consequential detail those hints cannot: the schedule "stops running and cannot be restored," making irreversibility concrete rather than abstract. It stops short of stating permission requirements or whether run history is preserved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, with the consequence and irreversibility front-loaded ahead of the alternative. Every sentence earns its place: what it does, what it destroys, and where to go instead.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive tool whose annotations already flag destructiveness and idempotency, the definition covers action, permanence, and the correct alternative, so nothing essential to invoking it correctly is missing. Minor gaps remain around auth requirements and whether output is returned, though a delete operation likely needs none.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single required parameter with 100% schema description coverage, and the schema already explains that the id comes from schedule_request or list_schedules. The description adds nothing about the id beyond that, so the baseline of 3 applies since the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Delete a scheduled request") plus the permanence qualifier "for good," and explicitly names the sibling pause_schedule as the non-destructive counterpart. An agent can distinguish it from get_schedule, pause_schedule, and resume_schedule without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit alternative and the condition that selects it: "To stop it for a while, use pause_schedule." This is exactly the routing decision an agent faces among the schedule siblings, so the when-to-use/when-not guidance is complete for the realistic ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one scheduled request with its recent runs: status code, duration, error and a preview of each response. Use this to check whether a request worked.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Schedule id, from schedule_request or list_schedules | |
| runs | No | How many recent runs to include. Default 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is free. The description adds real value beyond that by enumerating the returned content (status code, duration, error, response preview), which matters because no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with what is fetched, followed by the fields returned and the purpose. No filler or redundant restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two simple parameters and no nested structures, this is close to complete, and the description compensates for the missing output schema by listing the returned fields. Only minor gaps remain, such as whether a response preview is truncated or how large previews can get.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters carry their own descriptions, including the default of 10 for runs and where the id comes from. The description's "recent runs" phrasing is consistent but adds no syntax or limits beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Get one scheduled request with its recent runs" gives a specific verb and resource, and the field list (status code, duration, error, response preview) pins down exactly what comes back. The singular "one" implicitly contrasts with list_schedules, though no sibling is named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this to check whether a request worked" gives a genuine use case, but there is no guidance on when to prefer list_schedules, when to use run_now, or any prerequisite such as needing an id from schedule_request or list_schedules. Usage is implied rather than delimited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List scheduled requests in this workspace, newest first, with status (scheduled, paused or finished) and next run time.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most to return. Default 50. | |
| status | No | Filter by status. Default all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, non-destructive profile, so the description correctly focuses on behavior it can uniquely add: sort order ('newest first') and the fields returned (status, next run time). It omits anything about pagination beyond the limit parameter, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and resource, then adds ordering and return fields. No redundant or filler wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully discloses what comes back (status and next run time) and the ordering, which an agent needs to interpret results. Only the absence of paging guidance keeps it from a 5 for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters, including the enum values, are fully documented in the schema. The description echoes the status values without adding format or behavioral detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List scheduled requests') plus scope ('in this workspace'), which distinguishes it from the singular get_schedule sibling. It does not explicitly name the sibling alternatives, so it stops short of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is the enumeration tool versus get_schedule for one item, but the description never says when to use it or when to prefer another tool. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause a scheduled request so it stops running until resumed.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Schedule id, from schedule_request or list_schedules |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so safety and repeat-call behavior are covered structurally. The description adds the persistent-state semantics (paused until resumed), but says nothing about whether an in-flight run is aborted, whether history is retained, or what the call returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and resource, with zero redundant wording. Nothing can be removed without losing content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, non-destructive, idempotent state-change tool with a fully documented schema and no output schema, the description is nearly sufficient. The only material gap is what happens to a currently running execution and what state the schedule is returned in.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single `id` parameter already documents that it comes from schedule_request or list_schedules. The description contributes no additional meaning about the identifier, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ("Pause a scheduled request") and states the effect ("stops running until resumed"), which implicitly separates it from delete_schedule. It never names resume_schedule or delete_schedule, so sibling differentiation is only implied 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the phrase "until resumed": the agent can infer this is the temporary, reversible option in contrast to deleting. However, there is no explicit "use this instead of X when..." guidance and no stated preconditions such as the schedule needing to be active.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resume a paused request. A recurring one continues at its next cron time. A one-time one needs its run time to still be in the future.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Schedule id, from schedule_request or list_schedules |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it is a non-destructive, idempotent mutation; the description adds genuinely new behavior: a recurring schedule resumes at its next cron time, while a one-time schedule requires a future run time. That is real operational context beyond the hints, though it omits what error or resulting state occurs when the one-time run time is already past.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with zero padding; the action is front-loaded and the two schedule-type caveats follow in priority order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, non-destructive, idempotent mutation with a fully documented schema and no output schema, the description covers the essentials including the failure precondition. It is only slightly thin on what the agent should do if the one-time run time has passed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the id parameter already documents its source ('from schedule_request or list_schedules'). The description adds no additional meaning about the id or any format constraints, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Resume') plus the exact resource and required prior state ('a paused request'), which cleanly separates it from pause_schedule and delete_schedule in the sibling list. An agent can identify the operation without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The precondition (must be paused) and the schedule-type-dependent outcome give clear context for when to call it and when the call will not succeed. It does not explicitly name pause_schedule or list_schedules as the counterpart/verification steps, so it stops short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a scheduled request once, right now, without retries, and return the status code and response. A successful run counts toward the monthly limit. A one-time request is finished after this.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Schedule id, from schedule_request or list_schedules |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true, destructiveHint=false). The description adds real operational context: execution is non-retrying, a successful run is metered against the monthly quota, the return is a status code plus response body, and one-time schedules are consumed by the call. These are exactly the facts an agent cannot infer from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with the core action front-loaded, followed by quota and lifecycle consequences. Nothing is repeated from the schema and no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no output schema, and only generic annotations, the description supplies the missing pieces: no retries, quota consumption, the shape of the result, and the one-time consumption behavior. An agent has everything needed to invoke it and predict the consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'id' parameter already documents its format and where to obtain it (schedule_request or list_schedules). The description adds no further meaning about the identifier, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — send a scheduled request immediately, one time — plus modifiers (no retries) that separate it from siblings like schedule_request, pause_schedule, or resume_schedule. An agent can identify the operation without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The framing 'Send a scheduled request once, right now' plus 'A one-time request is finished after this' tells the agent this triggers an existing schedule rather than creating one. It stops short of explicitly naming alternatives such as schedule_request or delete_schedule or stating when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule an HTTP request to a public URL: once at an exact time (run_at) or repeatedly (cron). Pass exactly one of run_at or cron. RunLater sends it, retries failures and logs every run. Returns the schedule with its id and next run time.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http(s) URL to call. Private and local addresses are refused. | |
| body | No | Request body as text (JSON goes here as a string). Not sent on GET or DELETE. | |
| cron | No | Recurring: 5-field cron (minute hour day-of-month month day-of-week), for example "0 9 * * 1" for Mondays at 9:00. At most once a minute. | |
| name | No | Short label shown in the dashboard. Default: method and host. | |
| method | No | HTTP method. Default POST. | |
| run_at | No | One-time: ISO date and time, for example 2026-12-01T09:00:00 (read in timezone) or 2026-12-01T15:00:00Z. At most two years ahead. | |
| headers | No | Request headers, for example [{"name":"Authorization","value":"Bearer abc"}]. Values are never shown back. | |
| retries | No | Retries after a failed attempt, with exponential backoff. Default 3. | |
| timezone | No | IANA time zone for run_at without an offset and for cron, for example America/New_York. Default UTC. | |
| timeout_seconds | No | Seconds to wait for a response. Default 30. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the write, open-world, non-idempotent, non-destructive profile, and the description adds real behavior on top: RunLater sends the request, retries failures, logs every run, and only public http(s) URLs are accepted with private/local addresses refused. It stops short of warning that repeat calls create duplicate schedules (the non-idempotent consequence) or what auth the caller needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: capability and URL restriction first, the mode-selection rule second, execution behavior and return value last. No filler and nothing buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter creation tool with no output schema, the description covers the mode choice, the public-URL restriction, execution/retry/logging behavior, and the shape of the response (id and next run time). Combined with a fully described schema, an agent has what it needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds a cross-parameter rule the schema does not encode: exactly one of run_at or cron must be supplied. That is genuine semantic value beyond the field-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (schedule an HTTP request to a public URL) plus the two scheduling modes, and the return value is named. It is clearly distinguishable from siblings like run_now or list_schedules, which do not create schedules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit constraint for choosing between the two modes: 'Pass exactly one of run_at or cron.' It does not, however, tell the agent when to prefer this tool over run_now (immediate execution) or when a schedule already exists via get_schedule/list_schedules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
account_statusdelete_scheduleget_schedulelist_schedulespause_scheduleresume_schedulerun_nowschedule_requestLet agents make HTTP requests later: schedule, retry, cron, watch jobs, receive webhooks.
Reliable scheduling for one-off and recurring webhooks, built for apps and agents.
Schedule tasks for later from your AI agent: reminders, delayed webhooks, recurring jobs.
Scheduled, HMAC-signed, retried webhook triggers for AI agents. No account: self-register via tools.
Add one secure layer between your agents and this server.
