Skip to main content
Glama

add_paragraph

Insert formatted text paragraphs into Microsoft Word documents programmatically, supporting bold, italic, underline, font customization, color, and alignment options.

Instructions

Add a paragraph of text to the document

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
docIdYesDocument identifier
textYesParagraph text
formattingNoOptional formatting options

Implementation Reference

  • Switch case handler for the 'add_paragraph' tool. Extracts arguments and calls documentManager.addParagraph(), then returns a success message.
    case "add_paragraph":
      documentManager.addParagraph(args.docId, args.text, args.formatting);
      return {
        content: [
          {
            type: "text",
            text: `Paragraph added successfully.`,
          },
        ],
      };
  • Input schema defining the parameters for the add_paragraph tool: required docId and text, optional formatting object.
    inputSchema: {
      type: "object",
      properties: {
        docId: {
          type: "string",
          description: "Document identifier",
        },
        text: {
          type: "string",
          description: "Paragraph text",
        },
        formatting: {
          type: "object",
          description: "Optional formatting options",
          properties: {
            bold: { type: "boolean" },
            italic: { type: "boolean" },
            underline: { type: "boolean" },
            fontSize: { type: "number" },
            font: { type: "string" },
            color: { type: "string", description: "Hex color (e.g., FF0000 for red)" },
            alignment: {
              type: "string",
              enum: ["left", "center", "right", "justified"],
            },
          },
        },
      },
      required: ["docId", "text"],
  • src/index.ts:24-28 (registration)
    Registration of all tools including 'add_paragraph' via the documentTools array provided to the MCP server's ListToolsRequestHandler.
    server.setRequestHandler(ListToolsRequestSchema, async () => {
      return {
        tools: documentTools,
      };
    });
  • Core implementation of adding a formatted paragraph to the document using docx library, called by the tool handler.
    addParagraph(docId: string, text: string, formatting?: FormattingOptions): void {
      const docInfo = this.getDocument(docId);
    
      const textRunOptions: any = { text };
      if (formatting?.bold !== undefined) textRunOptions.bold = formatting.bold;
      if (formatting?.italic !== undefined) textRunOptions.italics = formatting.italic;
      if (formatting?.underline) textRunOptions.underline = {};
      if (formatting?.fontSize !== undefined) textRunOptions.size = formatting.fontSize * 2; // Half-points
      if (formatting?.font !== undefined) textRunOptions.font = formatting.font;
      if (formatting?.color !== undefined) textRunOptions.color = formatting.color;
    
      const textRun = new TextRun(textRunOptions);
    
      const paragraphOptions: any = {
        children: [textRun],
      };
      const alignment = this.getAlignment(formatting?.alignment);
      if (alignment !== undefined) {
        paragraphOptions.alignment = alignment;
      }
    
      const paragraph = new Paragraph(paragraphOptions);
    
      docInfo.paragraphs.push(paragraph);
      this.updateDocument(docId);
    }
  • Type definition for FormattingOptions used in add_paragraph tool schema and implementation.
    export interface FormattingOptions {
      bold?: boolean;
      italic?: boolean;
      underline?: boolean;
      fontSize?: number;
      font?: string;
      color?: string;
      alignment?: "left" | "center" | "right" | "justified";
      highlight?: string;
    }
Behavior2/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 states the tool adds text but doesn't describe where in the document it's added (e.g., at end, at cursor), whether it's a mutation that requires save_document to persist, what happens on error, or any permissions needed. This leaves significant gaps for a write operation.

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 a single, efficient sentence that states the core functionality without waste. It's front-loaded and appropriately sized for a tool with clear parameters in the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like placement, persistence, or error handling, nor does it explain return values. Given the complexity of adding content with optional formatting, more context is needed for effective use.

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 the schema already documents all parameters (docId, text, formatting) thoroughly. The description adds no additional meaning beyond implying 'paragraph' relates to the text parameter, but doesn't clarify formatting usage or parameter interactions. Baseline 3 is appropriate as the schema does the heavy lifting.

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 clearly states the action ('add') and resource ('paragraph of text to the document'), making the purpose immediately understandable. It distinguishes this from sibling tools like add_bullet_list or add_heading by specifying it's for paragraphs, though it doesn't explicitly contrast with alternatives like apply_text_formatting.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., document must exist), when to choose add_paragraph over apply_text_formatting or other content-adding tools, or any constraints on usage.

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/bibash44/word-documet-mcp-server'

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