Skip to main content
Glama
gavelcode

gavel

Official
by gavelcode
OverviewSchemaRelated ServersScoreDiscussions
Go
Local

Gavel

CI codecov License Bazel

Bazel builds your monorepo. Gavel judges it. Order in the codebase!

The quality gate for Bazel monorepos — build-graph-native, local, agent-ready.

Your monorepo builds green. That's not the same as innocent. Gavel gathers the evidence as Bazel aspects, holds every change to the law you set in gavel.yaml, and returns a verdict: the regression you just introduced stands charged, while a decade of existing debt is not on trial. One verdict, handed to your CI, your terminal, and your coding agent alike.

gavel init      # open the case
gavel judge     # hear it

Gavel judging a Bazel monorepo — a new finding is blocked while a decade of existing debt stays baselined

Install

# Homebrew — macOS & Linux
brew install gavelcode/tap/gavel

# or the install script — Linux, CI, Docker
curl -fsSL https://raw.githubusercontent.com/gavelcode/gavel/main/install.sh | sh

Prebuilt binaries for every platform are on the releases page. Gavel needs a Bazel 8.0+ (bzlmod) workspace; verify with gavel --version.

bazel build //apps/cli/cmd/gavel
# binary at bazel-bin/apps/cli/cmd/gavel/gavel_/gavel

Related MCP server: bazel-mcp

How it works

Every change gets its day in court.

1. The evidence comes from the build graph

Analyzers — golangci-lint, PMD, CPD, SpotBugs, Error Prone, Ruff, Bandit, ESLint, Clippy — run as Bazel aspects. They see the exact source tree, dependency graph, and toolchains Bazel already resolves; no separate scanner, no second config to drift. SonarQube re-scans the world; Gavel looks only at the targets the graph says changed (--affected), so a run stays fast as the monorepo grows. Every tool, every language, normalized to one format: SARIF.

2. You're only tried for what you changed

gavel.yaml is the quality gate — code, reviewed and versioned with the repo, not clicked into a web UI. It evaluates only what you just added against a committed baseline: new findings, coverage regressions, new architecture violations. Adopt Gavel on ten years of debt and it blocks on today's diff, never on the backlog.

projects:
  - name: payments
    pattern: "//payments/..."
    tooling:
      go: [golangci-lint, archtest]
    quality_gate:
      findings: { max_error: 0 }
      coverage: { min: 80 }
      architecture_violations: { max: 0 }

Every run saves a fingerprint snapshot; the next shows the delta — new, fixed, existing — plus the coverage trend. No server required.

  payments/api/handler.go:42  error  null check missing  golangci-lint:nilerr  NEW

  ⚖  VERDICT: FAIL — code_quality
     1 new · 8 fixed · 31 existing        coverage 73.5% (↑5.0%)        architecture PASS

3. A verdict your coding agent can request

Coding agents write code they can't see the consequences of — a lint regression, a coverage drop, a layering violation land three commits later in CI. gavel mcp starts a Model Context Protocol server that exposes judge, lint_file, findings, coverage, and arch as tools. Point Claude Code, Cursor, or Zed at it and the agent checks its own work against the same Bazel-aware gate as it writes — a quality conscience, inline.

For editors and dashboards, gavel watch re-analyzes on every save and emits a JSONL event stream. Both run fully local — no server, no network.

Gavel vs SonarQube: the case

SonarQube

Gavel

Build-graph awareness

None

Bazel aspects understand target dependencies

Monorepo model

One project, or a branch per project

Hierarchical: per-package, per-project, whole repo

Analysis scope

Full scan or file diff

Bazel-aware: changed files + affected targets

Local workflow

Server round-trip

Fully local, zero network

Coding-agent / editor loop

—

MCP server + watch event stream

Quality gate

Web-UI config

Code (gavel.yaml), versioned with the repo

Progress tracking

Server-backed

Local fingerprint snapshots, no infrastructure

Footprint

Java server + database + scanner

One static Go binary, runs inside Bazel

SonarQube is a mature platform with fifteen years of rules behind it, and Gavel isn't trying to replace it. Gavel answers a question SonarQube structurally can't: which packages of my Bazel monorepo are healthy, and did this change make one of them worse — where the build graph is the unit of analysis and the inner loop is where quality is actually won.

Already running aspect's rules_lint? Keep it. Gavel reads the SARIF it drops in bazel-bin/ (gavel judge --findings-source=rules_lint) and turns those reports into a gate — baseline delta, coverage, architecture, verdict — the layer rules_lint deliberately leaves to you.

Status

Alpha — v0.1.0. Under active development; APIs and config formats may change. Gavel gates its own repository on every commit — it is its own first user.

Working today:

  • gavel init — scaffold config + Bazel integration

  • gavel judge — analyze, evaluate the gate, show findings and the delta

  • gavel judge --project <name> · --quick · --summary · --affected — scope and shape the run

  • gavel judge --absolute — evaluate all findings (release gates, nightly)

  • gavel judge --json · --output-sarif report.sarif — structured output for CI, IDEs, GitHub Code Scanning

  • gavel judge --server URL --token TOKEN — shared team baseline: fetch and submit

  • gavel watch — re-analyze on change, emitting a JSONL event stream

  • gavel mcp — Model Context Protocol server for editor / agent integration

  • gavel validate — check Bazel integration health

  • Baseline mode (default): fingerprint-based new/fixed/existing classification, committed to git for the team

  • Analyzers: golangci-lint, PMD, CPD, SpotBugs, Error Prone, Ruff, Bandit, ESLint, Clippy

  • Server (optional): web dashboard, centralized history, team baselines, API-token auth

Documentation

Contributing

Issues and pull requests are welcome — see CONTRIBUTING.md and our Code of Conduct. Security reports go through SECURITY.md.

License

Apache License 2.0

Available Tools

8 tools
gavel_archA
Read-only

Check architecture layer violations (DDD layer rules). Returns per-project violations with rule, source and target packages. Runs a full analysis (not --quick) because architecture checks are skipped in quick mode.

ParametersJSON Schema
NameRequiredDescriptionDefault
projectNoAnalyze only this project (omit for all projects)
gavelspaceNoAbsolute path to a gavelspace directory (omit to use the directory where Claude Code is running)

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already indicate readOnlyHint=true, and the description confirms a read operation. It adds behavioral context about running a full analysis rather than quick mode, which is valuable. No contradictions.

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?

Two sentences that are front-loaded with purpose and return information, followed by key behavioral context. Every sentence adds value with no waste.

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

Completeness4/5

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

Given no output schema, the description provides a reasonable summary of returns (violations with rule, source, target packages). It does not mention limits or pagination, but for a simple tool with two optional parameters, it is fairly complete.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents both parameters. The description does not add additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.

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

Purpose4/5

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

The description clearly states the tool checks architecture layer violations with a specific verb and resource, and mentions return fields. It does not explicitly differentiate from siblings, but the purpose is unambiguous.

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

Usage Guidelines4/5

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

The description explains that this runs a full analysis because architecture checks are skipped in quick mode, providing context for when to use it. It implies that for quick analysis a different tool might be appropriate, but does not name specific alternatives.

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

gavel_coverageA
Read-only

Get code coverage for a project. Runs a full analysis and reports the overall percentage plus a per-file breakdown. Pass 'files' to focus on specific files and see their uncovered line ranges.

ParametersJSON Schema
NameRequiredDescriptionDefault
diffNoShow per-file coverage change since the last green baseline (only files whose coverage moved, plus files with no baseline marked '(new)'). Reports 'No previous baseline' on the first run.
filesNoFilter the per-file breakdown to these file paths (relative to workspace root). When set, uncovered line ranges are listed for each file.
projectNoProject name (analyzes all projects if omitted)
packagesNoFilter the per-file breakdown to whole package trees (relative to workspace root). A trailing '/...' matches the package and its subpackages; without it, only files directly in that package. Mutually exclusive with 'files'. Same output as 'files', with uncovered line ranges.
gavelspaceNoAbsolute path to a gavelspace directory (omit to use the directory where Claude Code is running)

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true. The description adds context about the output (overall percentage and per-file breakdown) and confirms it runs a full analysis, which is consistent with read-only behavior. No additional side effects are disclosed, but the description complements annotations.

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 two sentences, front-loading the main purpose and then adding one key usage hint. Every sentence is informative with no redundancy.

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

Completeness3/5

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

