Reg Monitoring

List regulatory deadlines

regmonitoring_list_deadlines

Read-onlyIdempotent

Regulatory deadlines with dates: consultation response dates, compliance deadlines, and rule effective dates, filterable by date range, status, firm type, jurisdiction and regulator. This is the tool for "what is coming up for my firm" and for building a compliance calendar. Status is derived at query time, never stored, so it is always current; buckets do not overlap (within_90 excludes anything already within 30 days). Set high_confidence_only when the answer will be planned against.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "regmonitoring_list_deadlines"
  }
}

Input Schema

Name	Required	Description
`to`	No	Latest deadline date, YYYY-MM-DD, inclusive.
`from`	No	Earliest deadline date, YYYY-MM-DD, inclusive.
`limit`	No	Default 50, max 100.
`offset`	No
`status`	No	Derived from the date at query time, never stored. "within_90" means within 90 days but not within 30 — the buckets do not overlap. Omit this and pass from/to for a plain date range.
`firm_types`	No	Records tagged "All Firms" are cross-cutting and match every firm-type filter.
`regulators`	No	Lowercase regulator codes. See regmonitoring_get_taxonomy.
`content_types`	No	Kind of document the deadline came from.
`jurisdictions`	No	Lowercase jurisdiction codes. See regmonitoring_get_taxonomy.
`deadline_types`	No	response_due = consultation closes; compliance_deadline = firms must have complied; effective_date = rule takes effect.
`high_confidence_only`	No	Only deadlines extracted with high confidence. Worth setting when the answer will be planned against — a wrong date is worse than no date.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description focuses on value-add: status is derived at query time and never stored, buckets do not overlap (within_90 excludes within_30), and confidence filtering exists. These are real behavioral traits an agent needs for correct planning, though return shape is not described.

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?

Purpose and filter scope are front-loaded, followed by use-case framing and per-parameter guidance. Each sentence carries information, though the comma-heavy filter list and parenthetical bucket explanation make it slightly dense.

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?

For an 11-parameter read-only list tool with no output schema, the description covers scope, filter dimensions, derived-status semantics, and confidence handling. It stops short of describing the returned record fields (deadline date, type, related document), which would help an agent interpret results.

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 91%, so the schema already documents dates, limit/offset, enums, and the non-overlapping status buckets. The description mostly restates those semantics (derived status, bucket exclusivity) and the high_confidence_only advice is verbatim in the schema, adding little beyond structured fields.

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 resource (regulatory deadlines), enumerates the sub-kinds it covers (consultation response dates, compliance deadlines, rule effective dates), and lists the filter dimensions. It also implicitly separates itself from search_updates by framing the tool as the one for upcoming dates and compliance calendars.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

It gives explicit use cases ("what is coming up for my firm", building a compliance calendar) and a conditional rule for high_confidence_only when output will be planned against. It does not explicitly name or exclude sibling tools such as regmonitoring_search_updates, so routing is inferred rather than stated.

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

All Reg Monitoring 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?