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

Servidor DraCor MCP

Un servidor de Protocolo de Contexto de Modelo (MCP) para interactuar con la API del Proyecto de Corpora Dramática (DraCor). Este servidor MCP permite analizar textos dramáticos y sus redes de personajes sin problemas mediante Claude u otros LLM.

Descripción general

Este proyecto implementa un servidor MCP utilizando el SDK oficial de Python del Protocolo de Contexto de Modelo, que proporciona acceso a la API DraCor v1. Esto permite a Claude y a otros LLM interactuar con corpus de textos dramáticos, analizar redes de personajes, recuperar información de obras y generar información sobre obras dramáticas en diferentes idiomas y períodos.

El proyecto incluye dos implementaciones:

dracor_mcp_fastmcp.py : implementación optimizada mediante la API basada en decorador FastMCP con API v1

Related MCP server: MCP-PIF Server

Características

Acceso a DraCor API v1 a través de una interfaz unificada
No se requiere autenticación (la API de DraCor es de acceso público)
Modelos de datos estructurados para entidades DraCor
Apoyo a las operaciones:
- Recuperación de información de corpus y juegos
- Análisis de red de caracteres
- Métricas y estadísticas de las jugadas
- Información del personaje y texto hablado
- Análisis comparativo del juego
- Funcionalidad de búsqueda
- Datos de relación entre personajes
- Datos de red en múltiples formatos (CSV, GEXF, GraphML)
- Análisis de género en las obras
- Recuperación de texto completo en formatos de texto plano y XML TEI
- Análisis completo del texto de la obra

Configuración

Prerrequisitos

Python 3.10 o superior
Gestor de paquetes UV (recomendado) o pip

Instalación con UV

Instalar UV:

pip install uv

Cree un entorno virtual e instale dependencias:

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

Instalar el servidor MCP en Claude Desktop:

Para la implementación estándar (API v0):

mcp install dracor_mcp_server.py

O para la implementación de FastMCP con API v1 (recomendado):

mcp install dracor_mcp_fastmcp.py

Modo de desarrollo

Para pruebas y desarrollo:

mcp dev dracor_mcp_server.py

O para la implementación de FastMCP con API v1 (recomendado):

mcp dev dracor_mcp_fastmcp.py

Esto iniciará el Inspector MCP donde podrá probar sus herramientas y recursos de forma interactiva.

Configuración de Claude

También puede configurar directamente Claude para usar el servidor DraCor MCP agregando lo siguiente a su archivo de configuración de Claude:

{
  "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"
      ]
    }
  }
}

Reemplace /path/to/dracor-mcp/ con la ruta real a su directorio dracor-mcp. Esta configuración utiliza uv run para ejecutar el servidor MCP con las dependencias necesarias sin necesidad de una instalación previa.

Docker (opcional)

Si prefieres usar Docker:

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

Para utilizar la implementación de FastMCP con la API v1 en su lugar:

docker run -e IMPLEMENTATION=fastmcp dracor-mcp

Detalles de implementación

Implementación estándar de MCP (API v0)

La implementación estándar en dracor_mcp_server.py utiliza las clases principales del SDK de MCP con la API v0 anterior:

Resource : para definir recursos de API
MCPToolImpl - Para implementar herramientas
PromptTemplate : para crear plantillas de indicaciones

Implementación de FastMCP (API v1)

La implementación de FastMCP en dracor_mcp_fastmcp.py utiliza un enfoque basado en decoradores más conciso con la API v1 actual:

@mcp.resource() - Para definir recursos de API
@mcp.tool() - Para implementar herramientas
@mcp.prompt() - Para crear plantillas de indicaciones

Este enfoque da como resultado un código más limpio y fácil de mantener, al tiempo que proporciona la misma funcionalidad pero con acceso a características de API más completas.

Características de la API v1

La implementación de la API v1 proporciona acceso a muchos puntos finales y capacidades adicionales:

Información de la API : información de la versión de la API de DraCor
Metadatos del corpus : metadatos detallados de todas las obras de un corpus
Métricas de juego : métricas de red y datos de análisis
Datos de red de caracteres : formatos CSV, GEXF y GraphML
Relaciones entre personajes : Relaciones explícitas entre personajes
Filtros de texto hablado : filtre por género, tipo de relación o rol del personaje
Acotaciones : recupera acotaciones con o sin oradores
Búsqueda de personajes : encuentra obras que contengan personajes específicos (por ID de Wikidata)

Uso

Una vez instalado en Claude Desktop, podrá interactuar con la API de DraCor a través de Claude. Aquí tiene algunos ejemplos:

Consultas básicas

Pídale a Claude que enumere los corpus disponibles:

Can you list all available drama corpora in DraCor?

Obtenga información sobre una obra específica:

Tell me about Goethe's Faust in the German corpus

Analizar redes de personajes:

Analyze the character network in Hamlet from the Shakespeare corpus

Consultas avanzadas

Analizar las relaciones entre los personajes:

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

Comparar obras:

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

Analizar la importancia del personaje:

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

Analizar la representación de género:

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

Encuentra un personaje en diferentes obras:

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

Analizar el texto completo de una obra de teatro:

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

Extraer temas del texto de la obra:

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

Analizar patrones del lenguaje:

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

Consultas de análisis literario

Analizar la estructura del juego:

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

Comparar autores:

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

Contexto histórico:

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

Recursos (API v1)

El servidor FastMCP expone los siguientes recursos:

