Skip to main content
Glama

plan_conversion

Generate optimal conversion plans for document format changes, ensuring proper workflow and handling complex multi-step transformations between PDF, DOCX, HTML, and Markdown formats.

Instructions

🎯 MANDATORY FIRST STEP - Smart Document Conversion Planner - ⚠️ CRITICAL: This tool MUST be executed BEFORE any document conversion operation! When users request any format conversion (e.g., 'convert MD to PDF', 'DOCX to HTML'), you MUST call this tool first to get the optimal conversion plan, then follow the plan's steps exactly. This ensures proper conversion workflow and handles complex multi-step conversions. For PDF conversions, note that playwright-mcp integration is required for final PDF generation, followed by process_pdf_post_conversion for watermarks/QR codes. Supports all format conversion path planning.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourceFormatYesSource file format (e.g.: pdf, docx, html, markdown, md, txt)
targetFormatYesTarget file format (e.g.: pdf, docx, html, markdown, md, txt)
sourceFileNoSource file path (optional, used to generate specific conversion parameters)
preserveStylesNoWhether to preserve style formatting
includeImagesNoWhether to include images
themeNoConversion theme (applicable to HTML/DOCX output)github
qualityNoConversion quality requirementsbalanced

Implementation Reference

  • Input schema (ConversionRequest) and output schema (ConversionPlan) with supporting types for the plan_conversion tool.
    interface ConversionRequest {
      sourceFormat: string;
      targetFormat: string;
      sourceFile?: string;
      requirements?: {
        preserveStyles?: boolean;
        includeImages?: boolean;
        theme?: string;
        quality?: 'fast' | 'balanced' | 'high';
      };
    }
    
    interface ConversionStep {
      stepNumber: number;
      toolName: string;
      description: string;
      inputFormat: string;
      outputFormat: string;
      parameters: Record<string, any>;
      estimatedTime: string;
      notes?: string;
    }
    
    interface ConversionPlan {
      success: boolean;
      sourceFormat: string;
      targetFormat: string;
      conversionPath: string[];
      steps: ConversionStep[];
      totalSteps: number;
      estimatedTotalTime: string;
      recommendations: string[];
      warnings?: string[];
      error?: string;
    }
  • The handler function that executes the plan_conversion tool logic, planning document format conversion paths using heuristics and predefined mappings.
    async planConversion(request: ConversionRequest): Promise<ConversionPlan> {
      try {
        const sourceFormat = this.normalizeFormat(request.sourceFormat);
        const targetFormat = this.normalizeFormat(request.targetFormat);
    
        // 验证格式支持
        if (!this.isFormatSupported(sourceFormat)) {
          return {
            success: false,
            sourceFormat,
            targetFormat,
            conversionPath: [],
            steps: [],
            totalSteps: 0,
            estimatedTotalTime: '0分钟',
            recommendations: [],
            error: `不支持的源格式: ${sourceFormat}`,
          };
        }
    
        if (!this.isFormatSupported(targetFormat)) {
          return {
            success: false,
            sourceFormat,
            targetFormat,
            conversionPath: [],
            steps: [],
            totalSteps: 0,
            estimatedTotalTime: '0分钟',
            recommendations: [],
            error: `不支持的目标格式: ${targetFormat}`,
          };
        }
    
        // 相同格式
        if (sourceFormat === targetFormat) {
          return {
            success: true,
            sourceFormat,
            targetFormat,
            conversionPath: [sourceFormat],
            steps: [
              {
                stepNumber: 1,
                toolName: 'read_document',
                description: '文件已经是目标格式,无需转换',
                inputFormat: sourceFormat,
                outputFormat: targetFormat,
                parameters: {},
                estimatedTime: '即时',
              },
            ],
            totalSteps: 1,
            estimatedTotalTime: '即时',
            recommendations: ['文件格式已匹配,无需转换'],
          };
        }
    
        // 查找转换路径
        const conversionPath = this.findConversionPath(sourceFormat, targetFormat);
        if (!conversionPath || conversionPath.length === 0) {
          return {
            success: false,
            sourceFormat,
            targetFormat,
            conversionPath: [],
            steps: [],
            totalSteps: 0,
            estimatedTotalTime: '0分钟',
            recommendations: [],
            error: `无法找到从 ${sourceFormat} 到 ${targetFormat} 的转换路径`,
          };
        }
    
        // 生成转换步骤
        const steps = this.generateConversionSteps(conversionPath, request);
        const totalTime = this.calculateTotalTime(steps);
        const recommendations = this.generateRecommendations(sourceFormat, targetFormat, request);
        const warnings = this.generateWarnings(sourceFormat, targetFormat, conversionPath);
    
        return {
          success: true,
          sourceFormat,
          targetFormat,
          conversionPath,
          steps,
          totalSteps: steps.length,
          estimatedTotalTime: totalTime,
          recommendations,
          warnings,
        };
      } catch (error: any) {
        return {
          success: false,
          sourceFormat: request.sourceFormat,
          targetFormat: request.targetFormat,
          conversionPath: [],
          steps: [],
          totalSteps: 0,
          estimatedTotalTime: '0分钟',
          recommendations: [],
          error: `规划转换路径时出错: ${error.message}`,
        };
      }
    }
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates critical behavioral traits: the mandatory sequencing requirement ('MUST be executed BEFORE'), the workflow nature ('get the optimal conversion plan, then follow the plan's steps exactly'), and integration dependencies ('playwright-mcp integration is required for final PDF generation'). However, it doesn't mention rate limits, error handling, or performance characteristics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately front-loaded with the critical 'MANDATORY FIRST STEP' information, but contains some redundancy (e.g., repeating format conversion examples) and could be more streamlined. The emojis and formatting add visual emphasis but don't necessarily improve conciseness. Most sentences earn their place, but some phrasing could be tightened.

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?

Given the complexity of a 7-parameter planning tool with no annotations and no output schema, the description does a good job explaining the tool's role in the workflow, mandatory sequencing, and integration points. However, it doesn't describe what the output plan looks like or how to interpret it, which is a significant gap since there's no output schema to compensate.

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?

The schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions and enums. It mentions format conversion generally but provides no additional syntax, format details, or parameter usage guidance beyond the structured schema.

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 explicitly states the tool's purpose as a 'Smart Document Conversion Planner' that must be executed before any document conversion operation. It specifies the verb ('plan') and resource ('conversion'), and clearly distinguishes it from sibling tools by emphasizing it's a mandatory first step rather than a direct conversion tool like convert_document or convert_markdown_to_pdf.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidelines: 'MUST be executed BEFORE any document conversion operation' and 'When users request any format conversion... you MUST call this tool first.' It also mentions specific follow-up tools for PDF conversions (playwright-mcp integration and process_pdf_post_conversion), giving clear alternatives and sequencing instructions.

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/Tele-AI/doc-ops-mcp'

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