The description explains the main output but does not cover the 'diff', 'packages', or 'gavelspace' parameters' effects beyond the schema. Since there is no output schema, the return value format is vague. Adequate but not comprehensive.

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 description coverage is 100%. The description adds value by explaining the outcome when 'files' is used (uncovered line ranges). This goes beyond the schema descriptions that list parameters but do not highlight the special behavior of 'files'.

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

Purpose4/5

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

The description clearly states that the tool gets code coverage and reports overall percentage plus per-file breakdown. However, it does not contrast with sibling tools like gavel_trends or gavel_findings, so differentiation is missing.

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

Usage Guidelines3/5

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

The description gives a usage hint for the 'files' parameter but does not provide guidance on when to use this tool versus alternatives (e.g., gavel_trends for trends). No exclusions or when-not-to-use advice is given.

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

gavel_findingsA
Read-only

Discover every lint finding across a project in one call. Runs a quick analysis (findings only, no coverage), returns a by-rule summary plus a flat file:line list with gate-blocking NEW findings sorted first. Filter by project, rule, or severity.

ParametersJSON Schema
NameRequiredDescriptionDefault
ruleNoKeep only findings whose rule id matches (omit for all rules)
limitNoMaximum findings to list in detail; the by-rule summary always counts all matches (default 100)
projectNoAnalyze only this project (omit for all projects)
severityNoKeep only findings of this severity, e.g. error or warning (omit for all)
gavelspaceNoAbsolute path to a gavelspace directory (omit to use the directory where Claude Code is running)

TDQS

A4.2/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true, which aligns with the description. The description adds behavioral context: it runs a quick analysis, returns sorted output with gate-blocking NEW findings first, and excludes coverage data.

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 two well-structured sentences that front-load the main action and efficiently convey the tool's purpose, behavior, and filtering options.

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

Completeness4/5

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

Given 5 parameters with full schema coverage and no output schema, the description covers the main purpose and key behavior. It could mention the output format more explicitly but is adequate for a scanning tool.

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%, and the description adds value by explaining that limit applies only to the detailed list while the summary counts all matches, and by clarifying the gavelspace parameter defaults to the current directory.

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 discovers lint findings across a project, specifies it returns a by-rule summary and a sorted flat file:line list, and distinguishes from sibling tools by noting 'no coverage'.

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

Usage Guidelines3/5

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

The description implies this tool is for quick analysis when you want all findings without coverage, but does not explicitly state when to use it versus alternatives like gavel_coverage or gavel_trends.

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

gavel_initA

Initialize Gavel in the workspace from an existing gavel.yaml. Installs Bazel aspects, registers tool dependencies in MODULE.bazel, and sets up .bazelrc includes.

ParametersJSON Schema
NameRequiredDescriptionDefault
fromYesPath to an existing gavel.yaml to use as input
gavelspaceNoAbsolute path to a gavelspace directory (omit to use the directory where Claude Code is running)

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description must disclose behavior. It mentions installation and registration side effects, but omits important details like idempotency, error handling on invalid input, or potential overwriting of existing configurations.

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 concise and front-loaded with the main purpose. However, the list of effects could be formatted for easier scanning (e.g., bullets), but the single sentence structure is acceptable.

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

Completeness2/5

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

Given no output schema and no annotations, the description should explain return values and error conditions. It does not mention what the tool returns (e.g., success message, configuration details) or what happens on failure. This is a gap for a tool that modifies workspace state.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. The description adds context like 'existing' for the 'from' parameter, but does not add significant meaning beyond the schema descriptions for either parameter.

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 initializes Gavel from an existing gavel.yaml, listing specific actions (install Bazel aspects, register dependencies, set up .bazelrc). This distinguishes it from siblings which handle different phases like validation or trends.

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

Usage Guidelines3/5

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

Usage is implied: you need an existing gavel.yaml. But no explicit guidance on when to use this versus siblings like gavel_validate or gavel_arch, nor any prerequisites or exclusions.

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

gavel_judgeB

Run static analyzers and evaluate the quality gate for configured projects. Returns verdict (pass/fail), findings count, coverage, and rule-by-rule results.

