What can you do with this server?

The DeepWriter MCP Server allows users to interact with DeepWriter's AI for project management and content generation via the MCP protocol. It offers several capabilities: * Project Management: Create, list, update, and delete projects * Content Generation: Generate content for projects using DeepWriter's AI * Detailed Project Access: Retrieve specific information about projects * MCP Integration: Works seamlessly with Claude and other MCP-compatible AI assistants The server adheres to MCP protocol standards, ensuring standardized interaction between users and DeepWriter's AI tools.

Which integrations are available for this server?

Offers a Discord community for contributors to get help and engage with the project. Supports environment variable configuration through .env files for storing API keys and other configuration settings. Uses ESLint for code style enforcement and static analysis as part of development guidelines. Uses GitHub for issue tracking, bug reports, feature requests, and pull requests via its repository. Provides specific configuration instructions for macOS systems when connecting to Claude for Desktop. Runs as a Node.js application, requiring v17 or higher for proper functionality. Uses npm (v6 or higher) for package management and dependency installation. Incorporates Prettier for consistent code formatting according to development guidelines. Built with TypeScript, providing type safety and modern JavaScript features.

How do I use DeepWriter MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DeepWriter MCP Server generate content for my sci-fi novel project" 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.

de en es ja ko ru zh

DeepWriter MCP Server

Official

by deepwriter-ai

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

DeepWriter MCP Server

Official Site: DeepWriter.com

Additional Documentation: DeepWriter API Access Docs

A Model Context Protocol (MCP) server for interacting with the DeepWriter API. This server provides tools for creating, managing, and generating content for DeepWriter projects through the standardized MCP interface.

Features

Project Management: Create, list, update, and delete projects
Content Generation: Generate content for projects using DeepWriter's AI
Project Details: Retrieve detailed information about projects
MCP Integration: Seamlessly integrate with Claude and other MCP-compatible AI assistants
Standard MCP Features: Implements MCP protocol version 2025-03-26
Transport Support: Stdio transport for local process communication

Related MCP server: HexagonML ModelManager MCP Server

Prerequisites

Node.js (v17 or higher)
npm (v6 or higher)
DeepWriter API key
An MCP-compatible client (e.g., Claude for Desktop)

Installation

Installing via Smithery

To install deepwriter-mcp for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @deepwriter-ai/deepwriter-mcp --client claude

Manual Installation

Clone the repository:

git clone https://github.com/yourusername/deepwriter-mcp.git
cd deepwriter-mcp

Install dependencies:
```
npm install
```
Create a .env file in the root directory with your DeepWriter API key:
```
DEEPWRITER_API_KEY=your_api_key_here
```
Build the project:
```
npm run build
```

Usage

Starting the Server

Start the MCP server:

node build/index.js

The server will listen on stdin for MCP requests and respond on stdout, following the MCP stdio transport specification.

Connecting to Claude for Desktop

To use the DeepWriter MCP server with Claude for Desktop:

Open your Claude for Desktop configuration file:
- macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
- Windows: %APPDATA%\Claude\claude_desktop_config.json

Add the server configuration:

{
  "mcpServers": {
    "deepwriter": {
      "command": "node",
      "args": ["/ABSOLUTE/PATH/TO/deepwriter-mcp/build/index.js"],
      "env": {
        "DEEPWRITER_API_KEY": "your_api_key_here"
      }
    }
  }
}

Restart Claude for Desktop to load the new configuration.

MCP Protocol Support

This server implements MCP protocol version 2025-03-26 with the following capabilities:

Transport: Stdio transport for local process communication
Tools: Full support for all DeepWriter API operations
Logging: Structured logging with configurable levels

Available Tools

1. listProjects

Lists all projects associated with your DeepWriter account.

{
  "api_key": "your_api_key_here"
}

2. getProjectDetails

Retrieves detailed information about a specific project.

{
  "api_key": "your_api_key_here",
  "project_id": "your_project_id_here"
}

3. createProject

Creates a new project with the specified title and email.

{
  "api_key": "your_api_key_here",
  "title": "Your Project Title",
  "email": "your_email@example.com"
}

4. updateProject

Updates an existing project with the specified changes.

{
  "api_key": "your_api_key_here",
  "project_id": "your_project_id_here",
  "updates": {
    "title": "Updated Project Title",
    "prompt": "Updated project prompt",
    "author": "Updated author name",
    "email": "updated@email.com",
    "model": "Updated model name",
    "outline_text": "Updated outline",
    "style_text": "Updated style guide",
    "supplemental_info": "Updated additional information",
    "work_description": "Updated work description",
    "work_details": "Updated work details",
    "work_vision": "Updated work vision"
  }
}

5. generateWork

Generates content for a project using DeepWriter's AI.

{
  "api_key": "your_api_key_here",
  "project_id": "your_project_id_here",
  "is_default": true // Optional, defaults to true
}

6. deleteProject

Deletes a project.

{
  "api_key": "your_api_key_here",
  "project_id": "your_project_id_here"
}

Development

Project Structure

deepwriter-mcp/
├── src/
│   ├── index.ts              # Main entry point and MCP server setup
│   ├── api/
│   │   └── deepwriterClient.ts  # DeepWriter API client
│   └── tools/                # MCP tool implementations
│       ├── createProject.ts
│       ├── deleteProject.ts
│       ├── generateWork.ts
│       ├── getProjectDetails.ts
│       ├── listProjects.ts
│       └── updateProject.ts
├── build/                    # Compiled JavaScript output
├── test-deepwriter-tools.js  # Tool testing script
├── test-mcp-client.js       # MCP client testing script
└── tsconfig.json            # TypeScript configuration

Building

npm run build

This will compile the TypeScript code into JavaScript in the build directory.

Testing

You can test the MCP server locally using the provided test scripts:

node test-mcp-client.js

node test-deepwriter-tools.js

TypeScript Configuration

The project uses TypeScript with ES modules and Node16 module resolution. Key TypeScript settings:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "Node16",
    "moduleResolution": "Node16",
    "outDir": "./build",
    "strict": true
  }
}

Troubleshooting

Common Issues

API Key Issues:
- Ensure your DeepWriter API key is correctly set in the .env file
- Check that the API key is being passed correctly in tool arguments
- Verify the API key has the necessary permissions
Connection Problems:
- Make sure the DeepWriter API is accessible from your network
- Check for any firewall or proxy settings that might block connections
- Verify your network connection is stable
MCP Protocol Issues:
- Ensure you're using a compatible MCP client
- Check that the stdio transport is properly configured
- Verify the client supports protocol version 2025-03-26
Parameter Naming:
- The server supports both snake_case (project_id) and camelCase (projectId) parameter names
- All parameters are case-sensitive
- Required parameters must not be null or undefined

Debugging

For detailed logs, run the server with the DEBUG environment variable:

DEBUG=deepwriter-mcp:* node build/index.js

You can also check Claude for Desktop logs at:

macOS: ~/Library/Logs/Claude/mcp*.log
Windows: %APPDATA%\Claude\logs\mcp*.log

Contributing

We welcome contributions from the community! Here's how you can help:

Submitting Issues

Bug Reports
- Use the GitHub issue tracker
- Include detailed steps to reproduce the bug
- Provide your environment details (Node.js version, OS, etc.)
- Include relevant logs and error messages
- Use the bug report template provided
Feature Requests
- Use the GitHub issue tracker with the "enhancement" label
- Clearly describe the feature and its use case
- Explain how it benefits the project
- Use the feature request template provided
Security Issues
- For security vulnerabilities, please DO NOT create a public issue
- Email security@deepwriter.com instead
- We'll work with you to address the vulnerability
- We follow responsible disclosure practices

Pull Requests

Before Starting
- Check existing issues and PRs to avoid duplicate work
- For major changes, open an issue first to discuss
- Read our coding standards and MCP implementation guidelines
Development Process
- Fork the repository
- Create a new branch from main
- Follow our coding style and conventions
- Add tests for new features
- Update documentation as needed
PR Requirements
- Include a clear description of changes
- Link related issues
- Add or update tests
- Update documentation
- Follow commit message conventions
- Sign the Contributor License Agreement (CLA)
Code Review
- All PRs require at least one review
- Address review feedback
- Keep PRs focused and reasonable in size
- Be responsive to questions and comments

Development Guidelines

Code Style
- Follow TypeScript best practices
- Use ESLint with our configuration
- Format code with Prettier
- Follow MCP protocol specifications
Testing
- Write unit tests for new features
- Maintain or improve test coverage
- Test MCP protocol compliance
- Test with multiple Node.js versions
Documentation
- Update README.md for user-facing changes
- Add JSDoc comments for new code
- Update API documentation
- Include examples for new features
Commit Messages
- Follow conventional commits format
- Reference issues where appropriate
- Keep commits focused and atomic
- Use clear, descriptive messages

Getting Help

Join our Discord community
Check the documentation
Ask questions in GitHub discussions
Attend our monthly contributor calls

Security

The server validates all inputs before processing
API keys are never logged or exposed in error messages
The stdio transport provides process isolation
All external API calls use HTTPS
Input validation prevents injection attacks

License

MIT

Available Tools

6 tools

createProjectC

Create a new project

ParametersJSON Schema

Name	Required	Description
`api_key`	Yes	The DeepWriter API key for authentication.
`email`	Yes	The email associated with the project.
`title`	Yes	The title for the new project.

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates something, implying a write operation, but doesn't mention authentication needs (though the schema covers this), potential side effects, error conditions, or what the response might look like. This is a significant gap 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.

