Skip to main content
Glama
Sign In
LiLBrain

LiLBrain

by MangoByteLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

lilbrain_clones

Identify copied or near-duplicate functions using token similarity to detect code duplication and support refactoring.

Instructions

Detect near-duplicate functions using token similarity. Finds copy-paste code.

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": "lilbrain_clones"
  }
}

Input Schema

NameRequiredDescriptionDefault
thresholdNoSimilarity threshold 0.0-1.0 (default 0.7)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does disclose the detection method (token similarity) and high-level goal, but it does not describe the output format, side effects, scope, or how the threshold affects behavior. This is adequate but not rich.

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 short, information-dense sentences with no filler. The main action and method are front-loaded, and the second sentence reinforces the practical use case.

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 simple tool with one optional parameter, the description plus schema is mostly sufficient for an agent to select and invoke it. The main missing piece is the result/return behavior—since there is no output schema, a brief note on what the tool returns would make it fully 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 coverage is 100%; the threshold parameter is already well documented in the input schema with type, range, and default value. The description adds nothing about the parameter beyond what the schema provides, so the baseline of 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 uses a specific verb ('Detect'), a clear resource ('near-duplicate functions'), and a precise method ('using token similarity'). It clearly distinguishes this tool from sibling code analysis tools like lilbrain_deadcode or lilbrain_semantic by stating its exact detection goal.

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 the tool should be used when looking for copy-paste or near-duplicate code, but it never explicitly says when to use this tool versus alternatives. With over 20 sibling tools, the lack of routing guidance is a clear gap.

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