Skip to main content
Glama
tejpalvirk

Quantitative Researcher MCP Server

by tejpalvirk

양적 연구자 MCP 서버

양적 연구 지식 그래프를 관리하고 연구 프로젝트, 데이터세트, 변수, 가설, 통계 검정, 모델 및 결과를 체계적으로 표현하는 도구를 제공하는 MCP 서버 구현입니다. 이 서버는 양적 연구자들이 데이터를 정리하고, 분석 결과를 추적하고, 가설을 평가하고, 수치 데이터에서 통찰력을 창출하는 데 도움을 줍니다.

특징

  • 지속적인 연구 컨텍스트 : 여러 분석 세션에 걸쳐 연구 엔터티 및 관계에 대한 구조화된 지식 그래프를 유지합니다.

  • 연구 세션 관리 : 고유 ID로 연구 분석 세션을 추적하고 시간 경과에 따른 진행 상황을 기록합니다.

  • 가설 검정 : 가설, 관련 검정 및 결과 결론을 추적합니다.

  • 데이터 세트 관리 : 데이터 세트 내의 기술 통계 및 변수를 구성하고 추적합니다.

  • 통계 분석 : 통계적 검정, 모델 및 결과를 기록합니다.

  • 변수 관계 : 변수 간의 상관 관계, 예측 및 기타 관계를 추적합니다.

  • 연구 질문 추적 : 데이터 분석을 특정 연구 질문에 연결

  • 데이터 시각화 : 데이터 세트 및 결과로부터 생성된 문서 시각화

  • 모델 성능 : 통계적 모델 성능 지표 모니터링

  • 연구 결과 문서화 : 결과를 뒷받침하는 통계적 증거에 연결

  • 연구 방법론 문서 : 방법론적 결정 및 접근 방식 추적

Related MCP server: Qualitative Researcher MCP Server

엔티티

Quantitative Researcher MCP 서버는 다음 엔터티 유형을 인식합니다.

  • 프로젝트 : 전체 연구 조사

  • 데이터 세트 : 분석에 사용되는 데이터 모음

  • 변수 : 데이터 세트의 특정 측정 가능한 속성

  • 가설 : 형식적으로 검증 가능한 진술

  • statisticalTest : 데이터에 적용되는 분석 방법

  • 결과 : 통계 분석 결과

  • analysisScript : 분석을 수행하는 데 사용되는 코드

  • 시각화 : 데이터의 시각적 표현

  • 모델 : 통계적/수학적 모델

  • 문헌 : 학술 자료

  • researchQuestion : 연구를 안내하는 공식적인 질문

  • 발견 : 결과 또는 결론

  • 참여자 : 연구대상자

  • 상태 : 엔터티 상태 값(활성, 완료, 보류, 중단)

  • 우선순위 : 우선순위 수준 값(높음, 낮음)

관계

엔터티는 다음 관계 유형을 통해 연결될 수 있습니다.

  • correlations_with : 변수 간 통계적 상관관계

  • 예측 : 독립변수에서 종속변수로의 예측 관계

  • 검정 : 통계적 검정은 가설을 검증합니다.

  • 분석 : 데이터 세트에 대해 수행된 분석

  • 생성 : 분석이 결과를 생성합니다

  • 시각화 : 시각화는 데이터나 결과를 표시합니다.

  • 포함 : 계층적 관계

  • part_of : 엔티티가 다른 엔티티의 일부입니다.

  • depends_on : 종속 관계

  • 뒷받침하다 : 가설이나 발견을 뒷받침하는 증거

  • 모순 : 가설이나 발견과 모순되는 증거

  • derived_from : 엔터티가 다른 엔터티에서 파생되었습니다.

  • controls_for : 혼동을 위한 변수/방법 제어

  • 조절하다 : 변수는 관계를 조절한다

  • 매개하다 : 변수가 관계를 매개한다

  • 구현 : 스크립트는 통계적 테스트/모델을 구현합니다.

  • 비교하다 : 그룹/변수 간의 통계적 비교

  • 포함 : 모델에 변수가 포함됩니다.

  • 검증 : 모델이나 결과를 검증합니다.

  • 인용 : 참고문헌

  • has_status : 엔터티를 현재 상태(활성, 완료, 보류, 중단)에 연결합니다.

  • has_priority : 엔티티를 우선순위 수준(높음, 낮음)에 연결합니다.

  • 선행 : 순서상 한 프로세스나 활동이 다른 프로세스나 활동보다 먼저 나온다는 것을 나타냅니다.

