Skip to main content
Glama
Sign In
LeanGate

LeanGate

by lambdabypi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

verify_lean

Checks new code changes for bloat, missing error handling, and security issues, then returns a pass or block gate to prevent committing faulty code.

Instructions

Call when you finish a change, before you report done or commit.

Checks new code for three things. Bloat: duplicates of existing code, dead code, unused imports, redundant checks, single-implementation abstractions, pass-through wrappers, hand-rolled stdlib functions, unneeded dependencies. Error handling: swallowed exceptions, missing timeouts, unchecked subprocesses, unclosed files, imports of project modules or names that don't exist. Security: injection, hard-coded secrets, verify=False, unsafe deserialization, unknown or vulnerable packages. diff is a unified diff; omit it to check the working tree against HEAD. Returns gate=pass|block with findings. Fix blocking findings or reject wrong ones via record_feedback.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "verify_lean"
  }
}

Input Schema

NameRequiredDescriptionDefault
diffNo
repoNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations present, the description carries the full burden and does well: it discloses what categories are examined, that `diff` must be a unified diff, that omitting it checks the working tree against HEAD, and the output contract (gate=pass|block with findings). It does not cover cost, performance, or what 'blocking' versus non-blocking findings look like, leaving a modest gap.

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?

Front-loaded with the trigger condition, then the check categories, then parameter and return semantics. The long enumeration of checks is dense but each item earns its place by defining scope. Slightly list-heavy, but no filler sentences.

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?

For a two-parameter analysis tool with no output schema and no annotations, the description covers purpose, trigger, both check semantics for `diff`, and the gate-based return shape. The only real omission is the `repo` parameter and any note on how the tool relates to the overlapping sibling checkers.

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 0%, so the description must compensate. It explains `diff` well (unified diff; omit to check working tree against HEAD), but `repo` is never mentioned and its meaning, expected format, or relationship to the working tree is left entirely unexplained.

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 states a specific verb (verify/check) and enumerates exactly what is checked: bloat, error handling, and security, each with concrete sub-items like dead code, swallowed exceptions, and hard-coded secrets. That is far more specific than the name alone. However, it does not differentiate itself from overlapping siblings such as check_reuse or check_dependency, whose domains (duplicate code, unneeded dependencies) are claimed here as part of 'bloat'.

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?

"Call when you finish a change, before you report done or commit" gives a clear temporal trigger for use. It also names a follow-up path (fix or reject via record_feedback), which is helpful. It stops short of explicit exclusions or a comparison to sibling tools like check_reuse, so the agent must infer when this is preferable.

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

Deploy Server

Other Tools