LeanGate

Overview Schema Source Related Servers Discussions Admin

record_feedback

Report whether a LeanGate finding was correct so false positives are rejected and project conventions in notes are remembered. Security findings require a person to waive them.

Instructions

Tell LeanGate whether a finding was right. A rejected finding (accepted=false) is never raised again, except a security finding: only a person can waive one (leangate waive), so tell the user why you think it's wrong instead. If note states a project convention (e.g. "we always validate at API handlers"), it is remembered.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "signature": "<signature>",
      "accepted": "<accepted>"
    },
    "name": "record_feedback"
  }
}

Input Schema

Name	Required	Description	Default
`note`	No
`repo`	No
`accepted`	Yes
`signature`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Oct 17, 2026

TDQS

A3.6/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: a rejected finding is never raised again, security findings are exempt from that suppression, and `note` text asserting a convention is persisted and remembered. It still omits what an accepted=true does, whether feedback is scoped per repo, and how the signature is obtained.

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?

Purpose is front-loaded, and the subsequent sentences add genuine constraints rather than filler. The security-waiver sentence is dense but earns its place; the parenthetical example for `note` adds clarity at low cost.

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?

For a four-parameter mutation with no annotations and no output schema, the description covers the key suppression rule and the security exception well, but leaves the required `signature` identifier and the `repo` scoping undefined, and never describes the result of a successful call.

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

Parameters2/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 define all four parameters. It gives real meaning for `accepted` (rejection semantics) and `note` (convention text is remembered), but `signature` — a required parameter — is never explained, and `repo` is not mentioned at all. Half the parameters remain semantically opaque.

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 opening sentence gives a specific verb and resource: report to LeanGate whether a finding was right. No sibling (show_report, verify_lean, minimize, etc.) overlaps with feedback submission, so the purpose is unambiguous by construction, though the description never explicitly differentiates itself from those tools.

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?

It states the trigger condition implicitly (you have a finding and a verdict) and, crucially, an exclusion: security findings cannot be rejected here and must be waived by a human via `leangate waive`. That when-not guidance is stronger than typical, but there is no explicit routing to an alternative tool for that case.

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

Deploy Server