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

Servidor MCP de DeepWriter

Un servidor de Protocolo de Contexto de Modelo (MCP) para interactuar con la API de DeepWriter. Este servidor proporciona herramientas para crear, gestionar y generar contenido para proyectos de DeepWriter mediante la interfaz estandarizada de MCP.

Características

Gestión de proyectos : crear, enumerar, actualizar y eliminar proyectos
Generación de contenido : genere contenido para proyectos utilizando la IA de DeepWriter
Detalles del proyecto : recupera información detallada sobre los proyectos
Integración con MCP : se integra perfectamente con Claude y otros asistentes de IA compatibles con MCP
Características estándar de MCP : Implementa el protocolo MCP versión 2025-03-26
Soporte de transporte : transporte Stdio para la comunicación de procesos locales

Related MCP server: HexagonML ModelManager MCP Server

Prerrequisitos

Node.js (v17 o superior)
npm (v6 o superior)
Clave API de DeepWriter
Un cliente compatible con MCP (por ejemplo, Claude for Desktop)

Instalación

Clonar el repositorio:

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

Instalar dependencias:
```
npm install
```
Cree un archivo .env en el directorio raíz con su clave API de DeepWriter:
```
DEEPWRITER_API_KEY=your_api_key_here
```
Construir el proyecto:
```
npm run build
```

Uso

Iniciando el servidor

Inicie el servidor MCP:

node build/index.js

El servidor escuchará en stdin las solicitudes MCP y responderá en stdout, siguiendo la especificación de transporte stdio de MCP.

Conectarse a Claude para escritorio

Para utilizar el servidor MCP de DeepWriter con Claude for Desktop:

Abra el archivo de configuración de Claude for Desktop:
- macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
- Ventanas: %APPDATA%\Claude\claude_desktop_config.json

Agregue la configuración del servidor:

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

Reinicie Claude for Desktop para cargar la nueva configuración.

Compatibilidad con el protocolo MCP

Este servidor implementa el protocolo MCP versión 2025-03-26 con las siguientes capacidades:

Transporte : Transporte de Stdio para la comunicación de procesos locales
Herramientas : Soporte completo para todas las operaciones de la API de DeepWriter
Registro : Registro estructurado con niveles configurables

Herramientas disponibles

1. listaProyectos

Enumera todos los proyectos asociados con su cuenta de DeepWriter.

{
  "api_key": "your_api_key_here"
}

2. obtener detalles del proyecto

Recupera información detallada sobre un proyecto específico.

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

3. crearProyecto

Crea un nuevo proyecto con el título y correo electrónico especificados.

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

4. actualizarProyecto

Actualiza un proyecto existente con los cambios especificados.

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

Genera contenido para un proyecto utilizando la IA de DeepWriter.

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

6. eliminarProyecto

Elimina un proyecto.

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

Desarrollo

Estructura del proyecto

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

Edificio

npm run build

Esto compilará el código TypeScript en JavaScript en el directorio build .

Pruebas

Puede probar el servidor MCP localmente utilizando los scripts de prueba proporcionados:

node test-mcp-client.js

node test-deepwriter-tools.js

Configuración de TypeScript

El proyecto utiliza TypeScript con módulos ES y resolución de módulos Node16. Configuración clave de TypeScript:

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

Solución de problemas

Problemas comunes

Problemas con la clave API :
- Asegúrese de que su clave API de DeepWriter esté configurada correctamente en el archivo .env
- Compruebe que la clave API se esté pasando correctamente en los argumentos de la herramienta
- Verifique que la clave API tenga los permisos necesarios
Problemas de conexión :
- Asegúrese de que la API de DeepWriter sea accesible desde su red
- Compruebe si hay alguna configuración de firewall o proxy que pueda bloquear las conexiones
- Verifique que su conexión de red sea estable
Problemas del protocolo MCP :
- Asegúrese de estar utilizando un cliente MCP compatible
- Compruebe que el transporte stdio esté configurado correctamente
- Verificar que el cliente admita la versión del protocolo 2025-03-26
Nombre de parámetro :
- El servidor admite los nombres de parámetros snake_case ( project_id ) y camelCase ( projectId )
- Todos los parámetros distinguen entre mayúsculas y minúsculas.
- Los parámetros obligatorios no deben ser nulos o indefinidos

