Skip to main content
Glama
nikhilpravinpise

Freelance MCP Server

by nikhilpravinpise
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

code_debug

Identify and fix issues in a code file by providing the path, issue description, fix type, and backup preference.

Instructions

Debug and fix issues in a code file

Args:
    file_path: Path to the code file to debug
    issue_description: Description of the issue to fix
    fix_type: Type of fix (auto, manual, suggest)
    backup: Whether to create a backup before making changes

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
backupNo
fix_typeNoauto
file_pathYes
issue_descriptionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.0

TDQS

B3.2/5.0
Behavior2/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 mentions a 'backup' parameter but does not explain its default behavior (true), nor does it disclose permission requirements, reversibility, or rate limits. The description implies a mutation but lacks crucial behavioral context.

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 front-loaded with the main action and neatly structured with an Args section. Every sentence is purposeful and no information is wasted.

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 covers parameters but lacks behavioral details (e.g., what 'auto' vs 'manual' means, consequences of backup). With no annotations and an output schema, the description is adequate but leaves gaps in expected behavior.

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?

The description lists all four parameters and provides brief explanations, effectively compensating for the 0% schema description coverage. It clarifies the meaning of 'fix_type' and 'backup', adding value beyond the schema's basic types.

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+resource ('Debug and fix issues in a code file'), which is clear. However, it does not differentiate from the sibling 'validate' or 'code_review', leaving ambiguity about when to choose this tool over those.

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 guidance is provided on when to use this tool versus alternatives like 'validate' or 'code_review'. There is no mention of prerequisites, context, or exclusions.

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