Conciseness5/5

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

The description is a single, clear sentence with zero wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly without unnecessary elaboration.

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

Completeness2/5

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

Given the complexity of a creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what a 'project' is, what happens after creation, or any behavioral traits beyond the basic action, leaving critical gaps for the agent to operate effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with all three parameters (api_key, email, title) well-documented in the schema. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create a new project' clearly states the action (create) and resource (project), which is adequate. However, it doesn't differentiate from sibling tools like 'updateProject' or specify what constitutes a 'project' in this context, making it somewhat vague but functional.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as 'updateProject' or 'listProjects'. It lacks context about prerequisites, timing, or exclusions, leaving the agent to 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.

deleteProjectC

Delete a project

ParametersJSON Schema

Name	Required	Description	Default
`api_key`	Yes	The DeepWriter API key for authentication.
`project_id`	Yes	The ID of the project to delete.

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. 'Delete a project' implies a destructive, irreversible mutation, but it doesn't specify authentication needs (implied by api_key param), rate limits, error conditions, or what happens upon success (e.g., confirmation message). For a destructive tool, this is insufficient.

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

Conciseness5/5

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

The description is extremely concise with zero wasted words—'Delete a project' is a clear, front-loaded statement. Every word earns its place, making it efficient for quick understanding, though this conciseness comes at the cost of detail.

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

Completeness2/5

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

Given the tool's complexity (destructive mutation with no annotations and no output schema), the description is incomplete. It doesn't cover behavioral aspects like irreversibility, authentication requirements, or response format, leaving gaps that could hinder correct agent usage in a context with siblings like 'updateProject'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with clear descriptions for both parameters (api_key for authentication, project_id for identification). The description adds no additional meaning beyond the schema, but since the schema is comprehensive, a baseline score of 3 is appropriate as it doesn't detract value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Delete a project' clearly states the verb (delete) and resource (project), making the basic purpose understandable. However, it lacks specificity about what 'project' means in this context and doesn't differentiate from sibling tools like 'updateProject' or 'getProjectDetails' beyond the obvious action difference. It's adequate but minimal.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., project must exist), consequences (e.g., irreversible deletion), or when to choose deletion over other operations like updating. With siblings like 'updateProject' and 'deleteProject' available, this gap is significant.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generateWorkC

Generate content for a project

ParametersJSON Schema

Name	Required	Description
`api_key`	Yes	The DeepWriter API key for authentication.
`is_default`	No	Whether to use default settings (optional, defaults to true).
`project_id`	Yes	The ID of the project to generate work for.

TDQS

C2.7/5.0

Behavior2/5

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. 'Generate content' implies a creation or processing action, but the description doesn't specify whether this is a read-only or destructive operation, what permissions are needed, or any rate limits. It lacks essential behavioral context for safe and effective use.

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

Conciseness5/5

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

The description is a single, efficient sentence with no wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly, though it lacks depth.

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

Completeness2/5

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

Given the complexity of a content generation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'content' entails, the format of the output, or any behavioral traits, leaving significant gaps for the agent to operate effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents all parameters (api_key, is_default, project_id) with descriptions. The description adds no additional meaning beyond what the schema provides, such as explaining how parameters interact or their impact on content generation. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Generate content for a project' states a vague purpose with the verb 'generate' and resource 'content for a project', but it lacks specificity about what type of content or how it differs from sibling tools like createProject or updateProject. It doesn't clearly distinguish itself from other project-related operations.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as createProject or updateProject. There are no explicit instructions, prerequisites, or context for usage, leaving the agent to infer based on 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.

getProjectDetailsC

Get detailed information about a specific project

ParametersJSON Schema

Name	Required	Description	Default
`api_key`	Yes	The DeepWriter API key for authentication.
`project_id`	Yes	The ID of the project to retrieve details for.

TDQS

C2.9/5.0

Behavior2/5

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 but lacks details on permissions, rate limits, error handling, or response format. For a read operation without annotations, this leaves significant gaps in understanding how the tool behaves.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.

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

Completeness2/5

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

Given the complexity of a read operation with no annotations and no output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, potential errors, or how results are structured, leaving the agent with insufficient context for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents both parameters ('api_key' for authentication and 'project_id' for identification). The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, resulting in a baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'detailed information about a specific project', making the purpose evident. However, it doesn't distinguish this tool from sibling tools like 'listProjects' or 'updateProject' beyond the basic action, missing explicit differentiation.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a project ID, or contrast it with 'listProjects' for overviews versus details. Without such context, usage is implied but not clarified.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

listProjectsC

List all projects for the authenticated user

ParametersJSON Schema

Name	Required	Description	Default
`api_key`	Yes	The DeepWriter API key for authentication.

