mcp-fifa-scheduler
Allows creating calendar events and sending email reminders for FIFA World Cup matches of a user's favorite team.
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., "@mcp-fifa-schedulerCreate a match event for Brazil and email me the details"
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.
mcp-fifa-scheduler
An MCP (Model Context Protocol) server that creates and notifies calendar-style events for FIFA World Cup matches of your favourite team. The server exposes a single tool, create_match_event, which gathers the match details from the user and posts them to a local backend that schedules the event and emails a reminder to the recipient.
Understanding MCP Elicitation
Elicitation is an MCP feature that lets a server request additional input from the user, mid-request, through the client. Instead of forcing all parameters to be supplied up front when a tool is called, the server can pause and ask the user for the information it needs — interactively.
Why it exists
Tools often need data that:
The model/agent doesn't have (e.g., a personal email address).
Should be confirmed by a human before an action is taken (e.g., sending an email or creating a calendar event).
Is better captured through a structured form than guessed by the model.
Elicitation provides a standard, secure way to collect that data without hard-coding it or trusting the model to invent it.
How it works
Capability negotiation. Elicitation is a client capability. During initialization, the client advertises whether it supports elicitation (and which modes, such as
form). The server checks this at runtime viagetClientCapabilities().The server requests input. When a tool needs more data, the server calls
elicitInput({ ... })with:A
mode(e.g.,"form").A human-readable
message.A
requestedSchema(JSON Schema) describing the fields, their types, validation rules, titles, descriptions, and defaults.
The client renders a UI. The client shows the user a form (or other appropriate UI) based on the schema, validating the input against the provided constraints.
The user responds. The result contains an
action:accept— the user submitted the form; the data is incontent.decline/cancel— the user refused or dismissed; the server should handle this gracefully (no action taken).
The server continues. With the collected, validated data, the server completes its work.
Elicitation in this project
Elicitation can be either: URL Elicitation or Form Elicitation. This server uses form elicitation to collect the recipient email, reminder time, and favourite team.
Read more on URL Elicitation: (https://modelcontextprotocol.io/specification/2025-11-25/client/elicitation#url-mode-elicitation-requests).
Key points illustrated by the code:
It gracefully degrades: if the client doesn't support form elicitation, the tool returns a clear message instead of failing silently. (Here, the email is considered mandatory, so a form-capable client is required.)
It respects user choice: if the user cancels the form, no event is created.
It uses the schema's defaults and validation (e.g.,
minimum/maximumfor reminder minutes,minLengthfor strings) so the client can guide the user toward valid input.
Best practices (general)
Always check the client capability before calling
elicitInput, and provide a fallback path.Keep schemas minimal and well-described (titles, descriptions, sensible defaults).
Never use elicitation to request secrets the user wouldn't expect a tool to ask for; be transparent about why the data is needed.
Always handle the non-
acceptactions so the user can safely back out.
Related MCP server: GoogleCalendarMCP
What src/index.ts does
src/index.ts is the entire server implementation. Here is a breakdown of its responsibilities:
1. Bootstrapping the MCP server
Imports
McpServerandStdioServerTransportfrom the MCP SDK, pluszodfor input validation.Instantiates an
McpServernamedfifaScheduler(version1.0.0).Declares the server capabilities it supports during initialization:
tools: { listChanged: true }— the server can notify clients when its tool list changes.
Note:
elicitationis a client capability, so it is intentionally not declared in the server's capabilities. The server only checks for it at runtime (see below). Some of the clients that support Elicitation are Copilot Claude CLI etc. Claude Desktop as of now doesn't supportelicitation
2. Registering the create_match_event tool
The tool is registered with server.registerTool(...) and described as:
"Create a match event for the match in the world cup and send to the mail of the recipient."
Its input schema (all optional, validated with zod) acts as a fallback for clients that cannot render an interactive form:
Field | Type | Purpose |
|
| The team whose match you want an event for. |
|
| The email address that will receive the reminder. |
|
| Minutes before kickoff to be reminded. |
3. Collecting input via elicitation
When the tool is invoked, the handler:
Checks whether the connected client advertises form elicitation support via
server.server.getClientCapabilities()?.elicitation?.form.If form elicitation is supported, it calls
server.server.elicitInput({ mode: "form", ... })to ask the user for (or confirm) three values through a structured form:email— recipient email (defaults to the passed-in value or a fallback address).reminderMinutes— integer between0and1440.favoriteTeam— the team name.All three fields are marked as
required.
If the user does not accept the form (
elicitation.action !== "accept") or returns no content, the tool returns a friendly "cancelled" message.If form elicitation is not supported, the tool returns an error message explaining that a form-capable client is required (because the recipient email can only be collected through the form).
4. Creating the event (backend call)
Once the inputs are gathered, the handler:
Sends a
POSTrequest tohttp://localhost:3000/create-eventwith a JSON body containingfavoriteTeam,email, andreminderMinutes.Handles failures gracefully:
A non-
okHTTP response returns an error result including the status code.Network/exception errors are caught and reported as an error result.
On success, it logs the response (to
stderr) and returns a confirmation message such as:"Match event for Argentina created and sent to user@example.com with a 60-minute reminder."
Project structure
package.json # package metadata, scripts, and dependencies
tsconfig.json # TypeScript compiler configuration
README.md # this file
src/
index.ts # MCP server implementation (the file documented above)
build/
index.js # compiled output (entry point / bin)Getting started
Prerequisites
Node.js (ESM-capable version).
A backend listening on
http://localhost:3000/create-eventthat accepts a JSONPOSTbody of{ favoriteTeam, email, reminderMinutes }.An MCP client that supports form elicitation (required to collect the recipient email).
Build
npm install
npm run buildThis compiles src/index.ts to build/index.js and makes it executable.
Run
The server speaks MCP over stdio, so it is typically launched by an MCP client rather than run directly. Configure your client to start it via the mcp-fifa-scheduler bin. On the client, mcp.json should be added with the following content:
{
"servers": {
"fifa-scheduler": {
"type": "stdio",
"command": "node",
"args": ["/path_to_index.js"]
}
}
}If Copilot is used in VS Code add a directory .vscode and add mcp.json within it.
Tool reference
create_match_event
Creates a World Cup match event and emails a reminder to the recipient.
Inputs (all optional; used as fallbacks when a form can't be rendered):
favoriteTeam(string) — Favourite team of the user.recipientEmail(string) — Email of the recipient.minutesRemaining(number) — Minutes remaining before the match starts.
Behaviour: Prompts the user via form elicitation for the email, reminder minutes, and favourite team, then posts the result to the local create-event backend and returns a confirmation message.
Available Tools
1 toolcreate_match_eventB
Create a match event for the match in the world cup and send to the mail of the recipient
| Name | Required | Description | Default |
|---|---|---|---|
| favoriteTeam | No | Favorite team of the user (used when the client can't render a form) | |
| recipientEmail | No | Email of the recipient (used when the client can't render a form) | |
| minutesRemaining | No | Minutes remaining before the match starts (used when the client can't render a form) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core actions (create and send email) but does not mention permissions, reversibility, error behavior, or what the match event constitutes. With no annotations, the description carries the full burden and leaves side effects under-specified.
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 concise at one sentence and front-loaded with the primary verb 'create.' However, the phrase 'send to the mail of the recipient' is awkward and slightly ambiguous, preventing a perfect score.
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 tool with no annotations and no output schema, the description is thin. It does not clarify what a match event is, what the email contains, or what happens on success or failure. This leaves significant gaps for an agent deciding when and how to invoke the tool.
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 fully describes all three parameters (favoriteTeam, recipientEmail, minutesRemaining) with descriptions like 'used when the client can't render a form.' The tool description adds no parameter-specific information, but schema coverage is 100%, so the baseline of 3 applies.
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 creates a match event and sends it to the recipient's email. The verb 'create' and resource 'match event' are specific, though the exact meaning of 'match event' is somewhat ambiguous.
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 the tool is for creating and emailing a match event but provides no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites. The usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
With only one tool, there is no possibility of confusion between tools. The single tool clearly targets a specific action.
The tool name 'create_match_event' follows a consistent verb_noun pattern, which is clean and predictable, even though there is only one tool.
A single tool for a scheduler server is severely insufficient; even a minimal scheduler would typically require listing, updating, or deleting events. The count feels far too thin for the declared purpose.
The tool only creates a match event and sends an email. There is no way to read, update, cancel, or manage events in any other way, so the surface is severely incomplete for a scheduling domain.
Maintenance
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
A MCP server that works with Google Calendar to manage event listing, reading, and updates.
A MCP server that works with Outlook Calendar to manage event listing, reading, and updates.
MCP server for Cronofy — read calendars, events and free/busy, and create, update or delete events.
An MCP server that provides email capabilities, hosted on Alpic platform
Related MCP Servers
- FlicenseAqualityDmaintenanceAn MCP server that enables scheduling, updating, deleting, and listing calendar appointments through Cal.com's Calendar API.43
- FlicenseDqualityBmaintenanceMCP server for interacting with Google Calendar, enabling reading events from public calendars and, with OAuth, creating, updating, and deleting events.1
- FlicenseAqualityDmaintenanceMCP server for managing Google Calendar reminders with time-based and location-based triggers, enabling creation, listing, and deletion of reminders.4
- FlicenseNot gradedqualityBmaintenanceMCP server for a desktop calendar that allows AI agents to manage events, check schedules, and avoid conflicts via standard MCP tools.1
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/jacobtony/mcp-fifa-scheduler'
If you have feedback or need assistance with the MCP directory API, please join our Discord server