Which integrations are available for this server?

Offers containerized deployment of the MCP server through Docker, with configurable implementation options. Supports configuration of rate limiting settings through .env file for managing DraCor API usage. Uses Pydantic for structured data models of DraCor entities, ensuring type safety and validation. Implements the MCP server using Python SDK, supporting both v0 and v1 API implementations. Allows finding plays containing specific characters by their Wikidata ID, connecting dramatic characters to structured knowledge graph identifiers. Provides access to play texts in TEI XML format, enabling structured analysis of dramatic texts with their markup.

How do I use DraCor MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DraCor MCP Server analyze character networks in Shakespeare's Hamlet" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

en es ja ko zh

DraCor MCP Server

by stijn-meijers

Overview Schema Related Servers Score Discussions

Python

Remote

DraCor MCP Server

A Model Context Protocol (MCP) server for interacting with the Drama Corpora Project (DraCor) API. This MCP server enables you to seamlessly analyze dramatic texts and their character networks through Claude or other LLMs.

Overview

This project implements an MCP server using the official Model Context Protocol Python SDK that provides access to the DraCor API v1. It allows Claude and other LLMs to interact with dramatic text corpora, analyze character networks, retrieve play information, and generate insights about dramatic works across different languages and periods.

The project includes two implementations:

dracor_mcp_fastmcp.py - Streamlined implementation using the FastMCP decorator-based API with v1 API

Related MCP server: MCP-PIF Server

Features

Access to DraCor API v1 through a unified interface
No authentication required (DraCor API is publicly accessible)
Structured data models for DraCor entities
Support for operations:
- Corpora and play information retrieval
- Character network analysis
- Metrics and statistics for plays
- Character information and spoken text
- Comparative play analysis
- Search functionality
- Character relationship data
- Network data in multiple formats (CSV, GEXF, GraphML)
- Gender analysis across plays
- Full text retrieval in plain text and TEI XML formats
- Complete play text analysis

Setup

Prerequisites

Python 3.10 or higher
UV package manager (recommended) or pip

Installation with UV

Install UV:

pip install uv

Create a virtual environment and install dependencies:

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

Install the MCP server in Claude Desktop:

For standard implementation (v0 API):

mcp install dracor_mcp_server.py

Or for FastMCP implementation with v1 API (recommended):

mcp install dracor_mcp_fastmcp.py

Development Mode

For testing and development:

mcp dev dracor_mcp_server.py

Or for FastMCP implementation with v1 API (recommended):

mcp dev dracor_mcp_fastmcp.py

This will launch the MCP Inspector where you can test your tools and resources interactively.

Claude Configuration

You can also directly configure Claude to use the DraCor MCP server by adding the following to your Claude configuration file:

{
  "mcpServers": {
    "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"
      ],
      "env": {
        "DRACOR_API_BASE_URL": "https://dracor.org/api/v1"
      }
    }
  }
}

Replace /path/to/dracor-mcp/ with the actual path to your dracor-mcp directory. This configuration uses uv run to execute the MCP server with the necessary dependencies without requiring a prior installation.

If you want to use a different server, e.g. the staging server, change it in the environment variable DRACOR_API_BASE_UR in the configuration file:

"env": {
  "DRACOR_API_BASE_URL": "https://staging.dracor.org/api/v1" 
  }

Docker (optional)

If you prefer using Docker:

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

To use the FastMCP implementation with v1 API instead:

docker run -e IMPLEMENTATION=fastmcp dracor-mcp

Implementation Details

Standard MCP Implementation (v0 API)

The standard implementation in dracor_mcp_server.py uses the core MCP SDK classes with the older v0 API:

Resource - For defining API resources
MCPToolImpl - For implementing tools
PromptTemplate - For creating prompt templates

FastMCP Implementation (v1 API)

The FastMCP implementation in dracor_mcp_fastmcp.py uses a more concise decorator-based approach with the current v1 API:

@mcp.resource() - For defining API resources
@mcp.tool() - For implementing tools
@mcp.prompt() - For creating prompt templates

This approach results in cleaner, more maintainable code while providing the same functionality but with access to more comprehensive API features.

v1 API Features

The v1 API implementation provides access to many additional endpoints and capabilities:

API info - Version information for the DraCor API
Corpus metadata - Detailed metadata for all plays in a corpus
Play metrics - Network metrics and analysis data
Character network data - CSV, GEXF, and GraphML formats
Character relations - Explicit relationships between characters
Spoken text filters - Filter by gender, relation type, or character role
Stage directions - Retrieve stage directions with or without speakers
Character lookup - Find plays containing specific characters (by Wikidata ID)

Usage

Once installed in Claude Desktop, you can interact with the DraCor API through Claude. Here are some examples:

Basic Queries

Ask Claude to list available corpora:

Can you list all available drama corpora in DraCor?

Get information about a specific play:

Tell me about Goethe's Faust in the German corpus

Analyze character networks:

Analyze the character network in Hamlet from the Shakespeare corpus

Advanced Queries

