validate_spec
Lint a .3tg.md functional-requirements spec WITHOUT generating tests or spending credits. Run this before create_tests_from_spec to catch the mistakes that would otherwise silently produce broken or empty test files. WHY THIS EXISTS: 3TG's spec parser is deliberately lenient — it never errors on ...
This record as markdown: /tools/dev-3tg-mcp/validate-spec.md
What validate_spec does on 3TG Test Generation
AI agents call validate_spec to retrieve information from 3TG Test Generation without modifying anything. It is typically the context-gathering step in research, monitoring, and reporting workflows, before the agent takes action elsewhere.
| Parameter | Type | Required | Description |
|---|---|---|---|
fileName | string | Yes | Path of the source file relative to the project root (e.g. "src/foo/bar.ts"). Must end in `.ts` or `.tsx` — the extension tells 3TG whether to parse a React com |
sourceCode | string | Yes | Full UTF-8 contents of the source file the spec describes. Needed so 3TG can compute the ground-truth list of exported functions and their parameter names to cr |
specContent | string | Yes | Full UTF-8 contents of the `.3tg.md` spec to validate — exactly as it lives under `.3tg/<sourceDir>/<basename>.3tg.md`. |
Parameters from the server's own tool schema.
Why validate_spec is rated Low
validate_spec is purely an inspection and validation tool. It reads and parses a specification file, performs analysis and checks, and returns results—no side effects, no data creation or modification, no code execution with external effects. This is a classic Read operation: data retrieval and validation without mutation.
From the tool's definition Tool description states it performs validation/linting WITHOUT generating tests, creating files, or modifying state. Uses verbs like 'lint', 'cross-checks', and 'runs' (a parser in read-only mode).
Risk signalsAccepts file system path (fileName)
Attacks that exploit this kind of access
The rule that runs validate_spec safely
PolicyLayer is an MCP gateway: it sits between your AI agents and 3TG Test Generation, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For validate_spec, this is the rule to start with:
validate_spec is read-only, so it stays allowed. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect 3TG Test Generation, apply this rule, and every validate_spec call is checked against it from then on.
Questions about validate_spec
Lint a .3tg.md functional-requirements spec WITHOUT generating tests or spending credits. Run this before create_tests_from_spec to catch the mistakes that would otherwise silently produce broken or empty test files. WHY THIS EXISTS: 3TG's spec parser is deliberately lenient — it never errors on a malformed .3tg.md, it just silently ignores tables it can't parse and emits whatever column names it sees. So a spec can look fine yet compile to nothing useful. This tool runs the same parse 3TG would, then cross-checks the result against the source's real exports (via 3TG's own analysis) and reports problems. WHAT IT CATCHES: - ERROR: the spec parsed to an empty config (no valid table — usually a wrong return-column header; it must be the literal =>, or a row/header column-count mismatch). - ERROR: a table targets a function the source does not export (the generated test would import a non-existent symbol). - WARNING: a parameter column matches no parameter of any exported function (likely a typo such as input_a for a). - INFO: exported functions the spec doesn't cover yet. WHAT IT CANNOT CHECK: whether the => expected-return values are arithmetically correct — 3TG itself doesn't verify that. Treat a valid: true result as "structurally sound and ready to compile", not "the expected values are right". This tool is FREE — no clientId, no quota, no test cases consumed. Surface the summary and any diagnostics back to the user; if there are errors, help them fix the spec, then re-validate. It is categorised as a Read tool in the 3TG Test Generation MCP Server, which means it retrieves data without modifying state.
validate_spec accepts 3 parameters: fileName, sourceCode, specContent. Required: fileName, sourceCode, specContent. The full parameter table on this page comes from the server's own tool schema.
Register the 3TG Test Generation MCP server in PolicyLayer and add a rule for validate_spec: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches 3TG Test Generation. Nothing to install.
validate_spec is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the validate_spec rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for validate_spec. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
validate_spec is provided by the 3TG Test Generation MCP server (https://mcp.3tg.dev/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on 3TG Test Generation, and thousands of servers like it.
This server
Across the catalogue