en es ja ko zh

DraCor MCP Server

Name: DraCor MCP Server
Author: stijn-meijers

by stijn-meijers

Overview Schema Source Related Servers Discussions Admin

Python

Remote

DraCor MCP 服务器

一个用于与戏剧语料库项目 (DraCor) API 交互的模型上下文协议 (MCP) 服务器。此 MCP 服务器使您能够通过 Claude 或其他 LLM 无缝分析戏剧文本及其人物关系。

概述

该项目使用官方的模型上下文协议 Python SDK 实现了一个 MCP 服务器，该 SDK 允许访问 DraCor API v1。它允许 Claude 和其他法学硕士 (LLM) 与戏剧文本语料库进行交互，分析角色网络，检索剧本信息，并生成关于不同语言和时期戏剧作品的见解。

该项目包括两个实施方案：

dracor_mcp_fastmcp.py - 使用基于 FastMCP 装饰器的 API 和 v1 API 进行精简实现

Related MCP server: MCP-PIF Server

特征

通过统一接口访问 DraCor API v1
无需身份验证（DraCor API 可公开访问）
DraCor 实体的结构化数据模型
运营支持：
- 语料库和戏剧信息检索
- 字符网络分析
- 比赛指标和统计数据
- 角色信息和口语文本
- 比较游戏分析
- 搜索功能
- 人物关系数据
- 多种格式的网络数据（CSV、GEXF、GraphML）
- 跨剧作的性别分析
- 纯文本和 TEI XML 格式的全文检索
- 完整剧本分析

设置

先决条件

Python 3.10 或更高版本
UV 包管理器（推荐）或 pip

紫外线安装

安装UV：

pip install uv

创建虚拟环境并安装依赖项：

uv venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate
uv pip install -e .

在 Claude Desktop 中安装 MCP 服务器：

对于标准实现（v0 API）：

mcp install dracor_mcp_server.py

或者使用 v1 API 实现 FastMCP（推荐）：

mcp install dracor_mcp_fastmcp.py

开发模式

对于测试和开发：

mcp dev dracor_mcp_server.py

或者使用 v1 API 实现 FastMCP（推荐）：

mcp dev dracor_mcp_fastmcp.py

这将启动 MCP 检查器，您可以在其中以交互方式测试您的工具和资源。

克劳德配置

您还可以通过将以下内容添加到 Claude 配置文件中，直接配置 Claude 以使用 DraCor MCP 服务器：

{
  "tools": {
    "DraCor API v1": {
      "command": "uv",
      "args": [
        "run",
        "--with",
        "mcp[cli]",
        "--with",
        "requests",
        "--with",
        "pydantic",
        "--with",
        "python-multipart",
        "mcp",
        "run",
        "/path/to/dracor-mcp/dracor_mcp_fastmcp.py"
      ]
    }
  }
}

将/path/to/dracor-mcp/替换为 dracor-mcp 目录的实际路径。此配置使用uv run执行 MCP 服务器及其必要的依赖项，无需事先安装。

Docker（可选）

如果您更喜欢使用 Docker：

docker build -t dracor-mcp .
docker run dracor-mcp

要使用带有 v1 API 的 FastMCP 实现：

docker run -e IMPLEMENTATION=fastmcp dracor-mcp

实现细节

标准 MCP 实现 (v0 API)

dracor_mcp_server.py中的标准实现使用核心 MCP SDK 类和较旧的 v0 API：

Resource - 用于定义 API 资源
MCPToolImpl - 用于实现工具
PromptTemplate - 用于创建提示模板

FastMCP 实现（v1 API）

dracor_mcp_fastmcp.py中的 FastMCP 实现使用当前 v1 API 的更简洁的基于装饰器的方法：

@mcp.resource() - 用于定义 API 资源
@mcp.tool() - 用于实现工具
@mcp.prompt() - 用于创建提示模板

这种方法可以产生更清晰、更易于维护的代码，同时提供相同的功能，但可以访问更全面的 API 功能。

v1 API 功能

v1 API 实现提供了对许多附加端点和功能的访问：

API 信息- DraCor API 的版本信息
语料库元数据——语料库中所有剧本的详细元数据
播放指标- 网络指标和分析数据
字符网络数据- CSV、GEXF 和 GraphML 格式
人物关系——人物之间的明确关系
口语文本过滤器- 按性别、关系类型或角色进行过滤
舞台指导- 检索有或无演讲者的舞台指导
角色查找- 查找包含特定角色的剧本（通过 Wikidata ID）

用法

在 Claude Desktop 中安装后，您可以通过 Claude 与 DraCor API 进行交互。以下是一些示例：

