IQ Books by ReconcileIQ

Deadlines

deadlines

Read-onlyIdempotent

Every date these books must meet, as the app's Reports, Deadlines shows them: VAT returns, MTD Income Tax updates, Self Assessment / final declaration, payments on account, partnership return, Companies House accounts and confirmation statement, corporation tax and CT600, CIS returns, PAYE, P60/P11D, year end, bank feed renewals. Each has a key, a due date, a status (overdue, due_soon, upcoming, done, not_applicable, needs_info, to_do, check), where the date comes from (hmrc, companies_house, rule, feed) and how it is worked out. 'overdue' with confirmed true means HMRC or the Companies House register said in the last week that it is still open; with confirmed false it means past its date and nothing in IQ Books shows it filed or paid (shown_as says 'Not filed here', 'No payment seen' or 'Not marked done'): it may have been done elsewhere, so ask before calling it late. HMRC's own dates are as last fetched by a person in the app (this tool never calls HMRC). Mark one with plan_bookkeeping mark_deadline {deadline: key, status}. Use it for 'what is due and when', before any filing date, and to plan a month's work. It looks 120 days ahead and leaves out what is done unless you widen horizon_days or set include_done. Reads only.

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": "deadlines"
  }
}

Input Schema

Name	Required	Description
`horizon_days`	No	How far ahead to look (default 120 days).
`include_done`	No	Also list deadlines done or marked in the last 60 days.
`organisation_id`	No	Defaults to the selected organisation.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already cover the read-only/idempotent/closed-world profile, and the description adds substantial context beyond them: HMRC dates are a stale human-fetched snapshot ('this tool never calls HMRC'), done items are filtered out by default, the 120-day default horizon, and the important nuance that 'overdue' + confirmed=false may mean filed elsewhere and should be checked before being called late.

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?

It is long, but front-loaded with purpose and dense with information an agent needs (status vocabulary, source values, the 'confirmed' caveat) since there is no output schema. The long enumeration of deadline types is the least efficient part, but it doubles as scope documentation.

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?

With no output schema, the description carries the burden of describing the return shape and does so well: each deadline has a key, due date, status (with the full status vocabulary), a source (hmrc, companies_house, rule, feed) and a derivation. Combined with the read-only annotations and the default-filter behavior, an agent has everything needed to call and interpret it.

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 the schema already documents horizon_days, include_done and organisation_id. The description only lightly reinforces this (default 120-day lookahead, widening the horizon or setting include_done to surface completed items), which is close to restating the schema rather than adding new semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause names the resource precisely ('Every date these books must meet, as the app's Reports, Deadlines shows them') and enumerates the categories covered (VAT returns, PAYE, CT600, confirmation statement, etc.), so an agent knows exactly what it retrieves. It does not explicitly say how it differs from the similar-sounding sibling vat_obligations, which keeps it from a 5.

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 concrete usage triggers: 'what is due and when', 'before any filing date', 'to plan a month's work'. It also routes the agent elsewhere for mutation ('Mark one with plan_bookkeeping mark_deadline') and adds a caution about interpreting 'overdue'. No explicit when-not-to-use or sibling exclusion is stated, so 4 rather than 5.

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

All IQ Books by ReconcileIQ 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?