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., "@kubecon-eu-mcp Plan a 4-day itinerary for a platform engineer interested in eBPF."
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.
An MCP server for KubeCon + CloudNativeCon Europe 2026. This tool serves as an agentic schedule planner, party optimizer, and conference guide for the event held March 23-26 at RAI Amsterdam.
kubecon-eu-mcp connects AI agents to live conference data, enabling them to help attendees navigate the schedule, discover social events, and plan their trip. It fetches data live from upstream sources with efficient in-memory caching to ensure accuracy throughout the week.
Data sources include:
CNCF / LF events website
As a meta tie-in, this project highlights the Agentics Day: MCP + Agents co-located event on Monday, March 23.
Related MCP server: agent-zone-mcp
Smart Scheduling: Search talks by topic, speaker, or technology (eBPF, AI, WASM, etc.).
Party Optimizer: Find evening social events and plan the best route through Amsterdam.
Logistics Guide: Access hotel block info, airline discounts, and venue transit details.
Agentic Planning: Built-in prompts to help users build 4-day itineraries or first-timer guides.
Session Scoring: Personalized session ranking using the scoring rubric from kubecon-event-scorer by Fredrik Carlsson — scores across role relevance, topic alignment, and strategic value.
Live Updates: Data is pulled directly from official sources to reflect last-minute room changes.
If you have uv installed, you can run the server without manual installation:
uvx kubecon-eu-mcpInstall the package from your local clone or repository:
pip install .
# Then run the server
kubecon-eu-mcpBuild and run the containerized server:
docker build -t kubecon-eu-mcp .
docker run -it kubecon-eu-mcpOnce connected to an MCP client like Claude Desktop, you can ask questions like:
"What AI talks are on Wednesday?"
"Find all sessions featuring Lin Sun."
"What's the best way to get to RAI Amsterdam from Schiphol airport?"
"Are there any parties near the venue on Tuesday night?"
"Plan a 4-day itinerary for a platform engineer interested in security."
User: What AI talks are on Tuesday?
Assistant: (Calls search_sessions(query="AI", day="tuesday"))
The agent searches the live schedule and returns matching sessions with titles,
speakers, rooms, and times. It can then help you compare options, flag conflicts
with other sessions you want to attend, and suggest alternatives.
The server exposes 12 specialized tools:
Tool | Description |
| Search talks by keyword, topic, or speaker. |
| Get the full schedule for a specific day. |
| Look up sessions for a specific person. |
| Discover social events and happy hours. |
| Get an optimized route for evening events. |
| Details on rooms, maps, and venue address. |
| Hotel block rates and distances to RAI. |
| Airport, transit, and airline discount codes. |
| Monday's specialized events (ArgoCon, Agentics Day, etc.). |
| High-level event summary and key dates. |
| Get sessions with a personalized scoring rubric for AI-powered ranking. |
| Check if selected sessions overlap in time. |
Access structured data directly via these URIs:
kubecon://overview: Full conference summary.
kubecon://venue: Venue layout and transit details.
kubecon://hotels: Accommodation options.
kubecon://colocated-events: Monday's co-located event list.
Pre-configured workflows for common tasks:
plan_my_kubecon: Builds a personalized 4-day itinerary based on interests.
party_tonight: Plans an evening of networking and social events.
first_timer_guide: Provides essential tips for new attendees.
whats_happening_now: Finds sessions starting soon based on current time.
create_profile: Interactive profile builder that scores and ranks sessions using the kubecon-event-scorer rubric.
Add this to your claude_desktop_config.json:
Standard (stdio) Mode:
{
"mcpServers": {
"kubecon-eu-mcp": {
"command": "uvx",
"args": ["kubecon-eu-mcp"]
}
}
}Hosted (HTTP) Mode:
If running the server with the --http flag:
{
"mcpServers": {
"kubecon-eu-mcp": {
"url": "http://localhost:8000/mcp"
}
}
}Clone the repository.
Install dependencies with uv sync or pip install -e ..
Run the server in development mode: python -m kubecon_eu_mcp.
Submit a Pull Request with your improvements.
License: MIT
Detect scheduling conflicts among selected sessions.
Checks whether any of the provided sessions overlap in time, helping attendees resolve conflicts in their planned schedule.
Inspired by kubecon-event-scorer's conflict detection.
Args: session_uids: Comma-separated session UIDs to check for conflicts.
Returns: JSON with conflict pairs, overlap duration, and session details.
| Name | Required | Description | Default |
|---|---|---|---|
| session_uids | Yes |
| 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 full burden. It describes the return value (JSON with conflict pairs, overlap duration, session details) but does not explicitly state that the tool is read-only or free of side effects. The description adds some behavioral context but could be more explicit about what it does not do.
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 five sentences with no wasted words. The first sentence states the purpose immediately. The structure is logical: purpose, action, inspiration, args, returns. Highly concise and front-loaded.
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 tool with one parameter and an output schema, the description is complete. It explains the task, the input format, and the output structure. Given the tool's low complexity and available output schema, no further information is needed.
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 provides only 'Session Uids' as type string with no description. The description adds critical semantics: 'Comma-separated session UIDs to check for conflicts', explaining format and purpose. With 0% schema description coverage, the description effectively documents the parameter.
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 detects scheduling conflicts among sessions, with specific verb 'detect' and resource 'conflicts among selected sessions'. It distinguishes from sibling tools like 'score_sessions' or 'search_sessions' by focusing specifically on conflict detection.
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 when you have a set of session UIDs to check for overlaps, but does not explicitly state when to use this tool over alternatives, nor does it mention prerequisites or exclusions. Sibling tools provide context but guidelines are not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find conference parties, happy hours, and social events.
Args: day: Optional day filter: "monday", "tuesday", "wednesday", "thursday". after: Optional time filter — only show events starting after this time (e.g., "6PM"). before: Optional time filter — only show events starting before this time (e.g., "10PM").
Returns: JSON array of parties with name, time, sponsor, location, and RSVP link.
| Name | Required | Description | Default |
|---|---|---|---|
| day | No | ||
| after | No | ||
| before | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully handles transparency. It explains the return structure (JSON array with fields) and parameter semantics. However, it doesn't mention edge cases (e.g., empty results) or data freshness, but for a read-only search tool this is adequate.
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 with a clear purpose sentence, a bulleted argument list, and a returns line. Every sentence adds value with no redundancy.
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 (3 optional params, no required, output schema present), the description fully covers what the tool does, its filters, and its return format. No gaps remain.
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?
Schema description coverage is 0%, but the description fully explains all three parameters: 'day' with values list, 'after' and 'before' with time format examples. This adds significant meaning beyond the bare schema.
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 resource ('conference parties, happy hours, and social events') and uses the verb 'find', which is specific and distinguishes it from sibling tools like get_schedule or detect_conflicts.
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?
While the description lists optional filters, it does not explicitly state when to use this tool versus alternatives (e.g., get_schedule for full agenda or plan_party_route for navigation). No guidance on exclusions or preferred conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find sessions by a specific speaker.
Args: name: Speaker name or partial name (e.g., "Lin Sun", "Bryce").
Returns: JSON array of sessions featuring the speaker.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not explicitly state side effects or safety, but the function is clearly a read-only search.
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 with three sentences, though it could be slightly more compact.
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?
With an output schema present and a simple tool, the description sufficiently explains the return as 'JSON array of sessions' and covers the parameter.
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 schema has 0% coverage, but the description adds that 'name' is a 'Speaker name or partial name' with examples, adding meaningful 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 clearly states 'Find sessions by a specific speaker' and provides examples, distinguishing it from sibling tools like find_parties or search_sessions.
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 when searching by speaker name but lacks explicit guidance on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Monday's co-located events (ArgoCon, CiliumCon, Agentics Day, etc.).
Returns: JSON array of co-located events with name, duration, room, and requirements.
| 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 provided, so the description carries full burden. It discloses return format (JSON array with fields), but lacks details on side effects, auth, or rate limits. For a simple read operation, this is adequate but not exceptional.
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 sentences, front-loaded with purpose and return structure. No redundant words; every sentence earns its place.
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, parameterless tool with an output schema described, the description covers the essentials. It specifies the day and examples, though it could mention if the list varies or if there are prerequisites, but overall complete enough.
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?
No parameters, so baseline is 4. The description adds value by specifying the context (Monday's events) and example event names, which helps the agent understand the scope beyond the empty schema.
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 retrieves 'Monday's co-located events' with specific examples, distinguishing it from sibling tools like 'get_conference_overview' which covers the main conference.
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 (e.g., 'get_schedule' or 'search_sessions'). The description does not mention when not to use it, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a high-level overview of the entire conference.
Returns: JSON with event name, dates, schedule at a glance, and useful links.
| 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 exist, so the description must handle behavioral disclosure. It states the return format (JSON with specific fields) which is helpful. However, it does not mention any authentication needs, rate limits, or potential side effects (though unlikely). It provides basic transparency but could be more explicit.
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 extremely concise, consisting of two short sentences. It front-loads the purpose and then lists what is returned. No unnecessary words or repetition.
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 that the tool has zero parameters and the output schema is provided (context signals indicate it exists), the description still adds value by summarizing the output fields. With low complexity, the description is fully adequate.
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 tool has no parameters, so the schema coverage is 100% by default. The description need not add parameter info, and it does not. According to guidelines, 0 parameters earns a baseline of 4, which is appropriate.
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 uses a specific verb ('Get') and resource ('high-level overview of the entire conference'), and lists the key content (name, dates, schedule, links). This clearly distinguishes it from sibling tools that focus on specific aspects like schedule, venue, or speakers.
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 that this tool is for a broad overview, but it does not explicitly state when to use it versus other tools like get_schedule or get_venue_info. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get conference hotel block information with rates and distances.
Returns: JSON array of hotels with name, address, rate, distance to venue, and availability.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions the return format (JSON array) but does not state side effects, auth needs, or error conditions. As a read operation, this is minimal.
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 two sentences: one for purpose, one for return format. Efficient and front-loaded, no wasted words.
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 no parameters and an output schema, the description explains the return content (name, address, rate, distance, availability). However, it lacks context about scope (e.g., which conference) or whether results are filtered. Adequate but could be more precise.
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?
There are no parameters, so baseline is 4. The description adds no parameter semantics, which is acceptable since there are none.
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 it retrieves conference hotel block information with rates and distances, matching the tool name. It distinguishes from siblings like get_venue_info and get_travel_info by specifying hotel blocks.
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 on when to use this tool versus alternatives (e.g., get_venue_info for venue details). The description only states what it does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full conference schedule for a specific day.
Args: day: Day name — "monday" (co-located), "tuesday", "wednesday", or "thursday".
Returns: JSON array of all sessions for that day, sorted by start time.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses output format (JSON array sorted by time) but lacks details on authorization, rate limits, or side effects. Basic transparency for a read operation.
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?
Concise, front-loaded with purpose, then parameter and return details. Every sentence adds value with no redundancy.
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 single parameter and output schema existence, the description adequately covers inputs and returns. Could mention that sessions are object details, which likely reside in output schema.
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?
Schema has 0% description coverage; description adds critical meaning by listing allowed day values ('monday' (co-located), 'tuesday', etc.) and context, significantly enhancing the bare schema.
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 it gets the full conference schedule for a specific day, listing exact day names and return type (JSON array sorted by start time). It distinguishes from siblings like search_sessions and get_conference_overview.
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 clear context to use with a specific day parameter, but does not explicitly exclude alternatives or give when-not-to-use guidance. The sibling set implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get travel information: airport, transit, parking, and airline discounts.
Returns: JSON with airport details, public transport info, parking, and airline discount codes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses that the tool returns a JSON with specific categories (airport, transit, parking, discounts). As a 'get' operation, it is implicitly read-only with no side effects, which is transparent enough.
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 concise sentences: the first states the purpose and scope, the second describes the return format. Every sentence is necessary and front-loaded with key information.
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 no parameters and an output schema, the description is complete. It covers the main categories of travel info returned, and the tool’s functionality is well-scoped without missing critical details.
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 tool has no parameters, so the baseline is 4. The description adds value by enumerating the types of information returned, which helps the agent understand the output without needing parameter guidance.
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 provides travel information including airport, transit, parking, and airline discounts, and lists the return format. It is distinct from sibling tools like get_hotel_info or get_venue_info which focus on lodging or venue details.
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 for travel-related queries but does not explicitly specify when to use this tool versus alternatives like get_hotel_info. No exclusions or contextual hints are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get venue details: address, rooms, maps, and transit information.
Returns: JSON with venue name, address, room list, map links, transit info, and parking.
| 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 must cover behavior. It indicates a read operation ('Get') and lists return fields, but does not disclose side effects, authorization needs, or limitations. It is adequate but not comprehensive.
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 extremely concise, two short lines covering purpose and return structure. Every word earns its place.
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?
The description lists return fields but fails to clarify which venue is targeted given zero parameters (e.g., implies a default venue). It lacks output schema details despite its presence, but is otherwise sufficient for a simple getter.
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 tool has zero parameters, and schema description coverage is 100%. Per guidelines, baseline is 4. The description adds no parameter info but none is needed.
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 retrieves venue details including address, rooms, maps, and transit info. It distinguishes from siblings like get_hotel_info which focus on hotel-specific data.
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 is provided on when to use this tool versus alternatives such as get_conference_overview or get_hotel_info. The description simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plan an optimized party-hopping route for an evening.
Returns parties for the requested day sorted by time, with location details to help plan an efficient route through Amsterdam.
Args: day: Day name — "monday", "tuesday", "wednesday", or "thursday". preferences: Optional preferences like "networking", "food", "near venue", "open bar".
Returns: JSON with sorted party timeline and location context for route planning.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | ||
| preferences | No |
| 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 sorted timeline with location context, but does not specify side effects, error handling, 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?
The description is concise (45 words), front-loaded with the purpose, and each sentence contributes meaning without redundancy.
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 no annotations and 0% schema coverage, the description provides sufficient guidance for day and preferences. The output schema exists so return format is documented. Missing edge cases (e.g., invalid day) but overall adequate.
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?
With 0% schema description coverage, the description adds significant value by listing allowed day values and providing examples for preferences, which goes well beyond the bare 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 tool plans an optimized party-hopping route for an evening in Amsterdam, with a specific verb and resource. It distinguishes from siblings like find_parties or get_schedule by focusing on route optimization and location details.
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 when to use the tool (planning a route) and mentions optional preferences, but does not explicitly state when not to use or provide alternatives such as find_parties or get_schedule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get sessions ready for personalized scoring, with a scoring rubric.
Returns scorable sessions (logistics events filtered out) along with a structured scoring rubric. You (the AI agent) should apply the rubric to rank sessions for the attendee.
Scoring rubric is based on the kubecon-event-scorer project by Fredrik Carlsson.
Args: role: Attendee's job title (e.g., "Platform Engineer", "SRE", "Developer"). interests: Comma-separated interests (e.g., "eBPF, security, AI on Kubernetes"). day: Optional day filter: "monday", "tuesday", "wednesday", "thursday". experience_level: "beginner", "intermediate", "advanced", or "expert". priorities: Comma-separated goals (e.g., "evaluate service mesh tools, learn GitOps"). prefer_hands_on: Boost hands-on workshops and labs. prefer_deep_dives: Boost deep technical talks over intros. avoid_vendor_pitches: Penalize vendor-heavy marketing sessions. limit: Max sessions to return (default 30).
Returns: JSON with attendee profile, scoring rubric, and session list to score.
| Name | Required | Description | Default |
|---|---|---|---|
| role | Yes | ||
| interests | Yes | ||
| day | No | ||
| experience_level | No | intermediate | |
| priorities | No | ||
| prefer_hands_on | No | ||
| prefer_deep_dives | No | ||
| avoid_vendor_pitches | No | ||
| limit | No |
| 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 describes that logistics events are filtered out, and the output includes a scoring rubric. It does not cover potential side effects like rate limits or authentication, but is fairly transparent for a read-only scoring tool.
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?
Description is well-structured with a clear summary, an Args section, and a Returns section. It is slightly lengthy but every sentence adds value. Could be trimmed slightly but remains effective.
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 complexity (9 parameters, scoring logic), the description is complete. It explains the filtering of logistics events, the scoring rubric, and the output structure. The presence of an output schema reduces the need for detailed return value explanation, but the description still covers the key aspects.
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?
With 0% schema description coverage, the description fully compensates by explaining each parameter in detail: e.g., 'comma-separated interests', 'boost hands-on workshops', 'penalize vendor-heavy marketing sessions.' This adds substantial meaning beyond the input schema.
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?
Clearly states it 'gets sessions ready for personalized scoring' and 'returns scorable sessions along with a scoring rubric.' It distinguishes itself from sibling tools like get_schedule and search_sessions by focusing on scoring rather than just listing or filtering.
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?
Explicitly tells the AI agent to 'apply the rubric to rank sessions for the attendee.' It implies this tool is for scoring, not just browsing, but does not explicitly mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search conference sessions by keyword, topic, speaker name, or technology.
Args: query: Search query (e.g., "eBPF", "security", "AI agents", "platform engineering"). day: Optional day filter: "monday", "tuesday", "wednesday", "thursday". track: Optional track filter (e.g., "Keynote", "Tutorial", "Breakout"). limit: Maximum number of results to return (default 20).
Returns: JSON array of matching sessions with title, speakers, time, room, and URL.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| day | No | ||
| track | No | ||
| limit | No |
| 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 full burden for behavioral disclosure. It discloses the default limit (20) and return format (JSON array with specific fields). It implicitly suggests read-only behavior via 'search', but does not explicitly state side effects or required permissions. For a search tool, this is adequate but not exhaustive.
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 and well-structured: a single-line summary followed by a bulleted Args section and a Returns note. Every sentence is informative, and there is no extraneous content. It is front-loaded with the core action.
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 has 4 parameters, no annotations, and has an output schema, the description adequately covers purpose, parameter semantics, and return format. It does not discuss error handling, pagination, or optional behavioral details, but for a conference sessions search tool, this level of detail is sufficient.
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?
Schema coverage is 0%, but the description provides detailed semantic meaning for each parameter: query with examples, day with valid values ('monday'...), track with examples ('Keynote', 'Tutorial'), and limit with default. This adds significant value beyond the bare schema.
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: 'Search conference sessions by keyword, topic, speaker name, or technology.' It uses a specific verb ('Search') and identifies the resource ('conference sessions') with multiple search dimensions, which differentiates it from siblings like find_speaker (speaker-specific) and get_schedule (time-based).
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 explains parameters and provides examples (e.g., 'eBPF', 'security'), implying usage context. However, it does not explicitly state when to use this tool versus alternatives like get_schedule or score_sessions, nor does it mention when not to use it or any prerequisites.
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.
v0.2.1detect_conflictsfind_partiesfind_speakerget_colocated_eventsget_conference_overviewget_hotel_infoget_scheduleget_travel_infoget_venue_infoplan_party_routescore_sessionssearch_sessionsScored across 12 tools
Each tool targets a distinct aspect of conference attendance (scheduling, parties, travel, scoring, etc.) with no overlapping purposes. Even similar tools like find_parties and plan_party_route are clearly differentiated by scope and output.
All tool names use a consistent verb_noun pattern in snake_case (e.g., get_schedule, find_speaker, plan_party_route). Verbs are uniform ('get' for retrieval, 'find' for search, etc.) with no mixing of conventions.
12 tools is well-scoped for a conference MCP server, covering essential attendee needs without overwhelming. Each tool serves a clear purpose, and the count aligns with typical domain coverage.
The tool set covers core conference activities (schedule, sessions, speakers, travel, parties, conflict detection, scoring). A minor gap is the lack of a dedicated speaker bio tool, but search_sessions and find_speaker provide sufficient session-level detail.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
The Ferryhopper MCP server is a connector for LLMs and AI Agents in maritime travel that exposes ferry routes, schedules, and booking options. It enables AI assistants to search ports and connections across 33 countries and 190+ ferry operators, provide real-time ferry itineraries with indicative prices, and assist users with planning island-hopping or multi-leg journeys by processing natural language queries about ferry times, passenger counts, and travel durations.
MCP server for building and testing AI agents with multi-model experimentation and insights.
