Skip to main content
Glama
jigyasudham

veto

by jigyasudham
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

veto_dead_code

Read-only

Detect dead code in a project: unreferenced exports, commented-out blocks, and TODO/FIXME markers, then judge which are safe to delete.

Instructions

Project-scope dead code detector: exported symbols no other project file references (package entry points counted as public API), runs of commented-out code, and TODO/FIXME markers — all found deterministically — plus an LLM judgement of which are safe to delete.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
extensionsNoFile extensions to scan (default: ['.ts','.js']).
project_dirYesAbsolute path to the project root.
agent_responseNoPhase 2 response from the host AI (JSON). Pass this back when prompted by the server to complete the agentic loop.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.9.0
    • addedInput schema / properties / agent_response
      Added value: +{
+  "description": "Phase 2 response from the host AI (JSON). Pass this back when prompted by the server to complete the agentic loop.",
+  "type": "object"
+}
  2. First observedv2.7.1

TDQS

A3.8/5.0
Behavior4/5

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

With readOnlyHint=true already covering safety, the description adds genuinely useful behavioral detail: detection is deterministic, package entry points are treated as public API (avoiding false positives), and reporting is augmented by an LLM judgement of deletability. It does not explain the two-phase agentic loop, but the schema covers the agent_response param.

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?

A single front-loaded sentence opens with the verb and resource and gives the key scope facts with no filler. It is slightly run-on with its em-dash cascade but every clause carries information.

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, yet the description never hints at the return shape, and the two-phase agentic loop implied by agent_response is only covered by the schema. For a tool of this complexity, more about results and the loop would help, though annotations carry the safety profile.

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 parameters are already documented (project_dir, extensions default, agent_response). The description adds no per-parameter syntax or format detail, so the 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?

Names a specific verb and resource ('Project-scope dead code detector') and enumerates the three concrete things it finds (unreferenced exported symbols, commented-out code runs, TODO/FIXME markers). This clearly distinguishes it from nearby siblings like veto_clone_detector or veto_test_gaps without needing either schema.

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 usage (project-wide cleanup of dead code) but never states when to reach for this tool versus alternatives, nor any exclusions. No precondition or 'use this instead of X' guidance is provided, leaving routing to inference.

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