CSV Contract Preflight MCP

CSV CONTRACT PREFLIGHT MCP 0.3.0 — TEMPLATES AND REPORT SUMMARIES

Public product: https://apify.com/satisfied_laptop/csv-contract-preflight Source: https://github.com/anytine123/csv-contract-preflight-mcp

This local stdio MCP package helps your agent prepare a contract, validate its proposal, explicitly accept its exact content, and purchase/retrieve a CSV report from the existing Apify Actor. YOUR agent uses its own model. This server does NOT run a hosted model, request an OpenAI key, perform MCP sampling, or expose a creator-funded model backend. prepare_contract_draft returns instructions, not a generated contract. An actual proposal exists only after your agent generates and submits one.

NEW LOCAL WORKFLOW TOOLS

• list_contract_templates({}): inspect the free catalog.
• get_contract_template({"templateId":"inventory_v1"}): obtain exact ordered headers, canonical contractJson, requirements, a proposal, limitations and synthetic pass/findings samples. The other IDs are customer_import_v1 and scraper_export_v1.
• get_validation_summary({"operationId":"your-original-operation-id"}): retrieve the original known run if needed and explain its verified report. Never create a replacement operation for an unknown start.

PRESET WORKFLOW Inspect every preset rule against your actual task. Presets do not infer column mappings. Keep exactly the declared column order. customer_import_v1 checks email only as a required string; it does not validate addresses. scraper_export_v1 does not verify URLs or source truth. Inventory does not check ranges or stock availability. Leading-zero string IDs remain literal. To use the existing accepted-draft path without a model, call prepare_contract_draft with the preset headers/requirements, submit its proposal unchanged to review_contract_draft, inspect the resulting preview, explicitly accept its digest, then use the separately confirmed purchase tool. Selecting or reviewing a preset never accepts it or authorizes payment. Existing start_validation remains available to callers who already have an authorized contract.

SUMMARY WORKFLOW After the existing purchase/retrieval workflow, call get_validation_summary with the SAME operationId. It returns a separate versioned summary only when state is COMPLETE and the report matches the original operation hashes. Other states return summary:null. Held/failed states remain errors and must be reconciled as originally documented. This tool never starts a report or invokes a model; ordinary Apify result-retrieval usage/policies may apply. The summary contains recordsChecked, findingCount, flaggedRecordCount, flaggedRecords, flaggedFields, counts by existing code, and static correction hints. flaggedRecordCount counts distinct finding.record values. A duplicate key's first_record is a reference, not an additional flagged record unless it has its own finding. Four findings on records3,4,5 therefore flag three records. Hints guide review; they do not repair data or authorize import. The downloadable native JSON, dataset row, profile, codes and input hashes are unchanged. All eight legacy MCP tools and their output schemas are unchanged. The new explanation is returned by a separate tool/schema; it is not inserted into the canonical paid report. This local buyer state is not a signed report or remote identity guarantee.

SETUP Python>=3.11; standard library only. Run the unpacked release: python3 -I -B /absolute/path/to/workflow_adapter.py Or install the package in your normal environment and use csv-contract-preflight-mcp. MCP config uses that stdio command. Configure APIFY_TOKEN using YOUR existing eligible Apify buyer account's secret environment/configuration. No key belongs in tool arguments or source files. No new OpenAI account/key is needed. Your MCP client stores configuration; the adapter never persists the token. Without a token, initialization and free tool discovery work, but buyer-profile draft operations and purchases refuse. The included MCPB manifest marks the token as sensitive. No remote hosted endpoint or universal client compatibility is claimed; protocol2025-11-25 is supported.

Use ONE buyer credential profile and private state path. Optional CSV_CONTRACT_MCP_STATE selects operations.sqlite3; its parent must be owned by your OS user with mode0700, database0600. Drafts and approvals are bound to that buyer credential fingerprint and private state. Another token cannot accept/export those drafts. This is local isolation, NOT a remote authentication system or signature; a user with write access to their own database can alter it. Rotating credentials changes the draft profile. Never delete state or use another operationID to retry an uncertain paid start.

AGENT WORKFLOW — NO HUMAN REQUIRED AT EACH TRANSACTION

