Skip to main content
Glama
tejpalvirk

Quantitative Researcher MCP Server

by tejpalvirk

deletecontext

Remove incorrect, duplicate, or outdated elements from a quantitative research knowledge graph. Delete entities, relations, or observations to refine data accuracy and maintain analytical framework integrity.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesData for the deletion operation, structure varies by type but must be an array
typeYesType of deletion operation: 'entities', 'relations', or 'observations'
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.

Install Server

Other Tools

Related Tools

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