edhec-mcp

Overview Schema Source Related Servers Discussions Admin

Menu of the day

resto_menu

Read-onlyIdempotent

Fetch today's EDHEC campus restaurant menu as French page images to read dishes and prices; choose a site and optionally save the PDF.

Instructions

Today's menu of a campus restaurant as images (one per page, French), so you can read dishes and prices. site: "edhec" (default, Restaurant Le 1906, Roubaix), "lille", "issy" or "piktura". Optionally saves the PDF.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "resto_menu"
  }
}

Input Schema

Name	Required	Description	Default
`site`	No
`destDir`	No	Absolute folder to also save the menu PDF

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Nov 5, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses the output shape (images, one per page), the language (French), and the optional side effect of saving the PDF. That is meaningful added context, though it does not say how many pages typically come back or how image retrieval behaves.

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

Conciseness4/5

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

Two compact sentences, front-loaded with the resource and return format, followed by the parameter hints. The 'site: ...' fragment is telegraphic but efficient; nothing is padding.

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?

For a two-parameter, no-output-schema tool, the description covers what the agent gets back (per-page images), the language constraint, and the optional file write. Only pagination count and failure modes are unaddressed, which are minor here.

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?

With only 50% schema coverage and no description on 'site' in the schema, the description compensates by listing all four valid values and naming the default site and location. It also ties destDir to the PDF-save behavior, which goes slightly beyond the schema's own text.

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?

States a specific resource (today's menu of a campus restaurant) plus the return medium ('as images, one per page, French') and the reason ('read dishes and prices'). It is clear what the tool does, though it does not explicitly differentiate itself from siblings like resto_services or resto_history.

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?

Usage is implied: fetch today's menu when you want to read dishes and prices. There is no explicit when-not guidance and no named alternative among the many resto_* siblings, so the agent must infer selection from the description alone.

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