Skip to main content
Glama
deenesjakoruzh
c0dr

Canteen MCP

by c0dr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

매점 MCP

간단한 API 통합을 통해 식당의 점심 메뉴에 대한 액세스를 제공하는 MCP(모델 컨텍스트 프로토콜) 서버입니다.

설명

Canteen MCP는 구내식당의 일일 점심 메뉴를 검색하는 도구를 제공하는 FastMCP 기반 서버입니다. 메뉴 API에 연결하여 특정 날짜의 메뉴 데이터를 쿼리할 수 있는 구조화된 인터페이스를 제공합니다.

Related MCP server: Strapi MCP Server

특징

  • 특정 날짜의 점심 메뉴를 받아보세요

  • 실시간 통신을 위한 httpStream 기반 전송

  • 환경 기반 구성

  • 입력 검증을 통한 유형 안전 API

설치

지엑스피1

구성

예제 환경 파일을 복사하고 원하는 값으로 업데이트하세요.

cp .env.example .env

환경 변수

변하기 쉬운

설명

예

API_URL

점심 메뉴 API의 URL

https://lunch-menu-ai.vercel.app/api/v1/menu

포트

MCP 서버용 포트

8080

엔드포인트

HTTP 엔드포인트

/엔드포인트

용법

서버를 시작합니다:

npm start

사용 가능한 도구

점심 메뉴 받기

특정 날짜의 점심 메뉴를 검색합니다.

  • 매개변수 :

    • date : YYYY-MM-DD 형식의 문자열

  • 반환 : 메뉴 데이터를 포함하는 JSON 문자열

  • 예 :

    const result = await tool.execute({ date: "2024-10-05" });

개발

필수 조건

  • 노드.js >= 18

  • 엔피엠

개발 모드에서 실행

npm run dev

도커

이미지 구축

docker build -t canteen-mcp .

컨테이너 실행

docker run -d \
  -p 8080:3000 \
  -e API_URL=your_api_url \
  -e PORT=3000 \
  -e ENDPOINT=/http \
  --name canteen-mcp \
  canteen-mcp

GitHub 컨테이너 레지스트리 사용

최신 이미지를 가져옵니다.

docker pull ghcr.io/[your-username]/canteen-mcp:latest

전개

Hetzner에 배치

  1. Hetzner 서버에 SSH를 실행합니다.

ssh root@your-server-ip

  1. Docker가 아직 설치되지 않았다면 설치하세요.

curl -fsSL https://get.docker.com | sh

  1. docker-compose.yml 파일을 만듭니다.

version: '3.8'
services:
  canteen-mcp:
    image: ghcr.io/c0dr/canteen-mcp:latest
    restart: always
    ports:
      - "8080:3000"
    environment:
      - API_URL=your_api_url
      - PORT=3000
      - ENDPOINT=/http

  1. 서비스 시작:

docker-compose up -d

특허

이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.

https://github.com/punkpeye/fastmcp-boilerplate 기반

Available Tools

1 tool
get_lunch_menuA
Read-only

Get the lunch menu from the canteen for a specific date

ParametersJSON Schema
NameRequiredDescriptionDefault
dateYesThe date to get the menu for (YYYY-MM-DD)

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already provide readOnlyHint=true and openWorldHint=true, indicating this is a safe read operation with open-world assumptions. The description adds context about retrieving a menu for a date but does not disclose additional behavioral traits like error handling, data freshness, or format details. No contradiction with annotations is present.

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, clear sentence that efficiently conveys the tool's purpose without any wasted 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.

Completeness4/5

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

Given the tool's low complexity (one parameter, read-only, no output schema), the description is reasonably complete. It covers the main action and parameter intent, though it could benefit from mentioning the return format or potential limitations. With annotations handling safety and world assumptions, the description is adequate but not exhaustive.

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?

Schema description coverage is 100%, with the parameter 'date' fully documented in the schema (including description, pattern, and type). The description mentions 'for a specific date' but adds no extra meaning beyond what the schema provides, so it meets the baseline of 3 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 tool's purpose with a specific verb ('Get') and resource ('lunch menu from the canteen'), including the scope ('for a specific date'). It distinguishes what the tool does effectively, though there are no sibling tools to differentiate from, which prevents a perfect score of 5.

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

Usage Guidelines3/5

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

The description implies usage by specifying 'for a specific date', suggesting when to use it (when you need a menu for a particular date). However, it lacks explicit guidance on when not to use it or alternatives, and there are no sibling tools mentioned, so no comparison is provided.

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.

  1. 1 tool updatev1.0.0
    • First observedget_lunch_menu
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The tool 'get_lunch_menu' has a clear and distinct purpose that cannot be confused with any other tool in this set.

Naming Consistency5/5

Since there is only one tool, it inherently follows a consistent naming pattern. The tool name 'get_lunch_menu' uses a verb_noun structure, which is clear and predictable, though no comparison with other tools is possible.

Tool Count2/5

A single tool is too few for a server named 'Canteen MCP', which suggests a broader scope related to canteen operations. This minimal set severely limits functionality, as it only allows retrieving the lunch menu without any other operations like ordering, payment, or menu management.

Completeness1/5

The tool set is severely incomplete for a canteen domain. It only provides a 'get' operation for the lunch menu, with no coverage for creating, updating, or deleting menu items, handling orders, payments, or other typical canteen workflows, leading to significant gaps that will cause agent failures.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • OpenCTI MCP Server

    zxzinn
    A
    license
    A
    quality
    C
    maintenance
    A Model Context Protocol server that facilitates integration with OpenCTI, allowing users to query and retrieve cyber threat intelligence data via a standardized interface.
    16
    40
    MIT

  • Senechal MCP Server

    mattjoyce
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that provides health data from the Senechal API to LLM applications, enabling AI assistants to access, analyze, and respond to personal health information.
    GPL 3.0

  • OpenAPI MCP Server

    rahgadda
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol Server that enables LLMs to interact with and execute REST API calls through natural language prompts, supporting GET/PUT/POST/PATCH operations on configured APIs.
    6
    Apache 2.0