Skip to main content
Glama
scriptstar

Data Engineering Tutor MCP Server

by scriptstar
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

Data Engineering Tutor MCP Server

This repo contains a simple Model Context Protocol (MCP) server built with Node.js and TypeScript. It acts as a "Data Engineering Tutor," providing personalized updates about Data Engineering concepts, patterns, and technologies to a connected AI client.

This server demonstrates key MCP concepts: defining Resources, Tools, and Prompts to create a stateful, interactive agent helper.

Prerequisites

  • Node.js (v18 or later recommended)

  • npm (or your preferred Node.js package manager like yarn or pnpm)

  • An AI client capable of connecting to an MCP server (e.g., Cursor, Claude desktop app)

  • An OpenRouter API Key (for fetching live Data Engineering updates via Perplexity)

Related MCP server: tech-collector-mcp

Setup

  1. Clone the Repository:

    # If you haven't already
# git clone <repository-url>
# cd <repository-directory>

  2. Install Dependencies:

    npm install

  3. Prepare API Key: The de_tutor_get_updates tool requires an OpenRouter API key.

    • Obtain your key from OpenRouter.

    • Create a .env file in the project root (you can copy .env.example).

    • Add your key to the .env file:

      OPENROUTER_API_KEY=sk-or-xxxxxxxxxxxxxxxxxxxxxxxxxx

      (Replace the placeholder with your actual key.)

  4. Build the Server: Compile the TypeScript code.

    npm run build

Running the Server

You can run the server directly using Node:

node build/index.js

Alternatively, configure your MCP client (like Cursor or the Claude desktop app) to launch the server. The server name is de-tutor and the binary name (if needed for client config) is also de-tutor.

Example Client Configuration (e.g., for Claude Desktop):

{
  "mcpServers": {
    "de-tutor": {
      "command": "node",
      "args": ["/full/path/to/your/project/build/index.js"],
      "env": {
        "OPENROUTER_API_KEY": "sk-or-xxxxxxxxxxxxxxxxxxxxxxxxxx"
      }
    }
  }
}

(Ensure the path in args is the correct absolute path to the built index.js file on your system. You might not need the env section here if you are already using the .env file, as the server loads it directly via dotenv.)

Using with Cursor

Cursor is an AI-first code editor that can act as an MCP client. Setting up this server with Cursor requires configuring the server launch and potentially setting up a Project Rule for the guidance prompt, although Cursor might also pick up the server-provided prompt.

  1. Configure Server in Cursor:

    • Go to Cursor Settings > MCP > Add new global MCP server.

    • Paste in the same JSON as the example client configuration above, ensuring the path to build/index.js is correct for your system.

  2. (Optional) Create a Cursor Project Rule for the Prompt: If you prefer explicit rules or find Cursor isn't using the server's prompt automatically, you can provide the guidance using Cursor's Project Rules feature.

    • Create the directory .cursor/rules in your project root if it doesn't exist.

    • Create a file inside it named de-tutor.rule (or any .rule filename).

    • Paste the following guidance text into de-tutor.rule:

      You are a helpful assistant connecting to a Data Engineering knowledge server. Your goal is to provide the user with personalized updates about new Data Engineering concepts, patterns, and technologies they haven't encountered yet.

Available Tools:
1.  `de_tutor_get_updates`: Fetches recent general news and articles about Data Engineering. Use this first to see what's new.
2.  `de_tutor_read_memory`: Checks which Data Engineering concepts the user already knows based on their stored knowledge profile.
3.  `de_tutor_write_memory`: Updates the user's profile to mark whether they have learned or already know a specific Data Engineering concept mentioned in an update.

Your Workflow:
1.  Call `de_tutor_get_updates` to discover recent Data Engineering developments.
2.  Call `de_tutor_read_memory` to understand the user's current knowledge base.
3.  Present the new developments to the user, highlighting things they likely don't know.
4.  If the user confirms they know a concept or have learned it, call `de_tutor_write_memory` to update their profile.

Be concise and focus on delivering relevant, new information tailored to the user's existing knowledge.

  3. Connect and Use:

    • Ensure the de-tutor server is enabled in Cursor's MCP settings.

    • If using a rule file: Start a new chat or code generation request (e.g., Cmd+K) and include @de-tutor-rule (or whatever you named your rule file) in your request. This tells Cursor to load the rule's content, providing instructions on how to use the tools.

    • If relying on the server prompt: Simply start interacting with Cursor; it should have access to the tools and the guidance prompt provided by the server.

Features & Usage

This server provides the following capabilities:

  • Resource (data_engineering_knowledge_memory): Stores a simple JSON object in data/data-engineering-knowledge.json mapping known concepts (strings) to boolean flags (true).

  • Tools:

    • de_tutor_read_memory: Reads the current known concepts from the JSON file.

    • de_tutor_write_memory: Updates the JSON file to mark a concept as known (true) or unknown (false). Takes concept (string) and known (boolean) as input.

    • de_tutor_get_updates: Uses your OpenRouter API key to query Perplexity (perplexity/sonar-small-online) for recent Data Engineering news, patterns, and technologies.

  • Prompt (data-engineering-tutor-guidance): Provides instructions to the connected AI client on how to use the tools in a workflow:

    1. Get latest updates.

    2. Read known concepts from memory.

    3. Present new information to the user.

    4. Update memory based on user feedback.

Development & Debugging

  • Build: npm run build compiles TypeScript to JavaScript in the build/ directory.

  • Code Structure: See src/ for implementation details:

    • src/index.ts: Server entry point. Imports McpServer and StdioServerTransport from specific SDK paths. Instantiates McpServer. Imports and calls registration functions (registerPrompts, registerResources, registerTools) from other modules, passing the server instance. Sets up and connects the server using StdioServerTransport.

    • src/prompts/index.ts: Defines the guidance prompt text. Exports registerPrompts, which takes the McpServer instance and uses server.prompt() to register the static guidance prompt with its callback.

    • src/resources/index.ts: Exports KnowledgeMemory type and helper functions (readMemoryFile, writeMemoryFile) for file I/O on data/data-engineering-knowledge.json. Exports registerResources, which takes the McpServer instance and uses server.resource() to register the data_engineering_knowledge_memory resource with a specific URI and a ReadResourceCallback.

    • src/tools/index.ts: Exports registerTools, which takes the McpServer instance and uses server.tool() to register each tool (de_tutor_read_memory, de_tutor_write_memory, de_tutor_get_updates). Defines input schemas using Zod where necessary (for write_memory). Tool functions use helpers from resources/index.ts or fetch to perform actions and return results in the expected format.

  • MCP Inspector: Use @modelcontextprotocol/inspector to see raw message flow:

    npx @modelcontextprotocol/inspector node ./build/index.js

    (Ensure OPENROUTER_API_KEY is set in your environment if running this way and not relying solely on the .env file loaded by the server itself.)

Notes

  • This server uses a simple file (data/data-engineering-knowledge.json) for storing user knowledge. For more robust applications, consider a proper database.

  • Error handling is basic; production servers would need more comprehensive error management.

Wrapping up

This demo demonstrates the core steps involved in creating a functional MCP server using the TypeScript SDK and the McpServer class. We defined a resource to manage state, tools to perform actions (including interacting with an external API), and a prompt to guide the AI client.

This provides a foundation for building more complex and useful agentic capabilities with MCP.

(Also, if you run into any 🐛bugs, feel free to open up an issue.)

Available Tools

3 tools
de_tutor_get_updatesB

Fetches recent news and updates about Data Engineering concepts, patterns, and technologies using Perplexity Sonar via OpenRouter.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the data source ('Perplexity Sonar via OpenRouter') but doesn't describe what 'recent' means (timeframe), whether there are rate limits, authentication requirements, error conditions, or what format the news/updates will be returned in. For a tool with external API dependencies, this is insufficient behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that efficiently conveys the core purpose and implementation method. Every word earns its place with no redundancy or unnecessary elaboration. It's appropriately sized for a simple, parameterless tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's external API dependency and lack of annotations or output schema, the description is incomplete. It doesn't explain what 'recent' means, how many items are returned, the format/structure of returned data, error handling, or any limitations. For a tool fetching dynamic external data, this leaves significant gaps for the agent.

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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist. Baseline for 0 parameters is 4, as the description correctly focuses on the tool's purpose rather than non-existent parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('fetches') and resource ('recent news and updates about Data Engineering concepts, patterns, and technologies'), and mentions the implementation method ('using Perplexity Sonar via OpenRouter'). However, it doesn't explicitly differentiate from its siblings (de_tutor_read_memory and de_tutor_write_memory), which appear to be memory-related tools rather than news-fetching tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, timing considerations, or comparison with sibling tools. The agent must infer usage context solely from the purpose statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

