Skip to main content
Glama

Test Pulse

check_test
Read-only

Run the project's real test suite and return structured health — the same engine as the terminal command zephex check test. Detects bun, vitest, jest, pytest, go test, and cargo. Parses JUnit plus lcov (not a regex over stdout). Returns summary, a plain card (what broke, why clusters, coverage, warnings), fix_first, broken_areas, failure_clusters, coverage_by_area, and session_id. Not a file picker for what to edit. ALWAYS call after you edited source, when they ask if tests pass, what is failing, why tests failed, are we green, before commit, before push, or to re-run only the failed tests. PREFER this over running bun test, npm test, or pytest yourself and dumping logs. This already ran the suite, clustered the failures, and named the first file to fix. Workflow: task=detect sees the runner without executing (framework, command, test file count). task=run executes once and stores a session. Then task=failures, status, list, coverage, missing, why, or fix_prompt using session_id (or omit session_id to read the last run on this machine). Do not re-run the whole suite just to read failures. Read summary and fix_first first. On FAIL, call task=failures, then fix those files. task=why with a question explains clusters. task=missing finds changed source without tests. task=fix_prompt is a paste-ready brief. Pass diff_base: main after edits for failures_in_diff. area or file_filter scopes a later run. Local stdio: omit path (the editor cwd — their machine) or pass that project folder. Hosted: public GitHub URL or inline_files — not a local disk path. Does not modify source. Does not invent a runner if none exists. Does not choose product files to edit. Does not check npm packages. Does not scan a live URL. Example: check_test({ task: "run" }) then check_test({ task: "failures", session_id: "" }).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
areaNoScope to module/area name derived from test paths (e.g. proxy, auth, handlers)
pathNoProject folder. Local/stdio: omit to use the editor cwd (tests run on their machine), or pass the absolute folder. Hosted: public GitHub URL or inline_files — not a local disk path. Required for run/detect unless stdio cwd is a project. missing accepts path or session_id.
taskNorun = execute the suite (stores a session). detect = see runner, do not execute. failures|status|list|coverage|fix_prompt|why = read the last session (no re-run). missing = git-diff sources without tests. Same tasks as zephex check test / check test failures.run
limitNoMax rows for task:history (1–20)
commandNoOverride auto-detected test command
questionNoNatural-language follow-up for task:why (e.g. "what failed in proxy?")
diff_baseNoGit branch for patch coverage and failures_in_diff (e.g. main) — use after edits
session_idNoFrom a prior task=run (ts_*). Reuse for failures/status/list/why/fix_prompt so you do not re-run. Omit on stdio to read the last run on this machine.
timeout_msNoMax run time ms (default 1800000 stdio, capped 600000 hosted)
failed_onlyNoRe-run only tests that failed in the prior session
file_filterNoSubstring or glob fragment to filter test_files (e.g. auth, handlers)
coverage_topNoMax files in coverage slice
detail_levelNoToken budget: brief <500 tokens on PASS; agent default; full=all slicesagent
inline_filesNoHosted fallback when github is unavailable: { "package.json": "...", "src/foo.test.ts": "..." }. Supports task detect and task run (temp dir on Railway). Include package.json with scripts.test.
include_flakyNoInclude flaky test hints from local history
with_coverageNoCollect lcov coverage (default true)
include_missingNoGit-diff scan for source files without matching tests (default true on detect and when diff_base set)

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changed
    • changedInput schema / properties / path / description
      Previous value: -"Project root — absolute path (stdio) or public GitHub URL (hosted). Required for run/detect/missing (or session_id for missing)."New value: +"Project folder. Local/stdio: omit to use the editor cwd (tests run on their machine), or pass the absolute folder. Hosted: public GitHub URL or inline_files — not a local disk path. Required for run/detect unless stdio cwd is a project. missing accepts path or session_id."
    • changedInput schema / properties / session_id / description
      Previous value: -"Pass back from prior response (ts_*) for session tasks without re-running"New value: +"From a prior task=run (ts_*). Reuse for failures/status/list/why/fix_prompt so you do not re-run. Omit on stdio to read the last run on this machine."
    • changedInput schema / properties / task / description
      Previous value: -"detect=0 credits (inventory+gaps); missing=0 credits (test gaps only); run=1 credit hosted; failures|why|status=0 credits on session_id."New value: +"run = execute the suite (stores a session). detect = see runner, do not execute. failures|status|list|coverage|fix_prompt|why = read the last session (no re-run). missing = git-diff sources without tests. Same tasks as zephex check test / check test failures."
  2. Changed4 schema fields changed
    • changedInput schema / properties / include_missing / description
      Previous value: -"Detect source files without test files (defaults true when diff_base set)"New value: +"Git-diff scan for source files without matching tests (default true on detect and when diff_base set)"
    • changedInput schema / properties / path / description
      Previous value: -"Project root: absolute directory (stdio) or github:owner/repo / GitHub URL (hosted). Required for run/detect."New value: +"Project root — absolute path (stdio) or public GitHub URL (hosted). Required for run/detect/missing (or session_id for missing)."
    • changedInput schema / properties / task / description
      Previous value: -"run=execute suite (1 credit hosted); detect=dry-run; status|summary|list|failures|coverage|fix_prompt|why|compare=session cache (free); history=cloud scans (free, hosted)"New value: +"detect=0 credits (inventory+gaps); missing=0 credits (test gaps only); run=1 credit hosted; failures|why|status=0 credits on session_id."
    • changedInput schema / properties / task / enum
      Previous value: -[
      -  "run",
      -  "detect",
      -  "status",
      -  "summary",
      -  "list",
      -  "failures",
      -  "coverage",
      -  "fix_prompt",
      -  "history",
      -  "why",
      -  "compare"
      -]New value: +[
      +  "run",
      +  "detect",
      +  "status",
      +  "summary",
      +  "list",
      +  "failures",
      +  "missing",
      +  "coverage",
      +  "fix_prompt",
      +  "history",
      +  "why",
      +  "compare"
      +]
  3. Changed1 schema field changed
    • addedInput schema / properties / inline_files
      Added value: +{
      +  "additionalProperties": {
      +    "type": "string"
      +  },
      +  "description": "Hosted fallback when github is unavailable: { \"package.json\": \"...\", \"src/foo.test.ts\": \"...\" }. Supports task detect and task run (temp dir on Railway). Include package.json with scripts.test.",
      +  "type": "object"
      +}
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations establish readOnlyHint:true and destructiveHint:false, and the description corroborates and adds beyond structured data by disclosing session caching: it can be executed without re-running, and 'session_id persists across calls for the same run' but beware sub-concept of last-run. The description also carries the notable disclaimer that it 'does not invent a runner if none is present', 'does not modify test files...', and that a run is not re-executed on a status/read call but reuses the session. These are important behavioral traits: each call may be cached, and in hosted mode cannot accept a filesystem path.

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

