"Firefly III" matching MCP tools:

• eu_ai_act_complianceA

  systemprompt.io reportsA

  Generate a structured EU AI Act compliance report from a system description, model card, and data-flow document. Nothing is silently optional: system_description is always required (min 50 chars); model_card and data_flows each accept substantive content (min 50 chars) or the exact string 'declined' to explicitly opt out; and exactly one of decision_tree_answers (from the free risk classifier, becomes binding evidence) or skip_decision_tree: true must be sent. All of this is validated free of charge before payment. The deterministic Annex III decision tree runs on every call: user-supplied answers are binding, otherwise answers are AI-derived and recorded as such. The tree classification, article citations, obligations, and evidence checklist are returned verbatim in the report JSON, together with exact enforcement-timeline dates and the matched Annex III area from the curated dataset. A staged AI workflow then produces an article-by-article obligation gap analysis, a required-documentation checklist mapped to Annex IV, and a prioritised remediation plan. The report includes a deterministic input_coverage grade (full, partial, or description_only) computed from what was supplied versus declined, the full AI classification with rationale, a programmatic reconciliation check between the tree and the AI risk tier, and a citation audit that flags any implausible article references. Returns markdown plus structured JSON. Every paid call also generates a branded PDF report and returns its download link (valid 72 hours). Price: $1.50 per call, payable by card (Stripe checkout link in the 402 response) or USDC on Base (x402). Full documentation, inputs, and pricing: https://systemprompt.io/tools/eu-ai-act-compliance-report/ — more governance tools and reports at https://systemprompt.io/mcp

  ConnectorNo auth

