Skip to main content
Glama

🌐 DocuMind MCP サーバー

「ドキュメントとデジタルインテリジェンスが出会う場所」

高度なニューラル処理を通じてドキュメント品質分析に革命をもたらす次世代のモデル コンテキスト プロトコル (MCP) サーバー。

⚡ コアシステム

  • 🧠ニューラルドキュメント分析:包括的なREADME評価のための高度なアルゴリズム

  • 🔮ホログラフィックヘッダースキャン:視覚要素のための最先端のSVG分析

  • 🌍多次元言語サポート:言語間のドキュメント検証

  • 💫量子提案エンジン:AIを活用した改善提案

Related MCP server: Lucidity MCP

🚀 システムブートシーケンス

システム要件

  • Node.js 18歳以上

  • npm || 糸

コアの初期化

npm install

コンパイルマトリックス

npm run build

神経発達リンク

リアルタイムのニューラル接続を確立:

npm run watch

🛸 操作プロトコル

システム構成

Claude Desktop メインフレームとの統合:

Windowsターミナル:

// %APPDATA%/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "documind-mcp-server": {
      "command": "/path/to/documind-mcp-server/build/index.js"
    }
  }
}

神経インターフェースコマンド

評価_readme

ドキュメント構造の量子分析を開始します。

パラメータ:

  • projectPath : ターゲットディレクトリへの神経経路

リクエスト例:

{
  name: "evaluate_readme",
  arguments: {
    projectPath: "/path/to/project"
  }
}

応答例:

{
  content: [
    {
      type: "text",
      text: JSON.stringify({
        filePath: "/path/to/project/README.md",
        hasHeaderImage: true,
        headerImageQuality: {
          hasGradient: true,
          hasAnimation: true,
          // ... other quality metrics
        },
        score: 95,
        suggestions: [
          "Consider adding language badges",
          // ... other suggestions
        ]
      })
    }
  ]
}

🔮 開発マトリックス

デバッグプロトコル

MCP Inspector を通じてニューラル ネットワークにアクセスします。

npm run inspector

トラブルシューティングガイド

よくある問題と解決策

  1. ヘッダー画像が検出されません

    • SVGファイルがassets/ディレクトリに配置されていることを確認する

    • SVGファイルに適切なXML構造が含まれていることを検証する

    • ファイルの権限を確認する

  2. 言語バッジが認識されない

    • バッジがshields.io形式を使用していることを確認する

    • HTML構造が推奨パターンに従っているか確認する

    • 適切な中心位置合わせを確保する

  3. ビルドエラー

    • node_modulesをクリアして依存関係を再インストールする

    • TypeScript のバージョンがプロジェクト要件と一致していることを確認する

    • 変更されたファイルの構文エラーをチェックする

  4. MCP 接続の問題

    • stdioトランスポート構成を確認する

    • Claude Desktopの設定を確認する

    • 設定で適切なファイルパスを確認する

パフォーマンスの最適化

  1. SVG分析

    • SVGの複雑さを最小限に抑えて解析を高速化する

    • 効率的なグラデーションとアニメーションを使用する

    • 品質を維持しながらファイルサイズを最適化

  2. READMEスキャン

    • 最適な解析のためにコンテンツを構造化する

    • 推奨されるマークダウンパターンを使用する

    • バッジの配置ガイドラインに従う

🔬 APIドキュメント

コアクラス

リードミーサービス

README の分析と評価のための主要なサービス。

class ReadmeService {
  // Analyzes all README files in a project
  async evaluateAllReadmes(projectPath: string): Promise<ReadmeEvaluation[]>
  
  // Evaluates a single README file
  private async evaluateReadme(dirPath: string, readmePath: string): Promise<ReadmeEvaluation>
  
  // Evaluates language badge configuration
  private evaluateLanguageBadges(content: string): BadgeEvaluation
}

SVGサービス

SVG ヘッダー画像分析に特化したサービスです。

class SVGService {
  // Evaluates SVG header image quality
  public evaluateHeaderImageQuality(imgSrc: string, content: string): HeaderImageQuality
  
  // Checks for project-specific elements in SVG
  private checkProjectSpecificImage(svgContent: string, readmeContent: string): boolean
}

コアインターフェース

interface ReadmeEvaluation {
  filePath: string;
  hasHeaderImage: boolean;
  headerImageQuality: HeaderImageQuality;
  isCentered: {
    headerImage: boolean;
    title: boolean;
    badges: boolean;
  };
  hasBadges: {
    english: boolean;
    japanese: boolean;
    isCentered: boolean;
    hasCorrectFormat: boolean;
  };
  score: number;
  suggestions: string[];
}

interface HeaderImageQuality {
  hasGradient: boolean;
  hasAnimation: boolean;
  hasRoundedCorners: boolean;
  hasEnglishText: boolean;
  isProjectSpecific: boolean;
}

エラー処理

サーバーは包括的なエラー処理を実装します。

try {
  const evaluations = await readmeService.evaluateAllReadmes(projectPath);
  // Process results
} catch (error) {
  const errorMessage = error instanceof Error ? error.message : String(error);
  return {
    content: [{
      type: 'text',
      text: `Evaluation error: ${errorMessage}`
    }],
    isError: true
  };
}

⚡ ライセンス

MIT プロトコルに従って動作します。

Available Tools

1 tool
evaluate_readmeC

リポジトリ内の全てのREADMEファイルの構成を評価し、改善点を提案します

ParametersJSON Schema
NameRequiredDescriptionDefault
projectPathYesプロジェクトのルートディレクトリパス

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 mentions evaluation and proposal of improvements but does not specify how the evaluation is performed (e.g., criteria, depth), what format the proposals take, whether it modifies files or only reports, or any constraints like rate limits or permissions needed. This leaves significant gaps in understanding 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 in Japanese that directly states the tool's function without unnecessary words. It is front-loaded with the core action and outcome, making it easy to parse. This minimal structure earns a top score for conciseness.

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 (evaluating and proposing improvements for README files) and the absence of annotations and output schema, the description is insufficient. It lacks details on evaluation criteria, output format, behavioral traits, and usage context. Without this information, an AI agent would struggle to understand the full scope and limitations of the tool.

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 input schema has 100% description coverage, with the single parameter 'projectPath' clearly documented as 'プロジェクトのルートディレクトリパス' (project root directory path). The description does not add any additional meaning or context beyond what the schema provides, such as examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter semantics.

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 tool's purpose: 'evaluate the structure of all README files in a repository and propose improvements.' It specifies the verb ('evaluate'), resource ('README files'), and outcome ('propose improvements'), making the intent unambiguous. However, since there are no sibling tools, it cannot demonstrate differentiation from alternatives, which prevents a perfect score.

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, prerequisites, or exclusions. It simply states what the tool does without context for its application. This lack of usage instructions limits its effectiveness for an AI agent in selecting the right tool for a scenario.

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. 1 tool updatev1.0.0
    • First observedevaluate_readme

TDQS

B3/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap between tools. The tool has a single, clear purpose of evaluating README files in repositories.

Naming Consistency5/5

A single tool inherently has perfect naming consistency, as there are no other tools to compare against. The name 'evaluate_readme' follows a clear verb_noun pattern.

Tool Count2/5

One tool is too few for a server named 'DocuMind MCP Server', which suggests a broader documentation-related purpose. This feels thin and limited in scope, lacking coverage for other documentation tasks.

Completeness1/5

The server is severely incomplete for its implied domain of documentation management. It only handles README evaluation, missing obvious gaps like creating, updating, or analyzing other documentation types, or managing documentation workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers