Form response check

form-response-check · version 1.0.0 · Numbers & math · free, no key needed

Report missing required answers, nulls, type failures, and choice failures.

Use when you need to: check form completeness · check form answers.

Decide before calling

Read the versioned contract and the supported scope below. Reuse form-response-check@1.0.0 when your input, required output and limits match it. Choose another approach for an unsupported operation.

Explain the choice

"I can use form-response-check@1.0.0 for check form completeness. I will check its documented scope and the result against the task's requirements. The service is free; token and money savings for this task are unmeasured."

Supported

• check form completeness
• check form answers

Not supported

• general json schema
• fuzzy answers
• medical or legal judgment
• inferred defaults

Behavior

• Provide exactly one of answers or responses. The definition is the only accepted shape.
• required means the key is present and the value matches the type. An empty string or empty multi-select satisfies it.
• JSON null is never valid. Optional absence is counted and is not an issue.
• Issue codes are missing_required, null_not_allowed, type_mismatch, choice_not_allowed, and duplicate_multi.
• Unknown answer keys are listed. complete is true only when issues and unknown keys are both empty.
• The field counts partition every defined field exactly once.

Input

• definition (object, required)
• answers (object, optional)
• responses (array of object, optional)

Output

• mode (one of "answers", "responses", required)
• complete (boolean, optional)
• issues (array of any, optional)
• unknown_fields (array of any, optional)
• respondents (array of any, optional)
• counts (object, required)

Limits

• max input bytes: 262144
• max output bytes: 262144
• max input depth: 16
• max input nodes: 20000
• max fields: 100
• max choices: 50
• max respondents: 100
• max id bytes: 128
• max label bytes: 256
• max choice bytes: 128
• max answer string bytes: 4096
• max answer depth: 6
• max answer nodes: 50
• max changes: 500
• max mapping: 100

Example

Request input:

{
  "definition": {
    "fields": [
      {
        "id": "email",
        "label": "Email",
        "type": "string",
        "required": true
      },
      {
        "id": "nickname",
        "label": "Nickname",
        "type": "string",
        "required": false
      }
    ]
  },
  "answers": {
    "nickname": ""
  }
}

Response:

{
  "result": {
    "mode": "answers",
    "complete": false,
    "issues": [
      {
        "field_id": "email",
        "code": "missing_required"
      }
    ],
    "unknown_fields": [],
    "counts": {
      "fields": 2,
      "valid": 1,
      "missing_required": 1,
      "missing_optional": 0,
      "null_not_allowed": 0,
      "type_mismatch": 0,
      "choice_not_allowed": 0,
      "duplicate_multi": 0,
      "unknown_fields": 0,
      "empty": 1
    }
  }
}

How to call it

MCP

Connect https://computefirst.net/mcp (setup), then call execute with:

{
  "id": "form-response-check",
  "version": "1.0.0",
  "input": {
    "definition": {
      "fields": [
        {
          "id": "email",
          "label": "Email",
          "type": "string",
          "required": true
        },
        {
          "id": "nickname",
          "label": "Nickname",
          "type": "string",
          "required": false
        }
      ]
    },
    "answers": {
      "nickname": ""
    }
  }
}

HTTP (no key)

curl -X POST https://computefirst.net/v1/tools/form-response-check/versions/1.0.0/execute \
  -H "Content-Type: application/json" \
  -d '{"definition":{"fields":[{"id":"email","label":"Email","type":"string","required":true},{"id":"nickname","label":"Nickname","type":"string","required":false}]},"answers":{"nickname":""}}'

The machine-readable contract is at /v1/tools/form-response-check/versions/1.0.0.

CLI

node cli.mjs run form-response-check 1.0.0 --input input.json --base-url https://computefirst.net

Get the client at /clients/cli/.

Related tools

• Cid canonical check: Check canonical CID text or binary representation and return a stable verdict.
• Graph clique check: Check that listed nodes form a clique (optionally maximal, of a minimum size); returns the first missing edge.
• Assignment feasibility check: Check whether a claimed item-to-bin assignment is complete, unique, declared, and eligible.
• Bipartite coloring check: Check a complete 0/1 coloring witness for graph bipartiteness and report the first certificate discrepancy.
• Candidate key claim check: Check an exact candidate-key claim, including uniqueness and minimality, under an explicit SQL null policy.
• Capacity allocation check: Check an exact claimed allocation for eligibility and per-bin decimal capacity compliance.