• adr_exemption_calculatorA

  FreightUtils MCP ServerA

  Calculate ADR 1.1.3.6 "small load" exemption points for a dangerous-goods load. Each substance's transport category (0-4) sets a points multiplier (category 1 x50, 2 x3, 3 x1, 4 x0; the nine ADR 1.1.3.6.3 note-a entries UN 0081/0082/0084/0241/0331/0332/0482/1005/1017 are x20 with a 50 kg per-transport-unit cap); points = quantity x multiplier, and a load totalling 1,000 points or less qualifies for reduced ADR requirements. Transport category 0 substances can NEVER use this exemption — has_category_zero flags them. Provide un_number + quantity for a single substance, or items[] for a mixed load (items takes precedence if both are given). Quantities are in kg or litres per the substance's ADR unit. Multi-variant UNs: a UN number with more than one ADR Table A row (packing group / concentration variant — e.g. UN 1789 PG II vs PG III have different transport categories) needs packing_group (I|II|III) or variant_index (from adr_lookup) to pin one row. A packing_group that still leaves several rows is enough when those rows agree on class, transport category, scope and the 1.1.3.6.3 counted dimension (UN 1790 PG I: two concentration bands, both category 1) — the verdict is returned with items[].equivalent_variants + variant_note naming the rows it holds for; only when the rows DISAGREE (UN 2215 PG III: MOLTEN is category 0, the solid category 3) does it still ask for variant_index, and candidates[] then lists only that packing group's rows. With no disambiguator at all: a single-line call, or a load where EVERY line is ambiguous, returns blocking_errors[AMBIGUOUS_UN_VARIANT] + human_review_required + candidates[] (each candidate's item_index, un_number, variant_index, packing_group, proper_shipping_name, transport_category, multiplier) and NO verdict; a MIXED load withholds only the ambiguous line (items[].withheld true, points null, row fields null) while every other line keeps its points; total_points is null (1.1.3.6.4 sums every line, one term is unknown) and exempt is null UNLESS the resolved lines alone already disqualify the load — a CARRIAGE PROHIBITED entry, a category 0 entry, a per-substance maximum exceeded, or a partial sum already over 1,000 — in which case exempt is false with the ladder message (and carriage_prohibited true where that is the reason), because no packing group can undo those. warnings state the resolved lines' partial sum, candidates[] carry expected_unit (the 1.1.3.6.3 counted dimension — the only difference for UN 3375 PG II, liquid in L vs solid in kg), and the envelope carries human_review_required + candidates[] plus one AMBIGUOUS_UN_VARIANT warning per withheld line. Never a silently guessed row. Single-row UNs are unchanged. Scope verdicts: Table A rows listed "NOT SUBJECT TO ADR" or "CARRIAGE PROHIBITED" never enter the points math. An all-not-subject load (e.g. UN 1845 dry ice) returns not_subject_to_adr true with a dedicated message ("Not subject to ADR (road). Section 5.5.3 applies: ...") and, for dry ice, conditions[] quoting the ADR 2025 section 5.5.3 requirements verbatim (ventilation, package marking, warning mark, documentation, training). A load containing a CARRIAGE PROHIBITED entry returns exempt false with carriage_prohibited true. In a mixed load, not-subject items are excluded from the points and the exclusion is stated in warnings. Behavior: deterministic points arithmetic over ADR 2025 reference data; a UN that cannot be found returns blocking_errors (NOT_FOUND); exempt is the overall verdict. Rate-limited (anonymous use: 25 requests/day per IP): a 429 error body carries retry_after_seconds and a Retry-After header — back off and retry, or call get_subscribe_link for higher limits. Returns: items[] (each with packing_group, variant_index, transport_category, multiplier, points, quantity_unit/quantity_basis/expected_unit when a unit or basis was declared, scope flags where applicable, withheld + ambiguity_reason on an unpinned multi-variant line, and equivalent_variants + variant_note when a packing group resolved by equivalence), total_points (NULL when no verdict was reached), threshold (1000), exempt (NULL when no verdict was reached — never false as a stand-in), has_category_zero, has_quantity_exceedance, warnings, message, human_review_required + candidates[] when any line is withheld, and — on scope verdicts — not_subject_to_adr/conditions_ref/conditions[]/carriage_prohibited under result — or, when every line is ambiguous, human_review_required + candidates[] with blocking_errors, plus confidence, _source and citation (the FreightUtils v1 response envelope). Limitations: a deterministic calculation over reference data, not legal advice — even exempt loads keep core duties (packaging, marking, documentation), and mixed-packing rules still apply; verify against the current UNECE ADR text. Related: adr_lookup (per-substance data incl. transport category + variant_index), adr_lq_eq_check (the LQ/EQ relief routes instead of 1.1.3.6).

  ConnectorNo auth

