Skip to main content
Glama

LienDeadline

by io.github.LienDeadline
OverviewDiscussionsAdmin

Calculate from discovered supplier facts

calculate_supplier_deadlines_v3

Evaluates supplier-events-v3 project facts against the exact discovered rule and question identities. Returns independent notice and lien outcomes with sources and an exact nested input echo. When RI discovery asks ri_mailed_within_200_days after ri_mailed=yes, confirm whether mailing occurred within 200 days of first delivery. No, Unknown or omitted confirmation requires review; recording alone does not establish a 40-day target. Only calculated outcomes contain calculated deadline dates. Report every candidate_deadlines entry with its ID, date and sources under the API explanation. For NH review fallbacks, first_furnishing is a conservative checkpoint and final_furnishing is informational pending contract grouping and qualifying completion; passing the first checkpoint does not itself establish expiry. A calculated contract_completion outcome uses only the returned deadline, without substituting the first checkpoint or recomputing a date. Review candidates do not establish filing deadlines, completion or scheduled reminders. An optional preliminary_notice.notice_duties collection contains independently required named notices, each with its own calculated date, explanation and sources; the legacy preliminary date is only their earliest summary. Report every validated duty without inferring duties from candidates or treating one notice as satisfying all duties. A separate optional preliminary_notice.planned_notice_targets collection contains qualified intent planning targets with their target dates, assumed filing dates, full ten- or thirty-day intervals, explanations and sources. Planning targets do not establish statutory expirations, actual filing, notice completion or scheduled notifications. An optional verified action_by is a Conservative action date planning target under qualified review; the statutory deadline and countdown remain unresolved, with explanation, sources and warnings. Optional recurring_notice_facts supplies actual Tennessee furnished months or New Hampshire account records. Tennessee recurring_notice_periods cover entered periods only, including paid and unknown states; known unpaid duties remain independent. New Hampshire recurring_notice_checkpoints are advisory check-ins with unresolved legal status, not legal deadlines, service, completion or scheduled reminders; they do not reset earlier gaps. Never infer intervening months or blanket completion. Stale identities return 409, unavailable reviewed sources return 503. Requires a customer key and consumes one plan calculation unit. No project is saved, notice sent or lien filed.

Input Schema

NameRequiredDescriptionDefault
stateYesProject jurisdiction: state or DC.
eventsYesDiscovered event IDs only; missing means unknown. Date only for yes and only where the question permits it. Invoice dates are not furnishing dates.
hired_byYes
project_typeYes
rules_sourceYesExact rules_source from discovery for this scope.
questions_identityYesExact questions_identity from discovery.
recurring_notice_factsNoOnly when discovery returns a matching recurring_notice_intake descriptor. Actual recurring facts only: Tennessee entered furnished months with unpaid and retainage-only answers, or New Hampshire actual written accounts with coverage and supplied dates. Omission retains legacy behavior; unknown answers require review. Do not infer intervening months or actual notice from a plan. NH actual owner notice belongs in the discovered nh_owner_notice_given event.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / recurring_notice_facts
      Added value: +{
+  "description": "Only when discovery returns a matching recurring_notice_intake descriptor. Actual recurring facts only: Tennessee entered furnished months with unpaid and retainage-only answers, or New Hampshire actual written accounts with coverage and supplied dates. Omission retains legacy behavior; unknown answers require review. Do not infer intervening months or actual notice from a plan. NH actual owner notice belongs in the discovered nh_owner_notice_given event.",
+  "oneOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "kind": {
+          "const": "tn_monthly_nonpayment",
+          "type": "string"
+        },
+        "months": {
+          "items": {
+            "additionalProperties": false,
+            "properties": {
+              "month": {
+                "pattern": "^\\d{4}-(0[1-9]|1[0-2])$",
+                "type": "string"
+              },
+              "retainage_only": {
+                "enum": [
+                  "yes",
+                  "no",
+                  "unknown"
+                ],
+                "type": "string"
+              },
+              "unpaid": {
+                "enum": [
+                  "yes",
+                  "no",
+                  "unknown"
+                ],
+                "type": "string"
+              }
+            },
+            "required": [
+              "month",
+              "unpaid",
+              "retainage_only"
+            ],
+            "type": "object"
+          },
+          "maxItems": 16,
+          "minItems": 1,
+          "type": "array"
+        },
+        "version": {
+          "const": "supplier-recurring-facts-v1",
+          "type": "string"
+        }
+      },
+      "required": [
+        "version",
+        "kind",
+        "months"
+      ],
+      "type": "object"
+    },
+    {
+      "additionalProperties": false,
+      "properties": {
+        "accounts": {
+          "items": {
+            "additionalProperties": false,
+            "properties": {
+              "covered_through": {
+                "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+                "type": "string"
+              },
+              "id": {
+                "pattern": "^[a-z][a-z0-9_]{0,79}$",
+                "type": "string"
+              },
+              "supplied_date": {
+                "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+                "type": "string"
+              }
+            },
+            "required": [
+              "id",
+              "covered_through",
+              "supplied_date"
+            ],
+            "type": "object"
+          },
+          "maxItems": 16,
+          "type": "array"
+        },
+        "kind": {
+          "const": "nh_written_account",
+          "type": "string"
+        },
+        "version": {
+          "const": "supplier-recurring-facts-v1",
+          "type": "string"
+        }
+      },
+      "required": [
+        "version",
+        "kind",
+        "accounts"
+      ],
+      "type": "object"
+    }
+  ]
+}
  2. Added

TDQS

A3.7/5.0
Behavior4/5

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

With annotations declaring readOnlyHint=false, openWorldHint=true and non-idempotency, the description adds real operational context: stale identities return 409, unavailable reviewed sources return 503, a customer key is required, one plan calculation unit is consumed, and no project is saved, notice sent, or lien filed. It does not contradict the non-readOnly hint (credit consumption is a side effect), and it clarifies the safety profile beyond the bare annotations.

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

Conciseness3/5

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

Front-loaded with purpose and outcome, but the body is a dense run-on of overlapping negations ('do not establish filing deadlines', 'do not establish statutory expirations', 'not legal deadlines, service, completion or scheduled reminders') that repeat the same disclaimer across each collection. Much of it earns its place given the missing output schema, but it is not tight.

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?

No output schema exists, so the description must carry return semantics, and it does: it names candidate_deadlines, notice_duties, planned_notice_targets, action_by, Tennessee recurring_notice_periods and NH recurring_notice_checkpoints, explains what each does and does not establish, and covers auth, metering and error codes. For a 7-parameter, nested, high-complexity tool this is complete.

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 71% and the schema itself documents state, events, rules_source, questions_identity and the recurring_notice_facts oneOf in detail. The prose adds meaning for recurring_notice_facts and for how events identities must match discovery, but adds little for the enum/required parameters. Baseline 3 is appropriate.

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?

States a specific verb and resource: evaluates discovered supplier-events-v3 facts against rule/question identities and returns independent notice and lien outcomes. Clear enough that an agent knows what it produces, but it never distinguishes itself from the sibling calculate_supplier_deadlines (presumably the older version), so version selection is left to inference.

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?

Gives conditional reasoning guidance (e.g. 'When RI discovery asks ri_mailed_within_200_days...') and gates recurring_notice_facts ('Only when discovery returns a matching recurring_notice_intake descriptor'), but never says when an agent should call this tool versus calculate_supplier_deadlines or get_supplier_questions. Usage is implied by the workflow, not stated.

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