Conciseness4/5

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

The description is well-structured, front-loaded with the core purpose in the first sentence, followed by exclusions, use triggers, a workflow section, negative behavioral notes, and a brief example pair. Length is justified by the breadth (13 task values, 17 parameters), but a few repeated phrases (e.g., identical runner list, 'parsing no vs. not') could be tightened, so it is efficient but not maximally concise.

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?

The tool is highly complex with 17 parameters and 12 task modes, and there is no output schema; the description compensates fully by listing the 10 named return fields (breakdown, coverage, fix_first, broken-area-failures...). It covers operation in both standard I/O and hosted contexts, gaits through a typical 'run then inspect failures' sequence, and states limitations ('no npm check', 'no scanning') and the count of an execution. Everything an interview agent needs to know to call it correctly for a given situation is present.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3: the input schema already documents `task`, `session_id`, `path`, `diff_base`, `question`, etc. Leading the description above baseline is workflow guidance: it orders which value to use whenlife — 'task=detect... then task=run; then failures|status|list|coverage|why|fix_prompt with session_id' — and semantics that cross parameters, like 'diff_base: main after edits' and 'area/file_filter scopes the next run.' It makes the orchestrations between task and other parameters meaning richer than the schema's enum descriptions.

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?

Opens with a specific verb+resource: 'Run the project's real test suite and return structured health' — a precise, action-oriented statement of what it does. It further distinguishes itself from siblings by explicit negatives: 'not a file-picker for what to edit', 'Does not check npm packages', 'Does not scan a live URL', and names the terminal alias 'the same engine as zephex check test.'

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?

Gives extremely explicit triggers: 'ALWAYS use after you edited source, when they ask if tests pass, what is failing, why defects, green check, before commit, before push, or to re-run only failed tests.' It even names the alternative it replaces: 'PREFER this over running bun test, npm test, or pytest yourself and dumping logs.' Conditions like 'PREFER this over' and 'Use when not' make through when-to-use unambiguous; it also tells when NOT to: 'not a file picker for what to edit.'

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.4/5.0
Disambiguation5/5

Each tool targets a distinct domain: URL auditing, package checking, tests, architecture, code search, project context, planning, memory, code reading, and expert guides. Descriptions are extremely detailed and explicitly state when not to use each tool, leaving no ambiguity.

Naming Consistency4/5

Most tools follow the verb_noun snake_case pattern (audit_headers, check_package, check_test, explain_architecture, find_code, get_project_context, read_code), but project_memory (noun_noun) and Zephex_dev_info (brand_noun) deviate, and keep_thinking uses a gerund instead of a noun. The pattern is strong but not perfectly uniform.

Tool Count5/5

10 tools is well-scoped for a comprehensive development assistant. Each tool serves a clear purpose without redundancy, covering security, package management, testing, code understanding, project context, planning, memory, and expert knowledge. The count is neither too few nor excessive.

Completeness4/5

The tool surface covers a wide range of development analysis tasks: security auditing, package checking, test running, architecture mapping, code search, project context, planning, memory, code reading, and developer guides. Minor gaps include the lack of direct code editing or project execution/build tools, but the server appears intentionally focused on read-only information and planning.

Resources