Skip to main content
Glama

Compute Deadline

compute_deadline
Read-onlyIdempotent

Compute statutory FOI/OIA deadlines by counting working or calendar days from a start date. Deterministic calculation with no external dependencies.

Instructions

Compute a statutory FOI/OIA deadline from a start date and day count using the bleeding-edge fyi-core deadline engine. Use for local working-day or calendar-day deadline math; do not use for listing requests (list_requests) or sync health (sync_monitor). Read-only and idempotent; pure calculation with no database or network access. Returns a StatutoryDeadline JSON object (start_date, due_date, statutory_deadline_days, working_day_rule).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysYesNumber of statutory days to count after start_date (working days by default).
calendarNoWhen true, count calendar days including weekends; when false/omitted, count weekdays only (Mon–Fri).
start_dateYesInclusive statutory period start date in YYYY-MM-DD (typically submission/receipt day).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
due_dateYesComputed due date (YYYY-MM-DD).
start_dateYesStart date echoed from input (YYYY-MM-DD).
instance_idNo
working_day_ruleYesRule applied: weekdays_only or calendar_days.
statutory_deadline_daysYesDay count used in the calculation.
Behavior5/5

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

Disclosures go beyond annotations: 'Read-only and idempotent; pure calculation with no database or network access' and mentions return type. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences: purpose, usage, behavior/return. No redundant information, well-structured.

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?

Complete for a simple tool with output schema: covers purpose, usage, behavior, and return type adequately.

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 100% so description adds little param detail beyond implicit mention of start date and day count, but adequate given high 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?

Description clearly states the tool computes statutory FOI/OIA deadlines from start date and day count, and explicitly differentiates from siblings list_requests and sync_monitor.

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?

Explicitly states when to use (local working-day or calendar-day deadline math) and when not to use, listing sibling tools as alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/edithatogo/fyi-cli'

If you have feedback or need assistance with the MCP directory API, please join our Discord server