Allows processing and analysis of datasets from Hugging Face, specifically the dair-ai/emotion dataset, with tools for sampling records, counting entries by emotion, searching text, and analyzing emotion distributions.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Emotion Dataset Analysis MCP Server show the distribution of emotions in the dataset"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
CIS 6930 Data Engineering - Spring 2026
This repository contains starter code for the in-class MCP activity on HiPerGator.
You will build an MCP server that processes the dair-ai/emotion dataset from Hugging Face.
Related MCP server: HF Dataset MCP
cd /blue/cis6930/YOUR_GATORLINK
git clone https://github.com/YOUR_USERNAME/cis6930sp26-assignment1.5.git
cd cis6930sp26-assignment1.5cp .env.example .env
# Edit .env with your Hugging Face tokenmodule load mamba
uv sync
source .venv/bin/activateUsing HiPerGator Desktop is much easier and avoids SSH tunneling complexity.
Navigate to Interactive Apps > HiPerGator Desktop
Request a session (1 hour, 4 GB memory, 2 CPUs)
Once the desktop launches, open a terminal
Run:
cd /blue/cis6930/YOUR_GATORLINK/cis6930sp26-assignment1.5
module load mamba
source .venv/bin/activate
mcp dev server.pyOpen Firefox in the virtual desktop and go to http://localhost:6274
If you prefer to use your local browser, you'll need to set up SSH tunneling.
Run this command to start an interactive job with the MCP inspector:
ssh hpg "srun --partition=hpg-turin --account=cis6930 --qos=cis6930 \
--cpus-per-task=4 --ntasks=1 --mem-per-cpu=4gb --time=1:00:00 \
bash -c 'cd /blue/cis6930/YOUR_GATORLINK/cis6930sp26-assignment1.5 && \
module load mamba && source .venv/bin/activate && mcp dev server.py'"In another terminal, find which compute node your job is running on:
squeue -u $USERLook for the node name in the NODELIST column (e.g., c0702a-s2).
The MCP Inspector runs on two ports:
6274 - Web interface
6277 - Proxy server
Open a new terminal on your laptop and run:
ssh -L 6274:localhost:6274 -L 6277:localhost:6277 \
-J YOUR_GATORLINK@hpg.rc.ufl.edu YOUR_GATORLINK@COMPUTE_NODEExample:
ssh -L 6274:localhost:6274 -L 6277:localhost:6277 \
-J jsmith@hpg.rc.ufl.edu jsmith@c0702a-s2The -J flag (ProxyJump) connects through the login node directly to the compute node.
Open your browser and go to the url that was output by the the dev server. Is should look like http://localhost:6274/?MCP_PROXY_AUTH_TOKEN=e2a71ba1e83a76dd0ea24fed08b1d62413d5837fbea81cbc41a9233ae169f989 : http://localhost:6274?MCP_PROXY_AUTH_TOKEN={CODE}
You should see the MCP Inspector interface:
To avoid entering your password multiple times, set up SSH keys for HiPerGator: https://docs.rc.ufl.edu/access/ssh_keys/
Problem | Solution |
"Connection refused" | Ensure you're using |
"Address already in use" | Kill processes: `lsof -ti:6274 |
Host key verification failed | Add |
Page won't load | Verify |
Click the Tools tab in the left sidebar
Select a tool from the list (e.g., get_sample)
Fill in the parameter values
Click Run Tool
View the JSON response in the output panel
Tool | Parameters |
|
|
|
|
|
|
| (no parameters) |
The dair-ai/emotion dataset contains English Twitter messages labeled with six emotions:
Label | Emotion |
0 | sadness |
1 | joy |
2 | love |
3 | anger |
4 | fear |
5 | surprise |
After completing the activity, submit to Canvas:
Your outputs.txt file with tool outputs
A brief reflection (2-3 sentences)
Get the distribution of emotions in the dataset.
Returns: JSON string with counts and percentages for each emotion
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the return format (JSON with counts/percentages), which adds value, but omits safety characteristics (read-only vs. destructive), performance implications for large datasets, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two distinct sections (purpose and returns) with no wasted words. Information is front-loaded and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the existence of an output schema (per context signals), the description adequately covers the tool's function by specifying the return structure. Minor gap regarding dataset prerequisites prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters with 100% schema coverage establishes a baseline of 4. The description appropriately requires no parameter clarification since the tool operates on the implicit current dataset context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action (Get) and resource (distribution of emotions), but fails to distinguish from sibling tool 'count_by_emotion'. Both tools appear to provide counts; the description doesn't clarify when percentages/distribution analysis is preferable to simple counting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus 'count_by_emotion' or other siblings. No prerequisites are mentioned (e.g., whether a dataset must be loaded first), leaving usage context entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Count samples for a specific emotion.
Args: emotion: One of 'sadness', 'joy', 'love', 'anger', 'fear', 'surprise'
Returns: JSON string with count and percentage
| Name | Required | Description | Default |
|---|---|---|---|
| emotion | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return format ('JSON string with count and percentage'), which adds value beyond the schema. However, it omits safety traits (read-only status), rate limits, or side effects that would help an agent understand operational risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Uses structured Args/Returns format that efficiently organizes information. Front-loaded with the core purpose. Slightly redundant in documenting return values when an output schema exists, but necessary given the parameter documentation burden.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter counting tool, the description is nearly complete. It documents the parameter domain and return structure. Minor gap: doesn't clarify what 'samples' refers to (text samples inferred from siblings) or whether the count is relative to total dataset (implied by 'percentage').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Critical compensation for 0% schema description coverage: the description provides the complete enum constraint ('One of 'sadness', 'joy', 'love', 'anger', 'fear', 'surprise'') that the schema lacks. Without this, the agent would have no valid values to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action (Count) and resource (samples) with clear scope (for a specific emotion). Implies distinction from sibling 'analyze_emotion_distribution' by focusing on single-emotion queries, though it doesn't explicitly clarify when to choose one over the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus siblings like 'analyze_emotion_distribution' or 'search_text'. No prerequisites, exclusions, or workflow context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get n random samples from the emotion dataset.
Args: n: Number of samples to retrieve (default: 5, max: 20)
Returns: JSON string with samples including text and emotion label
| Name | Required | Description | Default |
|---|---|---|---|
| n | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and successfully discloses constraints ('max: 20') and return format ('JSON string with samples including text and emotion label'). It omits traits like idempotency or caching, but covers the essential behavioral constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Uses a clean docstring format with Args and Returns sections. Every sentence earns its place; no redundancy or fluff. The structure front-loads the core purpose before detailing parameters and returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one optional parameter and an existing output schema (reducing the need for extensive return documentation), the description is nearly complete. Minor gap: lacks explicit differentiation from siblings despite having clear siblings available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description fully compensates by documenting the 'n' parameter with semantics ('Number of samples'), default value, and maximum constraint ('max: 20'), exceeding baseline expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), resource ('samples from the emotion dataset'), and scope ('random'), clearly distinguishing it from sibling tools like search_text (query-based) and count_by_emotion (aggregation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying 'random samples,' which suggests when to use it (for random inspection), but lacks explicit guidance on when to choose this over search_text or other siblings, and lists no prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for samples containing specific text.
Args: query: Text to search for (case-insensitive) limit: Maximum results to return (default: 10)
Returns: JSON string with matching samples
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses case-insensitivity and that results are returned as a JSON string. However, it omits error handling behavior, what constitutes a 'sample', pagination details, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Uses an efficient docstring format (Args/Returns) that front-loads the purpose statement and structures metadata clearly. Every line provides necessary information without redundancy; appropriate length for a 2-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with 2 parameters, the description adequately covers inputs and outputs. While additional domain context about 'samples' would help, the return format documentation and parameter details provide sufficient information for invocation given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the Args section compensates effectively by documenting both parameters: noting the case-insensitive nature of 'query' and the default value of 'limit'. It adds semantic meaning beyond the raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (search), resource (samples), and scope (containing specific text). While it doesn't explicitly differentiate from siblings like 'get_sample', the tool name and description make the text-search purpose distinct from the emotion analysis siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'get_sample' (which likely retrieves by ID). The description provides no when-to-use or when-not-to-use conditions, prerequisites, or workflow guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0analyze_emotion_distributioncount_by_emotionget_samplesearch_textScored across 4 tools
The tools have mostly distinct purposes: analyze_emotion_distribution provides overall distribution, count_by_emotion counts specific emotions, get_sample retrieves random samples, and search_text finds text matches. However, analyze_emotion_distribution and count_by_emotion could potentially overlap in functionality since both provide emotion counts, though the former is comprehensive and the latter is specific.
All tool names follow a consistent verb_noun pattern using snake_case: analyze_emotion_distribution, count_by_emotion, get_sample, and search_text. The naming is predictable and readable throughout the set.
With 4 tools, the count is borderline for a dataset analysis server. It covers basic operations but feels thin for comprehensive analysis, lacking tools for filtering, updating, or advanced statistical analysis that might be expected in this domain.
The toolset covers core read operations (distribution analysis, counting, sampling, and searching) but has notable gaps. There are no tools for creating, updating, or deleting dataset entries, and missing advanced features like emotion trend analysis or dataset summarization limit completeness for the stated purpose.
This MCP server provides seamless access to Malaysia's government open data, including datasets, w…
This MCP server enables users to perform scientific computations regarding linear algebra and vect…
MCP server for AI dialogue using various LLM models via AceDataCloud
