Skip to main content
Glama

elenchus_apply_fix

Applies a fix to an issue in the current session, creates a checkpoint, updates issue status, refreshes file context, and optionally triggers re-verification to maintain fix-verify continuity.

Instructions

Apply a fix for an issue within the current session. Creates checkpoint, updates issue status, refreshes file context, and optionally triggers re-verification. Use this to maintain fix-verify continuity without starting new sessions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sessionIdYesSession ID
issueIdYesIssue ID being fixed
fixDescriptionYesDescription of the fix applied
filesModifiedYesList of files modified
triggerReVerifyNoWhether to trigger re-verification after fix

Implementation Reference

  • The main handler function for 'elenchus_apply_fix'. Gets the session, finds the issue, creates a checkpoint before applying the fix, updates the issue status (RAISED if re-verify needed, RESOLVED otherwise), adds a transition record, refreshes file context by re-reading modified files, runs pre-analysis on modified files, and returns status/nextAction.
    export async function applyFix(
      args: z.infer<typeof ApplyFixSchema>
    ): Promise<{
      success: boolean;
      issueId: string;
      status: 'RESOLVED' | 'PENDING_VERIFY';
      nextAction: string;
      reVerifyRequired: boolean;
    } | null> {
      const session = await getSession(args.sessionId);
      if (!session) return null;
    
      // Find the issue
      const issue = session.issues.find(i => i.id === args.issueId);
      if (!issue) {
        return {
          success: false,
          issueId: args.issueId,
          status: 'PENDING_VERIFY',
          nextAction: `Issue ${args.issueId} not found`,
          reVerifyRequired: false
        };
      }
    
      // Create checkpoint before fix
      await createCheckpoint(args.sessionId);
    
      // Update issue with fix information
      issue.resolution = args.fixDescription;
      issue.status = args.triggerReVerify ? 'RAISED' : 'RESOLVED';  // Keep as RAISED if re-verify needed
    
      // Add transition record
      if (!issue.transitions) {
        issue.transitions = [];
      }
      issue.transitions.push({
        type: 'REFINED',
        fromStatus: 'RAISED',
        toStatus: args.triggerReVerify ? 'RAISED' : 'RESOLVED',
        round: session.currentRound,
        reason: `Fix applied: ${args.fixDescription}`,
        triggeredBy: 'verifier',
        timestamp: new Date().toISOString()
      });
    
      await upsertIssue(args.sessionId, issue);
    
      // Refresh context for modified files
      if (args.filesModified.length > 0) {
        const updatedSession = await getSession(args.sessionId);
        if (updatedSession) {
          // Re-read modified files into context
          for (const filePath of args.filesModified) {
            // Remove old content
            updatedSession.context.files.delete(filePath);
          }
          // Re-add with updated content
          await expandContext(args.sessionId, args.filesModified, session.currentRound);
    
          // Run pre-analysis on modified files
          const preAnalysis = analyzeContextForIssues(updatedSession.context);
          const newFindings = preAnalysis
            .filter(r => args.filesModified.some((f: string) => r.file.includes(f)))
            .reduce((sum, r) => sum + r.findings.length, 0);
    
          if (newFindings > 0) {
            return {
              success: true,
              issueId: args.issueId,
              status: 'PENDING_VERIFY',
              nextAction: `Fix applied but pre-analysis found ${newFindings} new potential issues in modified files. Re-verification recommended.`,
              reVerifyRequired: true
            };
          }
        }
      }
    
      const nextAction = args.triggerReVerify
        ? 'Submit a Verifier round to verify the fix is complete and correct'
        : 'Issue marked as resolved. Continue with remaining issues or end session.';
    
      return {
        success: true,
        issueId: args.issueId,
        status: args.triggerReVerify ? 'PENDING_VERIFY' : 'RESOLVED',
        nextAction,
        reVerifyRequired: args.triggerReVerify ?? true
      };
    }
  • Zod schema for the ApplyFix tool: sessionId, issueId, fixDescription, filesModified (array of strings), and optional triggerReVerify (default true).
    export const ApplyFixSchema = z.object({
      sessionId: z.string().describe('Session ID'),
      issueId: z.string().describe('Issue ID being fixed'),
      fixDescription: z.string().describe('Description of the fix applied'),
      filesModified: z.array(z.string()).describe('List of files modified'),
      triggerReVerify: z.boolean().optional().default(true).describe('Whether to trigger re-verification after fix')
    });
  • Registers 'elenchus_apply_fix' in the issueManagementTools dictionary with description, ApplyFixSchema, and applyFix handler.
    elenchus_apply_fix: {
      description: 'Apply a fix for an issue within the current session. Creates checkpoint, updates issue status, refreshes file context, and optionally triggers re-verification. Use this to maintain fix-verify continuity without starting new sessions.',
      schema: ApplyFixSchema,
      handler: applyFix
    }
  • The tools object composes issueManagementTools (which includes elenchus_apply_fix) along with other tool modules.
    export const tools = {
      ...sessionLifecycleTools,
      ...issueManagementTools,
      ...mediatorTools,
      ...roleTools,
      ...reverifyTools,
      ...diffTools,
      ...cacheTools,
      ...pipelineTools,
      ...safeguardsTools,
      ...optimizationTools,
      ...dynamicRoleTools,
      ...llmEvalTools,
    };
  • Re-exports the applyFix handler function for direct imports from the tools package.
    export { getIssues, checkpoint, rollback, applyFix } from './issue-management.js';
Behavior4/5

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

With no annotations, the description carries full burden and discloses multiple behavioral traits: creates checkpoint, updates issue status, refreshes file context, optionally triggers re-verification. Does not cover error conditions or authorization needs, but provides strong transparency for core actions.

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?

Two concise sentences, first states action and sub-actions, second provides usage guidance. No redundant words, every sentence earns its place.

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?

Covers main functionality and usage context. Missing output details (no output schema), but given it's an action tool, the description is sufficiently complete for an agent to understand purpose and 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?

Schema coverage is 100%, baseline is 3. Description adds value by explaining the integrated workflow (fix application, checkpoint, context refresh), giving higher-level context to parameters like sessionId and issueId beyond their schema descriptions.

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?

Clearly states the tool applies a fix for an issue within the current session, lists specific sub-actions (creates checkpoint, updates issue status, etc.), and distinguishes from siblings by emphasizing continuity without starting new sessions.

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?

Provides explicit guidance on when to use: to maintain fix-verify continuity within a session. Explicitly contrasts with starting new sessions, but does not mention when not to use or list alternative tools.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jhlee0409/elenchus-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server