Skip to main content
Glama

Check program

check_file
Read-onlyIdempotent

Check a .hird file's program and return every diagnostic, warnings included, as the first and last step of an edit. Reports all errors and warnings across files with stable codes and positions.

Instructions

Check a .hird file's whole program and return every diagnostic, warnings included. Use it as the first and last step of an edit: nothing else reports a warning, and the other tools fail on the first error instead of listing them all. Returns ok (no diagnostic of severity Error anywhere in the program) and diagnostics across every file of the directory, each with file, a stable code (P… parse, C… check, both documented in docs/writing-hird-llm.md), severity, message, nullable help, a 1-based character position (line/column to an exclusive end_line/end_column), and related locations in the same file. Parse and type errors are results here, never isError. Read-only: compiles the file's directory in memory (cached until a sibling changes) and writes or executes nothing. Failures are isError results with a stable error.code: file_not_found, read_error, invalid_params, and, for every tool but check_file, parse_error or check_error carrying coded diagnostics in error.data.diagnostics (the shape check_file returns).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileYesPath to a .hird source file, absolute or relative to the server's working directory. Every .hird file in its directory is compiled with it as one program, so imported names resolve; answers may name a sibling file.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
fileYes
diagnosticsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A5/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses key behaviors: in-memory compilation with caching, that parse/type errors are returned as results rather than isError, stable error codes for failures, and that it writes/executes nothing. This is far richer than the annotation hints alone.

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 long but every sentence earns its place—purpose, usage, return shape, and error handling are densely packed without fluff. It is front-loaded with the core purpose and usage, making it easy to scan.

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?

It covers purpose, usage, behavioral details, return shape (ok, diagnostics with fields), and error handling (stable codes, isError behavior). Given the output schema exists, the description fully equips an agent to call the tool correctly and interpret results.

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?

Schema coverage is 100% with a clear description, but the description adds meaning: the file is compiled with every sibling in its directory, so imported names resolve, and answers may name sibling files. This contextual detail helps the agent understand the parameter's role beyond a simple path.

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 states a specific verb ('check') and resource ('.hird file's whole program'), and explicitly distinguishes itself from siblings: 'nothing else reports a warning, and the other tools fail on the first error instead of listing them all.' This makes its purpose unmistakable and differentiates it clearly.

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?

Explicitly prescribes when to use it: 'Use it as the first and last step of an edit' and explains why (other tools fail early, nothing else reports warnings). It also implies exclusions by noting other tools' behavior, giving clear context for choosing this tool over alternatives.

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