Provides tools for creating and managing Telegraph accounts and pages, including support for Markdown content conversion, page templates, view statistics, and export/backup functionality through the Telegraph API.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Telegraph MCP Server create a new page titled 'Project Update' with markdown content summarizing this week's progress"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that exposes the Telegraph API as tools for Claude and other LLM clients. This allows AI assistants to create, edit, and manage Telegraph pages programmatically.
This is part of the Telegraph tools ecosystem:
Project | Description | Package |
telegraph-mcp (this) | MCP Server for AI assistants (TypeScript) | |
MCP Server for AI assistants (Python) | ||
JavaScript/TypeScript library | ||
Python library |
Related MCP server: Telegram MCP Server
npx telegraph-mcpOr add to Claude Code:
claude mcp add telegraph -- npx telegraph-mcp13 Telegraph API tools covering all Telegraph functionality
Create and manage Telegraph accounts
Create, edit, and retrieve Telegraph pages
View statistics for pages
Markdown support - Write content in Markdown, automatically converted to Telegraph format
Templates - Pre-built templates for blog posts, documentation, articles, changelogs, and tutorials
Export/Backup - Export pages to Markdown or HTML, backup entire accounts
MCP Resources - Access Telegraph pages as MCP resources
MCP Prompts - Pre-defined prompts for common tasks
# With Claude Code
claude mcp add telegraph -- npx telegraph-mcp
# Or globally
npm install -g telegraph-mcpgit clone https://github.com/NehoraiHadad/telegraph-mcp.git
cd telegraph-mcp
npm install
npm run build
claude mcp add telegraph -- node $(pwd)/dist/index.jsclaude mcp add telegraph -- npx telegraph-mcpAdd this to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"telegraph": {
"command": "npx",
"args": ["-y", "telegraph-mcp"]
}
}
}Tool | Description | Auth Required |
| Create a new Telegraph account | No |
| Update account information | Yes |
| Get account details | Yes |
| Revoke and regenerate access token | Yes |
Tool | Description | Auth Required |
| Create a new Telegraph page (supports Markdown!) | Yes |
| Edit an existing page | Yes |
| Get a page by path | No |
| List all pages for an account | Yes |
| Get view statistics for a page | No |
Tool | Description | Auth Required |
| List all available page templates | No |
| Create a page using a template | Yes |
Tool | Description | Auth Required |
| Export a page to Markdown or HTML | No |
| Backup all pages from an account | Yes |
Use telegraph_create_account with:
- short_name: "MyBot"
- author_name: "AI Assistant"This returns an access_token that you should save for future operations.
Use telegraph_create_page with:
- access_token: "your_token_here"
- title: "My First Telegraph Page"
- content: "<p>Hello <b>world</b>!</p><p>This is my first Telegraph page.</p>"Use telegraph_create_page with:
- access_token: "your_token_here"
- title: "My Markdown Page"
- content: "# Hello World\n\nThis is **bold** and *italic*.\n\n- List item 1\n- List item 2"
- format: "markdown"Use telegraph_create_from_template with:
- access_token: "your_token_here"
- template: "blog_post"
- title: "My Blog Post"
- data: {
"intro": "Welcome to my blog!",
"sections": [
{"heading": "First Section", "content": "Section content here"}
],
"conclusion": "Thanks for reading!"
}Available templates: blog_post, documentation, article, changelog, tutorial
The content parameter accepts:
Markdown (with format: "markdown"): "# Hello\n\n**Bold** and *italic*"
HTML strings: "<p>Hello <b>world</b></p>"
JSON Node arrays: [{"tag": "p", "children": ["Hello ", {"tag": "b", "children": ["world"]}]}]
Syntax | Result |
| H3 heading |
| H4 heading |
| Bold text |
| Italic text |
| Link |
| Image |
| Unordered list |
| Ordered list |
| Blockquote |
| Inline code |
| Code block |
| Horizontal rule |
a, aside, b, blockquote, br, code, em, figcaption, figure, h3, h4, hr, i, iframe, img, li, ol, p, pre, s, strong, u, ul, video
href - for <a> tags
src - for <img>, <video>, <iframe> tags
Access Telegraph pages as MCP resources:
telegraph://page/{path}Example: telegraph://page/Sample-Page-12-15
Available prompts for guided workflows:
Prompt | Description |
| Guide for creating a blog post |
| Guide for creating documentation |
| Summarize an existing page |
# Install dependencies
npm install
# Build TypeScript
npm run build
# Run directly (for testing)
npm startnpx @modelcontextprotocol/inspector node dist/index.jsThis server implements all methods from the Telegraph API:
createAccount - Create a new Telegraph account
editAccountInfo - Update account information
getAccountInfo - Get account details
revokeAccessToken - Revoke access token
createPage - Create a new page
editPage - Edit an existing page
getPage - Get a page
getPageList - Get list of pages
getViews - Get page view statistics
MIT
Backup all pages from a Telegraph account
| Name | Required | Description | Default |
|---|---|---|---|
| access_token | Yes | Access token of the Telegraph account | |
| format | No | Export format | markdown |
| limit | No | Maximum number of pages to export |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does not explain what 'backup' entails (e.g., whether files are saved locally, whether it modifies account state, or what the output format is). The brief phrasing leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no fluff. It efficiently conveys the core purpose, though it could incorporate additional behavioral details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and the tool's potentially impactful operation (bulk backup), the description is too sparse. It omits important details like return value, side effects, and format handling, leaving the agent with insufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameters have descriptions. The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (backup) and resource (all pages from a Telegraph account). However, it does not explicitly differentiate from sibling tools like telegraph_export_page (single page) or telegraph_get_page_list (list without backup), which would help the agent choose correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description only states what it does, without context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Telegraph account. Returns an Account object with access_token that should be saved for future requests.
| Name | Required | Description | Default |
|---|---|---|---|
| short_name | Yes | Account name (1-32 characters) | |
| author_name | No | Default author name used when creating new articles (0-128 characters) | |
| author_url | No | Profile link opened when users click on the author name (0-512 characters) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, description discloses return value and reminds to save access token. Does not mention side effects or constraints, but creation is straightforward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with purpose. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes return type (Account with access_token) and action to take. With 3 params fully documented in schema, no gaps remain for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and describes each parameter with length constraints. Description adds minimal extra meaning (e.g., 'account name' for short_name), but baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'create', resource 'Telegraph account', and outcome 'returns Account with access_token'. Distinguishes from siblings like 'telegraph_edit_account_info'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Usage is implied from the tool's purpose, but no alternatives or contextual hints provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Telegraph page using a template
| Name | Required | Description | Default |
|---|---|---|---|
| access_token | Yes | Access token of the Telegraph account | |
| template | Yes | Template to use | |
| title | Yes | Page title | |
| data | Yes | Template data (fields depend on template type) | |
| author_name | No | Author name | |
| author_url | No | Author URL | |
| return_content | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states the action without disclosing behavioral traits such as authentication requirements, side effects, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that front-loads the key action and resource. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, nested objects, no output schema), the description is too short. It lacks information on return values, error handling, or behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has high coverage (86%) with descriptions for most parameters. The tool description adds no extra meaning beyond what the schema already provides, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (Telegraph page) with the specific method (using a template). It distinguishes from siblings like telegraph_create_page which creates a page without a template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like telegraph_create_page. The description does not mention any prerequisites or context for choosing a template-based creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Telegraph page. Returns a Page object including the URL of the created page.
| Name | Required | Description | Default |
|---|---|---|---|
| access_token | Yes | Access token of the Telegraph account | |
| title | Yes | Page title (1-256 characters) | |
| content | Yes | Page content - can be HTML string (e.g., "<p>Hello <b>world</b></p>"), Markdown string, or JSON array of Node objects | |
| format | No | Content format: "html" or "markdown" (default: "html") | html |
| author_name | No | Author name displayed below the title (0-128 characters) | |
| author_url | No | Profile link opened when users click on the author name (0-512 characters) | |
| return_content | No | If true, the content field will be returned in the Page object |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It mentions creation and return of a Page object with URL, but lacks details on authentication needs (implicit via access_token), idempotency, or rate limits. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that are front-loaded with purpose. No unnecessary words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description provides the core action and return value. However, it could be more complete by noting that access_token must be valid and that content supports multiple formats (though schema already covers format enum). Overall, sufficient for a straightforward creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents parameters. The description adds no extra meaning beyond the schema's descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Create a new Telegraph page') and its output ('Returns a Page object including the URL'). It effectively distinguishes from sibling tools like telegraph_edit_page and telegraph_get_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., telegraph_create_account, telegraph_create_from_template). There is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update information about a Telegraph account. At least one optional parameter must be provided.
| Name | Required | Description | Default |
|---|---|---|---|
| access_token | Yes | Access token of the Telegraph account | |
| short_name | No | New account name (1-32 characters) | |
| author_name | No | New default author name (0-128 characters) | |
| author_url | No | New default profile link (0-512 characters) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present. The description notes the optional parameter constraint but does not disclose other behavioral traits such as whether the update is immediate, if prior values are overwritten, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with two sentences, front-loading the main purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, yet description does not mention return values. For an update operation, some behavioral context is missing, but the operation is relatively simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds little value beyond the schema. The constraint about at least one optional parameter is already evident from the schema (only access_token required). No additional semantic information provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it updates a Telegraph account, with a specific constraint about optional parameters. Distinguishes from create/delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides the constraint that at least one optional parameter must be provided, but does not explicitly guide when to use this tool versus alternatives like create_account or get_account_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit an existing Telegraph page. Returns the updated Page object.
| Name | Required | Description | Default |
|---|---|---|---|
| access_token | Yes | Access token of the Telegraph account | |
| path | Yes | Path to the page (e.g., "Sample-Page-12-15") | |
| title | Yes | Page title (1-256 characters) | |
| content | Yes | Page content - can be HTML string, Markdown string, or JSON array of Node objects | |
| format | No | Content format: "html" or "markdown" (default: "html") | html |
| author_name | No | Author name (0-128 characters) | |
| author_url | No | Profile link (0-512 characters) | |
| return_content | No | If true, content field will be returned in the Page object |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose any behavioral traits such as side effects, idempotency, permissions, or error scenarios (e.g., what happens if the page doesn't exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and to the point. It could include more detail without becoming overly verbose, but it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description only says 'Returns the updated Page object' without detailing its structure. The tool is relatively simple, but combined with missing usage and behavioral guidance, it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for parameters, so baseline is 3. The description adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool edits an existing Telegraph page and returns the updated Page object. It uses a specific verb (edit) and resource (existing Telegraph page), distinguishing it from sibling tools like telegraph_create_page or telegraph_get_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool instead of alternatives (e.g., create_page vs edit_page) or prerequisites. The description is minimal and does not provide context for proper use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a Telegraph page to Markdown or HTML format
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the Telegraph page | |
| format | No | Export format | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It does not disclose whether the export is read-only, requires authentication, or how errors are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal but adequate for a simple export with two parameters, though missing details on output format structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions; description adds no extra meaning beyond stating the formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Export) and the resource (Telegraph page) and specifies output formats (Markdown or HTML), differentiating it from siblings like telegraph_get_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a Telegraph account.
| Name | Required | Description | Default |
|---|---|---|---|
| access_token | Yes | Access token of the Telegraph account | |
| fields | No | List of account fields to return (default: short_name, author_name, author_url) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states 'Get information,' implying a read operation, but fails to mention side effects, authentication details beyond the schema, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no extraneous words. It could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple account info retrieval tool, the description is adequate. However, it lacks details about return values or potential errors, which would be helpful given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters. The description adds no additional meaning beyond what is in the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get information about a Telegraph account' with a specific verb and resource, and it distinguishes itself from sibling tools that perform create, edit, or revoke operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor are there any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Telegraph page by its path. Returns a Page object.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the Telegraph page (e.g., "Sample-Page-12-15") | |
| return_content | No | If true, content field will be returned |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that content is only returned if return_content is true, but does not mention error behavior (e.g., invalid path), rate limits, or authentication requirements. The disclosure is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded. Every word is necessary and directly informative. There is no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially explains the return type ('Page object') but lacks details on how to obtain the path or how this tool fits with siblings. For a simple retrieval tool, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of path and the effect of return_content, but it does not significantly expand beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a Telegraph page by its path and returns a Page object. This directly distinguishes it from sibling tools like create_page, edit_page, or get_page_list, which handle different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a path and want the page, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., get_page_list to obtain paths, or get_views for view counts). No exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of pages belonging to a Telegraph account. Returns a PageList object with total_count and pages array.
| Name | Required | Description | Default |
|---|---|---|---|
| access_token | Yes | Access token of the Telegraph account | |
| offset | No | Sequential number of the first page to be returned (default: 0) | |
| limit | No | Number of pages to be returned (0-200, default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, rate limits, authentication requirements, or any behavioral nuances beyond a basic read operation. The tool is implied to be read-only but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and 30 words, front-loaded with purpose, and contains no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with well-documented parameters and no output schema, the description covers the essential purpose and return type. However, it could include more context about error handling or authentication, but the current content is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all parameters with descriptions (100% coverage), so the description adds no additional meaning. Baseline 3 is appropriate as the schema already provides sufficient documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Get a list of pages') and the resource ('belonging to a Telegraph account'), distinguishing it from sibling tools like telegraph_get_page (single page) or telegraph_create_page. The return type (PageList) is specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool over alternatives, nor are there any preconditions or exclusions mentioned. The required access_token is implied by the schema but not contextualized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the number of views for a Telegraph page. Can filter by year, month, day, or hour.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the Telegraph page | |
| year | No | Year (2000-2100, required if month is passed) | |
| month | No | Month (1-12, required if day is passed) | |
| day | No | Day (1-31, required if hour is passed) | |
| hour | No | Hour (0-24) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states a read operation without disclosing rate limits, error handling, or what happens for invalid pages. The behavioral burden is not met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence, no fluff. Front-loaded with purpose and filter options. Minor improvement could include structure for optional parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details on return value, units, pagination, and error scenarios. Given no output schema and no annotations, the description is insufficient for a tool with 5 parameters and possible time filtering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so baseline is 3. The description adds 'Can filter by year, month, day, or hour' but does not clarify hierarchical dependencies already implied by schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the number of views for a Telegraph page and mentions optional time filters. This distinguishes it from siblings focused on account or page management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or when to apply filters. The purpose is clear but lacks context about alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available page templates with their fields
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'list', implying a safe read, but does not confirm idempotency, auth requirements, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 5 words, no redundant information. Perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple list tool, but lacks mention of how the output relates to sibling tools (e.g., using templates with telegraph_create_from_template). The return format is not described, though no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema coverage is 100% trivially. Per guidelines, baseline for 0 params is 4; the description adds the phrase 'with their fields', which slightly hints at return content but is not necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (available page templates), with the detail 'with their fields', making it distinct from sibling tools that perform other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like telegraph_create_from_template, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Revoke the current access_token and generate a new one. The old token becomes invalid immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| access_token | Yes | Access token of the Telegraph account to revoke |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes that the old token becomes invalid immediately, which is a behavioral trait. However, without annotations, it does not disclose other behaviors like whether the new token is automatically returned, or if the action requires the current token's validity. Moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear, front-loaded sentences with no extra words. Every sentence adds value: the first states the action and result, the second specify invalidation timing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description omits what the tool returns (e.g., the new token). For an agent to use this correctly, knowledge of the response format is crucial. Annotations are absent, and the description leaves a significant gap given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter is fully documented in the schema. The description does not add any additional meaning beyond what the schema provides, hitting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'revoke the current access_token and generate a new one,' clearly identifying the action and resource. It distinguishes from sibling tools like telegraph_create_account. However, it does not clarify what happens to the generated new token (e.g., returned in response), which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as telegraph_create_account or telegraph_get_account_info. The description only states what the tool does, with no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clear and distinct purpose: account management, page operations, template listing, and views. No two tools could be confused for the same action on the same resource.
All tools consistently use the 'telegraph_' prefix followed by a clear verb_noun pattern (e.g., create_account, edit_page, get_views). The naming is uniform and predictable.
With 13 tools, the set is well-scoped for the Telegraph domain, covering account lifecycles, page creation/editing, export, and analytics without being overly large or insufficient.
The toolset covers most core operations: account creation and info, page CRUD (except delete), export, and views. The absence of a delete tool is a minor gap, but the surface is largely complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Publish, update, read, rename, and share single-URL web pages from any AI agent.
Publish, update, list, and delete Markdown pages on Booklet directly from your AI assistant.
Create, edit, preview, publish, and manage web pages from MCP-capable AI clients.
Share HTML/Markdown documents via URL instantly. Create, edit, delete docs from any AI tool.
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