info:// - Información de la API y detalles de la versión
corpora:// - Lista de todos los corpus disponibles
corpus://{corpus_name} - Información sobre un corpus específico
corpus_metadata://{corpus_name} - Metadatos para todas las obras de un corpus
plays://{corpus_name} - Lista de obras de un corpus específico
play://{corpus_name}/{play_name} - Información sobre una obra específica
play_metrics://{corpus_name}/{play_name} - Métricas de red para una jugada específica
characters://{corpus_name}/{play_name} - Lista de personajes de una obra específica
spoken_text://{corpus_name}/{play_name} - Texto hablado en una obra (con filtros opcionales)
spoken_text_by_character://{corpus_name}/{play_name} - Texto hablado por cada personaje
stage_directions://{corpus_name}/{play_name} - Indicaciones escénicas en una obra
network_data://{corpus_name}/{play_name} - Datos de red en formato CSV
relations://{corpus_name}/{play_name} - Datos de relación de personajes en formato CSV
character_by_wikidata://{wikidata_id} - Lista de reproducciones que contienen un personaje por ID de Wikidata
full_text://{corpus_name}/{play_name} - Texto completo de una obra en formato de texto sin formato
tei_text://{corpus_name}/{play_name} - Texto XML TEI completo de una obra

Herramientas (API v1)

El servidor FastMCP proporciona las siguientes herramientas:

search_plays - Busca reproducciones basadas en una consulta
compare_plays - Compara dos jugadas en términos de métricas y estructura
analyze_character_relations - Analiza las relaciones entre los personajes de una obra.
analyze_play_structure - Analizar la estructura de una obra
find_character_across_plays - Encuentra un personaje en varias obras
analyze_full_text - Analizar el texto completo de una obra, incluidos los diálogos y las acotaciones.

Plantillas de indicaciones (API v1)

El servidor FastMCP incluye estas plantillas de aviso:

analyze_play - Plantilla para analizar una jugada específica
character_analysis - Plantilla para analizar un personaje específico
network_analysis - Plantilla para analizar una red de personajes
comparative_analysis - Plantilla para comparar dos obras
gender_analysis - Plantilla para analizar la representación de género en una obra de teatro
historical_context - Plantilla para analizar el contexto histórico de una obra
full_text_analysis - Plantilla para analizar el texto completo de una obra de teatro

Cómo funciona

Este proyecto utiliza el SDK oficial del Protocolo de Contexto de Modelo de Python para construir un servidor MCP que expone recursos y herramientas que Claude puede usar para interactuar con la API de DraCor.

Cuando le preguntas a Claude una pregunta sobre textos dramáticos, puede:

Acceda a recursos como corpus, obras de teatro, personajes y redes.
Utilice herramientas para buscar, comparar y analizar jugadas
Proporcionar información y visualizaciones basadas en los datos.

La API de DraCor es de acceso público, por lo que no se requiere autenticación.

Limitación de velocidad

Tenga en cuenta las políticas de limitación de velocidad de DraCor. El servidor incluye opciones de limitación de velocidad que se pueden configurar en el archivo .env.

Solución de problemas

Si encuentra problemas:

Asegúrese de estar utilizando Python 3.10 o superior
Intente ejecutar en modo de desarrollo para depurar: mcp dev dracor_mcp_fastmcp.py
Verifique el estado de la API de DraCor en https://dracor.org/doc/api

Aviso para usar con MCP

Su tarea consiste en analizar las jugadas históricas de la base de datos DraCor para identificar problemas de etiquetado de identificación de personajes. En concreto:

Seleccione una obra de la base de datos de DraCor y realice un análisis exhaustivo de sus relaciones entre personajes, texto completo y estructura.
Identifique todas las posibles inconsistencias en el etiquetado de identificación de caracteres, incluyendo:
- Variaciones ortográficas de los nombres de los personajes
- Confusión o combinación de nombres de personajes
- Variantes ortográficas históricas
- Discrepancias entre la identificación de los personajes y las indicaciones escénicas
Cree un informe detallado de posibles errores de etiquetado de identificación de caracteres en un formato de tabla estructurada con las siguientes columnas:
- ID de texto (identificador único de la obra)
- ID de personaje actual utilizado en la base de datos
- Variante(s) problemática(s) encontrada(s) en el texto
- Tipo de error (ortográfico, variación, confusión, etc.)
- Explicación del problema

Hazlo por este texto: [nombre del juego]"

Licencia

Instituto Tecnológico de Massachusetts (MIT)

Expresiones de gratitud

Este proyecto utiliza:

SDK de Python del protocolo de contexto de modelo para crear el servidor MCP
DraCor API v1 para texto dramático y datos de red
Proyecto Drama Corpora (DraCor) para proporcionar los datos subyacentes y la 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

Servidor DraCor MCP

Descripción general

Características

Configuración

Prerrequisitos

Instalación con UV

Modo de desarrollo

Configuración de Claude

Docker (opcional)

Detalles de implementación

Implementación estándar de MCP (API v0)

Implementación de FastMCP (API v1)

Características de la API v1

Uso

Consultas básicas

Consultas avanzadas

Consultas de análisis literario

Recursos (API v1)

Herramientas (API v1)

Plantillas de indicaciones (API v1)

Cómo funciona

Limitación de velocidad

Solución de problemas

Aviso para usar con MCP

Licencia

Expresiones de gratitud

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

DataForSEO MCP Serverofficial

Appeared in Searches