Moltline RegClock

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

Annotations already state read-only, idempotent, non-destructive, and closed-world behavior, but the description adds substantial context beyond them: free usage, the response shape, missing-answer handling, and the fact that invalid input returns an error object rather than a protocol error. It also confirms that retrying after correcting input is safe.

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?

The purpose is front-loaded in the first sentence, followed by a compact example, usage boundaries, and error behavior. Despite covering many details, every sentence adds practical information for invoking the tool correctly.

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?

The tool involves a nested facts object and regime identifier, and the description supplies an example, explains missing answers, and clarifies error behavior. An output schema exists, so the description need not document every return field, and it is complete enough for correct invocation.

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 would be 3, but the description adds a concrete typical input example showing the nested facts object and the regime/facts relationship. The added example and the explanation of how unanswered questions surface as missing give useful meaning beyond the schema.

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: apply a regime's statutory criteria to facts and name the event type. It immediately distinguishes the tool's scope from severity judgment in the abstract, so an agent can tell what this tool is for.

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?

It gives clear usage guidance: use this when deciding whether an incident triggers a regime at all, and explicitly says it is not for judging severity in the abstract. It does not name specific sibling alternatives such as explain_rule or validate_report, so it stops short of full routing guidance.

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

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

Goes well beyond the annotations: it discloses the error contract ('never raises a protocol error; it returns {"error": ...}') with an example, states retry safety after correction, and warns that clocks running off an earlier submission are estimates until actual times are passed in 'submitted'. These are behavioral traits the readOnly/idempotent hints do not convey.

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?

Front-loads purpose, then a worked input/return example, then regime-specific parameter notes, then the exclusion and error contract. The return-value fragment partially duplicates the output schema, but the call shape is otherwise dense and waste-free.

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?

An output schema exists, so return explanation is not required, and the description still supplies the error path, retry safety, and per-regime prerequisites. For a 12-parameter, nested-object tool this is enough to call correctly on the first attempt.

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 genuine cross-parameter semantics the schema cannot express: which regime requires which extra parameter (DORA needs classification_at + country, SEC needs materiality_determined_at, HIPAA takes discovery_date and flags.individuals_affected) and how 'submitted' changes computed results. It leaves entity_class, subdiv, and measure_available_at to the schema, which lower-usage params can tolerate.

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 ('Compute every reporting deadline of one regime from the moment of awareness') with explicit scope ('one regime'). It also names the sibling it is not for ('Not for several regimes at once: use compute_deadlines_multi'), so an agent can distinguish it 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?

Gives a concrete triggering condition ('when an incident has just been identified and the agent needs the instants'), an explicit exclusion, and the named alternative for the excluded case. Usage is fully determined, not inferred.

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

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

Adds substantial context beyond the annotations: a non-throwing error contract with a concrete error payload example, the safety of retrying after correction, and a PREMIUM license cost signal. It does repeat read-only/idempotent from the annotations, but the error and licensing disclosures are the value-add.

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?

Front-loaded with the payoff, then example, then when-to-use, then error behavior. The inline JSON examples are dense but earn their space by showing the per-entry override pattern; a little trimming of formatting would help readability.

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?

Output shape is described (timeline sorted by due_at, first_due, per_regime) even though an output schema exists, and the failure mode is covered. The advanced anchor fields (classification_at, measure_available_at, materiality_determined_at) are only gestured at via 'anchors... shared', leaving their per-regime interaction to the schema.

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; the description earns above that by explaining override semantics — each regime entry may carry its own event_type and entity_class while anchors and flags are shared across the call. That resolves how the 11 parameters compose, which the flat schema does not.

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 (merged timeline across several regimes for one incident) and immediately distinguishes itself from the single-regime sibling. The example makes the scope concrete: one incident, multiple regimes, one ordered list.

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?

Explicit positive guidance ('Use when one incident triggers several regimes and the agent needs a single ordered list') plus an explicit negative with a named alternative ('Not for one regime: compute_deadlines is free'). No inference required.

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

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.

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.

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.

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.

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.

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.

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

Beyond the annotations (readOnly/idempotent/non-destructive), the description discloses two traits annotations cannot express: it is free, and it never raises a protocol error but instead returns {"error": "<what is wrong and how to fix it>"} with a concrete example. That error contract plus the retry-safety note is exactly the kind of behavioral context an agent needs and structured fields do not carry.

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?

Front-loaded with the purpose and the free/read-only guarantee, then example, then usage, then error contract. It is dense and nearly every clause earns its place, but the inline multi-line JSON blobs make it visually heavier than necessary and slightly slow to scan.

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 3-parameter, typed, single-object tool with an output schema, the description covers purpose, argument edge cases, sibling routing, cost, error semantics and retry safety. Nothing an agent needs in order to call it correctly is missing; return shape is even illustrated despite the output schema already documenting it.

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 would be 3, but the description adds value the schema lacks: a worked input example ({regime, event_type, obligation}) paired with the shape of the response, which clarifies how the three arguments compose. It stops short of enumerating valid regime/event_type/obligation values, deferring to list_regimes.

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: 'Quote the time limit, citation and required content for an obligation.' It also draws the boundary against the sibling that shares the same domain ('Not for computing dates: use compute_deadlines'), so an agent can discriminate it from the deadline-computation tools without opening a 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?

