Skip to main content
Glama

Read, set, or trigger my app's clock

dropyour_schedule

Your app's clock, in one verb. action='read' (default) tells you when it next rings, whether the app is frozen, and the last runs WITH THEIR EFFECT: verdict, duration, and the state version before and after — that is where you see 'it runs but writes nothing', which no error log can show you because there is no error. action='set' schedules one wake-up (5 minutes to 30 days from now); action='cancel' drops it. Your code re-arms itself from its scheduled handler, so setting from here REPLACES what the code armed. action='test' rings NOW and returns the verdict of that run — use it right after writing a scheduled handler instead of waiting for the clock. IT IS A REAL RUN: it counts as an invocation and, if your handler writes, it really writes. Read dropyour_logs with the same call to see what your app said. Tier 4 only — the clock belongs to a graduated app.

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": {
      "dropId": "<dropId>"
    },
    "name": "dropyour_schedule"
  }
}

Input Schema

NameRequiredDescriptionDefault
atNoFor action='set': when to ring (ISO datetime), between 5 minutes and 30 days from now.
actionNoread
dropIdYes
managementTokenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / at / pattern
      Previous value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"New value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$"
  2. Added

TDQS

A4.3/5.0
Behavior4/5

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

Adds substantial behavior beyond the annotations: 'test' is a real invocation that really writes, 'set' REPLACES whatever the code armed, and reads expose before/after state versions so you can detect 'it runs but writes nothing'. The Tier 4 precondition is also disclosed. Slight tension with destructiveHint=false, since replacement of the code-armed schedule and real writes are destructive-adjacent, but not a true contradiction for a single wake-up slot.

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?

Front-loaded with the default action and its return content, and nearly every clause carries operational information (state-version diffing, real-run warning, tier gate). It runs long with some rhetorical flourish ('in one verb', the all-caps real-run warning) that could be trimmed without losing meaning.

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?

Four parameters, no output schema, and thin annotations, and the description compensates well by describing what 'read' and 'test' return and the side effects of each mutating action. Gaps remain around authentication (managementToken), what dropId identifies, and failure modes such as cancelling when nothing is armed.

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 only 25% (only 'at' is documented, and the description largely repeats its 5-minute/30-day bound). The description does carry the full per-value meaning of the 'action' enum, which the schema does not, but 'dropId' and 'managementToken' are left entirely unexplained despite the low coverage 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?

Names the resource concretely (the app's clock/scheduled wake-up) and enumerates the four operations with what each does: read returns next ring time, frozen state, and last runs with verdict/duration/state-version; set/cancel manage the wake-up; test rings immediately. This is far more than a restatement of the title, and it distinguishes the tool from siblings like dropyour_logs by telling the reader to pair them.

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?

Explicit routing per action: default 'read' for inspecting schedule state, 'set' for scheduling (with a 5-minute-to-30-day window), 'cancel' to drop, and 'test' specifically 'right after writing a scheduled handler instead of waiting for the clock'. It also states the eligibility gate ('Tier 4 only — the clock belongs to a graduated app') and points to dropyour_logs for handler output.

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.