Depuración

Para obtener registros detallados, ejecute el servidor con la variable de entorno DEBUG:

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

También puedes consultar los registros de Claude for Desktop en:

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

Contribuyendo

¡Agradecemos las contribuciones de la comunidad! Puedes ayudar de esta manera:

Envío de problemas

Informes de errores
- Utilice el rastreador de problemas de GitHub
- Incluya pasos detallados para reproducir el error.
- Proporcione los detalles de su entorno (versión de Node.js, sistema operativo, etc.)
- Incluir registros y mensajes de error relevantes
- Utilice la plantilla de informe de errores proporcionada
Solicitudes de funciones
- Utilice el rastreador de problemas de GitHub con la etiqueta "mejora"
- Describa claramente la función y su caso de uso.
- Explique cómo beneficia al proyecto.
- Utilice la plantilla de solicitud de función proporcionada
Problemas de seguridad
- Para vulnerabilidades de seguridad, NO cree un problema público.
- En su lugar, envíe un correo electrónico a security@deepwriter.com
- Trabajaremos con usted para abordar la vulnerabilidad.
- Seguimos prácticas de divulgación responsable

Solicitudes de extracción

Antes de empezar
- Verifique los problemas y las relaciones públicas existentes para evitar trabajo duplicado
- Para cambios importantes, primero abra un problema para discutirlo
- Lea nuestros estándares de codificación y pautas de implementación de MCP
Proceso de desarrollo
- Bifurcar el repositorio
- Crear una nueva rama desde main
- Siga nuestro estilo y convenciones de codificación
- Agregar pruebas para nuevas funciones
- Actualice la documentación según sea necesario
Requisitos de relaciones públicas
- Incluya una descripción clara de los cambios
- Problemas relacionados con los enlaces
- Agregar o actualizar pruebas
- Actualizar la documentación
- Seguir las convenciones de mensajes de confirmación
- Firmar el Acuerdo de licencia de colaborador (CLA)
Revisión de código
- Todas las relaciones públicas requieren al menos una revisión
- Comentarios sobre la revisión de la dirección
- Mantenga las relaciones públicas enfocadas y de tamaño razonable
- Responder a preguntas y comentarios

Directrices de desarrollo

Estilo de código
- Siga las mejores prácticas de TypeScript
- Utilice ESLint con nuestra configuración
- Formatear código con Prettier
- Siga las especificaciones del protocolo MCP
Pruebas
- Escribir pruebas unitarias para nuevas funciones
- Mantener o mejorar la cobertura de pruebas
- Prueba de cumplimiento del protocolo MCP
- Prueba con múltiples versiones de Node.js
Documentación
- Actualizar README.md para los cambios que afectan al usuario
- Agregar comentarios JSDoc para el nuevo código
- Actualizar la documentación de la API
- Incluir ejemplos de nuevas funciones
Mensajes de confirmación
- Seguir el formato de confirmaciones convencional
- Cuestiones de referencia cuando corresponda
- Mantenga las confirmaciones enfocadas y atómicas
- Utilice mensajes claros y descriptivos

Obtener ayuda

Únete a nuestra comunidad de Discord
Consulte la documentación
Haz preguntas en las discusiones de GitHub
Asista a nuestras llamadas mensuales para colaboradores

Seguridad

El servidor valida todas las entradas antes de procesarlas
Las claves API nunca se registran ni se exponen en mensajes de error
El transporte stdio proporciona aislamiento del proceso
Todas las llamadas API externas utilizan HTTPS
La validación de entrada previene ataques de inyección

Licencia

Instituto Tecnológico de Massachusetts (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.

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
-

Servidor MCP de DeepWriter

Características

Prerrequisitos

Instalación

Uso

Iniciando el servidor

Conectarse a Claude para escritorio

Compatibilidad con el protocolo MCP

Herramientas disponibles

1. listaProyectos

2. obtener detalles del proyecto

3. crearProyecto

4. actualizarProyecto

5. generarTrabajo

6. eliminarProyecto

Desarrollo

Estructura del proyecto

Edificio

Pruebas

Configuración de TypeScript

Solución de problemas

Problemas comunes

Depuración

Contribuyendo

Envío de problemas

Solicitudes de extracción

Directrices de desarrollo

Obtener ayuda

Seguridad

Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches