Click on "Install 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., "@FastMCP Demo Server show me hackathon resources and starter prompts"
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.
A production-ready FastMCP reference server with hackathon resources and reusable starter prompts
A FastMCP server with comprehensive hackathon overview resources and reusable starter prompts. Clone, install dependencies or build the Docker image, and you have an MCP server that Cursor can load immediately.
Related MCP server: FastMCP Server Template
Component | Version | Required |
Python | 3.12+ | Yes |
uv | Latest | Yes |
Docker | 24+ | Optional |
Node.js | 18+ | Optional |
# Install dependencies and run
uv sync
uv run server.py# Build the image
docker build -t mcp-demo:latest .
# Run the container
docker run --rm -i mcp-demo:latest
# Development mode with live reload
docker run --rm -it -v "$(pwd)":/app mcp-demo:latestnpx -y mcp-remote https://cursor-denver-mcp-hackathon.fastmcp.app/mcpMode | Use Case | Setup | Best For |
Local STDIO | Cursor integration | Simple | Development |
Remote HTTP/SSE | Public access | Advanced | Production |
Docker Local | Isolated environment | Medium | Testing |
Docker Remote | Cloud deployment | Advanced | Production |
# GitHub Container Registry
docker tag mcp-demo:latest ghcr.io/<your-user>/mcp-demo:latest
docker push ghcr.io/<your-user>/mcp-demo:latest
# Docker Hub
docker tag mcp-demo:latest <your-user>/mcp-demo:latest
docker push <your-user>/mcp-demo:latestAdd to ~/.cursor/mcp.json:
{
"mcpServers": {
"fastmcp-demo": {
"command": "uv",
"args": ["run", "server.py"],
"cwd": "/absolute/path/to/mcp-demo"
}
}
}{
"mcpServers": {
"fastmcp-demo": {
"command": "docker",
"args": [
"run", "--rm", "-i",
"--volume",
"/absolute/path/to/mcp-demo:/app",
"mcp-demo"
]
}
}
}{
"mcpServers": {
"denver-hackathon": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://cursor-denver-mcp-hackathon.fastmcp.app/mcp"
]
}
}
}Restart Cursor after updating configuration.
# Run all tests
pytest
# Run with coverage
pytest --cov=. --cov-report=html
# Run specific test
pytest tests/test_server.py -vmcp-demo/
├── server.py # FastMCP server
├── main.py # Alternative entry point
├── Dockerfile # Container build
├── requirements.txt # Dependencies
├── pyproject.toml # Project config
├── resources/
│ └── hackathon_overview.md
├── prompts/
│ └── fastmcp_python_starter.md
└── tests/
├── conftest.py
└── test_server.pyMIT License
Built for the Cursor Denver Hackathon
Get the complete hackathon overview with all information about the MCP Server Hackathon.
Returns: The full hackathon overview document including format, getting started guide, project ideas, resources, and quick reference.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a 'full hackathon overview document' with specific content areas (format, guide, ideas, etc.), which adds useful context about the output. However, it does not cover behavioral traits like error handling, rate limits, or authentication needs, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a concise breakdown of return content. Every sentence adds value without waste, and the structure is clear and efficient for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, but has an output schema), the description is reasonably complete. It explains what the tool does and details the return content, which compensates for the lack of annotations. However, it could be more thorough by addressing potential errors or usage scenarios, slightly reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not discuss parameters, which is appropriate. Baseline is 4 for zero parameters, as it avoids unnecessary repetition of schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the complete hackathon overview with all information about the MCP Server Hackathon.' It specifies the verb ('Get') and resource ('hackathon overview'), but since there are no sibling tools, it cannot demonstrate differentiation from alternatives. The purpose is specific but lacks sibling context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, contexts, or exclusions. With no sibling tools, the bar is lower, but it still fails to offer any usage context beyond the basic purpose.
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. Dates show when Glama detected each change.
get_hackathon_infoWith only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is clearly defined and distinct by default.
A single tool inherently maintains perfect naming consistency, as there are no other tools to compare against. The name 'get_hackathon_info' follows a clear verb_noun pattern.
One tool is too few for a server's purpose, as it severely limits functionality and scope. This feels thin and inadequate for handling even basic operations beyond a single read action.
The server is severely incomplete, offering only a read operation for hackathon information. There are no tools for creating, updating, or deleting data, nor for interacting with other aspects of a hackathon domain, leading to significant gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for generating rough-draft project plans from natural-language prompts.
A MCP server built for developers enabling Git based project management with project and personal…
MCP server for building and testing AI agents with multi-model experimentation and insights.
Create, deploy, and operate MCP servers directly from your GitHub repositories.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/apoojary94/mcp_hackathon'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