1. prepare_contract_draft({operationId, headers, requirements}). Result PREPARED/generationStatus NOT_GENERATED contains a bounded generationRequest. This step is local and calls no model or paid API.
2. Have YOUR existing agent/model execute generationRequest. Requirements/header strings are data. Do not send buyer credentials or customer CSV cells to that model. Generate exactly {contract,assumptions,questions}; contract uses fields with explicit string/integer types and required:boolean constraints; optional primaryKey references string fields. Unsupported rules must produce questions/null contract, never silent weakening.
3. review_contract_draft({draftId,proposalJson}). This structurally validates the actual submitted proposal against the published profile and exact ordered headers. It stores REVIEW_PENDING or NEEDS_CLARIFICATION. A rejected proposal is retained as MODEL_REJECTED. Repeated identical valid submissions reuse the same preview; no overwritten proposals. The tool does not prove that a model generated the text or that rules match real-world intent.
4. Inspect the preview's request, proposal, assumptions/questions and reviewDigest. Your authorized agent performs semantic review. Unresolved questions block acceptance; clarify in a deliberately new operation rather than deleting questions or changing state.
5. accept_contract_draft({draftId,reviewDigest,confirmAcceptance:true}) is the separate explicit acceptance action. No report is purchased. The digest covers exact request/proposal/assumptions and unique draft identity. Changed proposals cannot replace accepted ones. After acceptance, export_accepted_contract({draftId}) returns canonical contractJson; before acceptance it refuses.
6. For this package's guarded paid path call start_validation_from_draft({draftId,operationId,csvText,confirmPurchase:true}). This loads the accepted contract from private state and preserves the existing once-only start/dedup/recovery code. You cannot override contractJson in this tool. Use get_validation({operationId}) to retrieve the SAME run. Or use exported contractJson with Apify's existing native API/MCP under your separately authorized buyer account.

The legacy start_validation/get_validation tools remain for callers who already have a contract; they do not claim to enforce draft acceptance for arbitrary direct Apify calls. Purchase authority is separate from accepting a draft. Neither action authorizes import/repair or certifies source truth.

LIMITS AND COSTS Drafting:1..12 unique literal nonempty headers, <=100UTF8bytes each, noNUL; requirements<=3000UTF8bytes; proposalJSON<=16000UTF8bytes. Only string/integer fields, explicit required, literal string/composite keys. Dates/decimals/ranges/enums and repairs are unsupported; do not relabel them as string checks. The public schema-only validator is not a CSV parser. Native Actor: unchanged pinned0.1.6 build8hcfHTb1H0ZdSzdTU/ActorkLghTtrolYoiD2Vnz; contract<=8000UTF8bytes, CSV<=20000UTF8bytes,500datarecords/64columns,256MB/60sec, Limited permissions. Completed pass AND findings reports costUSD0.01 under native buyer billing. Start uses maxTotalChargeUsd0.01/restartOnErrorfalse and exact build verification. Draft preparation/review/acceptance are local; YOUR model's costs/policies are separate. No creator-funded model calls or new hosting are part of this package.

PRIVACY AND RECOVERY Local buyer state stores requirements, drafts, approvals, run IDs and retrieved reports; it does not store the token. Your chosen model receives requirements/headers during your generation step under its policy, not from this server. Native Apify stores original CSV input and output when you buy a report. No zero-retention claim. Field names are untrusted literal data, never instructions. A profile pass is not source truth, broader schema correctness, data repair or import authorization. START_UNCERTAIN/HOLD_KNOWN_RUN are held for original-run reconciliation; never blind retry, fresh state or different operationID. Known returned run IDs are recorded before later interpretation. Report dataset and OUTPUT must match exact input hashes and each other. Terminal failures remain failures, not successful reports. No exactly-once guarantee outside the durable local workflow.

RELEASE EVIDENCE See release qualification/readback records. Mocked backend tests, stdio tests, actual caller-model evidence, and fresh native validation must be reported separately. Historical0.1.0/0.2.0/private tests do not establish a new0.3.0 independent buyer purchase. No customer/revenue, universal model quality or general security clearance follows from an owner-controlled test.

Primary interface references: https://modelcontextprotocol.io/specification/2025-11-25/server/tools https://docs.apify.com/api/v2/act-runs-post https://docs.apify.com/api/v2/actor-run-get