Skip to main content
Glama

LienDeadline

by io.github.LienDeadline
OverviewDiscussionsAdmin

Calculate supplier notice and lien deadlines

calculate_supplier_deadlines

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. Requires a customer key and consumes one plan calculation unit. No project is saved, notice sent or lien filed. Not legal advice.

Input 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 changed
    • changedInput schema / properties / florida_final_payment_status / description
      Previous value: -"Florida only: did the owner make final payment to the contractor? unknown when not verified; 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. Changed1 schema field changed
    • 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; omitted or unknown keeps the notice under review, and yes needs florida_final_payment_date for a notice baseline."
  3. First observed

TDQS

A3.6/5.0
Behavior4/5

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

With annotations declaring write-ish flags (readOnlyHint false, idempotent false, openWorld true), the description adds real operational context: it mutates nothing, requires a customer key, consumes one calculation unit, and performs no API call on invalid input – which explains the non-read-only hints. It also clarifies that review_required is a valid result, 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.

Conciseness2/5

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

It is a dense wall of run-on sentences covering conditional rules, return shape, billing, and disclaimers with little front-loading. The key routing fact (deadline calculation) is buried and the structure is hard to parse quickly.

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 tool with no output schema, it covers the return shape (statuses, deadline fields, warnings, citations, echo, disclaimer), auth/billing, and the state-specific conditional rules. Remaining gaps are minor, such as versioning relative to _v3.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents each parameter and default 3 would be acceptable. The description goes beyond by stating conditional dependencies (last_delivery_date required when deliveries_complete is true; FL/KS-specific fields rejected elsewhere; date accepted only with matching yes), which the schema does not express.

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 states a specific verb (calculates) and resource (supplier preliminary notice and lien filing deadlines) and names the delivery events source. It does not differentiate itself from the sibling calculate_supplier_deadlines_v3, so it falls short of 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 Guidelines3/5

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

It implies usage for deadline-date questions and states coverage limits (FL/KS private only, others return review_required), which is close to when-to-use, but never explicitly says when to choose this over calculate_supplier_deadlines_v3 or the get_* guide tools.

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

All LienDeadline toolsInspect
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