de_tutor_read_memoryB

Reads the user's current Data Engineering knowledge from memory.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a read operation, implying it's non-destructive, but doesn't cover aspects like authentication needs, rate limits, or what the return format looks like (e.g., structured data or raw text). This leaves significant gaps for a tool that interacts with user memory.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's function without any fluff or unnecessary details. It's front-loaded and every word earns its place, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (simple read operation with no parameters) and the lack of annotations and output schema, the description is minimally adequate. It specifies the resource but doesn't provide details on behavior or output, which could be helpful for an agent. However, for a zero-parameter tool, this is acceptable as a baseline.

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 tool has 0 parameters, and the schema description coverage is 100%, so there's no need for parameter documentation in the description. The baseline for this scenario is 4, as the description appropriately avoids redundant information while clearly indicating what resource is being accessed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Reads') and the resource ('user's current Data Engineering knowledge from memory'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from its sibling 'de_tutor_get_updates', which might also retrieve information, so it doesn't achieve the highest score for sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'de_tutor_get_updates' or 'de_tutor_write_memory'. There's no mention of prerequisites, context, or exclusions, leaving the agent with minimal usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

de_tutor_write_memoryC

Updates the user's Data Engineering knowledge memory for a specific concept.

ParametersJSON Schema
NameRequiredDescriptionDefault
conceptYesThe Data Engineering concept name (e.g., 'ETL', 'Data Warehousing')
knownYesWhether the user knows this concept (true/false)

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool updates memory, implying a mutation, but doesn't cover critical aspects like permissions needed, whether changes are reversible, rate limits, or what the response entails. This is a significant gap for a mutation tool without annotation support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity as a mutation tool with no annotations and no output schema, the description is incomplete. It fails to address behavioral traits, usage context, or output expectations, leaving the agent with insufficient information to operate the tool effectively beyond basic parameter input.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, meaning the input schema fully documents both parameters ('concept' and 'known'). The description adds no additional semantic details beyond what the schema provides, such as examples or usage context for the parameters, so it meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Updates') and resource ('user's Data Engineering knowledge memory for a specific concept'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'de_tutor_read_memory' or 'de_tutor_get_updates', which likely have different functions (reading vs. writing).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, such as the sibling tools mentioned. It lacks context about prerequisites, scenarios for updating memory, or any exclusions, leaving the agent with minimal usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updatesv1.0.0
    • First observedde_tutor_get_updates
    • First observedde_tutor_read_memory
    • First observedde_tutor_write_memory
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: fetching external updates, reading internal memory, and writing to internal memory. There is no overlap in functionality, making it easy for an agent to select the correct tool without confusion.

Naming Consistency5/5

All tools follow a consistent 'de_tutor_verb_noun' pattern with snake_case, using descriptive verbs like 'get', 'read', and 'write'. This predictability enhances usability and reduces cognitive load for agents.

Tool Count3/5

With only 3 tools, the set feels thin for a tutoring server, as it lacks interactive or instructional tools (e.g., explain concepts, quiz, or provide feedback). While the tools cover basic memory and update operations, the scope seems limited for effective tutoring.

Completeness2/5

The toolset is severely incomplete for a Data Engineering Tutor. It includes memory management and update fetching but misses core tutoring functions like explaining concepts, answering questions, or assessing knowledge. This will likely cause agent failures in delivering comprehensive tutoring.

Maintenance

ActivityInactive
ResponsivenessNo issues

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/scriptstar/de-mcp-server'

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