사용 가능한 도구

Quantitative Researcher MCP 서버는 연구 지식과 상호 작용하기 위한 다음과 같은 도구를 제공합니다.

시작 세션

새로운 양적 연구 세션을 시작하고, 고유 세션 ID를 생성하며, 현재 연구 프로젝트, 데이터세트, 모델, 시각화 및 이전 세션을 표시합니다. has_status 관계를 통해 상태 정보를, has_priority 관계를 통해 우선순위를 표시하며, 순차적 프로세스 관계를 기반으로 다음에 수행할 준비가 된 활동을 식별합니다.

로드 컨텍스트

특정 엔터티(프로젝트, 데이터 세트, 변수 등)에 대한 자세한 컨텍스트를 로드하고 엔터티 유형에 따라 관련 정보를 표시합니다. 상태 정보, 우선순위 수준 및 순차적 프로세스 관계가 포함됩니다.

세션 종료

구조화된 다단계 프로세스를 통해 연구 세션의 결과를 기록합니다.

  1. 요약 : 세션 요약, 기간 및 프로젝트 초점을 기록합니다.

  2. datasetUpdates : 세션 중 데이터세트에 대한 문서 업데이트

  3. newAnalyses : 수행된 새로운 통계 분석을 기록합니다.

  4. newVisualizations : 생성된 새로운 데이터 시각화를 추적합니다.

  5. hypothesisResults : 가설 검정 결과 문서화

  6. modelUpdates : 통계 모델에 대한 업데이트를 기록합니다.

  7. statusUpdates : 엔터티 상태 값의 변경 사항을 기록합니다.

  8. projectStatus : 전체 프로젝트 상태, 우선순위 할당 및 순차적 관계를 업데이트합니다.

  9. 어셈블리 : 모든 세션 데이터의 최종 어셈블리

빌드 컨텍스트

지식 그래프에 새로운 엔터티, 관계 또는 관찰을 생성합니다.

  • 엔터티 : 새로운 연구 엔터티(프로젝트, 데이터 세트, 변수, 상태, 우선순위 등)를 추가합니다.

  • 관계 : 엔티티 간 관계 생성(has_status, has_priority, precedes 포함)

  • 관찰 : 기존 엔터티에 관찰 추가

컨텍스트 삭제

지식 그래프에서 엔터티, 관계 또는 관찰을 제거합니다.

  • 엔티티 : 연구 엔티티 제거

  • 관계 : 엔터티 간 관계(상태, 우선순위, 순차 관계 포함)를 제거합니다.

  • 관찰 : 엔터티에서 특정 관찰을 제거합니다.

고급 컨텍스트

지식 그래프에서 정보를 검색합니다.

  • 그래프 : 전체 지식 그래프를 가져옵니다

  • 검색 : 쿼리 기준에 따라 노드 검색

  • 노드 : 이름으로 특정 노드 가져오기

  • 관련 : 관련 엔터티 찾기

  • 상태 : 특정 상태 값(활성, 완료, 보류, 중단)을 가진 엔터티를 찾습니다.

  • 우선순위 : 특정 우선순위 값(높음, 낮음)을 갖는 엔터티 찾기

  • 순서 : 연구 프로세스에 대한 순차적 관계 식별

도메인별 기능

Quantitive Researcher MCP 서버에는 양적 연구를 위한 특수 도메인 기능이 포함되어 있습니다.

  • getProjectOverview : 연구 질문, 방법론, 데이터 세트, 변수를 포함한 프로젝트에 대한 포괄적인 보기

  • getDatasetAnalysis : 변수, 기술 통계, 데이터 품질을 포함한 데이터 세트 내용 분석

  • getHypothesisTests : 가설 검정 및 결과 검토

  • getVariableRelationships : 변수 간의 상관 관계, 예측 및 기타 관계를 조사합니다.

  • getStatisticalResults : 통계 분석 결과를 요약합니다.

  • getVisualizationGallery : 데이터 세트 및 결과에 대해 생성된 시각화 보기

  • getModelPerformance : 통계 모델에 대한 성능 지표 평가

  • getResearchQuestionResults : 연구 질문별로 분석 및 결과 정리

  • getVariableDistribution : 개별 변수의 분포와 속성을 조사합니다.

  • getStatusOverview : 특정 상태(활성, 완료, 보류, 중단)의 모든 엔터티를 봅니다.

  • getPriorityItems : 우선순위가 높은 연구 과제 및 활동 식별

  • getResearchSequence : 선행 관계에 따라 연구 프로세스 순서를 시각화합니다.

예시 프롬프트

세션 시작

지엑스피1

연구 맥락 로딩 중

Load the context for the Climate Impact Study project so I can see the current state of my statistical analyses.

녹음 세션 결과

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.

연구 지식 관리

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.

용법

이 MCP 서버는 양적 연구자에게 다음을 제공합니다.

  • 분석 연속성 유지 : 여러 연구 세션에 걸쳐 분석 및 결과 추적

  • 통계적 증거 구성 : 가설을 뒷받침하는 통계적 테스트 및 결과에 연결합니다.

  • 문서 변수 관계 : 변수가 서로 어떻게 상관관계를 맺고, 예측하고, 영향을 미치는지 기록합니다.

  • 모델 개발 추적 : 통계 모델의 진화와 성능 문서화

  • 결과 해석 지원 : 통계적 결과를 연구 질문 및 이론적 프레임워크에 연결합니다.

  • 방법론적 엄격성 보장 : 방법론적 결정 및 분석 접근 방식 문서화

  • 연구 보고서 준비 : 연구 결과를 뒷받침하는 통계적 증거를 구성합니다.

  • 연구 진행 상황 추적 : 연구 라이프사이클 전반에 걸쳐 엔터티 상태를 모니터링합니다.

  • 연구 과제 우선순위 지정 : 우선순위가 높은 연구 활동을 식별하고 집중합니다.

  • 시퀀스 연구 프로세스 : 연구 및 분석 단계의 논리적 순서를 계획하고 시각화합니다.

구성

Claude Desktop과 함께 사용

claude_desktop_config.json 에 다음을 추가하세요:

GitHub에서 설치하고 npx로 실행하세요

{
  "mcpServers": {
    "quantitativeresearch": {
      "command": "npx",
      "args": [
        "-y",
        "github:tejpalvirk/quantitativeresearch"
      ]
    }
  }
}

전역적으로 설치하고 직접 실행하세요

먼저, 패키지를 전역으로 설치합니다.

npm install -g github:tejpalvirk/quantitativeresearch

그런 다음 Claude Desktop을 구성합니다.

{
  "mcpServers": {
    "quantitativeresearch": {
      "command": "contextmanager-quantitativeresearch"
    }
  }
}

도커

{
  "mcpServers": {
    "quantitativeresearch": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "mcp/quantitativeresearch"
      ]
    }
  }
}

건물

출처에서

# 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.js

도커:

docker build -t mcp/quantitativeresearch -f quantitativeresearch/Dockerfile .

특허

이 MCP 서버는 MIT 라이선스에 따라 라이선스가 부여됩니다. 즉, MIT 라이선스의 약관에 따라 소프트웨어를 자유롭게 사용, 수정 및 배포할 수 있습니다. 자세한 내용은 프로젝트 저장소의 LICENSE 파일을 참조하세요.

환경 변수

양적 연구 MCP 서버는 데이터가 저장되는 위치를 사용자 지정하기 위해 다음 환경 변수를 지원합니다.

  • MEMORY_FILE_PATH : 지식 그래프 데이터가 저장될 경로

    • 절대 경로 또는 상대 경로가 될 수 있습니다(상대 경로는 현재 작업 디렉토리를 사용함)

    • 기본값: ./quantitativeresearch/memory.json

  • SESSIONS_FILE_PATH : 세션 데이터가 저장될 경로

    • 절대 경로 또는 상대 경로가 될 수 있습니다(상대 경로는 현재 작업 디렉토리를 사용함)

    • 기본값: ./quantitativeresearch/sessions.json

사용 예:

# 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-quantitativeresearch

Available Tools

6 tools
advancedcontextA

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:

  1. 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

  1. 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

ParametersJSON Schema
NameRequiredDescriptionDefault
paramsYesParameters for the get operation, structure varies by type
typeYesType of get operation

TDQS

A4.6/5.0
Behavior4/5

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.

Conciseness3/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/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 '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.

Usage Guidelines5/5

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:

  1. type: The type of creation operation to perform

  • Accepts: "entities", "relations", or "observations"

  • Determines how the data parameter is interpreted

  1. 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

ParametersJSON Schema
NameRequiredDescriptionDefault
dataYesData for the creation operation, structure varies by type but must be an array
typeYesType of creation operation: 'entities', 'relations', or 'observations'

TDQS

A4.8/5.0
Behavior5/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 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.

Conciseness3/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/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 '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.

Usage Guidelines5/5

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:

  1. type: The type of deletion operation to perform

  • Accepts: "entities", "relations", or "observations"

  • Determines how the data parameter is interpreted

  1. 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

ParametersJSON Schema
NameRequiredDescriptionDefault
dataYesData for the deletion operation, structure varies by type but must be an array
typeYesType of deletion operation: 'entities', 'relations', or 'observations'

TDQS

A4.8/5.0
Behavior5/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 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.

Conciseness3/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/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 '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.

Usage Guidelines5/5

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:

  1. Summary Stage: Records basic session information

  2. Dataset Updates Stage: Documents changes to datasets

  3. New Analyses Stage: Records new statistical tests performed

  4. New Visualizations Stage: Documents visualizations created

  5. Hypothesis Results Stage: Records outcomes of hypothesis tests

  6. Model Updates Stage: Documents changes to statistical models

  7. Status Updates Stage: Records changes to entity status values

  8. Project Status Stage: Updates the overall project status

  9. Assembly Stage: Consolidates all information and finalizes the session record

Parameters explained:

  1. sessionId: Required - Unique identifier for the research session

  • Obtained from the startsession tool

  • Example: "quant_1234567890_abc123"

  1. 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

  1. 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

  1. 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

  1. 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"

  1. 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

  1. 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

  1. isRevision: Optional - Whether this is revising a previous stage

  • Boolean value (true/false)

  • Default: false

  1. 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:

  1. Dataset Entities: Updates existing datasets or creates new dataset entities with the provided information

  2. Statistical Analyses: Creates entities for statistical tests and links them to projects and variables

  3. Visualizations: Creates entities for data visualizations and links them to datasets and projects

  4. Hypothesis Updates: Updates existing hypotheses or creates new hypothesis entities with test results

  5. Model Updates: Updates existing model entities or creates new models with performance metrics

  6. Status Updates: Updates entity status values through has_status relations

  7. Priority Updates: Updates entity priority values through has_priority relations

  8. Sequence Updates: Updates sequential relationships through precedes relations

  9. 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

ParametersJSON Schema
NameRequiredDescriptionDefault
analysisNoText analysis or observations for the current stage
isRevisionNoWhether this is revising a previous stage
nextStageNeededYesWhether additional stages are needed after this one (false for final stage)
revisesStageNoIf revising, which stage number is being revised
sessionIdYesThe unique session identifier obtained from startsession
stageYesCurrent stage of analysis: 'summary', 'datasetUpdates', 'newAnalyses', 'newVisualizations', 'hypothesisResults', 'modelUpdates', 'projectStatus', or 'assembly'
stageDataNoStage-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
stageNumberYesThe sequence number of the current stage (starts at 1)
totalStagesYesTotal number of stages in the workflow (typically 8 for standard workflow)

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness3/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/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 '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.

Usage Guidelines5/5

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:

  1. entityName: Required - The name of the entity to retrieve context for

  • Example: "Customer Satisfaction Study", "Survey_Dataset", "Age_Variable"

  1. 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"

  1. 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

ParametersJSON Schema
NameRequiredDescriptionDefault
entityNameYesName of the entity to load context for
entityTypeNoType of entity to load (project, dataset, variable, etc.), defaults to 'project'
sessionIdNoSession ID from startsession to track context loading

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/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 '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.

Usage Guidelines5/5

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:

  1. Start a research session with startsession

  2. Review the provided context to decide what to focus on

  3. Use loadcontext to retrieve detailed information about specific research elements

  4. Conduct your analysis, adding new elements with buildcontext as needed

  5. 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

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior4/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 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.

Conciseness2/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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

A4.7/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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

ActivityInactive
ResponsivenessSyncing

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

Related MCP Servers

Latest Blog Posts

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