基本查询

要求 Claude 列出可用的语料库：

Can you list all available drama corpora in DraCor?

获取有关特定戏剧的信息：

Tell me about Goethe's Faust in the German corpus

分析角色网络：

Analyze the character network in Hamlet from the Shakespeare corpus

高级查询

分析人物关系：

What are the strongest character relationships in Pushkin's Boris Godunov?

比较剧本：

Compare Goethe's Faust and Schiller's Die Räuber in terms of network density and character count

分析角色重要性：

Who are the most central characters in Shakespeare's Hamlet based on speaking time and relationships?

分析性别代表性：

Analyze the gender distribution and representation in Molière's Le Misanthrope

寻找不同戏剧中的角色：

Find all plays that feature a character named "Hamlet" or similar

分析一出戏的全文：

Provide a comprehensive analysis of the full text of Goethe's Faust

从剧本中提取主题：

What are the main themes and motifs in the full text of Shakespeare's Hamlet?

分析语言模式：

Analyze the language patterns and style in Chekhov's The Cherry Orchard

文学分析查询

分析剧本结构：

Analyze the structure of Molière's Le Misanthrope in terms of acts, scenes, and dialogue distribution

比较作者：

Compare the network structures in plays by Shakespeare and Molière

历史背景：

Put Pushkin's Boris Godunov in its historical context and analyze how this is reflected in the character network

资源（v1 API）

FastMCP 服务器公开以下资源：

info:// - API 信息和版本详细信息
corpora:// - 所有可用语料库的列表
corpus://{corpus_name} - 有关特定语料库的信息
corpus_metadata://{corpus_name} - 语料库中所有剧本的元数据
plays://{corpus_name} - 特定语料库中的剧本列表
play://{corpus_name}/{play_name} - 有关特定剧本的信息
play_metrics://{corpus_name}/{play_name} - 特定剧目的网络指标
characters://{corpus_name}/{play_name} - 特定剧本中的角色列表
spoken_text://{corpus_name}/{play_name} - 戏剧中的口语文本（带有可选过滤器）
spoken_text_by_character://{corpus_name}/{play_name} - 每个角色说出的文本
stage_directions://{corpus_name}/{play_name} - 戏剧中的舞台指导
network_data://{corpus_name}/{play_name} - CSV 格式的网络数据
relations://{corpus_name}/{play_name} - CSV 格式的角色关系数据
character_by_wikidata://{wikidata_id} - 按维基数据 ID 列出包含角色的戏剧
full_text://{corpus_name}/{play_name} - 纯文本格式的戏剧全文
tei_text://{corpus_name}/{play_name} - 剧本的完整 TEI XML 文本

工具（v1 API）

FastMCP 服务器提供以下工具：

search_plays - 根据查询搜索剧本
compare_plays - 从指标和结构方面比较两部剧
analyze_character_relations - 分析戏剧中的人物关系
analyze_play_structure - 分析剧本的结构
find_character_across_plays - 在多个剧集中查找角色
analyze_full_text - 分析戏剧的全文，包括对话和舞台指导

提示模板（v1 API）

FastMCP 服务器包含以下提示模板：

analyze_play - 用于分析特定剧本的模板
character_analysis - 用于分析特定角色的模板
network_analysis - 用于分析字符网络的模板
comparative_analysis - 比较两部戏剧的模板
gender_analysis - 用于分析戏剧中性别表现的模板
historical_context - 用于分析戏剧历史背景的模板
full_text_analysis - 用于分析戏剧全文的模板

工作原理

该项目使用官方模型上下文协议 Python SDK 构建一个 MCP 服务器，该服务器公开 Claude 可以用来与 DraCor API 交互的资源和工具。

当你向克劳德询问有关戏剧文本的问题时，它可以：

访问语料库、剧本、角色和网络等资源
使用工具搜索、比较和分析剧本
根据数据提供见解和可视化

DraCor API 是公开访问的，因此不需要身份验证。

速率限制

请注意 DraCor 的速率限制策略。服务器包含可选的速率限制设置，可在 .env 文件中配置。

故障排除

如果您遇到问题：

确保您使用的是 Python 3.10 或更高版本
尝试在开发模式下运行进行调试： mcp dev dracor_mcp_fastmcp.py
在https://dracor.org/doc/api检查 DraCor API 状态

提示与 MCP 一起使用

你的任务是分析 DraCor 数据库中的历史剧情，找出角色 ID 标记问题。具体来说：

从 DraCor 数据库中选择一部戏剧，并对其人物关系、全文和结构进行全面分析。
识别角色 ID 标记中所有可能存在的不一致之处，包括：
- 角色名称的拼写变化
- 角色名称混淆或合并
- 历史拼写变体
- 角色 ID 与舞台指示不一致
以结构化表格形式创建潜在角色 ID 标记错误的详细报告，其中包含以下列：
- 文本ID（剧本的唯一标识符）
- 数据库中当前使用的角色ID
- 文本中发现有问题的变体
- 错误类型（拼写、变化、混淆等）
- 问题解释

针对此文本执行此操作：[playname]”

执照

麻省理工学院

致谢

该项目使用：

用于构建 MCP 服务器的模型上下文协议 Python SDK
用于戏剧文本和网络数据的 DraCor API v1
戏剧语料库项目（DraCor）提供底层数据和 API

Available Tools

6 tools

analyze_character_relationsC

Analyze the character relationships in a play.

ParametersJSON Schema

Name	Required	Description	Default
`corpus_name`	Yes
`play_name`	Yes

TDQS

C2.4/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 action ('analyze') but doesn't describe what the analysis involves, such as output format, computational intensity, or any constraints like data availability. This is a significant gap for a tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste, making it appropriately sized and front-loaded. However, its brevity contributes to under-specification rather than optimal clarity, slightly reducing its effectiveness despite the concise structure.

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 (analysis task), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't cover behavioral aspects, parameter details, or output expectations, making it inadequate for guiding an AI agent effectively in this context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds no meaning beyond the input schema, which has 0% schema description coverage for its 2 parameters. It doesn't explain what 'corpus_name' or 'play_name' refer to, their expected formats, or how they relate to the analysis. With low coverage, the description fails to compensate, leaving parameters largely undocumented.

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 states the tool's purpose as analyzing character relationships in a play, which is clear but vague. It specifies the verb 'analyze' and resource 'character relationships in a play', but doesn't differentiate from siblings like 'find_character_across_plays' or explain what analysis entails. It avoids tautology but lacks specificity about scope or output.

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 siblings like 'analyze_full_text' or 'analyze_play_structure', nor does it specify prerequisites, exclusions, or context for usage. This leaves the agent with minimal direction for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

analyze_full_textC

Analyze the full text of a play, including dialogue and stage directions.

ParametersJSON Schema

Name	Required	Description	Default
`corpus_name`	Yes
`play_name`	Yes

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. It states the tool analyzes full text but doesn't describe what the analysis entails (e.g., returns insights, statistics, or summaries), any limitations (e.g., corpus availability, processing time), or side effects. This leaves key behavioral traits unspecified for a tool with no structured safety hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words, though it could be more informative by elaborating on analysis outcomes or usage context without sacrificing brevity.

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 (analysis tool with no annotations, 0% schema coverage, and no output schema), the description is incomplete. It doesn't explain what the tool returns, how parameters are used, or behavioral aspects like error handling. For a tool that likely produces detailed outputs, this lack of context makes it inadequate for informed use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'full text of a play' but doesn't explain the parameters 'corpus_name' and 'play_name', such as what values are expected or how they relate to the analysis. This adds minimal meaning beyond the schema, failing to address the coverage gap.

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 action ('analyze') and resource ('full text of a play'), specifying it includes dialogue and stage directions. It distinguishes from siblings like 'analyze_character_relations' or 'analyze_play_structure' by focusing on full text analysis, though it doesn't explicitly name alternatives. The purpose is specific but could be more precise about what 'analyze' entails.

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 scenarios, prerequisites, or exclusions, such as when to choose 'analyze_play_structure' instead. Without this context, users must infer usage from tool names alone, which is insufficient for effective selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

analyze_play_structureC

Analyze the structure of a play including acts, scenes, and metrics.

ParametersJSON Schema

Name	Required	Description	Default
`corpus_name`	Yes
`play_name`	Yes

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 mentions analyzing 'acts, scenes, and metrics' but doesn't specify what 'metrics' entail, whether the analysis is read-only or modifies data, or what the output format might be (e.g., structured data, summary). This leaves gaps in understanding the tool's behavior, especially for a tool with parameters and no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded, consisting of a single, efficient sentence that directly states the tool's purpose. There's no unnecessary information or redundancy, making it easy to parse quickly. However, it could be slightly improved by adding a brief usage hint without sacrificing 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 (analyzing play structure with metrics), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like whether it's a read operation, what 'metrics' includes, or how results are returned. For a tool with parameters and analytical functions, more context is needed to ensure the agent can use it effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It doesn't add any meaning beyond what the input schema provides—it doesn't explain what 'corpus_name' or 'play_name' refer to, their expected formats, or examples. With 2 parameters and no schema descriptions, this is a significant gap, as the description fails to clarify parameter usage.

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 with a specific verb ('analyze') and resource ('structure of a play'), including what aspects it covers ('acts, scenes, and metrics'). It distinguishes itself from siblings like 'analyze_character_relations' or 'analyze_full_text' by focusing on structural analysis rather than character or textual analysis. However, it doesn't explicitly differentiate from 'compare_plays' or 'search_plays' in terms of structural vs. comparative/search functions.

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 specific corpus or play format, or when to choose this over siblings like 'analyze_full_text' for broader analysis or 'compare_plays' for structural comparisons. Usage is implied by the name and purpose but not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compare_playsC

Compare two plays in terms of metrics and structure.

ParametersJSON Schema

Name	Required	Description	Default
`corpus_name1`	Yes
`play_name1`	Yes
`corpus_name2`	Yes
`play_name2`	Yes

TDQS

C2.4/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 comparing metrics and structure but doesn't specify what the tool returns (e.g., a report, scores, or visual output), whether it's read-only or has side effects, or any limitations like performance or data availability. 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded and efficient, with no wasted words. It directly states the tool's function without unnecessary elaboration. However, it could be more structured by including key details, but it earns high marks for brevity and clarity within its limited scope.

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 comparing two plays with 4 parameters, no annotations, no output schema, and 0% schema coverage, the description is incomplete. It lacks details on what metrics and structure are compared, the output format, and any behavioral traits. For a tool with multiple inputs and no structured support, this description is inadequate to guide effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 4 parameters with 0% description coverage, and the tool description adds no parameter semantics. It doesn't explain what 'corpus_name' or 'play_name' refer to, their expected formats, or how they relate to the comparison. With low schema coverage, the description fails to compensate, leaving parameters largely undocumented.

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 states the tool compares two plays in terms of metrics and structure, which is a clear purpose but vague. It specifies the verb 'compare' and resource 'plays', but lacks details on what specific metrics or structural aspects are compared, making it less specific. It doesn't differentiate from siblings like 'analyze_play_structure' or 'search_plays', which could involve similar analyses.

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 when to choose this over sibling tools such as 'analyze_play_structure' for single-play analysis or 'find_character_across_plays' for character-focused comparisons. There are no explicit when/when-not instructions or prerequisites, leaving usage unclear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_character_across_playsC

Find a character across multiple plays in the DraCor database.

ParametersJSON Schema

Name	Required	Description	Default
`character_name`	Yes

TDQS

C2.6/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 tool 'finds' a character, implying a read-only search operation, but doesn't specify behavioral traits like whether it returns all occurrences, pagination, error handling, or performance characteristics. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves beyond the basic action.

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 function without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly. There's no wasted text, and it appropriately sized for the tool's apparent simplicity.

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 has no annotations, no output schema, and low parameter schema coverage, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of plays, character details, or links), how results are formatted, or any limitations. For a search tool with minimal structured data, the description should provide more context to be fully helpful to an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 1 parameter with 0% description coverage, so the schema provides no semantic details. The description doesn't add any meaning beyond the schema; it doesn't explain what 'character_name' should include (e.g., full name, partial matches, case sensitivity) or provide examples. With low schema coverage, the description fails to compensate, leaving the parameter poorly documented.

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 states the tool's purpose as finding a character across multiple plays in the DraCor database, which is clear but vague. It specifies the verb 'find' and resource 'character across multiple plays', but doesn't distinguish it from sibling tools like 'analyze_character_relations' or 'search_plays' that might also involve character-related operations. The purpose is understandable but lacks specificity about what 'find' entails compared to alternatives.

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, exclusions, or compare it to sibling tools such as 'analyze_character_relations' (which might analyze character networks) or 'search_plays' (which might search for broader content). Without any context on usage scenarios, the agent must infer when this tool is appropriate based on the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_playsB

Advanced search for plays in the DraCor database with multiple filter options.

Parameters:
- query: General text search across title, subtitle, and author
- corpus_name: Specific corpus to search within (e.g., "shake", "ger", "rus", "span", "dutch")
- character_name: Name of a character that should appear in the play
- country: Country of origin for the play
- language: Language of the play
- author: Name of the playwright
- year_from: Starting year for date range filter
- year_to: Ending year for date range filter
- gender_filter: Filter by plays with a certain gender ratio ("female_dominated", "male_dominated", "balanced")

ParametersJSON Schema

Name	Required	Description	Default
`query`	No
`corpus_name`	No
`character_name`	No
`country`	No
`language`	No
`author`	No
`year_from`	No
`year_to`	No
`gender_filter`	No

TDQS

B3.3/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 describes the tool as an 'advanced search' but doesn't clarify whether it's read-only, how results are returned (e.g., pagination, format), potential rate limits, or error conditions. This leaves significant gaps for an agent to understand the tool's behavior beyond basic functionality.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and appropriately sized. It starts with a clear purpose statement, followed by a bulleted list of parameters with concise explanations. There's no wasted text, and the information is front-loaded. A slight deduction because the bulleted format, while clear, could be slightly more integrated into prose for optimal flow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (9 parameters, no annotations, no output schema), the description is partially complete. It excels in parameter semantics but lacks behavioral details (e.g., output format, error handling) and usage guidelines. For a search tool with many filters, more context on result structure or limitations would help, but the parameter coverage prevents a lower score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds substantial value beyond the input schema, which has 0% description coverage. It provides clear explanations for all 9 parameters, including examples for 'corpus_name' (e.g., 'shake', 'ger') and specific values for 'gender_filter' ('female_dominated', etc.). This fully compensates for the schema's lack of descriptions, making parameter meanings explicit and actionable.

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 as 'Advanced search for plays in the DraCor database with multiple filter options.' This specifies the verb ('search'), resource ('plays'), and domain ('DraCor database'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate this search tool from its siblings like 'compare_plays' or 'find_character_across_plays', 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. It doesn't mention sibling tools like 'find_character_across_plays' (which might overlap with the 'character_name' parameter) or 'compare_plays', nor does it specify prerequisites or optimal use cases. The agent must infer usage from the parameter list alone.

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 updatesAug 15, 2025
- First observedanalyze_character_relations
- First observedanalyze_full_text
- First observedanalyze_play_structure
- First observedcompare_plays
- First observedfind_character_across_plays
- First observedsearch_plays

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

B3.3/5.0

Scored 2026-04-18 11:05 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: character relations analysis, full text analysis, play structure analysis, play comparison, cross-play character search, and play searching. The descriptions reinforce these distinct functions, making tool selection unambiguous for an agent.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with underscores (e.g., analyze_character_relations, search_plays). The naming is predictable and readable throughout the set, with no deviations in style or convention.

Tool Count5/5

Six tools is well-scoped for a DraCor server focused on play analysis and search. Each tool earns its place by covering distinct aspects of the domain, avoiding bloat while providing comprehensive functionality for the intended purpose.

Completeness4/5

The tool set covers core analysis and search operations for plays in the DraCor database, including text, structure, character, and comparative analysis. A minor gap exists in CRUD operations (e.g., no tools for adding or modifying plays), but this is reasonable given the server's likely read-only focus on an existing database.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

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
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
215
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2

Related MCP Servers

MCP Expert Server
Documentation Access API Testing
crazyrabbitLTC
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server utilizing Claude AI for generating intelligent queries and offering documentation assistance based on API documentation analysis.
Updated 2 years ago (2025-01-07 04:20 UTC)
18 npm
3
MIT
MCP-PIF Server
Autonomous Agents Knowledge & Memory Developer Tools
hungryrobot1
F
license
Not graded
quality
D
maintenance
This server implements the Model Context Protocol to facilitate meaningful interaction and understanding development between humans and AI through structured tools and progressive interaction patterns.
Updated a year ago (2025-10-20 14:28 UTC)
57
-
MCP Python Server — API
API Testing Developer Tools Browser Automation
cdryampi
F
license
Not graded
quality
D
maintenance
A Python server implementing the Model Context Protocol that exposes tools for querying external APIs, compatible with Claude Desktop and ChatGPT Desktop.
Updated a year ago (2025-05-09 11:03 UTC)
-
DataForSEO MCP Serverofficial
Search Marketing Web Scraping
dataforseo
A
license
B
quality
B
maintenance
A Model Context Protocol server that enables Claude to interact with DataForSEO APIs, allowing access to SEO data including SERPs, keyword research, on-page metrics, and domain analytics.
Updated 10 days ago (2026-10-02 17:45 UTC)
17
25,471 npm
250
Apache 2.0

Appeared in Searches

A server for generating better prompts for medical AI agents

DraCor MCP 服务器

概述

特征

设置

先决条件

紫外线安装

开发模式

克劳德配置

Docker（可选）

实现细节

标准 MCP 实现 (v0 API)

FastMCP 实现（v1 API）

v1 API 功能

用法

基本查询

高级查询

文学分析查询

资源（v1 API）

工具（v1 API）

提示模板（v1 API）

工作原理

速率限制

故障排除

提示与 MCP 一起使用

执照

致谢

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

DataForSEO MCP Serverofficial

Appeared in Searches