de en es ja ko ru zh

DeepWriter MCP Server

Name: DeepWriter MCP Server
Author: deepwriter-ai

Official

by deepwriter-ai

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

DeepWriter MCP 服务器

用于与 DeepWriter API 交互的模型上下文协议 (MCP) 服务器。该服务器通过标准化的 MCP 接口提供用于创建、管理和生成 DeepWriter 项目内容的工具。

特征

项目管理：创建、列出、更新和删除项目
内容生成：使用 DeepWriter 的 AI 为项目生成内容
项目详情：检索有关项目的详细信息
MCP 集成：与 Claude 和其他兼容 MCP 的 AI 助手无缝集成
标准 MCP 功能：实现 MCP 协议版本 2025-03-26
传输支持：用于本地进程通信的 Stdio 传输

Related MCP server: HexagonML ModelManager MCP Server

先决条件

Node.js（v17 或更高版本）
npm（v6 或更高版本）
DeepWriter API 密钥
与 MCP 兼容的客户端（例如 Claude for Desktop）

安装

克隆存储库：

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

安装依赖项：
```
npm install
```
使用您的 DeepWriter API 密钥在根目录中创建一个.env文件：
```
DEEPWRITER_API_KEY=your_api_key_here
```
构建项目：
```
npm run build
```

用法

启动服务器

启动 MCP 服务器：

node build/index.js

服务器将按照 MCP stdio 传输规范在 stdin 上监听 MCP 请求并在 stdout 上做出响应。

连接到 Claude 桌面版

要将 DeepWriter MCP 服务器与 Claude for Desktop 一起使用：

打开您的 Claude for Desktop 配置文件：
- macOS： ~/Library/Application Support/Claude/claude_desktop_config.json
- Windows： %APPDATA%\Claude\claude_desktop_config.json

添加服务器配置：

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

重新启动 Claude for Desktop 以加载新配置。

MCP 协议支持

该服务器实现了 MCP 协议版本 2025-03-26，具有以下功能：

传输：用于本地进程通信的 Stdio 传输
工具：全面支持所有 DeepWriter API 操作
日志记录：具有可配置级别的结构化日志记录

可用工具

1. 列出项目

列出与您的 DeepWriter 帐户相关的所有项目。

{
  "api_key": "your_api_key_here"
}

2. 获取项目详细信息

检索有关特定项目的详细信息。

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

3. 创建项目

创建具有指定标题和电子邮件的新项目。

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

4. 更新项目

使用指定的更改更新现有项目。

{
  "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. 生成工作

使用 DeepWriter 的 AI 为项目生成内容。

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

6. 删除项目

删除项目。

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

发展

项目结构

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

建筑

npm run build

这会将 TypeScript 代码编译为build目录中的 JavaScript。

测试

您可以使用提供的测试脚本在本地测试 MCP 服务器：

node test-mcp-client.js

或者

node test-deepwriter-tools.js

TypeScript 配置

该项目使用 TypeScript、ES 模块和 Node16 模块解析。关键 TypeScript 设置：

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

故障排除

常见问题

API 密钥问题：
- 确保您的 DeepWriter API 密钥在.env文件中正确设置
- 检查 API 密钥是否在工具参数中正确传递
- 验证 API 密钥是否具有必要的权限
连接问题：
- 确保 DeepWriter API 可以通过你的网络访问
- 检查任何可能阻止连接的防火墙或代理设置
- 验证网络连接是否稳定
MCP 协议问题：
- 确保您使用的是兼容的 MCP 客户端
- 检查 stdio 传输是否正确配置
- 验证客户端是否支持协议版本 2025-03-26
参数命名：
- 服务器支持 snake_case ( project_id ) 和 camelCase ( projectId ) 参数名称
- 所有参数区分大小写
- 必需参数不能为空或未定义

调试

要获得详细日志，请使用 DEBUG 环境变量运行服务器：

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

您还可以在以下位置检查 Claude for Desktop 日志：

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

贡献

欢迎社区贡献力量！您可以通过以下方式提供帮助：

提交问题

错误报告
- 使用 GitHub 问题跟踪器
- 包含重现错误的详细步骤
- 提供您的环境详细信息（Node.js 版本、操作系统等）
- 包含相关日志和错误消息
- 使用提供的错误报告模板
功能请求
- 使用带有“增强”标签的 GitHub 问题跟踪器
- 清晰地描述该功能及其用例
- 解释它如何使项目受益
- 使用提供的功能请求模板
安全问题
- 对于安全漏洞，请不要创建公共问题
- 请发送电子邮件至 security@deepwriter.com
- 我们将与您合作解决该漏洞
- 我们遵循负责任的披露惯例

拉取请求

开始之前
- 检查现有问题和 PR，以避免重复工作
- 对于重大变更，请先开 issue 讨论
- 阅读我们的编码标准和 MCP 实施指南
开发过程
- 分叉存储库
- 从main创建新分支
- 遵循我们的编码风格和约定
- 添加新功能测试
- 根据需要更新文档
公共关系要求
- 包括清晰的变更描述
- 链接相关问题
- 添加或更新测试
- 更新文档
- 遵循提交消息约定
- 签署贡献者许可协议（CLA）
代码审查
- 所有 PR 至少需要一次审核
- 解决评论反馈
- 保持 PR 的重点和规模合理
- 对问题和评论做出回应

开发指南

代码风格
- 遵循 TypeScript 最佳实践
- 将 ESLint 与我们的配置结合使用
- 使用 Prettier 格式化代码
- 遵循MCP协议规范
测试
- 为新功能编写单元测试
- 保持或提高测试覆盖率
- 测试 MCP 协议合规性
- 使用多个 Node.js 版本进行测试
文档
- 更新 README.md 以了解面向用户的更改
- 为新代码添加 JSDoc 注释
- 更新 API 文档
- 包括新功能的示例
提交消息
- 遵循常规提交格式
- 适当时参考问题
- 保持提交的集中性和原子性
- 使用清晰的描述性信息

获取帮助

加入我们的 Discord 社区
检查文档
在 GitHub 讨论中提问
参加我们每月的贡献者电话会议

安全

服务器在处理之前验证所有输入
API 密钥永远不会记录或暴露在错误消息中
stdio 传输提供进程隔离
所有外部 API 调用均使用 HTTPS
输入验证可防止注入攻击

执照

麻省理工学院

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.

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

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored 2026-04-18 10:10 across 6 tools

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

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
238
PCD (Portable Context Deck)OAuth
ai.portablecontext
Your portable context layer — load it into any AI.
Knowledge & Memory RAG Systems
1
ContexterOAuth
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 4 months ago (2026-05-30 12:12 UTC)
8 npm
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
-

DeepWriter MCP 服务器

特征

先决条件

安装

用法

启动服务器

连接到 Claude 桌面版

MCP 协议支持

可用工具

1. 列出项目

2. 获取项目详细信息

3. 创建项目

4. 更新项目

5. 生成工作

6. 删除项目

发展

项目结构

建筑

测试

TypeScript 配置

故障排除

常见问题

调试

贡献

提交问题

拉取请求

开发指南

获取帮助

安全

执照

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches