MCP-сервер для сроков подачи механикс-лиен и предварительных уведомлений в США. Охватывает все 50 штатов плюс округ Колумбия.
Передайте ему дату счёта и штат — и получите установленные законом сроки. Он оборачивает публичный API LienDeadline, которому для этих эндпоинтов не нужен API-ключ.
Claude Code:
claude mcp add liendeadline -- npx -y liendeadline-mcpClaude Desktop, в claude_desktop_config.json:
{
"mcpServers": {
"liendeadline": { "command": "npx", "args": ["-y", "liendeadline-mcp"] }
}
}Аккаунт и API-ключ не требуются.
Related MCP server: OpenWorkdays
Инструмент | Назначение |
| Сроки подачи предварительного уведомления и механикс-лиен по дате счёта и штату |
| 51 юрисдикция с доступными правилами |
| Базовое правило для одного штата с указанием статута |
| Все доступные руководства по коду и названию |
calculate_lien_deadline с state: "TX", invoice_date: "2026-07-01", project_type: "Commercial":
{
"state": "TX",
"invoice_date": "2026-07-01",
"preliminary_notice_deadline": "2026-09-15",
"lien_deadline": "2026-10-15",
"prelim_deadline_days": 18,
"lien_deadline_days": 48,
"warnings": ["If 15th falls on weekend/holiday, extends to next business day"]
}get_state_lien_guide возвращает правило, лежащее в основе этой даты, включая "statute": "Texas Property Code § 53.056", так что ответ можно проверить, а не принимать на веру.
Два намеренных решения, о которых стоит знать:
Ответы урезаются. Расчётный эндпоинт возвращает один и тот же объект трижды, а руководство по штату имеет размер ~16 КБ, из которых примерно 7 КБ — это отрисованный HTML. И то и другое сокращается до полей, с которыми может работать агент, что сокращает руководство с ~16 000 до ~4 300 символов.
Перенаправьте его с помощью LIENDEADLINE_API_URL, если нужен стейджинг.
Результаты — расчётные оценки на основе опубликованных правил штатов, пересматриваемые ежеквартально. Статуты меняются, а фактические обстоятельства различаются от проекта к проекту. Проверяйте критические сроки с юристом, прежде чем полагаться на них. Это не юридическая фирма, и она не подаёт никаких документов от вашего имени.
MIT
Customer API tool: requires LIENDEADLINE_API_KEY, a dedicated LienDeadline customer key; without one it returns a configuration error and makes no request. Calculates the preliminary notice and lien filing deadlines for one construction invoice from its invoice or delivery date and state. Returns JSON with state, invoice_date, project_type, preliminary_notice_deadline, lien_deadline, waiver_due_date, prelim_deadline_days, lien_deadline_days, warnings such as weekend or holiday rollover, notes and a disclaimer. A date, day count or project_type the API does not return is null; missing warnings is [] and missing notes is an empty string. API denials (401 key, 403 scope, 429 rate limit) return a tool error. Successful calculations consume one API plan unit. Not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Your role on the project, e.g. "supplier", "contractor", "subcontractor". | |
| state | Yes | Two-letter US state code, e.g. "TX", "CA", "DC", from the jurisdictions the customer API supports. | |
| notice_date | No | Date a preliminary notice was actually sent, YYYY-MM-DD, if one was. Omit otherwise. | |
| invoice_date | Yes | Invoice or delivery date in YYYY-MM-DD format; deadlines count from it. | |
| project_type | No | Usually "Commercial" or "Residential". Changes the deadline in some states. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: names the exact credential required, states that no request is made without it, enumerates the 401/403/429 failure modes, and discloses the billing side effect ('successful calculations consume one API plan unit'), which is consistent with readOnlyHint=false and destructiveHint=false. Null/empty-value semantics and the 'not legal advice' disclaimer round out the behavioral picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The credential precondition is front-loaded where it matters most, and the long middle sentence is justified by the absence of an output schema. The enumerated return-field list is dense and could have been tightened, but every clause still carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and five parameters, the description fully compensates: it documents the return field set, null and empty-list conventions, error classes, billing cost, and legal disclaimer. An agent can call this correctly and interpret the response without further documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all five parameters are already documented with formats and examples. The description reinforces that deadlines count from the invoice or delivery date and that project_type/state drive the result, but adds no syntax or validation detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: calculates preliminary notice and lien filing deadlines for one construction invoice, with state and date inputs named. It partially distinguishes itself from the supplier siblings only indirectly, via the 'customer key' requirement, and never names calculate_supplier_deadlines or the state-guide tools as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The auth precondition ('requires LIENDEADLINE_API_KEY... without one it returns a configuration error and makes no request') implicitly tells the agent when this tool will work, but there is no explicit when-to-use vs. when-not, and the closely related siblings (calculate_supplier_deadlines, calculate_supplier_deadlines_v3, get_state_lien_guide) are never referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-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_by | Yes | Who ordered the materials from the supplier: the owner, a contractor or a subcontractor. | |
| project_type | Yes | Private commercial, private residential, or public (public projects always need review). | |
| last_delivery_date | No | Date of the final delivery, YYYY-MM-DD, not earlier than first_delivery_date. Required when deliveries_complete is true. | |
| deliveries_complete | Yes | true 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_date | Yes | Date materials were first delivered (first furnishing), YYYY-MM-DD. Not an invoice date. | |
| kansas_extension_status | No | Kansas 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_date | No | Florida 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_date | No | Florida only: owner final-payment date, YYYY-MM-DD, not earlier than first_delivery_date. Supply only with florida_final_payment_status=yes. | |
| florida_termination_status | No | Florida 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_status | No | 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. |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Project jurisdiction: state or DC. | |
| events | Yes | Discovered event IDs only; missing means unknown. Date only for yes and only where the question permits it. Invoice dates are not furnishing dates. | |
| hired_by | Yes | ||
| project_type | Yes | ||
| rules_source | Yes | Exact rules_source from discovery for this scope. | |
| questions_identity | Yes | Exact questions_identity from discovery. | |
| recurring_notice_facts | No | 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. |
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.
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.
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.
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.
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.
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.
Returns LienDeadline's editorial mechanics lien and preliminary notice guide for one state or DC: rules (rule summary with statute citations), deadline_rows (deadline table), faqs (common questions) and source_url (the guide's web page), roughly 4 KB of JSON. For questions about how a state's lien or notice rules work, why a deadline falls where it does, or which statute applies. An unknown state code returns an error. The guide is an editorial reference, not a calculation: its day counts are summaries, not computed deadlines. Public and read-only; no key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter US state or DC code, e.g. "TX"; case-insensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely new context: the response is roughly 4 KB of JSON, an unknown state code produces an error, and the day counts are editorial summaries rather than computed deadlines — an important trust caveat not conveyed by any structured field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The paragraph is front-loaded with the return shape, then usage conditions, then error behavior, then the editorial disclaimer, then auth. Every sentence carries distinct information (payload fields, use cases, error case, trust caveat, access model) with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description takes on the burden of describing the return shape, and it does so explicitly (rules, deadline_rows, faqs, source_url, ~4 KB). Combined with annotations covering safety and the description covering error behavior and the editorial disclaimer, an agent has everything needed to call and interpret this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the two-letter code format, case-insensitivity and example are already documented, which sets the baseline at 3. The description adds value beyond the schema by specifying the error behavior for an unrecognized state code, giving the agent validation semantics the schema does not encode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: it returns LienDeadline's editorial mechanics lien and preliminary notice guide for one state or DC, and enumerates the exact payload (rules, deadline_rows, faqs, source_url). It implicitly distinguishes itself from the calculation sibling by framing the output as editorial reference material rather than computed deadlines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states clear when-to-use conditions ('For questions about how a state's lien or notice rules work, why a deadline falls where it does, or which statute applies') and notes the failure mode for an unknown state code. It does not explicitly name calculate_supplier_deadlines or list_state_lien_guides as alternatives, so the routing signal is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current supplier-events-v3 scope support, jurisdiction-specific yes/no/unknown event questions, date policies, optional recurring_notice_intake descriptor, sources and exact rule/question identities for a material supplier. Requires a customer key; no delivery dates needed. Discovery does not consume calculation quota. A 503 means the reviewed source is unavailable. Approval of research alone does not activate a scope.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Project jurisdiction: state or DC. | |
| hired_by | Yes | ||
| project_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnly/idempotent/openWorld) by disclosing that a customer key is required, that discovery consumes no calculation quota, that a 503 signals an unavailable reviewed source, and that approving research alone does not activate a scope. These are operationally important behaviors an agent cannot infer from the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads what is returned before the operational caveats, and every sentence carries information. The phrasing is dense and clause-heavy, but nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately enumerates the returned fields (scope support, questions, date policies, recurring_notice_intake descriptor, sources/identities) and covers the auth requirement and a failure mode. Parameter semantics remain thin, which is the only real completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%: hired_by and project_type are enums with no descriptions, and only 'state' is documented. The description's 'jurisdiction-specific' and 'material supplier' hints loosely touch state and persona but leave hired_by's meaning and the commercial/residential/public distinction unexplained, so it does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb+resource: returns supplier-events-v3 scope support, jurisdiction-specific yes/no/unknown event questions, date policies, and rule identities for a material supplier. The scope is narrow enough that an agent can separate it from calculate_supplier_deadlines without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates the discovery use case clearly ('no delivery dates needed', 'does not consume calculation quota'), which steers toward this tool over the calculate_* siblings. It stops short of explicitly naming an alternative or stating a when-not-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists every published state lien guide in one response, without pagination: count plus state_code, title and slug for all 50 states and DC, in alphabetical order by state name. It lists editorial guides only and does not indicate which states have calculated deadlines. Takes no parameters. Public and read-only; no key needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), but the description adds real value beyond them: no pagination, alphabetical ordering, inclusion of a count, editorial-only scope, and explicit 'public; no key needed' auth disclosure. It does not cover failure modes, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and scope, and every sentence carries information (ordering, count, exclusions, auth). Minor overlap between 'Public and read-only' and the readOnlyHint annotation is the only redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description correctly compensates by enumerating the return shape (count plus state_code, title, slug) and the ordering. For a zero-parameter read tool this is complete enough to call blind.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline is 4. The description correctly states 'Takes no parameters', which matches the empty schema and prevents the agent from hunting for filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (lists) and resource (every published state lien guide) with explicit scope: all 50 states and DC, in one response, no pagination. The plural 'every ... guide' plus the returned fields distinguishes it from the singular sibling get_state_lien_guide without needing to open either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: 'does not indicate which states have calculated deadlines' hints that calculate_supplier_deadlines is the tool for deadline data, but no sibling is named and no explicit when-to-use/when-not rule is given. Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Customer API tool: requires LIENDEADLINE_API_KEY with the states:read scope. Returns count and the two-letter codes of the jurisdictions the customer invoice calculation accepts. It does not list editorial guides or the states with reviewed supplier baselines. Takes no parameters. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely new behavior: the LIENDEADLINE_API_KEY requirement and the states:read scope, plus the return shape (count + codes), which the annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the auth requirement and return content, then exclusions, then no-params. Efficient overall, though 'Read-only' is mild redundancy against the readOnlyHint annotation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by describing the return (count and two-letter codes), the auth prerequisite, and the exclusions. Nothing an agent needs to call this zero-parameter read tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing to document; the description correctly states 'Takes no parameters.' Baseline 4 applies since no param semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: returns the count and two-letter codes of jurisdictions the customer invoice calculation accepts. It actively distinguishes itself from the sibling list_state_lien_guides by stating it does not list editorial guides or reviewed-baseline states, so an agent can tell them apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Frames usage by identifying the audience/tool family ('Customer API tool') and the required key/scope, and rules out the guide-oriented sibling use case. It stops short of naming the alternative tool explicitly, so the guidance is clear but not fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.5.5calculate_supplier_deadlines_v31 field changedInput schema / properties / recurring_notice_factsAdded 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"
+ }
+ ]
+}v0.5.4calculate_lien_deadline1 field changedInput schema / properties / state / descriptionPrevious value: -"Two-letter US state code, e.g. \"TX\", \"CA\", \"DC\"; one of the codes list_supported_states returns."New value: +"Two-letter US state code, e.g. \"TX\", \"CA\", \"DC\", from the jurisdictions the customer API supports."calculate_supplier_deadlines1 field changedInput schema / properties / florida_final_payment_status / descriptionPrevious 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."calculate_supplier_deadlines_v3get_supplier_questionsv0.3.1calculate_lien_deadline4 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / invoice_date / descriptionPrevious value: -"Invoice or delivery date in YYYY-MM-DD format."New value: +"Invoice or delivery date in YYYY-MM-DD format; deadlines count from it."Input schema / properties / notice_date / descriptionPrevious value: -"Date a preliminary notice was actually sent, YYYY-MM-DD, if one was."New value: +"Date a preliminary notice was actually sent, YYYY-MM-DD, if one was. Omit otherwise."Input schema / properties / state / descriptionPrevious value: -"Two-letter US state code, e.g. \"TX\", \"CA\", \"DC\"."New value: +"Two-letter US state code, e.g. \"TX\", \"CA\", \"DC\"; one of the codes list_supported_states returns."calculate_supplier_deadlinesget_state_lien_guide2 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / state / descriptionPrevious value: -"Two-letter US state code, e.g. \"TX\"."New value: +"Two-letter US state or DC code, e.g. \"TX\"; case-insensitive."v0.1.0calculate_lien_deadlineget_state_lien_guidelist_state_lien_guideslist_supported_statesScored across 7 tools
The descriptions are unusually explicit about boundaries (editorial vs. customer API, invoice vs. delivery-event inputs), which saves the public-read trio. However, calculate_supplier_deadlines (events-v2) and calculate_supplier_deadlines_v3 (events-v3) clearly overlap, and nothing in the tool set says when to prefer one, so an agent can easily pick the stale version. list_state_lien_guides vs. list_supported_states is also a subtle list-vs-list pair that only the long descriptions disambiguate.
Names follow a consistent verb_noun snake_case pattern (get_/list_/calculate_), which is easy to scan. The deviations are minor: a version suffix on only one tool (calculate_supplier_deadlines_v3, whose unversioned sibling exists) and a slightly vague 'get_supplier_questions' next to the more specific 'get_state_lien_guide'.
Seven tools is a well-scoped surface for a reference-plus-calculation service. The only waste is the parallel v2/v3 supplier calculation pair, which arguably should have been consolidated, but overall each tool maps to a real operation.
The surface covers reference lookup (single and bulk), supported-jurisdiction discovery, invoice-based calculation, and supplier event-based calculation plus rule/question discovery, which is a coherent lifecycle for a deadline service. Gaps are modest: no event-based path for non-supplier parties (owner/GC/subcontractor), and no way to retrieve or re-check a previously computed scenario.
Computes California state court deadlines and cites the code section behind every date. No API key.
Compute deadlines in business days with public holidays (200+ countries). $0.002/call.
Zero-signup business-day date-math API: add days, count days between dates, is-business-day.
Deterministic date arithmetic with auditable receipts: business days, due dates, holidays.
