indico-mcp

Overview Schema Source Related Servers Discussions Admin

indico_unschedule_timetable_entry

Destructive

Remove a timetable entry from an Indico event: conference contributions return to the unscheduled list, while meeting entries are deleted only if allowed.

Instructions

Remove an entry from the timetable.

    In a conference, a contribution goes back to the unscheduled list. Anything else deletes data:
    in meetings the contribution itself is deleted, and a session block is deleted with its schedule.
    Those cases are refused unless the server runs with INDICO_ALLOW_DELETE=true.

Input Schema

TableJSON Schema

Name	Required	Description
`entry_id`	Yes
`event_id`	Yes	Indico event id (the number in /event/<id>/)
`instance`	No	Indico instance: a configured name (see indico_list_instances) or its URL; an event link works too. Can be left out when only one instance is configured or a default is set.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 27, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Goes well beyond the destructiveHint/openWorldHint annotations by detailing exactly what is destroyed in each case (a meeting contribution itself, or a session block with its schedule) versus merely unscheduled (a conference contribution). It also discloses the INDICO_ALLOW_DELETE=true server gate that causes refusal, which is critical behavioral context.

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?

The imperative summary is front-loaded, and the dense follow-up clauses each carry distinct information (conference behavior, meeting behavior, session-block behavior, the refusal gate). Slightly heavy but nothing wasted.

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?

With an output schema present and annotations declaring the destructive/open-world profile, the description covers what an agent most needs: what removal means per context and the server-side gate. It omits required permissions or authorization needs, a minor gap for a destructive operation.

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 67%: event_id and instance are documented in the schema, but entry_id carries no description anywhere. The description adds no parameter-level meaning, so the baseline of 3 is appropriate given the schema does most of the lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Remove an entry from the timetable'), which cleanly separates it from sibling mutation tools like indico_move_timetable_entry and indico_schedule_contribution. The distinction between removing an entry and deleting underlying data is made explicit.

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 explains context-dependent outcomes (conference vs meeting) but never states when to prefer this tool over alternatives such as indico_move_timetable_entry, nor the prerequisites for calling it. Usage is implied from the name and behavior rather than guided.

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