Skip to main content
Glama
deenesjakoruzh
deepwriter-ai

DeepWriter MCP Server

Official
by deepwriter-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

DeepWriter MCP Server

Ein Model Context Protocol (MCP)-Server für die Interaktion mit der DeepWriter-API. Dieser Server bietet Tools zum Erstellen, Verwalten und Generieren von Inhalten für DeepWriter-Projekte über die standardisierte MCP-Schnittstelle.

Merkmale

  • Projektmanagement : Projekte erstellen, auflisten, aktualisieren und löschen

  • Inhaltsgenerierung : Generieren Sie Inhalte für Projekte mithilfe der KI von DeepWriter

  • Projektdetails : Rufen Sie detaillierte Informationen zu Projekten ab

  • MCP-Integration : Nahtlose Integration mit Claude und anderen MCP-kompatiblen KI-Assistenten

  • Standard-MCP-Funktionen : Implementiert MCP-Protokollversion 2025-03-26

  • Transportunterstützung : Stdio-Transport für lokale Prozesskommunikation

Related MCP server: HexagonML ModelManager MCP Server

Voraussetzungen

  • Node.js (v17 oder höher)

  • npm (v6 oder höher)

  • DeepWriter-API-Schlüssel

  • Ein MCP-kompatibler Client (z. B. Claude für Desktop)

Installation

  1. Klonen Sie das Repository:

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

  2. Installieren Sie Abhängigkeiten:

    npm install

  3. Erstellen Sie mit Ihrem DeepWriter-API-Schlüssel eine .env Datei im Stammverzeichnis:

    DEEPWRITER_API_KEY=your_api_key_here

  4. Erstellen Sie das Projekt:

    npm run build

Verwendung

Starten des Servers

Starten Sie den MCP-Server:

node build/index.js

Der Server wartet auf stdin auf MCP-Anfragen und antwortet auf stdout gemäß der MCP-stdio-Transportspezifikation.

Verbindung zu Claude für Desktop herstellen

So verwenden Sie den DeepWriter MCP-Server mit Claude für Desktop:

  1. Öffnen Sie Ihre Claude for Desktop-Konfigurationsdatei:

    • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

    • Windows: %APPDATA%\Claude\claude_desktop_config.json

  2. Fügen Sie die Serverkonfiguration hinzu:

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

  3. Starten Sie Claude für Desktop neu, um die neue Konfiguration zu laden.

MCP-Protokollunterstützung

Dieser Server implementiert das MCP-Protokoll Version 2025-03-26 mit den folgenden Funktionen:

  • Transport : Stdio-Transport für lokale Prozesskommunikation

  • Tools : Vollständige Unterstützung für alle DeepWriter-API-Operationen

  • Protokollierung : Strukturierte Protokollierung mit konfigurierbaren Ebenen

Verfügbare Tools

1. Projekte auflisten

Listet alle Projekte auf, die mit Ihrem DeepWriter-Konto verknüpft sind.

{
  "api_key": "your_api_key_here"
}

2. getProjectDetails

Ruft detaillierte Informationen zu einem bestimmten Projekt ab.

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

3. Projekt erstellen

Erstellt ein neues Projekt mit dem angegebenen Titel und der angegebenen E-Mail.

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

4. Projekt aktualisieren

Aktualisiert ein vorhandenes Projekt mit den angegebenen Änderungen.

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

Generiert Inhalte für ein Projekt mithilfe der KI von DeepWriter.

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

6. Projekt löschen

Löscht ein Projekt.

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

Entwicklung

Projektstruktur

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

Gebäude

npm run build

Dadurch wird der TypeScript-Code im build -Verzeichnis in JavaScript kompiliert.

Testen

Sie können den MCP-Server lokal mit den bereitgestellten Testskripten testen:

node test-mcp-client.js

oder

node test-deepwriter-tools.js

TypeScript-Konfiguration

Das Projekt verwendet TypeScript mit ES-Modulen und Node16-Modulauflösung. Wichtige TypeScript-Einstellungen:

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

Fehlerbehebung

Häufige Probleme

  1. Probleme mit dem API-Schlüssel :

    • Stellen Sie sicher, dass Ihr DeepWriter-API-Schlüssel in der .env Datei korrekt festgelegt ist

    • Überprüfen Sie, ob der API-Schlüssel in den Tool-Argumenten korrekt übergeben wird

    • Überprüfen Sie, ob der API-Schlüssel über die erforderlichen Berechtigungen verfügt

  2. Verbindungsprobleme :

    • Stellen Sie sicher, dass die DeepWriter-API von Ihrem Netzwerk aus zugänglich ist

    • Überprüfen Sie, ob Firewall- oder Proxy-Einstellungen Verbindungen blockieren könnten.

    • Überprüfen Sie, ob Ihre Netzwerkverbindung stabil ist

  3. Probleme mit dem MCP-Protokoll :

    • Stellen Sie sicher, dass Sie einen kompatiblen MCP-Client verwenden

    • Überprüfen Sie, ob der stdio-Transport richtig konfiguriert ist

    • Überprüfen Sie, ob der Client die Protokollversion 2025-03-26 unterstützt.

  4. Parameterbenennung :

    • Der Server unterstützt sowohl snake_case ( project_id ) als auch camelCase ( projectId ) Parameternamen

    • Bei allen Parametern wird zwischen Groß- und Kleinschreibung unterschieden.

    • Erforderliche Parameter dürfen nicht null oder undefiniert sein

Debuggen

Um ausführliche Protokolle zu erhalten, führen Sie den Server mit der Umgebungsvariable DEBUG aus:

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

