Learn Schema Validation With a Tiny GitHub Issue Fields Project

GitHub announced on July 2, 2026 that Issue fields are generally available, including integration with GitHub’s MCP server.

Primary source: GitHub Changelog, July 2, 2026.

That creates a useful beginner project: validate structured issue metadata before an MCP client—or any program—uses it. The schema below is invented for learning. It is not GitHub’s API schema.

Define three fields

// schema.mjs
export const schema = {
  priority: {
    kind: "singleSelect",
    required: true,
    options: ["P0", "P1", "P2", "P3"]
  },
  estimate: { kind: "number", required: false, min: 0, max: 100 },
  customerImpact: { kind: "text", required: false, maxLength: 120 }
};

Enter fullscreen mode Exit fullscreen mode

A schema describes both type and domain rules. estimate must be a number, but it also has to fit the range this project accepts.

Validate at the boundary

// validate.mjs
import { schema } from "./schema.mjs";

export function validate(input) {
  const errors = [];
  if (!input || Array.isArray(input) || typeof input !== "object") {
    return ["fields must be an object"];
  }

  for (const [name, rule] of Object.entries(schema)) {
    if (rule.required && !(name in input)) errors.push(`${name}: missing`);
  }

  for (const [name, value] of Object.entries(input)) {
    const rule = schema[name];
    if (!rule) { errors.push(`${name}: unknown field`); continue; }

    if (rule.kind === "singleSelect" &&
        (typeof value !== "string" || !rule.options.includes(value))) {
      errors.push(`${name}: expected ${rule.options.join(", ")}`);
    }
    if (rule.kind === "number" &&
        (typeof value !== "number" || !Number.isFinite(value) ||
         value < rule.min || value > rule.max)) {
      errors.push(`${name}: expected ${rule.min}..${rule.max}`);
    }
    if (rule.kind === "text" &&
        (typeof value !== "string" || value.length > rule.maxLength)) {
      errors.push(`${name}: expected at most ${rule.maxLength} characters`);
    }
  }
  return errors;
}

Enter fullscreen mode Exit fullscreen mode

Try these fixtures in a local test harness:

{"priority":"P1","estimate":8,"customerImpact":"Checkout is blocked"}

Enter fullscreen mode Exit fullscreen mode

{"priority":"urgent","estimate":-4,"mysteryField":true}

Enter fullscreen mode Exit fullscreen mode

The second should produce three errors. These are expected outcomes from reading the unexecuted template, not recorded test results.

Where MCP fits

MCP client
  -> tool input validation
  -> authorization and repository policy
  -> GitHub API call

Enter fullscreen mode Exit fullscreen mode

Validation is not authorization. A perfectly shaped request can still target the wrong repository or issue. A production tool also needs authenticated identity, least privilege, field discovery from official interfaces, write confirmation, rate-limit handling, and audit records.

Common beginner mistakes are checking only JSON syntax, silently converting every value, ignoring unknown fields, and copying a teaching schema into production.

After this project, you should be able to explain parsing versus validation, type versus domain constraints, and why tool schemas do not replace authorization. Issue fields provide the current topic; the durable skill is making structured tools fail clearly at their boundary.