Analyze character relationships:

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

Compare plays:

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

Analyze character importance:

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

Analyze gender representation:

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

Find a character across different plays:

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

Analyze the full text of a play:

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

Extract themes from play text:

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

Analyze language patterns:

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

Literary Analysis Queries

Analyze play structure:

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

Compare authors:

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

Historical context:

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

Resources (v1 API)

The FastMCP server exposes the following resources:

info:// - API information and version details
corpora:// - List of all available corpora
corpus://{corpus_name} - Information about a specific corpus
corpus_metadata://{corpus_name} - Metadata for all plays in a corpus
plays://{corpus_name} - List of plays in a specific corpus
play://{corpus_name}/{play_name} - Information about a specific play
play_metrics://{corpus_name}/{play_name} - Network metrics for a specific play
characters://{corpus_name}/{play_name} - List of characters in a specific play
spoken_text://{corpus_name}/{play_name} - Spoken text in a play (with optional filters)
spoken_text_by_character://{corpus_name}/{play_name} - Text spoken by each character
stage_directions://{corpus_name}/{play_name} - Stage directions in a play
network_data://{corpus_name}/{play_name} - Network data in CSV format
relations://{corpus_name}/{play_name} - Character relation data in CSV format
character_by_wikidata://{wikidata_id} - List plays containing a character by Wikidata ID
full_text://{corpus_name}/{play_name} - Full text of a play in plain text format
tei_text://{corpus_name}/{play_name} - Full TEI XML text of a play

Tools (v1 API)

The FastMCP server provides the following tools:

search_plays - Search for plays based on a query
compare_plays - Compare two plays in terms of metrics and structure
analyze_character_relations - Analyze character relationships in a play
analyze_play_structure - Analyze the structure of a play
find_character_across_plays - Find a character across multiple plays
analyze_full_text - Analyze the full text of a play, including dialogue and stage directions

Prompt Templates (v1 API)

The FastMCP server includes these prompt templates:

analyze_play - Template for analyzing a specific play
character_analysis - Template for analyzing a specific character
network_analysis - Template for analyzing a character network
comparative_analysis - Template for comparing two plays
gender_analysis - Template for analyzing gender representation in a play
historical_context - Template for analyzing the historical context of a play
full_text_analysis - Template for analyzing the full text of a play

How It Works

This project uses the official Model Context Protocol Python SDK to build an MCP server that exposes resources and tools that Claude can use to interact with the DraCor API.

When you ask Claude a question about dramatic texts, it can:

Access resources like corpora, plays, characters, and networks
Use tools to search, compare, and analyze plays
Provide insights and visualizations based on the data

The DraCor API is publicly accessible, so no authentication is required.

Rate Limiting

Be mindful of DraCor's rate limiting policies. The server includes optional rate limiting settings that can be configured in the .env file.

Troubleshooting

If you encounter issues:

Ensure you're using Python 3.10 or higher
Try running in development mode to debug: mcp dev dracor_mcp_fastmcp.py
Check the DraCor API status at https://dracor.org/doc/api

Prompt to use with MCP

"Your task is to analyze historical plays from the DraCor database to identify character ID tagging issues. Specifically:

Select a play from the DraCor database and perform a comprehensive analysis of its character relations, full text, and structure.
Identify all possible inconsistencies in character ID tagging, including:
- Spelling variations of character names
- Character name confusion or conflation
- Historical spelling variants
- Discrepancies between character IDs and stage directions
Create a detailed report of potential character ID tagging errors in a structured table format with the following columns:
- Text ID (unique identifier for the play)
- Current character ID used in the database
- Problematic variant(s) found in the text
- Type of error (spelling, variation, confusion, etc.)
- Explanation of the issue

do it for this text: [playname]"

License

MIT

Acknowledgements

This project uses:

Model Context Protocol Python SDK for building the MCP server
DraCor API v1 for dramatic text and network data
Drama Corpora Project (DraCor) for providing the underlying data and 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.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

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

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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
237
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
Artificial Wit AI
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)
19
3
MIT
MCP-PIF Server
Autonomous Agents Knowledge & Memory Developer Tools
hungryrobot1
F
license
Not graded
quality
F
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 10 months 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
A
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 2 days ago (2026-09-01 10:59 UTC)
17
22,898
242
Apache 2.0

Appeared in Searches

A server for generating better prompts for medical AI agents

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/stijn-meijers/dracor-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

DraCor MCP Server

Overview

Features

Setup

Prerequisites

Installation with UV

Development Mode

Claude Configuration

Docker (optional)

Implementation Details

Standard MCP Implementation (v0 API)

FastMCP Implementation (v1 API)

v1 API Features

Usage

Basic Queries

Advanced Queries

Literary Analysis Queries

Resources (v1 API)

Tools (v1 API)

Prompt Templates (v1 API)

How It Works

Rate Limiting

Troubleshooting

Prompt to use with MCP

License

Acknowledgements

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

DataForSEO MCP Serverofficial

Appeared in Searches

Latest Blog Posts

MCP directory API