• adr_lq_eq_checkA

  FreightUtils MCP ServerA

  Check whether dangerous goods qualify for ADR Limited Quantity (LQ, ADR 3.4) or Excepted Quantity (EQ, ADR 3.5) relief. LQ compares each item's per-inner-packaging quantity against that substance's LQ maximum; EQ resolves the substance's E-code (E0-E5) and checks the per-inner limit, plus the per-outer limit when inner_packaging_qty is given. Provide mode ("lq" or "eq") and 1-20 items, each with un_number, quantity and unit — ml or L for liquids, g or kg for solids; quantity is per INNER packaging, not the whole load. Unit families: column (7a) states the limit in ONE dimension — a mass for some entries, a volume for others — and ADR supplies no density, so a mass quantity against a volume limit (or the reverse) CANNOT be compared. Those items return status 'inconclusive' with the dimension named, never a pass or a fail, and a batch holding any inconclusive item never reads overall_status 'qualifies'. Send the quantity in the unit given by lq_limit_unit to get a verdict. Multi-variant UNs: a UN number with more than one ADR Table A row (packing group / concentration variant — e.g. UN 1789 PG II LQ 1 L vs PG III LQ 5 L) needs packing_group (I|II|III) or variant_index (from adr_lookup) on that item to pin one row. A packing_group that still leaves several rows is enough when those rows agree on class, column (7a), column (7b) and scope (UN 1790 PG I: two concentration bands, both LQ 0 / E0) — the item is answered with equivalent_variants + variant_note naming the rows it holds for; only when the rows DISAGREE does it still ask for variant_index, and candidates[] then lists only that packing group's rows. With no disambiguator at all: a single-item call, or a batch where EVERY item is ambiguous, returns blocking_errors[AMBIGUOUS_UN_VARIANT] + human_review_required + candidates[] (each candidate's item_index, un_number, variant_index, packing_group, proper_shipping_name, limited_quantity, excepted_quantity) and NO verdict; a MIXED batch withholds only the ambiguous item (status 'withheld', withheld true, row fields null) while the other items are answered, overall_status never reads 'qualifies' while an item is withheld, summary carries withheld, and the envelope carries human_review_required + candidates[] plus one AMBIGUOUS_UN_VARIANT warning per withheld item. Never a silently checked packing group. Single-row UNs are unchanged. Behavior: deterministic reference check; each item gets a status and reason (an LQ value of "0" or code E0 means the relief is not permitted for that substance), with overall_status and summary counts across the batch. Table A rows listed "NOT SUBJECT TO ADR" (e.g. UN 1845 dry ice) get item status not_subject — outside ADR scope, neither a pass nor a fail — and an all-not-subject batch returns overall_status not_applicable; "CARRIAGE PROHIBITED" rows are not_permitted with the prohibition stated in reason. Rate-limited (anonymous use: 25 requests/day per IP): a 429 error body carries retry_after_seconds and a Retry-After header — back off and retry, or call get_subscribe_link for higher limits. Returns: mode, overall_status (qualifies | does_not_qualify | partial | not_applicable | inconclusive), items[] (un_number, variant_index, substance, class, packing_group, lq_limit or eq_code, quantity_entered, status — within_limit | exceeds_limit | not_permitted | not_subject | inconclusive | withheld — reason, scope flags where applicable, withheld + ambiguity_reason on a withheld item, and equivalent_variants + variant_note when a packing group resolved by equivalence), summary {total_items, qualifying, exceeding, not_permitted, not_subject?, inconclusive?, withheld?}, the ADR chapter references, and human_review_required + candidates[] when any item is withheld — all under result — or, when every item is ambiguous, human_review_required + candidates[] with blocking_errors, plus confidence, _source and citation (the FreightUtils v1 response envelope). Limitations: a quantity-threshold check only — LQ/EQ relief also requires packaging, marking and documentation conformity that this tool does not assess; not legal advice, verify against the current UNECE ADR text. Related: adr_lookup (the per-substance LQ/EQ values + variant_index), adr_exemption_calculator (the 1.1.3.6 load-points route instead).

  ConnectorNo auth

• upload_trial_balanceA

  schedule-iiiA

  Stage a Trial Balance spreadsheet (xlsx or csv, max 4 MB) for an entity by INLINING its bytes as base64. This path is ONLY for programmatic callers (a script, Claude Code, an automation) that already have the raw file on disk. If a HUMAN has the file — e.g. they attached it to this chat — do NOT use this tool and do NOT base64-encode the file: call create_upload_link instead and give them the link to upload it in their browser. File size does not change this: even a small attached file goes through create_upload_link — inlining a human-supplied file is unreliable and its bytes routinely truncate. Even for a file you hold on disk, prefer create_upload_link once the file is larger than about 10 KB: base64 through a model context mutates a token often enough that the damage lands as a PLAUSIBLE trial balance, not as an obvious error. VERIFY THE HASH BEFORE YOU CONFIRM ANYTHING: this tool returns received_file_hash, the sha256 of the bytes the server actually received. Compute the sha256 of the file on your disk and compare the two. If they differ, the bytes changed in transit — do NOT call confirm_column_mapping on this session; re-send the file with create_upload_link instead. A mismatched file can still parse cleanly and still show sensible columns, so the hash is the only reliable check. Returns the upload session with detected columns and mapping SUGGESTIONS — nothing is ingested yet. Next: verify received_file_hash, then review the suggested column mapping with your user, then call confirm_column_mapping.

  ConnectorNo auth

• get_tb_rowsA

  schedule-iiiA

  Read the SOURCE DATA behind a statement: the trial-balance rows (account name, debit, credit) as landed for a period, BEFORE grouping — the pre-statement numbers, not statement figures. PREFER FILTERS over fetching everything: name_patterns (e.g. ['cash','bank','od']), side ('debit'/'credit' by net balance), and min_abs_balance return a small exact subset with its own debit/credit totals — e.g. wrong-side cash accounts = name_patterns ['cash','bank'] + side 'credit'. Paginated (page 1-based; page_size default 50, max 500). These are the CURRENT live rows: statement figures are frozen at a generated version, so if the trial balance was re-uploaded after a version was generated, these rows may not tie to that version (the response `note` says so). Amounts are decimal strings in rupees. Figures are Datavrn's deterministic engine output; interpretation is your assistant's.

  ConnectorNo auth

• get_setup_statusA

  schedule-iiiA

  Answer "how do I get started?", "what do I do next?", or help a user who seems lost setting up. Returns where they are in the journey from an empty organization to a finished Schedule III statement, and the ONE next step to take. Call it WITHOUT client_id first (the organization view): it lists the entities this credential can see, or — if there are none — the step to create the first one. Then call it again WITH one entity’s client_id for that entity’s full step-by-step path (upload trial balance → confirm groupings → capture figures → generate → download). Each step has a status (done / next / todo / blocked / web_only) and either the exact tool to call or a web-app link. NARRATE ONE STEP AT A TIME — walk the user through the single `next` step; do not dump the whole list unprompted. Steps marked web_only are done in the Datavrn web app and need a login — never claim you can do them yourself. This tool reports STATUS only (counts, names, what is done) — it never returns a figure or balance; read those with get_statement_figures once a statement is generated.

  ConnectorNo auth

• finalise_statementA

  schedule-iiiA

  Seal a statement version as Datavrn’s permanent client copy, recorded as authorised by the member you name. THIS IS NOT APPROVAL OR ADOPTION OF THE FINANCIAL STATEMENTS AND IT IS NOT A SIGNATURE. It does not discharge section 134(1) for a company or section 34(3) for an LLP. THERE IS NO UNDO. A change afterwards means generating a new version and finalising that one; the version you seal here stays sealed. Call get_finalise_readiness first, show your user every gate and every warning it returns, get their explicit go-ahead, and only then send the confirm_token it gave you together with the acknowledgements. Never acknowledge a warning your user has not seen, and never write the acceptance reason yourself — it is their professional judgment in their own words. Datavrn will refuse if anything about the statement changed after you read the state, and nothing will be finalised. If the response comes back with reused set to true, a finalisation of this same version was already under way: nothing new was done and your approval was not used. Do not call finalise_statement again — the status field says where that finalisation is (queued, running, or paused, which means it hit a temporary problem and Datavrn will retry it on its own). Poll get_job with the job_id and tell your user what it says.

  Connector

  Destructive

  No auth

• assert_previous_year_no_activityA

  schedule-iiiA

  Record your user’s assertion that the previous year genuinely had no activity, so this statement’s all-nil previous-year Profit and Loss is a fact rather than a closing-entry artefact. This clears Datavrn’s refusal to finalise it. THIS IS A PROFESSIONAL ASSERTION ABOUT A CLIENT’S ACCOUNTS, RECORDED IN THE NAMED MEMBER’S NAME AND KEPT WITH THE STATEMENT. Only send it when your user has told you, in their own words, that the previous year had no activity — a dormant entity is the case it is for. NEVER write the reason yourself and never paraphrase it into something firmer: send what they said. If they are unsure, or if the previous year DID trade and the trial balance was simply taken after closing, do not call this — the other two remedies in get_comparative_source_state are the correct ones. Call get_comparative_source_state first, read out the finding, get their explicit go-ahead, and send the confirm_token it returned. Datavrn refuses if the previous-year figures changed after you read the state, and nothing is recorded. It can be withdrawn in Datavrn if it was recorded in error; withdrawing restores the refusal.

  ConnectorNo auth

• get_parcel_land_classA

  Cenogram - Polish Real Estate DataA

  The official land-use and soil-quality classification recorded for one land parcel, and what it implies for taking the land out of agricultural use. Returns the land-use categories and the soil-quality grades entered for the parcel, whether any of those grades is in the protected I-III range, whether the parcel lies inside a city's administrative boundary (which changes the rule that applies), and a note on the re-designation consequences with the date the legal state behind it was verified. Use it when the question is specifically about the classification or about re-designating farmland. For anything else about the parcel — price history, flood risk, zoning, buildings, permits, surroundings, transport — call get_parcel_report instead: it is one call at a flat price and includes this same classification as one of its sections. Address it by a full cadastral id in the natural '/' form ('142907_2.0014.342/5'), the URL-safe '-' form, or the internal UUID from a search or resolve result. The categories and grades come back as SETS. The source records no area for any of them, so the answer can never say which category prevails on the parcel or give a share — a parcel listing two categories has both, in unknown proportion. This layer answers only where the county publishes the classification; many counties, including several large cities, do not. Four states, told apart explicitly: covered = the county publishes it and the parcel has an entry; covered_no_data = the county publishes it and this parcel has none (a checked negative — still billed); not_covered = the county does not publish it, or we do not hold the parcel (refunded); not_computed = the lookup could not finish in time (refunded — retry). Costs 4 API tokens, refunded on not_covered and not_computed. Not legal advice, and never a statement that a parcel can or cannot be built on.

  ConnectorOAuth

• till_exportA

  biiiB

  ACCOUNTING EXPORT: turn the verified receipts into an accountant-ready CSV that QuickBooks / Xero / Excel import (the export finance teams need to adopt). Every row carries its own txHash + Basescan link, so the accountant re-verifies each amount on Base themselves — the export is a POINTER to the chain, never a book to trust. Non-custodial (BIII moved no funds). Columns: date, receipt_no, reference, description, payer, gross_usdc, tip_usdc, charged_usdc, token, chain, tx_hash, basescan_url, status. Dedup by txHash; optional block-time window; brand slugs the filename. WINDOW HONESTY: a receipt with no on-chain block time cannot be proven to fall inside a dated window, so it is excluded from one — and summary.undatedExcluded reports HOW MANY were, with the same warning prepended to `disclosure`. If that count is non-zero the CSV is short by those rows: re-run with no window to see them all.

  ConnectorNo auth

• ingest_uploadA

  schedule-iiiA

  Commit a validated upload into the entity’s books. This is a TWO-CALL approval: if the upload has any warnings, or would permanently delete existing trial-balance rows for a period it covers, the first call writes NOTHING and refuses with every warning, the exact record counts, and a short-lived removal_token. Show your user every warning and both counts, get their explicit go-ahead, then resend the SAME call adding removal_token and removal_count exactly as returned. acknowledge_warnings is IGNORED on this connection — the token is the only acknowledgment, so sending it changes nothing. A clean, additive ingest needs no token and succeeds on the first call. Returns the ingestion outcome including any notices.

  Connector

  Destructive

  No auth

• list_grouping_suggestionsA

  schedule-iiiA

  List ungrouped accounts with DETERMINISTIC grouping suggestions (curated rules + name/group-path matching — no AI is involved; Datavrn never applies a suggestion itself). Paginated. Each row carries a reason and a confidence tier: present them to your user GROUPED BY CONFIDENCE, and call out low-confidence and balance-bearing rows for individual attention — a single blanket approval is not a review of the low-confidence tail. Confirm only what your user approves via confirm_groupings. Returns a summary (counts by confidence tier) plus one page of suggestion rows — fetch tier by tier with the confidence filter instead of everything at once; pass include='confirmed' to see already-confirmed groupings.

  ConnectorNo auth

• generate_schedule_iiiA

  schedule-iiiA

  Queue the Schedule III workbook build (returns a job_id to poll with get_job — the build runs as a background job). REFUSES when ungrouped accounts exist unless acknowledged: before acknowledging, present the ungrouped accounts to your user and obtain their explicit go-ahead; record it in acknowledge_reason and pass the exact count in acknowledge_count — an acknowledgement WITHOUT its count is always re-demanded. A multi-month statement period additionally requires acknowledge_multi_month_pnl WITH acknowledge_month_count (confirm with your user that the TBs are period movements, not cumulative). Never acknowledge anything the user has not seen. Once queued, the build usually completes in a few minutes — tell your user their statements are being prepared and poll get_job periodically; do not present the wait as a problem.

  ConnectorNo auth

• get_statement_notesA

  schedule-iiiA

  Read the line-by-line breakdown of a generated statement's notes — every line's current and prior-year amount, and the note total. Pass note_numbers (from get_statement_figures' note_index) to fetch specific notes, or omit for all. Use this to answer "what's in Other Expenses?" or "what makes up trade receivables?". Each line has a kind: 'component' (an additive line), 'subtotal' (a presentational group subtotal — do NOT add it into the total, or you double-count), or 'header'. Fixed-asset / intangible notes carry a `block` per class with gross_block, accumulated depreciation, and net (the additions/deletions movement schedule itself lives in the workbook). If the full set is too large it returns too_large:true with a note_index — fetch note_numbers in small batches. A single very large note (e.g. a PPE schedule or an ageing note) is returned in explicitly-flagged line pages: each page carries the authoritative note total, lines_page, lines_total, and has_more_lines — keep fetching lines_page until has_more_lines is false; never treat one page's lines as the whole note. Amounts are decimal strings in rupees. Figures are Datavrn's deterministic engine output; interpretation is your assistant's.

  ConnectorNo auth

• declare_capture_naA

  schedule-iiiA

  Record that a capture section had NOTHING to report this period, DOES NOT APPLY to this entity, or that this is the entity’s FIRST YEAR (previous-year figures only). These are three different statements and are not interchangeable: "nothing this period" means the section applies but had no activity; "does not apply" means it never applies to this entity at all. This is your user’s professional assertion, recorded as authorised by them — ask which one is true, and never guess. NOT every reason is available for every section — call get_schedule3_workspace and read allowed_reason_codes on the section before you ask your user, so you never put a choice to them that Datavrn will refuse. The restrictions: Settings takes NO answer here at all (it is only answered by saving the settings); share capital and partner capital take only "nothing this period", because those sections are shown only for statement formats they apply to, so "does not apply" can never be true; and "first year" belongs only to previous-year figures. To record a REVIEW being complete (previous-year figures, disclosures) use confirm_capture_review instead; this tool cannot make that assertion. A section can only hold one active answer. If the section’s current answer is still standing, this call refuses — revoke it with revoke_capture_declaration first. If the current answer was already WITHDRAWN by later changes (Datavrn shows the section as unanswered), this call supersedes it: the old answer is marked withdrawn and stays on the record, and the response names what was withdrawn. An answer is never edited in place. Superseding or changing an answer invalidates any finalise approval you already hold — the next finalise_statement will ask you to review the current state again. Generate a fresh version after your last capture change — finalisation checks the version’s frozen capture state, not today’s.

  Connector

  Destructive

  No auth

• save_partner_capitalA

  schedule-iiiA

  Save the partner or owner capital schedule for an LLP or other non-corporate entity — Note 3a (capital account) or Note 3b (current account), one section per call. Send the COMPLETE schedule for the section you name: anyone you leave out is removed, and a renamed partner reads as one removal plus one addition. If your request would remove anyone, would change the figures of a partner who stays — including their profit-sharing ratio — or would repeat a person’s name that is not already repeated on file, this returns an approval request first and changes NOTHING; tell your user exactly what would change and get their go-ahead before resending with the approval. Two rows with the same person name are both kept: Datavrn never merges them, because two partners may genuinely share a name. A repeated name is therefore saved as a separate row each time it appears, and every one of those rows adds to that person’s balance on the note, so check with your user that there really are that many people before you send a schedule that repeats a name. Adding a partner with a new, different name needs no approval. share_pct is the profit-sharing ratio stated in the LLP or partnership agreement at the reporting date. A ratio that changed part-way through the year cannot be represented here, and a partner who joined or left mid-year cannot be dated — record the position at the reporting date and tell your user the note cannot explain a mid-year change. These figures come from the agreement; Datavrn does not verify them. Datavrn warns about ratios that do not total 100% only when at least TWO capital-account rows carry a ratio, so a partly-filled schedule gets no warning at all — check the total yourself with get_partner_capital. This is your user’s data about named people, recorded as authorised by them. After a successful save, read the section back with get_partner_capital and show your user the new closing balances — this replaces the whole section, and a schedule they cannot see afterwards is a schedule they cannot check. Generate a fresh version after your last capture change — finalisation checks the version’s frozen capture state, not today’s.

  Connector

  Destructive

  No auth

• save_accounting_policiesA

  schedule-iiiA

  Save the Significant Accounting Policies text (Note 2) your user has chosen, one policy per title. SEND THE COMPLETE SET EVERY TIME: this replaces all of Note 2, so any title you leave out of this call is removed — including one someone answered in the Datavrn app. Call list_statement_policy_choices first and send back every title. If your call would drop a saved policy, Datavrn saves nothing and returns an approval request naming how many would be dropped — show your user, and send the approval back only if they mean to drop them. A complete resend drops nothing and saves straight away. Use the exact policy headings this statement format carries; a heading Datavrn does not recognise is refused and nothing is saved. Resolving a bracketed template choice such as "[FIFO / weighted average]" is an ACCOUNTING POLICY DECISION SPECIFIC TO THIS ENTITY: get your user’s explicit choice, and never pick one because it is the common answer. If a policy was set this year and differs from last year’s answer, that is a CHANGE IN ACCOUNTING POLICY requiring disclosure under AS-5 / Ind AS 8 — tell your user before you save it. Check list_statement_policy_choices first: a row that differs from last year while its captured flag is false is NOT a change — last year’s wording has simply not been carried forward, and unless you send it again this note prints Datavrn’s generic template wording in its place. Saving here re-opens the disclosure review — after your last change, confirm the disclosure review again with confirm_capture_review before generating. Recorded as authorised by the member you name. Generate a fresh version after your last capture change — finalisation checks the version’s frozen capture state, not today’s.

  Connector

  Destructive

  No auth

• list_replacementsA

  schedule-iiiA

  List what a connected data source’s AUTOMATIC syncs have REPLACED for one entity — each one showing what was overwritten, how many records, and whether it can still be undone. Call this when a user says figures for a past period look wrong or changed on their own, and after any surprise in a period a connector covers. Datavrn keeps the replaced data for 30 days from the moment it was replaced: within that window state is "restorable" and preview_replacement_restore/restore_replacement can put it back; after it, state is "lapsed" — the record of what happened is kept and is still listed here, but it can no longer be undone from this connection, so tell the user to contact Datavrn support if they need that data recovered. "restored" means it has already been put back. Only syncs that ran UNATTENDED are listed: a replacement someone on the team previewed and confirmed themselves is not offered for undo, by design. window_closes_at is the date the undo window shuts. If connection_attributed is false, Datavrn can no longer prove which connection made that replacement — say so rather than naming this one. To find these without a connection id, call get_pending_work: it lists every still-undoable replacement across the entities you can see, with the entity and connection to use here.

  ConnectorNo auth

• check_en378_zonesA

  The New Engineer — HVACA

  DETERMINISTIC: the same inputs always give the same result — from any AI, on any day. Figures come from the standard's tables and formulas, never from a language model's estimate. Every step is auditable. EN 378 applied to BUILDING projects, volume by volume. An installation does not occupy one room but several: the machine, the rooms crossed by refrigerant lines, the rooms served by indoor units. Each volume is classified on its own — access category (a/b/c) and location class (I–IV) — and each classification calls for its own measures. The tool answers per volume, never as a single verdict. It returns, for every volume: its classification and why, the charge limit from Tables C.1 and C.2 of EN 378-1 (with the C.2 formula computed when the table calls for it), whether the charge exceeds it, the EN 378-3 measures that follow, the applicable texts (EN 378-1 to -4, EN IEC 60079-10-1, SUVA 66139 and 2153) and the ventilation flow rates. FOUR CONFIGURATIONS COVER ALMOST EVERY BUILDING PROJECT. Bring the user's case back to one of them wherever possible: machine_en_local_technique chiller or heat pump, all refrigerant inside the machine, standing in a plant room -> c III enceinte_accessible_fermee all refrigerant inside a walk-in ventilated enclosure that stays closed even for maintenance -> the enclosure is c III, the room around it carries no requirement enceintes_inaccessibles one or more units, each in a manufacturer's non-accessible ventilated enclosure -> TWO analyses: the enclosure in operation (class IV, the manufacturer sizes and justifies it, ask him for the enclosure ventilation), and the plant room with the enclosure OPEN for maintenance, which comes back to c III split_traversant split or VRF outdoors, refrigerant lines crossing occupied rooms -> each room on its own; offices and their circulations are b I, and formula C.2 gives the maximum charge for the floor area, or the minimum floor area for the charge THIS TOOL ANSWERS SAFETY IN THE ROOM. It says NOTHING about whether the refrigerant may still be placed on the market or refilled: in Switzerland that is `check_refrigerant_switzerland`. A question that mixes both - « may I use R-32 for 3 kg in a server room, and until when can I refill it » - needs BOTH tools: call this one for the room, and check_refrigerant_switzerland for the dates. Do not answer half the question. NEVER guess. The refrigerant, the configuration and the charge are always needed; a split also needs the floor area and how the indoor unit is mounted (floor, wall, window, ceiling), since C.2 depends on it. Without them the result is `provisional` and carries `questions_to_ask`: ask them, one or two at a time, then call again. Answer from `answer_outline`, volume by volume. In building projects, detection is preferred over treating a plant room as an ATEX zone. C.3 is never used. Say that the practical limit alone proves nothing: the charge limit of Tables C.1 and C.2 is what counts. SCOPE: building services. Cold rooms, food refrigeration and industrial process refrigeration are a different trade.

  ConnectorNo auth

• adw.adw_566A

  AlpineDataWorks Intelligence ServerB

  Returns a 0-100 US medical-device recall-enforcement pressure index (openFDA 90-day recall count, severity-weighted by FDA class I=3/II=2/III=1, vs the prior 90 days) with score, trend, confidence, top_drivers, class breakdown, top recall reason, and recent Class I/II recalls. Call when the user asks about medical-device recalls, FDA device enforcement, or device safety risk, or when timing supplier reviews, procurement holds, or med-tech exposure. For drug recalls use ADW-552. Updates: daily.

  ConnectorNo auth

• fda_search_enforcementA

  FDA Data MCPA

  Search FDA enforcement actions (recalls) for drugs, devices, and food across all companies. Filter by company name (fuzzy match), recall classification (Class I=most serious/Class II/Class III), date range, or status (Ongoing/Terminated). Returns recall details including product description, reason, and distribution pattern. Related: fda_recall_facility_trace (trace a recall to its manufacturing facility by recall_number), fda_ires_enforcement (iRES recall data with cross-references), fda_device_recalls (device-specific recall data).

  ConnectorNo auth