LienDeadline vs Swiss Case Law
A side-by-side look at the LienDeadline and Swiss Case Law MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose LienDeadline for legal work; choose Swiss Case Law for legal. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose LienDeadline when
- You need dedicated capabilities in the Legal domain.
- You want tools like
calculate_supplier_deadlines, get_supplier_questions, calculate_supplier_deadlines_v3.
Choose Swiss Case Law when
- You need dedicated capabilities in the Legal domain.
- Its auth model fits you: No auth required.
- You want tools like
search, fetch, search_decisions.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Legal | Legal |
| Quality signal | 57/100 · Good | 59/100 · Good |
| Install command | Not confirmed yet | Not confirmed yet |
| Transport | — | — |
| Auth | Not declared | No auth required |
| Pricing | Not declared | Free |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 1 | 75 |
| Directory activity | 1 views 0 installs 0 upvotes | 3 views 0 installs 0 upvotes |
| Tools | 7 | 42 |
| Full listing | View LienDeadline | View Swiss Case Law |
Tools & capabilities
LienDeadline tools 7
calculate_supplier_deadlinesCalculates 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.get_supplier_questionsReturns 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.calculate_supplier_deadlines_v3Evaluates 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.calculate_lien_deadlineCustomer 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.list_supported_statesCustomer 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.get_state_lien_guideReturns 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.list_state_lien_guidesLists 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.
Swiss Case Law tools 42
searchMinimal search tool following the deep-research search/fetch convention. Returns a ranked list of Swiss court decisions matching a query, each as {id, title, url, snippet}. Pair with `fetch` to retrieve a decision's full text by id. General (non-deep-research) clients should prefer `search_decisions`, which exposes filters (court, canton, date, language) and richer metadata.fetchMinimal fetch tool following the deep-research search/fetch convention. Fetches one Swiss decision's full text by id, returning {id, title, text, url, metadata}. The id comes from a `search` result (a decision_id like bger_6B_1234_2025; a docket number or BGE reference also resolves). General clients should prefer `get_decision`.search_decisionsUse this tool to find COURT DECISIONS (Rechtsprechung): 1,050,000+ Swiss federal and cantonal decisions plus ~2,800 ECtHR decisions concerning Switzerland. Full-text search with keywords, phrases (in quotes), Boolean operators (AND, OR, NOT), prefix matching (word*), docket lookup (6B_1234/2025) and column-scoped search (regeste:keyword). Filter by court, canton, language, date range, chamber. Results are relevance-ranked and enriched with citation counts, statute references and is_leading_case. Use offset to page. Most recent decisions: empty query + sort='date_desc' + court filter. Newly PUBLISHED decisions (alerts): published_from + sort='published_desc'. Not for statutes (search_laws), commentary (search_scholarship), or administrative guidance (search_practice).get_decisionFetch a single court decision with full text. Look up by decision_id (e.g., bger_6B_1234_2025), docket number (e.g., 6B_1234/2025), or partial match. Full text is truncated at 200,000 characters for very long decisions. Set full_text=false to get only metadata and regeste.get_decisionsUse this tool to fetch SEVERAL decisions at once (1-10 ids) instead of calling get_decision repeatedly. Same data per decision — canonical citation strings, Markdown link, Regeste, metadata — in ONE call. Prefer this whenever you are about to read more than one decision from a search result: it is the difference between one tool call and ten, which matters because clients cap tool calls per turn. full_text defaults to FALSE here (unlike get_decision) because ten full judgments exceed connector response limits; set it true only for a short id list, and each text is excerpted with the cut disclosed. Ids not found are reported individually — the rest of the batch still returns.list_courtsList all available courts with decision counts, date ranges, and language coverage. Use this to discover what data is available.get_statisticsGet aggregate statistics about the dataset. Optionally filter by court, canton, or year.find_citationsGiven a decision_id, show what it cites and what cites it. Uses the reference graph database with 9.65M citation edges. Returns resolved citations with confidence scores and unresolved references.find_appeal_chainTrace the appeal chain (Instanzenzug) for a decision. Shows prior instances (lower courts) and subsequent instances (appeals to higher courts). Reconstructs the full procedural path, e.g. Bezirksgericht → Obergericht → Bundesgericht. Uses the is_prior_instance flag from decision headers.find_leading_casesFind the most-cited decisions for a topic or statute. Authority ranking based on citation graph; a free-text topic ranks decisions whose regeste carries the query terms first (`regeste_match`: share of terms found, null without a regeste). Filter by statute (law_code + article), topic query, court, and date range. Top-3 results auto-attach a `pinpoint` field {e_number, matched_sentence, confidence, url, score, source} anchoring the most-relevant Erwägung (surface it as 'E. <e_number>' when confidence is high or medium). Each result also carries citation_string_{de,fr,it} + canonical_url + is_leading_case + citation_count for ready-to-quote Swiss-format citations. A statute reference inside `query` ("Art. 29 BV") is used as the statute filter. When the query excludes every candidate, the page is relaxed to ranked OR and flagged `filters_relaxed: true` with a `note` — nearest neighbours, not on-point authority.analyze_legal_trendYear-by-year decision counts showing jurisprudence evolution. Use with a statute reference (law_code + article), a text query, or both. Returns yearly counts with visual bar chart.draft_mock_decisionBuild a research-only mock decision outline from user facts. Combines relevant Swiss case law retrieval with statute references. If possible, enriches statutes with Fedlex text excerpts. IMPORTANT: The tool may return clarification questions (high/medium priority). High-priority clarifications must be answered (via the clarifications parameter) before the tool will provide a conclusion. Call again with clarifications to get the full analysis.- +30 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
LienDeadline
No confirmed install command for LienDeadline yet — follow the setup steps linked from its listing page rather than a guessed package name.
Swiss Case Law
No confirmed install command for Swiss Case Law yet — follow the setup steps linked from its listing page rather than a guessed package name.
Frequently asked questions
LienDeadline is categorized under Legal and uses an install path we have not confirmed yet. Swiss Case Law belongs to Legal and uses an install path we have not confirmed yet. Pick LienDeadline for legal work and Swiss Case Law for legal.
Neither server has a confirmed install command yet, so we don't publish a guessed config. Follow each project's own setup instructions, linked from its listing page.
LienDeadline has no declared pricing — check the project's own site. Swiss Case Law is listed as free. Auth: no auth required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add liendeadline and swiss-case-law as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, LienDeadline has a quality signal of 57/100 (Good) with 1 views, 0 installs and 1 GitHub stars. Swiss Case Law has 59/100 (Good) with 3 views, 0 installs and 75 GitHub stars.