Skip to main content
Glama

git_lint_commits

Deterministically validate commit messages against guidelines—no AI, network, or credentials needed. Lint a single message or a commit range, enforcing format, style, and footer rules with a YAML pass/fail report.

Instructions

Deterministically validate commit messages against guidelines — no AI, no network, no credentials required (unlike git_check_commits, which calls an AI model). Checks: type/scope format, scope membership in scopes.yaml, subject length, lowercase/no-trailing-period style, blank line after the subject when a body is present, and forbidden footers. Does NOT check type-matches-diff, scope-file-correspondence, or description truthfulness — those need a model and stay in git_check_commits. Set message to lint a single literal message directly (bypassing git entirely), or range to lint every non-merge commit in a range (defaults to commits ahead of the base branch). Mirrors omni-dev git commit message lint. Returns a YAML payload with the full CheckReport, a pass/fail summary, and the exit code the CLI would use (honouring strict).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rangeNoCommit range to lint (e.g., `HEAD~3..HEAD`, `abc123..def456`). Defaults to commits ahead of the default base branch when omitted (unlike `git_check_commits`, which requires `range`).
strictNoWhen true, warnings are treated as non-zero exit conditions. Defaults to `false` (only errors fail).
messageNoLint this literal message directly instead of a commit range (the `--stdin` equivalent) — no git repository is touched. Exactly one of `range`/`message` should be set; `message` takes precedence if both are.
repo_pathNoPath to the git repository. Defaults to the current working directory. Ignored when `message` is set.
context_dirNoOptional explicit context directory (overrides the standard `.omni-dev/` resolution chain for both `scopes.yaml` and `commit-rules.yaml`).
Behavior5/5

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

No annotations exist, so the description carries full burden. It discloses deterministic execution, no network/credentials, a precise list of checks and non-checks, bypassing git entirely with `message`, default range behavior, strict-mode effect on exit code, and the YAML payload structure.

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?

Packed with information but each sentence earns its place. Leads with purpose, contrasts with sibling, lists checks, lists non-checks, details usage modes, and describes return value. No redundancy or filler.

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?

Despite no output schema, the description explains the full return payload (CheckReport, pass/fail summary, exit code) and covers all parameter behaviors, operation modes, and relationship to `git_check_commits`. This is a complete, self-contained specification.

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%, yet description adds meaningful semantics beyond the schema: explains mutual exclusivity of `range`/`message`, precedence (`message` takes precedence), `repo_path` ignored when `message` set, and how `strict` affects exit codes. It also clarifies defaults like range defaulting to base branch commits.

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?

Description opens with a specific verb+resource: 'deterministically validate commit messages against guidelines'. It clearly distinguishes from sibling `git_check_commits` by highlighting the deterministic, no-AI nature, and enumerates exact checks performed and excluded.

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?

Provides explicit comparison with `git_check_commits`, stating that AI-dependent checks 'need a model and stay in `git_check_commits`'. Also explains when to use `message` vs `range` with precedence rules and default behavior, giving concrete usage guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rust-works/omni-dev'

If you have feedback or need assistance with the MCP directory API, please join our Discord server