TDQS

C2.9/5.0

Behavior2/5

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 it's a list operation (implied read-only) but doesn't mention pagination, sorting, filtering, rate limits, or what the output looks like. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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

Conciseness5/5

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

The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information.

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

Completeness2/5

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

Given no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what the output contains (project list format), whether there are limitations (like max results), or authentication requirements beyond the implied 'authenticated user'. For a tool that likely returns multiple items, more context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (the single parameter 'api_key' is fully described in the schema). The description doesn't add any parameter information beyond what the schema provides. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List') and resource ('projects') with scope ('all projects for the authenticated user'). It distinguishes from siblings like 'getProjectDetails' (which retrieves a specific project) by indicating it returns all projects. However, it doesn't explicitly differentiate from other list-like operations that might exist in the sibling set.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like authentication (though implied by 'authenticated user'), nor does it compare with siblings like 'getProjectDetails' for retrieving specific projects. There's no explicit when/when-not usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

updateProjectC

Update an existing project

ParametersJSON Schema

Name	Required	Description
`api_key`	Yes	The DeepWriter API key for authentication.
`project_id`	Yes	The ID of the project to update.
`updates`	Yes	Object containing fields to update.

TDQS

C2.7/5.0

Behavior2/5

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. 'Update an existing project' implies a mutation operation but doesn't specify permissions required, whether changes are reversible, rate limits, or what happens to fields not included in updates. This leaves significant gaps for an agent to understand the tool's behavior.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero wasted words. It's appropriately front-loaded with the core action and resource, making it easy to parse quickly.

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

Completeness2/5

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

For a mutation tool with 3 parameters, no annotations, no output schema, and multiple sibling tools, the description is inadequate. It doesn't explain what the tool returns, how updates are applied, or provide context about when this tool is appropriate versus alternatives. The high schema coverage helps but doesn't compensate for missing behavioral and usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all 3 parameters (api_key, project_id, updates) and their nested properties. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Update an existing project' clearly states the action (update) and resource (project), but it's vague about what aspects can be updated and doesn't differentiate from sibling tools like createProject or deleteProject. It provides basic purpose but lacks specificity about scope.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like createProject or deleteProject. The description doesn't mention prerequisites (e.g., needing an existing project ID) or contextual factors that would inform 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv1.0.0Aug 14, 2025
- First observedcreateProject
- First observeddeleteProject
- First observedgenerateWork
- First observedgetProjectDetails
- First observedlistProjects
- First observedupdateProject

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no ambiguity: create/delete/update/list projects, get project details, and generate content are all unique operations. The descriptions clearly differentiate between project management and content generation tasks.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with clear, descriptive names. The naming convention is uniform throughout the set, making it easy to understand each tool's function at a glance.

Tool Count5/5

Six tools is well-scoped for a project/content generation server. Each tool earns its place with complete CRUD coverage for projects plus dedicated content generation functionality, avoiding both bloat and insufficiency.

Completeness5/5

The tool surface provides complete CRUD coverage for projects (create, read, update, delete, list) plus content generation capabilities. There are no obvious gaps for the stated domain of project-based writing/content creation.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
PCD (Portable Context Deck)
ai.portablecontext
Your portable context layer — load it into any AI.
Knowledge & Memory RAG Systems
1
Contexter
io.github.maaakso
Share one project context across ChatGPT, Claude, Telegram and any MCP client.
Knowledge & Memory Note Taking
1

Related MCP Servers

MCP Server
RAG Systems Databases File Systems
GobinFan
F
license
B
quality
D
maintenance
Implements the Model Context Protocol (MCP) to provide AI models with a standardized interface for connecting to external data sources and tools like file systems, databases, or APIs.
Updated a year ago (2025-05-05 08:18 UTC)
1
153
-
HexagonML ModelManager MCP
Developer Tools App Automation
hexsupport
F
license
Not graded
quality
D
maintenance
Provides a Model Context Protocol interface for HexagonML ModelManager tools, enabling interaction with machine learning model management functionality through natural language.
Updated 5 months ago (2026-04-10 08:06 UTC)
1
-
Puter MCP Server
AI & Machine Learning Image & Video Processing Speech Processing
tiantian-pago
A
license
Not graded
quality
D
maintenance
Provides AI-powered media generation tools including image, speech, video, OCR, and voice conversion via the Model Context Protocol.
Updated 3 months ago (2026-05-30 12:12 UTC)
16
MIT
Meetup MCP Server
AI & Machine Learning Knowledge & Memory
ajeetraina
F
license
Not graded
quality
D
maintenance
A Model Context Protocol implementation for managing context, prompts, and model interactions in Meetup applications.
Updated a year ago (2025-05-04 16:37 UTC)
1
-

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/deepwriter-ai/Deepwriter-MCP'

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