ParametersJSON Schema
NameRequiredDescriptionDefault
quickNoSkip coverage and architecture checks (findings only)
projectNoAnalyze only this project (omit for all projects)
affectedNoAnalyze only targets affected by changed files. Implies --quick.
gavelspaceNoAbsolute path to a gavelspace directory (omit to use the directory where Claude Code is running)

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries full burden. It states the tool runs analyzers and returns results, implying non-destructive behavior but omitting details on side effects, prerequisites (e.g., project initialization), or performance impact.

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 a single sentence with essential information: action and return values. Every word contributes, and it is front-loaded with the verb and object.

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

Completeness4/5

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

Given no output schema, the description adequately lists return components (verdict, findings, coverage, rule-by-rule). However, it misses context about prerequisites (e.g., gavel_init requirement) and the concept of a quality gate.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions; it does not elaborate on how parameters affect behavior.

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

Purpose4/5

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

The description clearly states the tool runs static analyzers and evaluates a quality gate, returning a verdict and metrics. It distinguishes from siblings like gavel_findings and gavel_coverage by focusing on the combined verdict, but could explicitly contrast use cases.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. The description only implies usage for running analyzers and checking quality, but does not mention when to prefer gavel_findings, gavel_coverage, or other siblings.

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

gavel_lint_fileA
Read-only

Get lint findings for a specific file. Runs a quick analysis (findings only, no coverage) and returns findings filtered to the requested file path.

ParametersJSON Schema
NameRequiredDescriptionDefault
fileYesFile path relative to workspace root
projectNoProject name (analyzes all projects if omitted)
gavelspaceNoAbsolute path to a gavelspace directory (omit to use the directory where Claude Code is running)

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already provide readOnlyHint=true. Description adds valuable behavioral context: 'quick analysis' and 'no coverage', which goes beyond annotations and helps set expectations.

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?

Two tightly focused sentences. First states core purpose, second adds constraints and efficiency insight. No wasted words.

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

Completeness3/5

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

No output schema exists, and description does not hint at the structure or format of returned findings. For a tool with 3 parameters and no output schema, more detail on return values would improve completeness.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. Description does not add any additional meaning to parameters beyond what the schema already provides.

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?

Clear verb 'Get' with specific resource 'lint findings for a specific file'. Includes distinguishing details ('quick analysis, findings only, no coverage') that differentiate from siblings like gavel_coverage and gavel_findings.

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

Usage Guidelines3/5

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

Implies use for per-file quick linting but does not explicitly state when to use this vs siblings or when not to use it. No mention of alternatives or context.

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

gavel_validateA
Read-only

Validate Gavel structural setup — checks that required files exist, .bazelrc includes are in place, and MODULE.bazel has the expected entries.

ParametersJSON Schema
NameRequiredDescriptionDefault
gavelspaceNoAbsolute path to a gavelspace directory (omit to use the directory where Claude Code is running)

TDQS

A3.7/5.0
Behavior3/5

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

Annotations declare readOnlyHint=true, consistent with the description. The description adds what exactly is validated, providing some behavioral context beyond the annotation, but no details on side effects, auth, or error conditions.

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?

A single, well-structured sentence that front-loads the purpose and concisely lists what is checked. No unnecessary words.

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 tool's simplicity (1 optional param, read-only, no output schema), the description provides adequate context. It fully explains what the tool does without needing additional details.

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

Parameters3/5

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

Schema coverage is 100% and the single parameter's description is clear. The tool description does not add meaning beyond the schema, but the schema itself is sufficient. Baseline 3 applies.

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 validates Gavel structural setup and lists specific checks (files, .bazelrc, MODULE.bazel). It distinguishes from siblings like gavel_init or gavel_judge by focusing on validation.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool vs alternatives. The description implies it's for post-setup checks, but does not state prerequisites or when to avoid.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

Each tool has a distinct purpose: architecture checks, initialization, coverage, findings, quality gate, file-level lint, trends, and validation. No overlap in functionality.

Naming Consistency5/5

All tools follow a consistent gavel_ prefix with descriptive snake_case names, making them predictable and easy to distinguish.

Tool Count5/5

With 8 tools, the set is well-scoped for a code quality server, covering setup, analysis, and monitoring without being excessive or sparse.

Completeness5/5

The tool surface covers the full lifecycle: initialization, validation, architecture, coverage, linting (global and per-file), quality gate evaluation, and trends. No obvious missing operations for the domain.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

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/gavelcode/gavel'

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