Skip to main content
Glama

3TG Test Generation

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileNameYesPath 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 component table or a unit table. The spec filename is derived by replacing the extension with `.3tg.md`.
sourceCodeYesFull 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 cross-check the spec against.
specContentYesFull UTF-8 contents of the `.3tg.md` spec to validate — exactly as it lives under `.3tg/<sourceDir>/<basename>.3tg.md`.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
validYesTrue iff there are zero error-severity diagnostics. Warnings and info do NOT flip this to false — they're advisory. `true` means "structurally sound; safe to compile", not "expected values are correct".
parsedYesWhat 3TG actually parsed — useful for eyeballing coverage.
summaryYesOne-line human summary — lead with this when reporting back.
diagnosticsYesOrdered findings. `error` = will break generation; `warning` = probably a mistake but generation still runs; `info` = advisory (coverage gaps, unverifiable columns).

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description fully discloses behavior: it runs the same parse as 3TG, cross-checks against source exports, reports specific error/warning/info types, and notes it cannot verify arithmetic correctness. Also states it is free and consumes no quota.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections (WHAT IT CATCHES, WHAT IT CANNOT CHECK) and front-loads the main purpose. Every sentence adds valuable information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists (mentioned but not shown), the description does not need to explain return values. It covers purpose, usage, parameters, behavioral details, and limitations, making it complete for a lint tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% description coverage; the description adds further context (e.g., fileName extension determines parsing type, sourceCode needed for ground-truth checks, specContent description). This adds value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lints a `.3tg.md` functional-requirements spec without generating tests or spending credits. It distinguishes from sibling tools like `create_tests_from_spec` by specifying it is a pre-check step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises running this before `create_tests_from_spec` to catch mistakes, and lists what it catches vs cannot check. It provides clear context on when to use and exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.8/5.0
Disambiguation5/5

Each tool has a distinct purpose: creating agent instructions, generating mocks, specs (file-level and function-level), tests (from source and from spec), client info lookup, help, config validation, and spec validation. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores (e.g., create_agent_instructions, get_client_info, validate_config). No mixing of conventions.

Tool Count5/5

With 10 tools, the server is well-scoped: setup, spec generation, test generation from two sources, validation, and support. Neither too few nor too many for its purpose.

Completeness5/5

The tool surface covers the full lifecycle: agent instructions, mocks, specs (entire file or single function), tests from source or spec, config and spec validation, help, and account info. No obvious gaps.

Resources