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

Сервер Model Context Protocol (MCP) для взаимодействия с API DeepWriter. Этот сервер предоставляет инструменты для создания, управления и генерации контента для проектов DeepWriter через стандартизированный интерфейс MCP.

Функции

Управление проектами : создание, перечисление, обновление и удаление проектов.
Генерация контента : генерация контента для проектов с использованием искусственного интеллекта DeepWriter.
Сведения о проекте : получение подробной информации о проектах.
Интеграция с MCP : бесшовная интеграция с Claude и другими совместимыми с MCP помощниками на базе искусственного интеллекта.
Стандартные функции MCP : Реализует версию протокола MCP 2025-03-26
Поддержка транспорта : транспорт Stdio для локальной связи процессов

Related MCP server: HexagonML ModelManager MCP Server

Предпосылки

Node.js (v17 или выше)
npm (v6 или выше)
API-ключ DeepWriter
Клиент, совместимый с MCP (например, Claude for Desktop)

Установка

Клонируйте репозиторий:

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

Установите зависимости:
```
npm install
```
Создайте файл .env в корневом каталоге с вашим ключом API DeepWriter:
```
DEEPWRITER_API_KEY=your_api_key_here
```
Создайте проект:
```
npm run build
```

Использование

Запуск сервера

Запустите MCP-сервер:

node build/index.js

Сервер будет прослушивать stdin на предмет запросов MCP и отвечать на stdout, следуя спецификации транспорта MCP stdio.

Подключение к 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 со следующими возможностями:

Транспорт : стандартный транспорт для локальной связи процессов
Инструменты : Полная поддержка всех операций API DeepWriter
Ведение журнала : структурированное ведение журнала с настраиваемыми уровнями

Доступные инструменты

1. списокПроекты

Список всех проектов, связанных с вашей учетной записью DeepWriter.

{
  "api_key": "your_api_key_here"
}

2. получитьProjectDetails

Извлекает подробную информацию о конкретном проекте.

{
  "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.

{
  "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 в JavaScript в каталоге build .

Тестирование

Вы можете протестировать сервер 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 :
- Убедитесь, что ваш ключ API DeepWriter правильно установлен в файле .env
- Проверьте правильность передачи ключа API в аргументах инструмента.
- Убедитесь, что ключ API имеет необходимые разрешения.
Проблемы с подключением :
- Убедитесь, что API DeepWriter доступен из вашей сети.
- Проверьте настройки брандмауэра или прокси-сервера, которые могут блокировать соединения.
- Убедитесь, что ваше сетевое соединение стабильно
Проблемы с протоколом 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
- Мы будем работать с вами над устранением уязвимости.
- Мы следуем ответственной практике раскрытия информации

Запросы на извлечение

Перед началом
- Проверьте существующие проблемы и запросы на исправление ошибок, чтобы избежать дублирования работы.
- Для крупных изменений сначала откройте тему для обсуждения
- Ознакомьтесь с нашими стандартами кодирования и рекомендациями по внедрению 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. получитьProjectDetails

3. создатьПроект

4. обновлениеПроекта

5. сгенерироватьРаботу

6. удалитьПроект

Разработка

Структура проекта

Здание

Тестирование

Конфигурация TypeScript

Поиск неисправностей

Общие проблемы

Отладка

Внося вклад

Отправка вопросов

Запросы на извлечение

Руководство по разработке

Получение помощи

Безопасность

Лицензия

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches