Skip to main content
Glama

telegraph_create_page

Create a new Telegraph page with HTML or Markdown content, specifying title, author details, and format to publish content online.

Instructions

Create a new Telegraph page. Returns a Page object including the URL of the created page.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
access_tokenYesAccess token of the Telegraph account
titleYesPage title (1-256 characters)
contentYesPage content - can be HTML string (e.g., "<p>Hello <b>world</b></p>"), Markdown string, or JSON array of Node objects
formatNoContent format: "html" or "markdown" (default: "html")html
author_nameNoAuthor name displayed below the title (0-128 characters)
author_urlNoProfile link opened when users click on the author name (0-512 characters)
return_contentNoIf true, the content field will be returned in the Page object

Implementation Reference

  • Tool handler case that validates input, parses content, calls the createPage API wrapper, and returns the result as a text content block.
    case 'telegraph_create_page': {
      const input = CreatePageSchema.parse(args);
      const content = telegraph.parseContent(input.content, input.format);
      const result = await telegraph.createPage(
        input.access_token,
        input.title,
        content,
        input.author_name,
        input.author_url,
        input.return_content
      );
      return {
        content: [{
          type: 'text' as const,
          text: JSON.stringify(result, null, 2),
        }],
      };
    }
  • Tool registration definition in the pageTools array, including name, description, and JSON input schema.
    {
      name: 'telegraph_create_page',
      description: 'Create a new Telegraph page. Returns a Page object including the URL of the created page.',
      inputSchema: {
        type: 'object' as const,
        properties: {
          access_token: {
            type: 'string',
            description: 'Access token of the Telegraph account',
          },
          title: {
            type: 'string',
            description: 'Page title (1-256 characters)',
            minLength: 1,
            maxLength: 256,
          },
          content: {
            type: 'string',
            description: 'Page content - can be HTML string (e.g., "<p>Hello <b>world</b></p>"), Markdown string, or JSON array of Node objects',
          },
          format: {
            type: 'string',
            description: 'Content format: "html" or "markdown" (default: "html")',
            enum: ['html', 'markdown'],
            default: 'html',
          },
          author_name: {
            type: 'string',
            description: 'Author name displayed below the title (0-128 characters)',
            maxLength: 128,
          },
          author_url: {
            type: 'string',
            description: 'Profile link opened when users click on the author name (0-512 characters)',
            maxLength: 512,
          },
          return_content: {
            type: 'boolean',
            description: 'If true, the content field will be returned in the Page object',
            default: false,
          },
        },
        required: ['access_token', 'title', 'content'],
      },
    },
  • Zod schema for input validation, parsed in the handler.
    export const CreatePageSchema = z.object({
      access_token: z.string().describe('Access token of the Telegraph account'),
      title: z.string().min(1).max(256).describe('Page title (1-256 characters)'),
      content: z.string().describe('Page content - can be HTML string, Markdown string, or JSON array of Node objects'),
      format: z.enum(['html', 'markdown']).optional().default('html').describe('Content format: "html" or "markdown" (default: "html")'),
      author_name: z.string().max(128).optional().describe('Author name (0-128 characters)'),
      author_url: z.string().max(512).optional().describe('Profile link (0-512 characters)'),
      return_content: z.boolean().optional().describe('If true, content field will be returned in the Page object'),
    });
  • Low-level API wrapper function that makes the POST request to Telegraph's createPage endpoint.
    export async function createPage(
      access_token: string,
      title: string,
      content: Node[],
      author_name?: string,
      author_url?: string,
      return_content?: boolean
    ): Promise<Page> {
      return apiRequest<Page>('createPage', {
        access_token,
        title,
        content,
        author_name,
        author_url,
        return_content,
      });
    }
  • Utility function called by handler to parse input content into Telegraph Node array, supporting HTML, Markdown, or JSON.
    export function parseContent(content: string | Node[], format: 'html' | 'markdown' = 'html'): Node[] {
      if (Array.isArray(content)) {
        return content;
      }
    
      // Try to parse as JSON first (in case it's a stringified Node array)
      try {
        const parsed = JSON.parse(content);
        if (Array.isArray(parsed)) {
          return parsed;
        }
      } catch {
        // Not JSON, continue with string parsing
      }
    
      // Convert markdown to HTML if format is markdown
      let htmlContent = content;
      if (format === 'markdown') {
        htmlContent = markdownToHtml(content);
      }
    
      // Convert HTML to nodes
      return htmlToNodes(htmlContent);
    }
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 creates a page and returns a Page object with URL, but omits critical details: whether this is a mutating operation (implied but not explicit), authentication requirements (though hinted via 'access_token' in schema), rate limits, error conditions, or what happens on failure. For a creation tool with zero annotation coverage, this leaves significant gaps.

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 two concise sentences with zero waste: the first states the action and resource, the second specifies the return value. It is front-loaded with the core purpose and efficiently structured, earning its place without redundancy.

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?

Given the tool's complexity (7 parameters, creation operation) and lack of annotations and output schema, the description is minimally adequate. It covers the basic purpose and return value, but misses behavioral context (e.g., side effects, auth needs) and doesn't compensate for the absence of output schema details. It's complete enough to understand what it does, but not how it behaves or what to expect fully.

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 fully documents all 7 parameters (e.g., 'access_token' for account, 'title' with length limits, 'content' formats). The description adds no additional parameter semantics beyond what's in the schema, such as explaining relationships between parameters (e.g., how 'format' interacts with 'content'). Baseline 3 is appropriate when schema does the heavy lifting.

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 clearly states the action ('Create a new Telegraph page') and the resource ('Telegraph page'), distinguishing it from siblings like 'telegraph_edit_page' (modification) and 'telegraph_get_page' (retrieval). It specifies the return value ('Returns a Page object including the URL'), which adds precision beyond the basic action.

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 for creating new pages, but provides no explicit guidance on when to use this versus alternatives like 'telegraph_create_from_template' or 'telegraph_edit_page'. It mentions the return value, which hints at its purpose, but lacks clear when/when-not directives or prerequisite context (e.g., needing an account first).

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/NehoraiHadad/telegraph-mcp'

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