Quantitative Researcher MCP Server
Servidor MCP de Investigador Cuantitativo
Una implementación de servidor MCP que proporciona herramientas para la gestión de gráficos de conocimiento de investigación cuantitativa, lo que permite la representación estructurada de proyectos de investigación, conjuntos de datos, variables, hipótesis, pruebas estadísticas, modelos y resultados. Este servidor ayuda a los investigadores cuantitativos a organizar sus datos, realizar el seguimiento de sus análisis, evaluar hipótesis y generar información a partir de datos numéricos.
Características
Contexto de investigación persistente : mantener un gráfico de conocimiento estructurado de las entidades de investigación y las relaciones en múltiples sesiones de análisis
Gestión de sesiones de estudio : Realice un seguimiento de las sesiones de análisis de investigación con identificaciones únicas y registre el progreso a lo largo del tiempo
Prueba de hipótesis : seguimiento de hipótesis, sus pruebas asociadas y conclusiones resultantes
Gestión de conjuntos de datos : organice y realice un seguimiento de las estadísticas descriptivas y las variables dentro de los conjuntos de datos.
Análisis estadístico : Registrar pruebas estadísticas, modelos y sus resultados.
Relaciones entre variables : realice un seguimiento de correlaciones, predicciones y otras relaciones entre variables
Seguimiento de preguntas de investigación : vincule los análisis de datos con preguntas de investigación específicas
Visualización de datos : visualizaciones de documentos creadas a partir de conjuntos de datos y resultados
Rendimiento del modelo : supervisar las métricas estadísticas de rendimiento del modelo
Documentación de los hallazgos de la investigación : Vincular los hallazgos con la evidencia estadística que los respalda
Documentación de metodología de investigación : seguimiento de decisiones y enfoques metodológicos
Related MCP server: Qualitative Researcher MCP Server
Entidades
El servidor MCP de Quantitative Researcher reconoce los siguientes tipos de entidades:
proyecto : Estudio de investigación general
conjunto de datos : recopilación de datos utilizados para el análisis
variable : atributo medible específico en un conjunto de datos
hipótesis : Enunciado formal comprobable
Prueba estadística : método de análisis aplicado a datos
resultado : Resultado del análisis estadístico
analysisScript : Código utilizado para realizar el análisis
visualización : representación visual de datos
modelo : Modelo estadístico/matemático
Literatura : Fuentes académicas
Pregunta de investigación : Preguntas formales que guían el estudio
hallazgo : Resultados o conclusiones
Participante : Sujetos de investigación
estado : Valores de estado de la entidad (activo, completado, pendiente, abandonado)
prioridad : Valores de nivel de prioridad (alto, bajo)
Relaciones
Las entidades se pueden conectar a través de los siguientes tipos de relaciones:
correlates_with : Correlación estadística entre variables
predice : Relación predictiva de variable independiente a variable dependiente
Pruebas : La prueba estadística examina la hipótesis.
análisis : Análisis realizado en el conjunto de datos
produce : El análisis produce resultados
visualiza : La visualización muestra datos o resultados
contiene : Relación jerárquica
part_of : La entidad es parte de otra entidad
depends_on : Relación de dependencia
apoyos : evidencia que apoya una hipótesis o hallazgo
contradice : evidencia que contradice una hipótesis o hallazgo
derived_from : La entidad se deriva de otra entidad
controles_para : Controles de variables/métodos para factores de confusión
modera : Variable modera una relación
media : La variable media una relación
implementa : El script implementa una prueba/modelo estadístico
compara : Comparación estadística entre grupos/variables
incluye : El modelo incluye variables
valida : valida un modelo o resultado
cita : Referencias bibliográficas
has_status : Vincula las entidades a su estado actual (activo, completado, pendiente, abandonado)
has_priority : vincula entidades a su nivel de prioridad (alto, bajo)
precede : Indica que un proceso o actividad viene antes de otro en una secuencia
Herramientas disponibles
El servidor MCP de Quantitative Researcher proporciona estas herramientas para interactuar con el conocimiento de investigación:
inicio de sesión
Inicia una nueva sesión de investigación cuantitativa, generando un ID de sesión único y mostrando los proyectos de investigación, conjuntos de datos, modelos, visualizaciones y sesiones anteriores en curso. Muestra información de estado mediante relaciones has_status, niveles de prioridad mediante relaciones has_priority e identifica actividades listas para trabajar a continuación según las relaciones secuenciales del proceso.
contexto de carga
Carga el contexto detallado de una entidad específica (proyecto, conjunto de datos, variable, etc.) y muestra información relevante según el tipo de entidad. Incluye información de estado, niveles de prioridad y relaciones secuenciales entre procesos.
fin de sesión
Registra los resultados de una sesión de investigación a través de un proceso estructurado de múltiples etapas:
Resumen : Registra el resumen de la sesión, la duración y el enfoque del proyecto.
datasetUpdates : documenta las actualizaciones de los conjuntos de datos durante la sesión
newAnalyses : Registra nuevos análisis estadísticos realizados
newVisualizations : Realiza un seguimiento de las nuevas visualizaciones de datos creadas
hypothesisResults : Documenta los resultados de las pruebas de hipótesis
modelUpdates : Registra actualizaciones de modelos estadísticos
statusUpdates : Registra los cambios en los valores de estado de la entidad
projectStatus : actualiza el estado general del proyecto, las asignaciones de prioridad y las relaciones secuenciales
ensamblaje : ensamblaje final de todos los datos de la sesión
contexto de construcción
Crea nuevas entidades, relaciones u observaciones en el gráfico de conocimiento:
Entidades : Agregar nuevas entidades de investigación (proyectos, conjuntos de datos, variables, estado, prioridad, etc.)
relaciones : Crea relaciones entre entidades (incluyendo has_status, has_priority, precedes)
observaciones : Agregar observaciones a entidades existentes
eliminar contexto
Elimina entidades, relaciones u observaciones del gráfico de conocimiento:
entidades : Eliminar entidades de investigación
relaciones : eliminar relaciones entre entidades (incluidas relaciones de estado, prioridad y secuenciales)
observaciones : eliminar observaciones específicas de las entidades
contexto avanzado
Recupera información del gráfico de conocimiento:
gráfico : Obtenga el gráfico de conocimiento completo
búsqueda : busca nodos según criterios de consulta
nodos : obtener nodos específicos por nombre
relacionado : Encuentra entidades relacionadas
estado : busca entidades con un valor de estado específico (activo, completado, pendiente, abandonado)
prioridad : busca entidades con un valor de prioridad específico (alto, bajo)
secuencia : Identificar relaciones secuenciales para los procesos de investigación
Funciones específicas del dominio
El servidor MCP de Quantitative Researcher incluye funciones de dominio especializadas para la investigación cuantitativa:
getProjectOverview : Vista completa de un proyecto que incluye preguntas de investigación, metodología, conjuntos de datos y variables
getDatasetAnalysis : análisis del contenido del conjunto de datos, incluidas variables, estadísticas descriptivas y calidad de los datos
getHypothesisTests : Revisión de pruebas de hipótesis y sus resultados
getVariableRelationships : Examinar correlaciones, predicciones y otras relaciones entre variables
getStatisticalResults : resume los resultados de los análisis estadísticos
getVisualizationGallery : Ver visualizaciones creadas para conjuntos de datos y resultados
getModelPerformance : evalúa las métricas de rendimiento de los modelos estadísticos
getResearchQuestionResults : Organiza análisis y resultados por preguntas de investigación
getVariableDistribution : Examina la distribución y las propiedades de variables individuales
getStatusOverview : Ver todas las entidades con un estado específico (activo, completado, pendiente, abandonado)
getPriorityItems : Identificar tareas y actividades de investigación de alta prioridad
getResearchSequence : Visualiza la secuencia de procesos de investigación basándose en relaciones precedentes
Ejemplos de indicaciones
Iniciar una sesión
Let's start a new quantitative research session for my Climate Impact Study project.Cargando contexto de investigación
Load the context for the Climate Impact Study project so I can see the current state of my statistical analyses.Resultados de la sesión de grabación
I've just finished analyzing data for my Climate Impact Study. I ran three new regression models to test the relationship between temperature and crop yield, created two visualizations of the correlation patterns, and confirmed our hypothesis about rainfall effects. I've marked the temperature analysis as complete and assigned high priority to the regional variation analysis. The model performance improved by 15% after controlling for regional variations.Gestión del conocimiento de investigación
Create a new variable called "Annual Precipitation" that's part of the "Climate Measures" dataset with observations noting it's normally distributed with a mean of 34.5 inches. Set its status to active and make it precede the "Crop Yield Analysis" process.Update the status of the "Data Cleaning" process to "completed" and add an observation that all outliers have been properly handled.Uso
Este servidor MCP permite a los investigadores cuantitativos:
Mantener la continuidad analítica : realizar un seguimiento de los análisis y resultados en múltiples sesiones de investigación
Organizar la evidencia estadística : vincular las hipótesis con las pruebas y resultados estadísticos que las respaldan
Documentar relaciones entre variables : registrar cómo las variables se correlacionan, predicen o influyen entre sí
Desarrollo de modelos de seguimiento : documentar la evolución de los modelos estadísticos y su rendimiento
Apoyar la interpretación de resultados : conectar los hallazgos estadísticos con las preguntas de investigación y los marcos teóricos
Garantizar el rigor metodológico : documentar las decisiones metodológicas y los enfoques analíticos
Preparar informes de investigación : organizar la evidencia estadística para respaldar los hallazgos de la investigación.
Seguimiento del progreso de la investigación : supervise el estado de la entidad durante todo el ciclo de vida de la investigación
Priorizar las tareas de investigación : identificar y centrarse en actividades de investigación de alta prioridad
Secuenciar procesos de investigación : planificar y visualizar el orden lógico de los pasos de investigación y análisis
Configuración
Uso con Claude Desktop
Agregue esto a su claude_desktop_config.json :
Instalar desde GitHub y ejecutar con npx
{
"mcpServers": {
"quantitativeresearch": {
"command": "npx",
"args": [
"-y",
"github:tejpalvirk/quantitativeresearch"
]
}
}
}Instalar globalmente y ejecutar directamente
Primero, instale el paquete globalmente:
npm install -g github:tejpalvirk/quantitativeresearchA continuación configure Claude Desktop:
{
"mcpServers": {
"quantitativeresearch": {
"command": "contextmanager-quantitativeresearch"
}
}
}estibador
{
"mcpServers": {
"quantitativeresearch": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"mcp/quantitativeresearch"
]
}
}
}Edificio
De la fuente
# Clone the repository
git clone https://github.com/tejpalvirk/contextmanager.git
cd contextmanager
# Install dependencies
npm install
# Build the server
npm run build
# Run the server
cd quantitativeresearch
node quantitativeresearch_index.jsEstibador:
docker build -t mcp/quantitativeresearch -f quantitativeresearch/Dockerfile .Licencia
Este servidor MCP cuenta con la licencia MIT. Esto significa que puede usar, modificar y distribuir el software libremente, sujeto a los términos y condiciones de la licencia MIT. Para más detalles, consulte el archivo de LICENCIA en el repositorio del proyecto.
Variables de entorno
El servidor MCP de investigación cuantitativa admite las siguientes variables de entorno para personalizar dónde se almacenan los datos:
MEMORY_FILE_PATH : Ruta donde se almacenarán los datos del gráfico de conocimiento
Puede ser absoluto o relativo (las rutas relativas utilizan el directorio de trabajo actual)
Predeterminado:
./quantitativeresearch/memory.json
SESSIONS_FILE_PATH : Ruta donde se almacenarán los datos de la sesión
Puede ser absoluto o relativo (las rutas relativas utilizan el directorio de trabajo actual)
Predeterminado:
./quantitativeresearch/sessions.json
Ejemplo de uso:
# Store data in the current directory
MEMORY_FILE_PATH="./quantitative-memory.json" SESSIONS_FILE_PATH="./quantitative-sessions.json" npx github:tejpalvirk/contextmanager-quantitativeresearch
# Store data in a specific location (absolute path)
MEMORY_FILE_PATH="/path/to/data/quantitative-memory.json" npx github:tejpalvirk/contextmanager-quantitativeresearch
# Store data in user's home directory
MEMORY_FILE_PATH="$HOME/contextmanager/quantitative-memory.json" npx github:tejpalvirk/contextmanager-quantitativeresearchAvailable Tools
6 toolsadvancedcontextA
A sophisticated query tool for exploring, analyzing, and retrieving complex information from the quantitative research knowledge graph.
When to use this tool:
Retrieving a comprehensive view of your entire research knowledge structure
Searching for specific research entities across your quantitative data projects
Getting detailed information about particular research projects, datasets, or statistical elements
Exploring relationships between variables and their statistical properties
Analyzing hypothesis test results and their implications
Retrieving statistical model performance metrics
Accessing visualization galleries for specific projects or datasets
Examining variable distributions and their statistical properties
Finding connections between different aspects of your research
Creating statistical reports or summaries from your data
Exploring the relationships between research questions and findings
Identifying entities by status to track research progress
Filtering tasks by priority to manage research workflow
Analyzing sequential relationships between research processes
Key features:
Offers specialized operations for querying different aspects of quantitative research data
Retrieves complete or filtered views of the research knowledge graph
Provides flexible search capabilities across all research entities
Supports detailed exploration of specific entities by name
Generates specialized views for projects, datasets, hypotheses, and variables
Retrieves statistical results, visualizations, and model performance metrics
Provides detailed variable distribution analysis
Identifies related entities to explore connections within your research
Returns consistently structured JSON responses for easy processing
Facilitates depth and breadth exploration of quantitative data
Supports status-based filtering of research entities
Enables priority-based task management
Provides sequential process analysis capabilities
Parameters explained:
type: The type of query operation to perform
Accepts one of the specialized operations: "graph", "search", "nodes", "project", "dataset", "hypothesis", "variables", "statistics", "visualizations", "model", "question", "distribution", "related", "status", "priority", "sequence"
Determines how the params parameter is interpreted
params: Operation-specific parameters (structure varies by type):
For "graph": No parameters needed (retrieves the full research knowledge graph)
For "search": Object containing:
query: Search string to find entities (supports entity type filters)
For "nodes": Object containing:
names: Array of entity names to retrieve
For "project": Object containing:
projectName: Name of the project to retrieve details for
For "dataset": Object containing:
datasetName: Name of the dataset to retrieve analysis for
For "hypothesis": Object containing:
projectName: Project name to filter hypotheses by
hypothesisName: (Optional) Specific hypothesis to retrieve tests for
For "variables": Object containing:
variableName: Name of the variable to retrieve relationship information for
For "statistics": Object containing:
projectName: Project name to retrieve statistical results for
testType: (Optional) Type of statistical test to filter by
For "visualizations": Object containing:
projectName: Project name to retrieve visualizations for
datasetName: (Optional) Dataset name to filter visualizations by
For "model": Object containing:
modelName: Name of the model to retrieve performance metrics for
For "question": Object containing:
questionName: Name of the research question to retrieve results for
For "distribution": Object containing:
variableName: Name of the variable to analyze distribution of
datasetName: (Optional) Dataset name to contextualize the variable
For "related": Object containing:
entityName: Name of the entity to find related entities for
For "status": Object containing:
statusValue: The status value to filter by (e.g., "active", "completed", "pending", "abandoned")
For "priority": Object containing:
priorityValue: The priority value to filter by (e.g., "high", "low")
For "sequence": Object containing:
entityName: Name of the entity to find sequential relationships for
Operation details:
graph: Returns the complete research knowledge graph with all entities and relationships
search: Performs text-based search across entity names and observations
nodes: Retrieves detailed information about specific entities by name
project: Returns comprehensive project information including datasets, hypotheses, tests, and findings
dataset: Provides detailed dataset analysis with variables, descriptive statistics, and correlations
hypothesis: Retrieves hypothesis tests and their results for a project or specific hypothesis
variables: Examines relationships between a variable and other variables (correlations, dependencies)
statistics: Collects statistical test results for a project, optionally filtered by test type
visualizations: Returns visualization metadata and descriptions for a project or dataset
model: Provides detailed model performance metrics, parameters, and validation results
question: Retrieves research question details, related hypotheses, and supporting findings
distribution: Analyzes the statistical distribution of a variable with descriptive stats and normality tests
related: Identifies all entities directly connected to a specific entity
status: Retrieves all entities with a specific status value
priority: Retrieves all entities with a specific priority value
sequence: Identifies sequential relationships for a specific entity showing preceding and following entities
Status and Priority Information:
Status queries return entities organized by their current research stage
Priority queries help identify critical research tasks and elements
Status values include: active, completed, pending, abandoned
Priority values include: high, low
Status and priority are assigned through has_status and has_priority relations
Sequential Process Information:
Sequence queries identify entities that come before or after in a research process
Sequential relationships help visualize the research workflow and methodology
The sequence operation shows both incoming and outgoing precedes relations
Process sequences are essential for understanding multi-step analytical procedures
Return information:
success: Boolean indicating whether the operation succeeded
Additional fields depend on the operation type:
graph: Complete knowledge graph
results: For search operations
nodes: For specific entity retrieval
project/dataset/hypothesis/etc.: For specialized views
status/priority: Lists of entities with specified status/priority values
sequence: Preceding and following entities in research processes
You should:
Start with broad queries ("graph", "search") to explore your research corpus
Use specific entity queries ("nodes", "project", "dataset") for detailed information
Examine variable relationships and distributions to understand your data
Review hypothesis tests and statistical results to evaluate evidence
Explore model performance metrics to assess predictive accuracy
Use visualization galleries to communicate research findings
Examine research questions and their supporting evidence
Use status queries to identify all entities at a particular research stage
Use priority queries to focus on high-priority research tasks
Use sequence queries to understand process flows in your research methodology
Combine multiple operations to build a comprehensive understanding of your research
Use the related operation to discover connections between entities
Apply search filters to find specific types of research elements
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Parameters for the get operation, structure varies by type | |
| type | Yes | Type of get operation |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by detailing return formats ('consistently structured JSON responses'), operation behaviors (e.g., 'graph returns complete knowledge graph'), and context like status/priority values. It doesn't mention rate limits or authentication needs, but covers most behavioral aspects thoroughly for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While well-structured with clear sections, the description is excessively long (over 800 words) with repetitive information. Many bullet points could be consolidated, and the 'You should' section largely repeats earlier content. It's front-loaded with purpose, but could be much more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 operation types, varied params), no annotations, and no output schema, the description provides exceptional completeness. It covers purpose, usage, parameters, operations, return values, and practical guidance. The only gap is technical constraints like rate limits, but for a query tool with this complexity, it's remarkably thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema description coverage, the description adds extensive value beyond the schema. It explains all 16 possible 'type' values (schema only lists 13), provides detailed 'params' structures for each type, and includes 'Operation details' section explaining what each type returns. This goes far beyond the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'exploring, analyzing, and retrieving complex information from the quantitative research knowledge graph' with specific verbs and resource. It distinguishes from siblings like 'buildcontext', 'deletecontext', etc., which imply different operations (creation, deletion) rather than query/analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'When to use this tool' section with 15 specific scenarios, plus a 'You should' section with 14 actionable guidelines. It clearly differentiates when to use this tool versus not mentioning alternatives, but the detailed scenarios cover most use cases comprehensively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
buildcontextA
A versatile tool for constructing and enhancing the quantitative research knowledge graph by adding new research elements, relationships, and observations.
When to use this tool:
Creating new research entities (projects, datasets, variables, hypotheses, statistical tests, etc.)
Establishing relationships between research elements (e.g., connecting variables to datasets, statistical tests to hypotheses)
Adding observations, properties, or metadata to existing research entities
Building the research corpus incrementally as data collection and analysis progress
Organizing and structuring quantitative data within your research framework
Documenting statistical analyses, models, and their results
Tracking research questions and linking them to findings
Creating visualizations and connecting them to data and analyses
Setting status values for research activities and entities
Assigning priorities to research tasks and activities
Defining sequential relationships between research processes
Key features:
Creates three distinct types of knowledge graph elements: entities, relations, and observations
Supports specialized quantitative research entity types (projects, datasets, variables, hypotheses, statistical tests, etc.)
Validates entity and relation types against predefined standards for the quantitative research domain
Handles batch creation of multiple entities or relations in a single operation
Returns confirmation with details of created elements
Ensures proper data typing and structure for the quantitative research knowledge graph
Enables comprehensive documentation of statistical analysis processes
Supports status and priority assignment through entity-relation model
Enables sequential relationships through precedes relation
Parameters explained:
type: The type of creation operation to perform
Accepts: "entities", "relations", or "observations"
Determines how the data parameter is interpreted
data: The content to add to the knowledge graph (structure varies by type):
For "entities": An array of objects, each containing:
name: Unique identifier for the entity
entityType: One of the valid entity types (project, dataset, variable, hypothesis, statisticalTest, result, analysisScript, visualization, model, literature, researchQuestion, finding, participant, status, priority)
observations: Array of strings containing notes or properties about the entity
For "relations": An array of objects, each containing:
from: Name of the source entity
to: Name of the target entity
relationType: The type of relationship between entities (e.g., correlates_with, predicts, tests, analyzes, produces, has_status, has_priority, precedes)
For "observations": Either a single object or an array of objects, each containing:
entityName: Name of the entity to add observations to
contents: Array of strings with new observations to add
Valid entity types:
project: Overall research study
dataset: Collection of data used for analysis
variable: Specific measurable attribute in a dataset
hypothesis: Formal testable statement
statisticalTest: Analysis method applied to data
result: Outcome of statistical analysis
analysisScript: Code used to perform analysis
visualization: Visual representation of data
model: Statistical/mathematical model
literature: Academic sources
researchQuestion: Formal questions guiding the study
finding: Results or conclusions
participant: Research subjects
status: Entity status values
priority: Entity priority values
Valid relation types:
correlates_with: Statistical correlation between variables
predicts: Predictive relationship from independent to dependent variable
tests: Statistical test examines hypothesis
analyzes: Analysis performed on dataset
produces: Analysis produces result
visualizes: Visualization displays data or result
contains: Hierarchical relationship
part_of: Entity is part of another entity
depends_on: Dependency relationship
supports: Evidence supporting a hypothesis or finding
contradicts: Evidence contradicting a hypothesis or finding
derived_from: Entity is derived from another entity
controls_for: Variable/method controls for confounds
moderates: Variable moderates a relationship
mediates: Variable mediates a relationship
implements: Script implements statistical test/model
compares: Statistical comparison between groups/variables
includes: Model includes variables
validates: Validates a model or result
cites: References literature
has_status: Links entity to its status
has_priority: Links entity to its priority
precedes: Entity comes before another entity in sequence
Status information:
Valid status values include: active, completed, pending, abandoned
Status is assigned through the has_status relation type
Status helps track progress of research activities
Priority information:
Valid priority values: high, low
Priority is assigned through the has_priority relation type
Priority helps identify critical research tasks
Sequential Process Information:
The precedes relation establishes logical ordering between research processes
Sequential relationships document the flow of the research methodology
Helps maintain proper order in multi-step analysis procedures
Return information:
JSON response indicating success or failure
For successful operations:
Success flag set to true
Details of created elements in the "created" field (for entities/relations) or "added" field (for observations)
For failed operations:
Success flag set to false
Error message describing the issue
Error handling:
Validates entity types against the predefined list for quantitative research
Validates relation types against acceptable standards
Returns descriptive error messages for invalid inputs
Gracefully handles type mismatches and formatting errors
You should:
Use consistent naming conventions for entities to facilitate relationships and retrieval
Begin by creating projects and datasets before more specific research elements
Add detailed observations to entities to enhance context and retrievability
Create relationships to build a comprehensive network of interconnected research data
Document statistical methodology thoroughly by connecting tests, variables, and hypotheses
Add statistical results with appropriate metadata (p-values, effect sizes, confidence intervals)
Create visualizations and link them to the data they represent
Use relations to document the flow of analysis from data to findings
Connect literature to support hypotheses and contextualize findings
Structure models with clear relationships to the variables they include
Document analysis scripts with information about their purpose and implementation
Use has_status relations to track the progress of research activities (active, completed, pending, abandoned)
Use has_priority relations to indicate important research elements (high, low)
Use precedes relations to establish sequences in research methodologies
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Data for the creation operation, structure varies by type but must be an array | |
| type | Yes | Type of creation operation: 'entities', 'relations', or 'observations' |
TDQS
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 thoroughly describes key behavioral traits: validation of entity/relation types against predefined standards, batch creation support, return format details (success/failure with created/added fields), error handling with descriptive messages, and specific behavioral aspects like status/priority assignment and sequential relationships. This goes well beyond the basic input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive but overly verbose (over 800 words). While well-structured with clear sections (purpose, usage, features, parameters, valid types, return info, guidelines), it includes redundant information (e.g., listing entity/relation types could be more concise) and could be more front-loaded. Some sentences don't earn their place in a tool description context, making it less efficient than ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (knowledge graph construction with multiple operation types), no annotations, and no output schema, the description provides exceptional completeness. It covers purpose, usage scenarios, behavioral details, parameter semantics, valid values, return formats, error handling, and extensive implementation guidelines. This fully compensates for the lack of structured metadata and provides everything needed for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema description coverage, the description adds substantial semantic value through a dedicated 'Parameters explained' section. It explains how the 'type' parameter determines interpretation of 'data', provides detailed structural examples for each type (entities, relations, observations), lists all valid entity types (16 types) and relation types (25 types), and clarifies status/priority values. This transforms the schema's basic definitions into practical, domain-specific guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'constructing and enhancing the quantitative research knowledge graph by adding new research elements, relationships, and observations.' It specifies the exact operations (creating entities, relations, observations) and distinguishes this from sibling tools like 'deletecontext' and 'loadcontext' by focusing on creation rather than deletion or loading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'When to use this tool' section with 12 specific scenarios (e.g., 'Creating new research entities,' 'Establishing relationships between research elements'), and a detailed 'You should' section with 15 actionable guidelines (e.g., 'Begin by creating projects and datasets before more specific research elements,' 'Use consistent naming conventions'). This provides comprehensive guidance on when and how to use the tool effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
deletecontextA
A precise tool for removing elements from the quantitative research knowledge graph, enabling researchers to maintain data accuracy and refine their analytical framework.
When to use this tool:
Removing incorrect or duplicate research entities
Deleting erroneous relationships between research elements
Clearing outdated observations from research entities
Restructuring your research framework as analysis evolves
Removing invalid statistical tests or models
Correcting relationships between variables, datasets, or results
Cleaning up the knowledge graph during research refinement phases
Eliminating deprecated hypotheses or findings that are no longer supported
Removing preliminary analyses that have been superseded by more rigorous methods
Reorganizing your analytical structure by removing and recreating elements
Updating status assignments when research activities change state
Modifying priority assignments as research focus shifts
Restructuring sequential relationships between research processes
Key features:
Provides targeted deletion capabilities for three distinct types of knowledge graph elements: entities, relations, and observations
Maintains knowledge graph integrity during deletion operations
Supports batch deletion of multiple items in a single operation
Returns clear confirmation of deletion results
Preserves the overall structure of the research knowledge graph while removing specific elements
Performs validation to ensure deletion requests are properly formatted
Handles status and priority relation management
Supports modification of sequential process relationships
Parameters explained:
type: The type of deletion operation to perform
Accepts: "entities", "relations", or "observations"
Determines how the data parameter is interpreted
data: The elements to remove from the knowledge graph (structure varies by type):
For "entities": Array of entity names to delete
Example: ["Dataset_2021", "Hypothesis_A", "Model_Linear", "Status_Completed"]
For "relations": Array of relation objects, each containing:
from: Name of the source entity
to: Name of the target entity
relationType: Type of relationship to remove (e.g., "correlates_with", "has_status", "has_priority", "precedes")
Example: [{ "from": "Variable_Age", "to": "Variable_Income", "relationType": "correlates_with" }]
For "observations": Array of objects, each containing:
entityName: Name of the entity to remove observations from
observations: Array of specific observations to remove
Example: [{ "entityName": "Dataset_Main", "observations": ["size:1000", "collection_date:2022-05-15"] }]
Deletion behavior by type:
Entities: Removes the specified entities and all their associated relations from the knowledge graph
Relations: Removes only the specified relationships, leaving the connected entities intact
Observations: Removes specific observations from entities while preserving the entities themselves
Status and Priority Management:
When deleting status or priority entities, be aware of the impact on entities that reference them
For changing an entity's status, delete the existing has_status relation before creating a new one
For changing priority, delete the existing has_priority relation before creating a new one
Status values (active, completed, pending, abandoned) are managed through relations, not direct properties
Priority values (high, low) are managed through relations, not direct properties
Sequential Process Management:
Removing precedes relations affects the logical flow of research processes
When reorganizing research phases, update all affected precedes relations
Consider restructuring sequential relationships after deletion to maintain methodological continuity
Sequential relationships are important for maintaining proper order in multi-step analyses
Safety considerations:
Entity deletion is permanent and will also remove all relationships involving those entities
Consider exporting or backing up your research knowledge graph before performing large-scale deletions
For sensitive operations, consider removing specific observations rather than entire entities
When removing statistical tests or results, consider the impact on your overall analysis framework
Status changes should be carefully managed to maintain accurate research progress tracking
Changes to sequential relationships may affect dependent research activities
Return information:
JSON response indicating success or failure
For successful operations:
Success flag set to true
Confirmation message with count of deleted items
For entities: "Deleted X entities"
For relations: "Deleted X relations"
For observations: "Deleted observations from X entities"
For failed operations:
Success flag set to false
Error message describing the issue
You should:
Be specific in your deletion requests to avoid unintended data loss
Use relations deletion when you want to disconnect entities without removing them
For observations, provide the exact observations to ensure only the intended content is removed
When restructuring your analysis, consider how deletions will affect related elements
Use deletecontext in conjunction with buildcontext to refine and evolve your research framework
Regularly review your knowledge graph for elements that may need to be removed or updated
Consider the cascading effects of entity deletion on your overall research structure
Delete outdated statistical results when new analyses are performed
Remove incorrect relationships between variables when better understanding is gained
When updating entity status, delete the old has_status relation before creating a new one
When updating entity priority, delete the old has_priority relation before creating a new one
Maintain logical consistency when modifying sequential analysis relationships
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Data for the deletion operation, structure varies by type but must be an array | |
| type | Yes | Type of deletion operation: 'entities', 'relations', or 'observations' |
TDQS
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 and excels. It details deletion permanence ('Entity deletion is permanent'), safety considerations ('Consider exporting or backing up'), cascading effects ('will also remove all relationships involving those entities'), and specific behaviors by type ('Entities: Removes the specified entities and all their associated relations'). It also covers status/priority management and sequential process impacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive but overly verbose at ~1,200 words with repetitive sections. While well-structured with clear headings, it includes redundant advice (e.g., multiple mentions of status/priority management) and could be more front-loaded. Some sentences like 'Regularly review your knowledge graph for elements that may need to be removed or updated' don't earn their place for tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description provides exceptional completeness. It covers purpose, usage scenarios, parameter semantics, behavioral details, safety considerations, return information, and integration with sibling tools. The detailed examples and type-specific behaviors compensate for the lack of structured output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema description coverage, the description adds substantial value beyond the schema. It provides detailed 'Parameters explained' with examples for each type, clarifies how 'data' structure varies by 'type', and explains behavioral differences ('Deletion behavior by type'). The schema only indicates 'structure varies by type' and enum values, while the description gives concrete examples and interpretation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'removing elements from the quantitative research knowledge graph' with specific verbs like 'removing,' 'deleting,' and 'clearing.' It distinguishes itself from sibling tools like 'buildcontext' by focusing exclusively on deletion operations rather than creation or modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'When to use this tool' section with 13 specific scenarios, including 'Removing incorrect or duplicate research entities' and 'Deleting erroneous relationships.' It also mentions alternatives like using 'relations deletion when you want to disconnect entities without removing them' and suggests using 'deletecontext in conjunction with buildcontext to refine and evolve your research framework.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
endsessionA
A multi-stage tool for documenting quantitative research sessions, recording statistical analyses, tracking dataset updates, and creating a structured record of research evolution.
When to use this tool:
Concluding a quantitative research analysis session
Documenting updates to datasets and variables
Recording new statistical analyses and test results
Tracking creation of data visualizations
Documenting hypothesis test results and conclusions
Updating statistical model performance information
Creating a structured record of research activities
Establishing a formal conclusion to a focused research period
Building a historical record of project development
Documenting observations and insights from statistical analysis
Updating status values for research activities and entities
Assigning or modifying priority levels for research tasks
Establishing or modifying sequential relationships between research processes
Key features:
Provides a structured, multi-stage workflow for research session documentation
Records dataset updates in the knowledge graph
Captures new statistical analyses and their results
Tracks creation of data visualizations and their purposes
Documents hypothesis test outcomes with statistical significance
Updates statistical model performance metrics
Updates project status information
Maintains session continuity with unique session IDs
Supports revision of previous stages when needed
Offers a comprehensive assembly stage that consolidates all session information
Manages status progression of research activities
Tracks priority assignments for research tasks
Documents sequential relationships between research processes
The endsession tool uses a sequential, multi-stage approach with 9 typical stages:
Summary Stage: Records basic session information
Dataset Updates Stage: Documents changes to datasets
New Analyses Stage: Records new statistical tests performed
New Visualizations Stage: Documents visualizations created
Hypothesis Results Stage: Records outcomes of hypothesis tests
Model Updates Stage: Documents changes to statistical models
Status Updates Stage: Records changes to entity status values
Project Status Stage: Updates the overall project status
Assembly Stage: Consolidates all information and finalizes the session record
Parameters explained:
sessionId: Required - Unique identifier for the research session
Obtained from the startsession tool
Example: "quant_1234567890_abc123"
stage: Required - Current stage of the endsession workflow
Accepts: "summary", "datasetUpdates", "newAnalyses", "newVisualizations", "hypothesisResults", "modelUpdates", "statusUpdates", "projectStatus", or "assembly"
Each stage has specific data requirements and processing logic
stageNumber: Required - The sequence number of the current stage
Starts at 1 and typically progresses through the stages
Used to track progress through the session documentation workflow
totalStages: Required - Total number of stages planned for this workflow
Typically 9 for the complete workflow
Provides context for the progress within the overall process
analysis: Optional - Text analysis or observations for the current stage
Descriptive text explaining the work done in this stage
Example: "Analyzed multiple regression results and identified significant predictors"
stageData: Optional - Stage-specific structured data
Structure varies by stage type:
summary: { summary: "Session summary text", duration: "3 hours", project: "ProjectName" }
datasetUpdates: { datasets: [{ name: "Dataset1", size: "500 rows", variables: "10", status: "active", description: "Dataset description" }] }
newAnalyses: { analyses: [{ name: "Analysis1", type: "regression", result: "p<0.05", pValue: "0.03", variables: ["var1", "var2"] }] }
newVisualizations: { visualizations: [{ name: "Viz1", type: "scatter", description: "Correlation visualization", datasetName: "Dataset1" }] }
hypothesisResults: { hypotheses: [{ name: "H1", status: "completed", evidence: "Statistical significance in regression model", pValue: "0.02" }] }
modelUpdates: { models: [{ name: "Model1", type: "regression", performance: "R²=0.85", variables: ["var1", "var2"] }] }
statusUpdates: { statusUpdates: [{ entityName: "Dataset1", newStatus: "completed", note: "Data cleaning and validation complete" }, { entityName: "Model2", newStatus: "active", note: "Model training in progress" }] }
projectStatus: { projectStatus: "active", projectObservation: "Data analysis phase complete", priorityUpdates: [{ entityName: "AnalysisTask1", priority: "high", note: "Critical for upcoming publication" }], sequenceUpdates: [{ before: "DataCleaning", after: "ModelTraining", note: "Reorganized analysis workflow" }] }
assembly: No stageData needed - automatically assembled from previous stages
nextStageNeeded: Required - Whether additional stages are needed after this one
Boolean value (true/false)
Set to false on the final stage to complete the session
isRevision: Optional - Whether this is revising a previous stage
Boolean value (true/false)
Default: false
revisesStage: Optional - If revising, which stage number is being revised
Required when isRevision is true
Indicates which previous stage is being updated
Status and Priority Management:
The statusUpdates stage allows for batch updates to entity status values
Valid status values include: active, completed, pending, abandoned
Priority assignments (high, low) can be modified in the projectStatus stage
Status changes are implemented through has_status relations
Priority changes are implemented through has_priority relations
Status and priority changes are tracked to maintain research progress history
Sequential Process Management:
The projectStatus stage allows for defining or modifying sequential relationships
The precedes relation is used to establish logical ordering between research processes
Sequential updates help maintain a coherent research workflow
Process sequences can be visualized through the loadcontext tool
Critical research sequences are maintained to ensure methodological integrity
When the endsession workflow completes (assembly stage with nextStageNeeded: false), the tool performs these updates:
Dataset Entities: Updates existing datasets or creates new dataset entities with the provided information
Statistical Analyses: Creates entities for statistical tests and links them to projects and variables
Visualizations: Creates entities for data visualizations and links them to datasets and projects
Hypothesis Updates: Updates existing hypotheses or creates new hypothesis entities with test results
Model Updates: Updates existing model entities or creates new models with performance metrics
Status Updates: Updates entity status values through has_status relations
Priority Updates: Updates entity priority values through has_priority relations
Sequence Updates: Updates sequential relationships through precedes relations
Project Status: Updates the project status, adds an updated timestamp, and records observations
Return information:
JSON response with the following structure when stages are in progress:
success: Boolean indicating whether the operation succeeded
stageCompleted: The stage that was just completed
nextStageNeeded: Whether more stages are required
stageResult: The processed result of the current stage
Formatted markdown text summary when the session is completed, including:
Session date and project name
Summary of the session
Dataset updates
New statistical analyses
New visualizations
Hypothesis test results
Model updates
Status changes
Priority modifications
Sequential relationship updates
Project status update
You should:
Complete all stages in order for comprehensive session documentation
Provide specific details in each stage for accurate research documentation
Specify dataset updates with clear size, variable count, and status information
Include p-values and variable names for statistical analyses
Connect visualizations to specific datasets when possible
Document hypothesis test results with evidence and significance levels
Include performance metrics when updating statistical models
Update entity status using has_status relations with valid status values (active, completed, pending, abandoned)
Assign priorities using has_priority relations with valid priority values (high, low)
Define process sequences using precedes relations to establish research workflows
Include relevant observations for project status updates
If making a revision, specify which stage is being revised
Only mark nextStageNeeded as false on the final assembly stage
Review the final summary message to confirm all session details were recorded properly
Use the unique session ID consistently across all stages
| Name | Required | Description | Default |
|---|---|---|---|
| analysis | No | Text analysis or observations for the current stage | |
| isRevision | No | Whether this is revising a previous stage | |
| nextStageNeeded | Yes | Whether additional stages are needed after this one (false for final stage) | |
| revisesStage | No | If revising, which stage number is being revised | |
| sessionId | Yes | The unique session identifier obtained from startsession | |
| stage | Yes | Current stage of analysis: 'summary', 'datasetUpdates', 'newAnalyses', 'newVisualizations', 'hypothesisResults', 'modelUpdates', 'projectStatus', or 'assembly' | |
| stageData | No | Stage-specific data structure - format depends on the stage type: - For 'summary' stage: { summary: "Session summary text", duration: "3 hours", project: "Project Name" } - For 'datasetUpdates' stage: { datasets: [{ name: "Dataset1", size: "500 rows", variables: "10", status: "cleaned", description: "Dataset description" }] } - For 'newAnalyses' stage: { analyses: [{ name: "Analysis1", type: "regression", result: "p<0.05", pValue: "0.03", variables: ["var1", "var2"] }] } - For 'newVisualizations' stage: { visualizations: [{ name: "Viz1", type: "scatter", description: "Correlation visualization", datasetName: "Dataset1" }] } - For 'hypothesisResults' stage: { hypotheses: [{ name: "H1", status: "confirmed", evidence: "Statistical significance in regression model", pValue: "0.02" }] } - For 'modelUpdates' stage: { models: [{ name: "Model1", type: "regression", performance: "R²=0.85", variables: ["var1", "var2"] }] } - For 'projectStatus' stage: { projectStatus: "in_progress", projectObservation: "Data analysis phase complete" } - For 'assembly' stage: no stageData needed - automatic assembly of previous stages | |
| stageNumber | Yes | The sequence number of the current stage (starts at 1) | |
| totalStages | Yes | Total number of stages in the workflow (typically 8 for standard workflow) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels. It details the multi-stage workflow with 9 stages, explains what happens upon completion (updates to datasets, analyses, visualizations, etc.), describes return formats (JSON during stages, markdown summary at end), and covers revision capabilities and session continuity management.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive but overly verbose at 1000+ words, with redundant sections (e.g., 'Key features' repeats stage details). While well-structured with clear headings, it could be more concise by eliminating repetition and tightening explanations without losing critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 9 parameters, nested objects, no annotations, and no output schema, the description is exceptionally complete. It covers purpose, usage, workflow, parameters with examples, behavioral outcomes, return formats, and best practices, leaving no gaps for agent understanding despite the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema description coverage, the description adds substantial value beyond the schema. It provides detailed examples for each stageData structure, explains the purpose of each parameter in context (e.g., sessionId from startsession, stage progression logic), and clarifies relationships between parameters like isRevision and revisesStage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'documenting quantitative research sessions' with specific verbs like 'recording statistical analyses' and 'tracking dataset updates.' It distinguishes itself from sibling tools by focusing on session conclusion rather than session initiation (startsession) or context management (loadcontext, buildcontext, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists 13 'When to use this tool' scenarios, providing clear context for application. It distinguishes usage from alternatives by specifying it's for 'concluding a quantitative research analysis session' and 'establishing a formal conclusion to a focused research period,' contrasting with startsession for initiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
loadcontextA
A powerful tool for retrieving detailed contextual information about quantitative research entities, providing rich statistical insights tailored to each entity type.
When to use this tool:
Retrieving comprehensive information about research projects, datasets, variables, and statistical elements
Exploring the statistical relationships between variables
Examining hypothesis tests and their results
Reviewing model performance metrics and parameters
Analyzing dataset properties and descriptive statistics
Inspecting visualizations related to specific datasets or projects
Understanding statistical test results and their significance
Preparing for statistical analysis by establishing data context
Examining variable distributions and correlations
Getting a holistic view of quantitative research progress
Tracking research activities by their current status
Managing tasks based on their assigned priorities
Understanding sequential relationships between research processes
Key features:
Provides richly formatted, context-aware information about quantitative research entities
Adapts output format based on entity type (project, dataset, variable, model, hypothesis, statistical_test)
Presents both direct entity information and related statistical elements
Shows statistical metrics, p-values, and significance levels
Tracks entity views within the current research session
Formats information in a structured, readable markdown format
Highlights relationships between variables and statistical tests
Presents performance metrics for statistical models
Shows dataset characteristics and variable properties
Includes status information for tracking research progress
Displays priority assignments for critical research elements
Visualizes sequential relationships between research processes
Parameters explained:
entityName: Required - The name of the entity to retrieve context for
Example: "Customer Satisfaction Study", "Survey_Dataset", "Age_Variable"
entityType: Optional - The type of entity being retrieved
Default: "project"
Helps the system format the output appropriately
Common types include: "project", "dataset", "variable", "model", "hypothesis", "statistical_test", "status", "priority"
sessionId: Optional - The current session identifier
Typically provided by startsession
Used for tracking entity views within the session
Each entity type returns specialized context information:
Project: Shows project status (via has_status), description, datasets, hypotheses, statistical tests, models, key visualizations, and priority (via has_priority)
Dataset: Displays project affiliation, status (via has_status), size, variable count, descriptive statistics, visualizations, and models trained on it
Variable: Shows data type, role, scale, descriptive statistics, normality tests, and correlations with other variables
Model: Displays type, training dataset, creation date, status (via has_status), performance metrics, and model parameters
Hypothesis: Shows status (via has_status), p-value, creation date, associated tests, and project affiliation
Statistical Test: Shows test type, result, p-value, date, variables analyzed, and hypotheses tested
Status: Shows all entities assigned this status value, organized by entity type
Priority: Shows all entities assigned this priority value, organized by entity type
Other Entity Types: Shows basic entity information and observations
Status and Priority Information:
All entity displays include status information when available via has_status relations
Priority assignments are shown for research tasks and other prioritized elements
Valid status values include: active, completed, pending, abandoned
Valid priority values include: high, low
Sequential Process Relationships:
Entity displays show preceding and following entities through precedes relations
Process sequences are visualized to show workflow between research activities
Research phases and activities display their position in the overall analytical pipeline
Sequential relationships help understand dependencies in multi-step analysis processes
Return information:
Formatted markdown text with hierarchical structure
Sections adapted to the specific entity type
Related entities shown with their statistical properties
Status and priority information prominently displayed
Sequential relationships clearly indicated
Error messages if the entity doesn't exist or can't be retrieved
You should:
Specify the exact entity name for accurate retrieval
Provide the entity type when possible for optimally formatted results
Start with project entities to get a high-level overview of research
Examine dataset context to understand variable relationships
Review variable context to understand distributions and correlations
Use hypothesis context to assess research question outcomes
Explore model context to evaluate predictive performance
Examine statistical test context to understand analysis results
Check status entities to see all research elements at the same stage
Review priority entities to identify critical research tasks
Explore sequential relationships to understand analysis workflows
After retrieving context, follow up on specific entities of interest
Use in conjunction with startsession to maintain session tracking
Remember that this tool only retrieves existing information; use buildcontext to add new entities
| Name | Required | Description | Default |
|---|---|---|---|
| entityName | Yes | Name of the entity to load context for | |
| entityType | No | Type of entity to load (project, dataset, variable, etc.), defaults to 'project' | |
| sessionId | No | Session ID from startsession to track context loading |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does an excellent job disclosing behavioral traits. It explains the tool adapts output based on entity type, tracks session views, returns formatted markdown, includes error handling, and clarifies it's read-only ('only retrieves existing information'). It could improve by mentioning rate limits or authentication needs, but covers most critical behavioral aspects thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While well-structured with clear sections, the description is excessively long with repetitive content. The 'Key features' section largely reiterates what's in 'When to use', and the entity type details could be more concise. However, it's front-loaded with purpose and usage guidelines, and every section adds some value, preventing a lower score despite verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides comprehensive context about what information is returned for each entity type, output format (formatted markdown), error conditions, and relationships to other tools. It covers almost everything an agent needs, though it could explicitly describe the exact structure of returned markdown or provide more detail on error messages.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so the baseline is 3. The description adds significant value beyond the schema by providing detailed explanations for each parameter with examples (e.g., 'Customer Satisfaction Study' for entityName), listing common entity types, explaining how entityType affects formatting, and clarifying sessionId's purpose ('Typically provided by startsession'). This goes well beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'retrieving detailed contextual information about quantitative research entities' with specific examples of entity types (projects, datasets, variables, etc.). It distinguishes itself from sibling tools like 'buildcontext' (which adds new entities) and 'deletecontext' (which removes entities), establishing a clear read-only retrieval function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive guidance with explicit 'When to use this tool' bullet points covering various scenarios (retrieving information, exploring relationships, examining tests, etc.). It also includes a dedicated 'You should' section with specific recommendations for different entity types and explicitly mentions when NOT to use it ('use buildcontext to add new entities'), making it highly actionable for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
startsessionA
A comprehensive tool for initializing a new quantitative research session, providing structured information about ongoing research projects, datasets, statistical models, and recent research activities.
When to use this tool:
Beginning a new quantitative analysis session
Getting oriented to your current research state across multiple projects
Planning which research elements to focus on in the current session
Reviewing recent research activities and progress
Identifying active research projects and their status
Exploring available datasets for analysis
Reviewing current research questions
Examining statistical models and their performance
Viewing recent visualizations of your data
Establishing research context before diving into specific analysis tasks
Re-engaging with your research after time away
Prioritizing high-priority research tasks
Tracking the status of various research activities
Understanding sequential research processes
Key features:
Generates a unique session identifier for tracking research activities
Retrieves and displays recent research sessions with summaries
Lists active research projects with status information
Provides a sample of available datasets with key information
Presents current research questions guiding your studies
Highlights recent statistical models with performance metrics
Displays recent visualizations with brief descriptions
Formats information in an easily scannable format for quick orientation
Integrates with the loadcontext tool for deeper exploration
Maintains continuity between research sessions
Tracks research session history for progress review
Displays high-priority research tasks needing attention
Shows status information for key research activities
Presents sequential relationships between research processes
Parameters explained: No parameters required - the tool automatically retrieves all relevant context.
Return information:
Recent research sessions (up to 3) with:
Date
Project name
Brief summary
Active research projects with:
Project name
Current status (via has_status relation)
Priority (if assigned via has_priority relation)
Available datasets (up to 5) with:
Dataset name
Type of data
Associated project
Status (active, completed, pending, abandoned)
Research questions (up to 5) with:
Question text
Associated project
Status (via has_status relation)
Recent statistical models with:
Model name
Model type
Performance metrics
Status (via has_status relation)
Recent visualizations with:
Visualization name
Type (chart, plot, etc.)
Associated dataset
High-priority research tasks (up to 5) with:
Task name
Current status (active, completed, pending, abandoned)
Associated project
Upcoming research activities (up to 3) with:
Activity name
Prerequisite activities (via precedes relation)
Current status (via has_status relation)
Status and Priority Information:
Research activities are displayed with their current status values
High-priority tasks are prominently highlighted for attention
Valid status values include: active, completed, pending, abandoned
Priority values (high, low) help indicate which tasks need immediate attention
Status is retrieved through has_status relations
Priority is retrieved through has_priority relations
Sequential Process Information:
Upcoming activities show prerequisite tasks that must be completed first
Research phases are presented in their logical sequence
The precedes relation is used to determine activity ordering
Sequential relationships help visualize the research workflow
Session Workflow:
Start a research session with startsession
Review the provided context to decide what to focus on
Use loadcontext to retrieve detailed information about specific research elements
Conduct your analysis, adding new elements with buildcontext as needed
End the session with endsession to record your research progress
You should:
Begin each focused research period with startsession to establish context
Review recent sessions to maintain continuity in your research
Identify active projects that require attention
Note available datasets for potential analysis
Consider current research questions that need investigation
Review existing statistical models before creating new ones
Examine recent visualizations to understand data representation
Prioritize high-priority tasks for immediate attention
Check the status of research activities to maintain progress awareness
Consider sequential relationships when planning your research activities
Use the session ID when using other tools to maintain session tracking
After completing a session, record your progress using endsession
Establish a regular cadence of research sessions to maintain momentum
Use the structured overview to make deliberate choices about where to focus your analytical effort
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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 thoroughly describes what the tool does: generates a session ID, retrieves and displays various research elements (projects, datasets, models, etc.), formats information scannably, and integrates with loadcontext. It also explains the tool's role in tracking session history and maintaining continuity. However, it lacks details on potential limitations like rate limits or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long and repetitive, with multiple sections (Key features, Return information, Status and Priority Information, Sequential Process Information, Session Workflow, You should) that overlap in content. For example, 'Return information' lists details already implied in earlier sections. While structured, it includes redundant sentences like 'Establish a regular cadence of research sessions to maintain momentum' that don't add unique value, reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (initializing sessions with multiple data types) and lack of annotations or output schema, the description provides comprehensive context: it details what information is returned (e.g., recent sessions, active projects, datasets), explains status/priority systems, and outlines workflow integration. However, without an output schema, it could benefit from more precise formatting details for the returned data to fully compensate for the missing structured output definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the baseline is 4. The description explicitly states 'No parameters required - the tool automatically retrieves all relevant context,' which adds clarity beyond the schema by confirming the tool's autonomous operation. No further parameter details are needed given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose as 'initializing a new quantitative research session' and 'providing structured information about ongoing research projects, datasets, statistical models, and recent research activities.' It clearly distinguishes this from siblings like loadcontext (for deeper exploration) and endsession (for recording progress), establishing a specific verb+resource combination with clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'When to use this tool' section with 14 specific scenarios, such as 'Beginning a new quantitative analysis session' and 'Re-engaging with your research after time away.' It also provides a detailed 'Session Workflow' section that explains how this tool fits into a sequence with loadcontext, buildcontext, and endsession, offering clear alternatives and integration points.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool has a clearly distinct purpose: advancedcontext for querying, buildcontext for adding, deletecontext for removing, loadcontext for retrieving details, startsession for initializing, and endsession for documenting sessions. There is no overlap in functionality; an agent can easily differentiate between them based on their names and descriptions.
All tool names follow a consistent pattern of descriptive compound words or phrases (e.g., advancedcontext, buildcontext, deletecontext, loadcontext, startsession, endsession). They use consistent casing (lowercase) and structure, making them predictable and readable without any deviations.
With 6 tools, the server is well-scoped for quantitative research management. Each tool serves a distinct and essential role in the research lifecycle (query, add, delete, retrieve details, initialize sessions, document sessions), and no tool feels redundant or missing for the domain.
The tool set provides complete coverage for managing a quantitative research knowledge graph: querying (advancedcontext), creating (buildcontext), deleting (deletecontext), retrieving details (loadcontext), session initialization (startsession), and session documentation (endsession). This covers the full CRUD lifecycle and research workflow without any gaps.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Research portfolio management — organize projects and track research artifacts.
Provenance-tagged knowledge graph of AI/ML research: papers, citations, methods, code.
Knowledge graph ingestion, entity search, ontology analysis, and CoSync scoring.
Related MCP Servers
- FlicenseAqualityDmaintenanceProvides tools for managing project knowledge graphs, enabling structured representation of projects, tasks, milestones, resources, and team members.616
- FlicenseAqualityDmaintenanceProvides tools for managing qualitative research knowledge graphs, enabling structured representation of research projects, participants, interviews, observations, codes, themes, and findings.610
- FlicenseAqualityDmaintenanceProvides tools for managing student knowledge graphs, enabling structured representation of courses, assignments, exams, concepts, and study resources.61
- AlicenseNot gradedqualityNot gradedmaintenanceProvides tools for semantic decomposition, proof search, knowledge graph operations, and neuro-symbolic reasoning that bridges neural LLMs with symbolic AI through RDF triples, lambda calculus, and compositional intelligence principles.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/tejpalvirk/quantitativeresearch'
If you have feedback or need assistance with the MCP directory API, please join our Discord server