Skip to main content
Glama
LienDeadline

liendeadline-mcp

Calculate supplier notice and lien deadlines

calculate_supplier_deadlines
Read-onlyIdempotent

Calculates preliminary notice and lien filing deadlines for construction material suppliers in Florida and Kansas from delivery dates, flagging other states for review.

Instructions

Calculates a construction material supplier's preliminary notice and lien filing deadlines from delivery events (contract supplier-events-v2), for questions that need deadline dates. Available baselines cover Florida and Kansas private projects; other states and public projects return review_required, which is a valid result, not an error. How the parameters depend on each other: last_delivery_date is required when deliveries_complete is true. Florida (FL) takes florida_final_payment_status and florida_termination_status; Kansas (KS) takes kansas_extension_status; these are rejected for other states. Each takes yes, no or unknown: an omitted or unknown answer keeps the affected deadline under review, and a blanket review flag is not accepted. The Florida final-payment answer holds the notice for suppliers not hired by the owner. A Florida event date is accepted only with the matching yes answer. Delivery dates are furnishing dates, not invoice dates. Returns JSON with an overall status (calculated or review_required), preliminary_notice and lien_filing (each with its own status: calculated, not_required, review_required or awaiting_final_delivery, plus deadline, days_from_now, description and statute source_url), critical_warnings, statute_citations, an exact echo of the submitted inputs and a disclaimer. Invalid or contradictory facts return an error naming the field before any API call. Public, stateless and read-only: no key needed, nothing is stored, and no notice is sent or lien filed. Not legal advice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stateYesTwo-letter code of the state where the project is located, e.g. "FL", "KS", "TX"; any state or DC is accepted. Decides which event questions apply.
hired_byYesWho ordered the materials from the supplier: the owner, a contractor or a subcontractor.
project_typeYesPrivate commercial, private residential, or public (public projects always need review).
last_delivery_dateNoDate of the final delivery, YYYY-MM-DD, not earlier than first_delivery_date. Required when deliveries_complete is true.
deliveries_completeYestrue when the final delivery has happened (then last_delivery_date is required); false while deliveries are ongoing, which returns awaiting_final_delivery for the lien date.
first_delivery_dateYesDate materials were first delivered (first furnishing), YYYY-MM-DD. Not an invoice date.
kansas_extension_statusNoKansas only: was a statutory lien-period extension filed and mailed? no permits the ordinary lien baseline; yes, unknown or omitted requires qualified review.
florida_termination_dateNoFlorida only: contract or notice-of-commencement termination date, YYYY-MM-DD, not earlier than first_delivery_date. Supply only with florida_termination_status=yes; a lien date still requires qualified review.
florida_final_payment_dateNoFlorida only: owner final-payment date, YYYY-MM-DD, not earlier than first_delivery_date. Supply only with florida_final_payment_status=yes.
florida_termination_statusNoFlorida only: was the original contract or notice of commencement terminated? no permits the lien baseline; yes, unknown or omitted requires qualified lien review.
florida_final_payment_statusNoFlorida only: did the owner make final payment to the contractor? unknown when not verified. For suppliers not hired by the owner, unknown, omitted, or yes without florida_final_payment_date makes preliminary notice review_required.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.4
    • changedInput schema / properties / florida_final_payment_status / description
      Previous value: -"Florida only: did the owner make final payment to the contractor? Use unknown if unverified; omitted or unknown keeps the notice under review, and yes needs florida_final_payment_date for a notice baseline."New value: +"Florida only: did the owner make final payment to the contractor? unknown when not verified. For suppliers not hired by the owner, unknown, omitted, or yes without florida_final_payment_date makes preliminary notice review_required."
  2. Addedv0.3.1

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), the description discloses that the tool is public, stateless and read-only, needs no key, stores nothing, and sends no notice or files no lien. It also explains the failure mode ('invalid or contradictory facts return an error naming the field before any API call') and that review_required is intentional output, not an error.

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 supported scope are front-loaded, then dependency rules, then return shape, then safety posture — a logical order with no filler sentences. It is dense and re-states a few facts already in the schema (state codes, hired_by), which slightly dilutes conciseness.

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?

There is no output schema, and the description fully compensates by enumerating the returned structure: overall status (calculated or review_required), preliminary_notice and lien_filing each with their own status values, deadline, days_from_now, description, statute source_url, plus critical_warnings, statute_citations, an input echo and a disclaimer. For an 11-parameter tool with complex conditional rules, nothing essential to correct invocation appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is already 100%, the description adds cross-parameter semantics the schema cannot express: last_delivery_date is required when deliveries_complete is true, FL parameters are rejected for other states, each yes/no/unknown answer governs whether a deadline stays under review, and a blanket review flag is not accepted. It also clarifies that a Florida event date is only valid with the matching 'yes' answer and that delivery dates are furnishing, not invoice, dates.

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 description opens with a precise verb+resource+scope: calculating a construction material supplier's preliminary notice and lien filing deadlines from delivery events. An agent immediately knows the domain and output. However, it never distinguishes itself from the sibling calculate_supplier_deadlines_v3, so the reader cannot tell which of the two near-identical tools to pick.

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 states the triggering condition ('for questions that need deadline dates'), names the supported baselines (Florida and Kansas private projects), and pre-empts a misread by explaining that review_required for other states/public projects is a valid result rather than an error. It stops short of naming alternatives such as get_state_lien_guide or the v3 sibling, so it is clear context without explicit routing.

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