Gives an explicit inclusion criterion ('when a caller needs the rule's own words next to a computed date'), an explicit exclusion with a named alternative (compute_deadlines), and edge-case guidance for empty arguments ('leave obligation empty to get every obligation…; leave event_type empty on single-event regimes').

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

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

Goes well beyond the annotations (which already declare read-only, idempotent, non-destructive) by disclosing that invalid input never raises a protocol error but returns {"error": "<what is wrong and how to fix it>"}, and that retrying after correction is safe. It also flags the tool as FREE, which annotations do not convey.

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?

Front-loaded with the purpose and the FREE marker, and each subsequent sentence (example, when-to-use, scope caveat, error contract) carries information. It is somewhat dense as one flowing block, and the example return value partly duplicates the output schema.

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 three-parameter lookup tool it covers purpose, scope caveat, error behavior, retry safety, and usage triggers; the presence of an output schema means the return format needs no further explanation. Nothing an agent needs to call this correctly is missing.

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 country/year/subdiv semantics are already documented, and the description only adds a sample input ({"country": "IE", "year": 2026}). That example illustrates format but adds no constraint or meaning the schema lacks, so the 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 the public holidays the engine uses for a country and year') with explicit scope, and names its relationship to compute_deadlines, so an agent can separate it from sibling tools without opening a schema. The parenthetical naming of the underlying `holidays` package further pins down semantics.

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 concrete when-to-use triggers ('checking why a business-day adjustment landed where it did', 'see whether a country/subdivision is supported') plus an explicit when-not ('Not a legal register of bank holidays'). It stops short of naming the closest sibling (list_regimes) as the alternative for the country-support question it mentions.

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

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

Beyond the annotations (readOnly, idempotent, closed-world), the description discloses cost ('FREE'), the non-protocol-error behavior ('never raises a protocol error; returns {"error": ...}'), recovery guidance, and the meaning of verified_on. These are precisely the traits an agent cannot infer from structured fields.

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?

Front-loaded purpose and cost, then usage, then behavior notes — good ordering with no filler. The inline output sample is slightly redundant given an output schema exists, though it does make the regime object shape concrete.

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?

Covers purpose, cost, usage trigger, downstream consumers, error semantics, retry safety, and scope caveat. Nothing an agent needs in order to call a zero-parameter read tool correctly is missing.

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?

Zero parameters, so the baseline is 4. The description still shows the canonical empty input {} and what the resulting object contains, which clarifies that no filtering or arguments are needed.

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 the reporting regimes this server can compute, with citations') and immediately distinguishes itself from siblings by naming compute_deadlines and classify_event as the consumers of its output. An agent knows exactly what this returns and why it exists.

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 when choosing the regime id and event_type for compute_deadlines or classify_event' gives an explicit trigger condition plus the downstream tools, which is the real selection logic for a discovery tool. The 'Not for legal advice' line sets the boundary of what the results may be used for.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: a PREMIUM license gate, per-row mapping rules (dated deadlines become VEVENTs with citation in description plus a VALARM; open-ended rows go to CSV only), and a documented error contract (returns {"error": ...} rather than a protocol error, safe to retry). That is well beyond what the structured fields convey.

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?

Front-loaded with purpose, then example input/output, then usage and error behavior – a sensible order with no filler sentences. The inline JSON snippets make it longer than strictly necessary, but each carries real information.

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 4-parameter export tool with full schema coverage, an output schema, and explicit annotations, the description still covers the license constraint, input provenance, output shape, and failure/retry behavior. An agent has everything needed to call it correctly and recover from bad input.

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 baseline would be 3, but the description adds meaning the schema does not: what the deadlines rows actually contain and how they are split between VEVENTs and CSV, plus a concrete example input object. The alarm and incident_ref semantics largely duplicate schema text, keeping it below a 5.

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 ('Export computed deadlines as an iCalendar file and CSV rows') and explicitly separates itself from compute_deadlines ('Not for computing deadlines'). An agent can distinguish it from all siblings including compute_deadlines_multi without opening a 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?

Gives the positive trigger ('Use when the timeline needs to land in a calendar or a ticket'), the negative case ('Not for computing deadlines'), and the upstream source of input (rows from compute_deadlines / compute_deadlines_multi). Nothing about when to select this tool is left to inference.

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

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

Goes well beyond the annotations by disclosing that the content check is a keyword heuristic (not semantic), that GDPR timing flags late notifications lacking reasons, and that malformed input never raises a protocol error but returns a structured {error} object. The PREMIUM license constraint and the safe-retry statement add operational context annotations cannot express.

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?

Front-loads the purpose and the license constraint, then the examples, then the caveats and error contract. Dense but each block carries information; the inline JSON examples are worth their length, though the return-value narration is partly redundant with the output schema.

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 6-parameter tool with a nested free-form report object and an output schema, the description covers purpose, triggering moment, heuristic limits, error contract, and retry safety. An agent has everything needed to invoke it correctly and interpret failures.

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. The description does add value with a concrete input example showing regime/obligation/report shape and an error example enumerating valid obligation ids, but it leaves event_type and the optional submitted_at/due_at defaults to the schema alone.

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: check a draft report against a statutory content list and its deadline. The word 'check' plus the 'presence not quality' boundary clearly separates it from compute_deadlines, deadline_status, and classify_event, which produce inputs or status rather than validating content.

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 before a report is sent' gives an explicit call point, and 'Not a legal review, and it cannot judge quality, only presence' rules out a misapplication. It does not explicitly route the agent to compute_deadlines for due_at or to list_regimes for regime ids, though the schema's parameter descriptions cover that handoff.

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