Sie können die Protokolle von Claude für Desktop auch hier überprüfen:

  • macOS: ~/Library/Logs/Claude/mcp*.log

  • Windows: %APPDATA%\Claude\logs\mcp*.log

Beitragen

Wir freuen uns über Beiträge aus der Community! So können Sie helfen:

Probleme melden

  1. Fehlerberichte

    • Verwenden Sie den GitHub-Issue-Tracker

    • Fügen Sie detaillierte Schritte zur Reproduktion des Fehlers hinzu

    • Geben Sie Ihre Umgebungsdetails an (Node.js-Version, Betriebssystem usw.).

    • Fügen Sie relevante Protokolle und Fehlermeldungen ein

    • Verwenden Sie die bereitgestellte Fehlerberichtsvorlage

  2. Funktionsanfragen

    • Verwenden Sie den GitHub-Issue-Tracker mit dem Label „Verbesserung“

    • Beschreiben Sie die Funktion und ihren Anwendungsfall klar

    • Erklären Sie, welchen Nutzen es für das Projekt hat

    • Verwenden Sie die bereitgestellte Vorlage für Funktionsanforderungen

  3. Sicherheitsprobleme

    • Bei Sicherheitslücken bitte KEIN öffentliches Problem erstellen

    • Senden Sie stattdessen eine E-Mail an security@deewriter.com

    • Wir arbeiten mit Ihnen zusammen, um die Schwachstelle zu beheben

    • Wir befolgen verantwortungsvolle Offenlegungspraktiken

Pull Requests

  1. Bevor es losgeht

    • Überprüfen Sie vorhandene Probleme und PRs, um doppelte Arbeit zu vermeiden

    • Bei größeren Änderungen öffnen Sie zunächst ein Problem, um es zu besprechen

    • Lesen Sie unsere Kodierungsstandards und MCP-Implementierungsrichtlinien

  2. Entwicklungsprozess

    • Forken Sie das Repository

    • Erstellen Sie einen neuen Zweig vom main

    • Befolgen Sie unseren Programmierstil und unsere Konventionen

    • Fügen Sie Tests für neue Funktionen hinzu

    • Aktualisieren Sie die Dokumentation nach Bedarf

  3. PR-Anforderungen

    • Fügen Sie eine klare Beschreibung der Änderungen hinzu

    • Linkbezogene Probleme

    • Tests hinzufügen oder aktualisieren

    • Dokumentation aktualisieren

    • Befolgen Sie die Konventionen für Commit-Nachrichten

    • Unterzeichnen Sie die Contributor License Agreement (CLA)

  4. Code-Überprüfung

    • Alle PRs erfordern mindestens eine Überprüfung

    • Feedback zu Bewertungen ansprechen

    • Halten Sie PRs fokussiert und in angemessener Größe

    • Reagieren Sie auf Fragen und Kommentare

Entwicklungsrichtlinien

  1. Codestil

    • Befolgen Sie die Best Practices für TypeScript

    • Verwenden Sie ESLint mit unserer Konfiguration

    • Code mit Prettier formatieren

    • Befolgen Sie die MCP-Protokollspezifikationen

  2. Testen

    • Schreiben Sie Unit-Tests für neue Funktionen

    • Aufrechterhaltung oder Verbesserung der Testabdeckung

    • Testen der MCP-Protokollkonformität

    • Testen mit mehreren Node.js-Versionen

  3. Dokumentation

    • Aktualisieren Sie README.md für benutzerseitige Änderungen

    • JSDoc-Kommentare für neuen Code hinzufügen

    • API-Dokumentation aktualisieren

    • Fügen Sie Beispiele für neue Funktionen ein

  4. Commit-Nachrichten

    • Befolgen Sie das herkömmliche Commit-Format

    • Verweisen Sie gegebenenfalls auf Probleme

    • Halten Sie Commits fokussiert und atomar

    • Verwenden Sie klare, beschreibende Nachrichten

Hilfe bekommen

  • Treten Sie unserer Discord-Community bei

  • Überprüfen Sie die Dokumentation

  • Stellen Sie Fragen in GitHub-Diskussionen

  • Nehmen Sie an unseren monatlichen Mitarbeitergesprächen teil

Sicherheit

  • Der Server validiert alle Eingaben vor der Verarbeitung

  • API-Schlüssel werden nie protokolliert oder in Fehlermeldungen angezeigt.

  • Der stdio-Transport bietet Prozessisolierung

  • Alle externen API-Aufrufe verwenden HTTPS

  • Eingabevalidierung verhindert Injektionsangriffe

Lizenz

MIT

Available Tools

6 tools
createProjectC

Create a new project

ParametersJSON Schema
NameRequiredDescriptionDefault
api_keyYesThe DeepWriter API key for authentication.
emailYesThe email associated with the project.
titleYesThe 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
NameRequiredDescriptionDefault
api_keyYesThe DeepWriter API key for authentication.
project_idYesThe 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
NameRequiredDescriptionDefault
api_keyYesThe DeepWriter API key for authentication.
is_defaultNoWhether to use default settings (optional, defaults to true).
project_idYesThe 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
NameRequiredDescriptionDefault
api_keyYesThe DeepWriter API key for authentication.
project_idYesThe 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
NameRequiredDescriptionDefault
api_keyYesThe 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
NameRequiredDescriptionDefault
api_keyYesThe DeepWriter API key for authentication.
project_idYesThe ID of the project to update.
updatesYesObject 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.

  1. 6 tool updatesv1.0.0
    • 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 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

Related MCP Connectors

Related MCP Servers

Appeared in Searches