The Emlog MCP Server enables AI assistants to interact with an Emlog blog system through standardized interfaces for content management and retrieval.
Core Capabilities:
Article Management: Create, update, retrieve, and search blog articles with options for titles, content, categories, tags, and draft status
Comment Management: Add and retrieve comments on articles, with support for replies
Micro-note Creation: Create and manage short updates with privacy settings
File Uploads: Upload images and other media resources to the blog
User Information: Retrieve details about the current user
Content Interaction: Like articles with optional user details
Content Discovery: Search or filter articles by keywords, tags, or categories with pagination and sorting options
Used as the HTTP client for interacting with the Emlog API, enabling article management, comments, and file uploads
Manages environment variables for Emlog API credentials and configuration settings
Integration with GitHub for repository hosting and version control of the Emlog MCP project
Supports Markdown format for creating and editing blog content within Emlog blog system
Runs the Emlog MCP server using Node.js runtime environment to connect AI assistants with Emlog blog systems
Distributes the Emlog MCP server as an npm package for easy installation and updates
Provides type-safe interactions with the Emlog blog platform API through TypeScript implementation
Validates input parameters and API responses for type safety when interacting with Emlog blog systems
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., "@Emlog MCP Server create a new article about AI blogging tools with the title 'Top 5 AI Tools for Bloggers'"
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 Emlog blog system integration service based on Model Context Protocol (MCP), allowing AI assistants to interact with Emlog blogs through standardized interfaces.
Blog Articles (emlog://articles) - Get all blog article lists
Categories (emlog://categories) - Get all category information
Comments (emlog://comments) - Get comment lists (based on latest articles)
Micro Notes (emlog://notes) - Get micro note lists
Draft Articles (emlog://drafts) - Get all draft article lists
User Information (emlog://user) - Get current user information
create_article - Create new blog articles
update_article - Update existing blog articles
get_article - Get specific article details
search_articles - Search articles (supports keyword, tag, category filtering)
like_article - Like articles
add_comment - Add comments
get_comments - Get comment lists for specific articles
create_note - Create micro notes
upload_file - Upload files (images and other media resources)
get_user_info - Get user information
get_draft_list - Get draft article lists
get_draft_detail - Get detailed information of specific drafts
Related MCP server: MCP Blogger Posting Server
TypeScript - Type-safe JavaScript superset
Node.js - JavaScript runtime environment
MCP SDK - Model Context Protocol TypeScript SDK
Axios - HTTP client library
Zod - TypeScript-first schema validation library
form-data - Multipart form data processing
Use emlog-mcp directly in Claude Desktop configuration without local installation. Jump to MCP Client Configuration section.
git clone https://github.com/eraincc/emlog-mcp.git
cd emlog-mcpnpm installCopy the example configuration file and edit:
cp .env.example .envSet the following environment variables in the .env file:
# Emlog API base URL (required)
EMLOG_API_URL=https://your-emlog-site.com
# Emlog API key (required)
EMLOG_API_KEY=your_api_key_hereGetting API Key:
Log in to your Emlog backend management system
Go to "Settings" → "API Interface"
Enable API functionality and generate API key
Copy the generated key to the .env file
npm run buildnpm startOr development mode:
npm run devAdd to Claude Desktop configuration file (usually located at ~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"emlog": {
"command": "npx",
"args": ["emlog-mcp"],
"env": {
"EMLOG_API_URL": "https://your-emlog-site.com",
"EMLOG_API_KEY": "your_api_key_here"
}
}
}
}Note: The configuration now directly uses the published npm package emlog-mcp, no local installation or compilation required. npx will automatically download and run the latest version.
The project also provides an example configuration file claude-desktop-config.json for reference.
For other MCP-supporting clients, please refer to their respective documentation for stdio transport configuration.
This service is built on Emlog's REST API, supporting the following main operations:
GET /api/article_list - Get article lists
GET /api/article_view - Get specific article details
POST /api/article_save - Create/update articles
POST /api/article_like - Like articles
GET /api/draft_list - Get draft lists
GET /api/draft_detail - Get specific draft details
GET /api/sort_list - Get category lists
GET /api/comment_list - Get comment lists
POST /api/comment_save - Publish comments
GET /api/note_list - Get micro note lists
POST /api/note_save - Publish micro notes
POST /api/upload - Upload files
GET /api/userinfo - Get user information
// Through MCP tool call
{
"name": "create_article",
"arguments": {
"title": "My New Article",
"content": "This is the article content, supporting HTML and Markdown formats.",
"sort_id": 1,
"tag": "technology,programming,MCP",
"is_private": "n",
"allow_comment": "y"
}
}// Search articles containing keywords
{
"name": "search_articles",
"arguments": {
"keyword": "technology",
"page": 1,
"count": 10
}
}// Through MCP resource access
{
"uri": "emlog://articles"
}// Get draft list
{
"name": "get_draft_list",
"arguments": {
"count": 10
}
}// Get detailed information of specific draft
{
"name": "get_draft_detail",
"arguments": {
"id": 123
}
}// Upload image file
{
"name": "upload_file",
"arguments": {
"file_path": "/path/to/image.jpg"
}
}// Publish micro note
{
"name": "create_note",
"arguments": {
"content": "This is a micro note",
"is_private": false
}
}The service includes comprehensive error handling mechanisms:
Network Errors - Automatic retry and timeout handling
API Errors - Detailed error information return
Authentication Errors - API key validation failure prompts
Parameter Errors - Input parameter validation and prompts
# Build project
npm run build
# Start service
npm start
# Development mode (auto restart)
npm run dev
# Watch mode (auto compile)
npm run watch
# Run tests
npm testThe service outputs runtime status information to stderr for debugging:
Emlog MCP server running on stdioThe project includes a simple test script test-server.js to verify if the service is working properly:
node test-server.jsAPI Key Protection - Ensure API keys are not leaked, use environment variables for storage
HTTPS Connection - Recommend using HTTPS connection to Emlog API in production
Permission Control - Ensure API keys have appropriate permission scope
Input Validation - All user inputs are validated and sanitized
Connection Failure
Check if EMLOG_API_URL is correct
Confirm Emlog site is accessible
Authentication Failure
Verify if EMLOG_API_KEY is valid
Check API key permissions
Tool Call Failure
Check specific reasons in error messages
Confirm parameter format is correct
emlog-mcp/
├── src/ # Source code directory
│ ├── index.ts # MCP service main entry
│ └── emlog-client.ts # Emlog API client
├── dist/ # Compiled output directory
├── docs/ # Documentation directory
│ └── api_doc.md # Detailed Emlog API documentation
├── .env.example # Environment variable example file
├── .gitignore # Git ignore file configuration
├── claude-desktop-config.json # Claude Desktop configuration example
├── test-server.js # Test script
├── package.json # Project configuration and dependencies
├── tsconfig.json # TypeScript configuration
└── README.md # Project documentationWelcome to submit Issues and Pull Requests to improve this project. Before submitting code, please ensure:
Code passes TypeScript compilation checks
Follows project code style
Adds appropriate error handling
Updates relevant documentation
MIT License
Add a comment to an article
| Name | Required | Description | Default |
|---|---|---|---|
| commail | No | Email of the commenter | |
| comment | Yes | The comment content | |
| comname | Yes | Name of the commenter | |
| comurl | No | Website URL of the commenter | |
| gid | Yes | The ID of the article to comment on | |
| pid | No | Parent comment ID for replies |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool adds a comment but doesn't describe what happens after submission (e.g., comment appears publicly, requires moderation, triggers notifications). For a mutation tool with zero annotation coverage, this lack of behavioral details is a significant gap.
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, direct sentence with zero wasted words. It front-loads the core action ('Add a comment') and target ('to an article'), making it immediately scannable and efficient for an agent.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, error conditions, or return values. While the schema covers parameters well, the overall context for safe and effective use is lacking.
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 description coverage is 100%, with each parameter clearly documented in the schema (e.g., 'gid' as article ID, 'pid' for replies). The description adds no parameter-specific information beyond implying 'gid' is needed to target an article. This meets the baseline of 3 since the schema does the heavy lifting.
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 ('Add') and target ('comment to an article'), making the purpose immediately understandable. It distinguishes from siblings like 'create_article' or 'update_article' by focusing specifically on commenting functionality. However, it doesn't explicitly differentiate from potential comment-related tools like 'reply_to_comment' (though none exist in siblings), keeping it from a perfect score.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., article must exist), exclusions (e.g., cannot comment on drafts), or related tools like 'get_comments' for viewing comments. Without such context, the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new blog article
| Name | Required | Description | Default |
|---|---|---|---|
| allow_remark | No | Whether to allow comments | |
| content | Yes | The content of the article | |
| cover | No | The cover image URL | |
| draft | No | Whether to save as draft (y) or publish (n) | |
| excerpt | No | The excerpt/summary of the article | |
| sort_id | No | The category ID for the article | |
| tags | No | Comma-separated tags for the article | |
| title | Yes | The title of the article | |
| top | No | Whether to pin to homepage |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create a new blog article' implies a write/mutation operation but provides no information about permissions required, whether creation is reversible, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral 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?
The description is maximally concise with a single sentence that gets straight to the point. There's zero wasted language or unnecessary elaboration - it's front-loaded with the essential information about what the tool does.
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 mutation tool with 9 parameters, no annotations, and no output schema, the description is inadequate. It doesn't address behavioral aspects, error conditions, return values, or how this tool relates to siblings. The combination of being a write operation with complex inputs requires more contextual information than provided.
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?
The description adds no parameter information beyond what's already in the schema (which has 100% coverage). All 9 parameters are documented in the schema with descriptions, so the baseline score of 3 is appropriate. The description doesn't provide additional context about parameter relationships, default behaviors, or usage patterns.
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 verb ('Create') and resource ('blog article'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_note' or 'update_article' - it just states the basic function without clarifying what distinguishes this specific article creation tool.
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 provides no guidance on when to use this tool versus alternatives like 'create_note' or 'update_article'. There's no mention of prerequisites, appropriate contexts, or when this specific article creation tool should be chosen over other creation/mutation tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new micro-note
| Name | Required | Description | Default |
|---|---|---|---|
| private | No | Whether the note is private (y) or public (n) | |
| t | Yes | The content of the micro-note |
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 'Create a new micro-note', implying a write/mutation operation, but doesn't disclose any behavioral traits such as permissions required, whether notes are ephemeral or persistent, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in 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?
The description is extremely concise with a single sentence ('Create a new micro-note') that directly states the purpose without any fluff. It is front-loaded and wastes no words, making it efficient for quick understanding. Every word earns its place by conveying essential action and resource 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 tool's mutation nature (creating a note), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like side effects, error handling, or return values, which are critical for an agent to use the tool correctly. The high schema coverage helps with parameters, but overall context for safe and effective usage is lacking.
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 description coverage is 100%, with clear descriptions for both parameters ('t' as content, 'private' with enum values). The description adds no parameter semantics beyond what the schema provides, as it doesn't mention parameters at all. Given high schema coverage, the baseline score of 3 is appropriate, as the schema adequately documents parameters without needing description supplementation.
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 ('new micro-note'), making the purpose immediately understandable. It distinguishes from siblings like 'add_comment' or 'create_article' by specifying 'micro-note' as the resource type. However, it doesn't explicitly differentiate from 'create_article' beyond the resource name, missing a clear distinction in scope or format.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'create_note' over 'create_article' or 'add_comment', nor does it specify prerequisites, contexts, or exclusions for usage. This leaves the agent without explicit direction for tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific article by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the article to retrieve | |
| password | No | Password for protected articles |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool retrieves an article but doesn't describe what happens if the ID is invalid, whether it returns full or partial content, if authentication is needed, or error handling. This leaves significant gaps in understanding the tool's behavior beyond basic retrieval.
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 with a single sentence that directly states the tool's purpose. It's front-loaded with the core action and contains no unnecessary words or redundant information, making it highly efficient for quick understanding.
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 and output schema, the description is incomplete for a retrieval tool. It doesn't explain what is returned (e.g., article content, metadata), error conditions, or authentication needs. For a tool with 2 parameters and no structured behavioral hints, more context is needed to fully understand its operation.
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 description coverage is 100%, so the schema fully documents both parameters ('id' and 'password'). The description adds no additional meaning beyond what's in the schema, such as explaining ID formats or when the password is required. This meets the baseline score of 3 since the schema handles parameter documentation adequately.
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 ('Get') and resource ('a specific article by ID'), making the purpose immediately understandable. It distinguishes from siblings like 'search_articles' by focusing on retrieval of a single item rather than searching multiple. However, it doesn't explicitly contrast with other read operations like 'get_draft_detail' or 'get_comments', which slightly limits differentiation.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'get_article' over 'search_articles' for finding articles, or when to use it versus 'get_draft_detail' for draft content. There are also no prerequisites or exclusions stated, such as requiring authentication or article visibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comments for an article (with pagination support)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the article | |
| page | No | Page number for paginated comments (requires backend pagination enabled) |
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 mentions 'pagination support', which adds some context about handling large datasets, but fails to cover critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or what the return format looks like (e.g., structure of comments).
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 and front-loaded, consisting of a single sentence that directly states the tool's function and key feature (pagination). There is no wasted text, making it efficient for an agent to parse.
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 of a tool that retrieves data with pagination, no annotations, and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., safety, performance), output structure, and usage context, leaving significant gaps for an agent to operate effectively.
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?
The input schema has 100% description coverage, clearly documenting both parameters ('id' and 'page'). The description adds minimal value by implying the tool fetches comments for an article and supports pagination, but doesn't provide additional semantics beyond what the schema already states, such as pagination behavior details or format constraints.
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 purpose with a specific verb ('Get') and resource ('comments for an article'), distinguishing it from siblings like 'get_article' or 'add_comment'. However, it doesn't explicitly differentiate from potential similar tools beyond the sibling list provided, such as if there were a 'get_all_comments' tool.
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 provides no guidance on when to use this tool versus alternatives. It mentions pagination support but doesn't specify when pagination is needed or how it relates to other tools like 'get_article' or 'search_articles', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific draft
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the draft to retrieve |
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 only states it retrieves details without mentioning whether this is a read-only operation, if it requires authentication, what happens if the draft doesn't exist, or the format of the returned details. This leaves significant gaps for a tool that fetches data.
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, straightforward sentence with no wasted words. It's front-loaded and efficiently conveys the core action, making it easy to parse quickly.
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 of fetching specific data, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral aspects like error handling, return format, or authentication needs, which are crucial for proper tool invocation in this context.
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?
The description doesn't add meaning beyond the input schema, which has 100% coverage and clearly documents the 'id' parameter as 'The ID of the draft to retrieve'. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 verb ('Get') and resource ('details of a specific draft'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_draft_list' or 'get_article', which would require more specificity about what 'details' entail.
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. For example, it doesn't explain when to use 'get_draft_detail' versus 'get_draft_list' or 'get_article', nor does it mention prerequisites like needing a draft ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of draft articles
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of drafts to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose permissions, rate limits, pagination, sorting, or return format (e.g., list structure). This is inadequate for a tool with potential complexity in list retrieval.
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, efficient sentence with zero waste. It is front-loaded and appropriately sized for a simple tool, earning full marks for 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?
Given no annotations and no output schema, the description is incomplete. It lacks details on behavior, return values, and usage context, which are essential for an agent to effectively use this tool in a system with multiple article-related siblings.
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 description coverage is 100%, so the schema fully documents the 'count' parameter. The description adds no parameter semantics beyond what the schema provides, meeting the baseline of 3 for high coverage without extra value.
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 verb 'Get' and the resource 'list of draft articles', making the purpose understandable. It distinguishes from siblings like 'get_draft_detail' (specific draft) and 'get_article' (published articles), but could be more specific about scope (e.g., all drafts vs filtered).
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 like 'search_articles' (which might filter drafts) or 'get_draft_detail' (for a single draft). The description implies usage for retrieving drafts but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current user information
| 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 carries the full burden of behavioral disclosure. It states 'Get current user information' but doesn't clarify what 'current' means (e.g., logged-in user, default user), whether it's a read-only operation, what permissions are required, or the format of returned data. This leaves significant gaps in understanding the tool's behavior beyond basic purpose.
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 with a single sentence ('Get current user information'), which is front-loaded and wastes no words. For a simple tool with no parameters, this brevity is effective and appropriate, making it easy to parse quickly.
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 tool's simplicity (0 params, no output schema, no annotations), the description is minimal but incomplete. It lacks details on behavioral aspects like authentication needs, data format, or error handling. While the schema handles inputs, the description should provide more context for a tool that retrieves user information, especially without annotations to fill in gaps.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate here. Baseline is 4 for 0 params, as the schema fully covers the absence of inputs, and the description doesn't need to compensate for any gaps.
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 ('Get') and resource ('current user information'), making the tool's purpose understandable. However, it doesn't differentiate from potential sibling tools that might also retrieve user information (though none are listed in siblings), so it's not fully specific. The verb+resource combination is straightforward but lacks nuance about what 'information' entails.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for 'current user' (e.g., authentication needed), or compare it to other tools like 'get_article' or 'get_comments'. Without such guidance, an agent might struggle to select this tool appropriately in scenarios involving user data retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Like an article
| Name | Required | Description | Default |
|---|---|---|---|
| avatar | No | Avatar URL of the person liking | |
| gid | Yes | The ID of the article to like | |
| name | No | Name of the person liking |
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 but fails to do so. It doesn't reveal if this is a read-only or mutative operation, what permissions are required, potential side effects, or response format, leaving critical behavioral traits unspecified.
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 with a single sentence, 'Like an article,' which is front-loaded and wastes no words. While it lacks substance, it earns full marks for brevity and structure, as every word serves the minimal purpose stated.
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 of a mutative tool with no annotations and no output schema, the description is completely inadequate. It fails to explain what 'liking' entails, the expected outcome, or how it integrates with sibling tools, leaving significant gaps in understanding the tool's role and behavior.
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?
The input schema has 100% description coverage, documenting all three parameters clearly, so the description doesn't need to add parameter details. However, it also doesn't provide any additional context or meaning beyond the schema, such as explaining the relationship between parameters, resulting in a baseline score.
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 'Like an article' is a tautology that merely restates the tool name and title without adding specificity. It doesn't distinguish this tool from sibling tools like 'add_comment' or 'update_article' in terms of action or resource, leaving the purpose vague beyond the basic verb-noun pairing.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as whether it's for authenticated users only or how it differs from related actions like commenting or updating articles, making it misleadingly simplistic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search articles by keyword, tag, or category
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of articles per page | |
| keyword | No | Search keyword for article titles | |
| order | No | Sort order: views (by view count) or comnum (by comment count) | |
| page | No | Page number (default: 1) | |
| sort_id | No | Filter by category ID | |
| tag | No | Filter by tag |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the search functionality but doesn't describe pagination behavior (implied by 'page' parameter), rate limits, authentication requirements, or what the response format looks like (no output schema exists). This leaves significant gaps for a search tool.
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 - a single sentence that efficiently communicates the core functionality. There's no wasted language, and it's appropriately front-loaded with the essential information about what the tool does.
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 search tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the search behavior (AND/OR logic), result format, pagination details, or error conditions. The agent would need to infer too much from just the parameter descriptions.
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 description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description mentions keyword, tag, and category filtering but doesn't add meaningful semantic context beyond what the schema provides about these parameters. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as searching articles using specific criteria (keyword, tag, or category). It uses a specific verb ('Search') and identifies the resource ('articles'), but doesn't explicitly differentiate from sibling tools like 'get_article' which retrieves a single article rather than searching multiple.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_article' for retrieving specific articles or 'get_draft_list' for draft articles, nor does it specify prerequisites or contextual constraints for searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing blog article. If the article is currently a draft and no draft parameter is specified, it will remain as a draft.
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | The new content of the article | |
| cover | No | The new cover image URL | |
| draft | No | Whether to save as draft (y) or publish (n). If not specified and the article is currently a draft, it will remain as a draft. | |
| excerpt | No | The new excerpt/summary | |
| id | Yes | The ID of the article to update | |
| sort_id | No | The new category ID | |
| tags | No | New comma-separated tags | |
| title | Yes | The new title of the article |
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 mentions the draft behavior, which is valuable context about how the tool handles state transitions. However, it doesn't disclose other important behavioral traits like whether this requires authentication, what permissions are needed, whether updates are reversible, rate limits, or what happens to unspecified fields (partial vs. full updates). For a mutation 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two clear sentences. The first sentence states the core purpose, and the second adds important behavioral context about draft handling. There's no wasted language, and the information is front-loaded with the essential action first.
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 mutation tool with no annotations and no output schema, the description provides basic purpose and some behavioral context (draft handling), but it's incomplete. It doesn't cover authentication needs, error conditions, response format, or how partial updates work. Given the complexity of updating an article with 8 parameters, more contextual information would be helpful for the agent to use this tool effectively.
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 description coverage is 100%, so the schema already documents all 8 parameters thoroughly with descriptions, types, and constraints. The description doesn't add any parameter-specific information beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
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 ('Update') and resource ('existing blog article'), making the purpose immediately understandable. It distinguishes from siblings like 'create_article' by specifying it updates existing articles rather than creating new ones. However, it doesn't explicitly differentiate from other update-related tools that might exist in the broader context.
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 provides implied guidance about draft behavior ('If the article is currently a draft and no draft parameter is specified, it will remain as a draft'), which helps understand when to use this tool versus alternatives for publishing. However, it doesn't explicitly state when to use this tool versus other siblings like 'create_article' or provide clear exclusions or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a file (image, document, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Local path to the file to upload | |
| sid | No | Resource category ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('upload') but doesn't describe traits like required permissions, file size limits, supported formats beyond vague examples, error handling, or what happens after upload (e.g., returns a URL or ID). This leaves significant gaps for a mutation tool.
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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to scan. Every word contributes to conveying the basic purpose without unnecessary elaboration.
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 of a file upload tool (a mutation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits, usage context, and output expectations, leaving the agent with insufficient information to invoke it correctly beyond the basic 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?
The schema description coverage is 100%, with clear descriptions for both parameters ('file_path' and 'sid'). The description adds no meaning beyond this, as it doesn't explain parameter interactions, the purpose of 'sid', or file path constraints. With high schema coverage, the 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 states the verb ('upload') and resource ('a file'), but it's vague about what types of files are supported ('image, document, etc.') and doesn't distinguish this tool from potential siblings like 'create_article' or 'create_note', which might also involve file uploads. It provides a basic purpose but lacks specificity.
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. For example, it doesn't clarify if this is for standalone file uploads versus attachments in other tools like 'create_article', or mention prerequisites like authentication. The description offers no context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0add_commentcreate_articlecreate_noteget_articleget_commentsget_draft_detailget_draft_listget_user_infolike_articlesearch_articlesupdate_articleupload_fileMost tools have clearly distinct purposes targeting specific resources like articles, comments, drafts, and files, with minimal overlap. However, 'create_article' and 'create_note' might cause slight confusion if notes are a type of article, but their descriptions help differentiate them as separate entities.
All tools follow a consistent verb_noun naming pattern (e.g., add_comment, create_article, get_draft_list), using snake_case throughout. This predictability makes it easy for agents to understand and select tools based on their actions and targets.
With 12 tools, this server is well-scoped for a blog management system, covering core operations like article CRUD, commenting, drafts, and file uploads. Each tool serves a distinct function without unnecessary bloat, fitting typical workflows for content creation and management.
The toolset provides strong coverage for blog management, including CRUD for articles, comments, drafts, and user info, with search and like functionality. Minor gaps include no update/delete for comments or notes, and no direct management of tags/categories, but agents can work around these with available tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create, manage, publish, and analyze Inblog content through AI agents.
Create, edit, organize, publish, and configure JustBlogged blogs from MCP clients.
Hosted MCP for BlogBat: read, write, generate, and publish blog articles and content.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/eraincc/emlog-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
