Skip to main content
Glama
Sign In

Moltline RegClock

by com.moltlinestudio
OverviewDiscussionsAdmin

Deadline Status

deadline_status
Read-onlyIdempotent

Mark each computed deadline open, due soon, overdue or submitted as of now. FREE.

Typical input {"deadlines": , "now": "2026-09-15T08:00:00+02:00"} returns {"items": [{"obligation": "early_warning", "status": "due_soon", "hours_remaining": 1.5, ...}], "overdue": 0, "next_due": {...}}. Use when polling an incident timeline or deciding what to escalate next. Not for computing the deadlines themselves. Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "deadlines must be a non-empty list of rows from compute_deadlines"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.

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": {
      "deadlines": "<deadlines>",
      "now": "<now>"
    },
    "name": "deadline_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
nowYesthe current instant, ISO 8601 with a UTC offset.
deadlinesYesrows from compute_deadlines / compute_deadlines_multi (each with obligation and due_at).
submittedNoactual submission times keyed by obligation id (or "regime/obligation").

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses a key error contract: invalid input does not raise a protocol error but returns an {"error": ...} object with remediation guidance. It also explains retry safety after correction and shows the return shape, which gives the agent actionable behavioral context beyond readOnlyHint, idempotentHint, and destructiveHint.

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?

The description is front-loaded and logically structured: purpose, example input/output, usage context, exclusion, and error behavior. It is slightly overlong because 'FREE.' is unnecessary, the return example duplicates the output schema, and read-only/idempotent repeats the annotations, but the core content is efficient.

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?

Given the annotations and the presence of an output schema, the description is complete enough to call the tool correctly. It covers purpose, intended use, exclusion, input example, error behavior, and retry safety, leaving only low-level details to the schema.

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 all three parameters are already documented in the schema. The description adds a typical input example for deadlines and now, but it does not explain the optional submitted parameter or add meaning beyond the schema. This fits the baseline 3 for high schema coverage.

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 names a specific operation and resource: it marks computed deadlines with one of several statuses as of a given instant. It also explicitly excludes computing the deadlines themselves, which distinguishes it from compute_deadlines and compute_deadlines_multi. An agent can understand what this tool does 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.

Usage Guidelines5/5

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

It states concrete usage contexts: polling an incident timeline or deciding what to escalate next. It also states the negative case, 'Not for computing the deadlines themselves,' and the input description points back to rows from compute_deadlines, effectively routing the agent to the right sibling.

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

All Moltline RegClock 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