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

Annotations already declare the mutation nature (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so safety is partly covered. The description adds nothing beyond this: it doesn't say the link becomes publicly visible, whether it requires edit rights, or that attaching is additive rather than replacing existing links. For a write tool it should do more.

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?

A single front-loaded sentence with zero waste; the verb-resource construction leads and the clarifying examples follow immediately. Nothing is redundant or padded.

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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. However, for a write tool with 6 parameters the description leaves gaps: no permission requirements, no indication of how session vs contribution targeting interacts, and no confirmation of idempotency. Adequate but incomplete.

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 67%, with event_id, instance, session_id and contribution_id already documented in the schema. The description adds marginal value by framing the three target parameters as alternative attachment points, but gives no detail on url format or title behavior. Baseline 3 is appropriate given partial schema coverage.

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 states a specific verb ('Attach') and resource ('link'), and enumerates the target entities (event, session, contribution) plus examples of link types (slides, recording, document). It's clearly distinguishable from all siblings, none of which attach links, though it does not explicitly name a contrasting sibling.

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?

There is no guidance on when to use this tool versus alternatives, nor on how to choose between attaching at the event, session, or contribution level. No prerequisites (permissions, instance selection) are mentioned. Usage is only implied by the single sentence.

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

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

Annotations only say readOnlyHint=false, destructiveHint=false, openWorldHint=true – a bare mutation profile. The description adds genuine behavioral context beyond that: Indico may unschedule the contribution when its slot no longer fits, which is a non-obvious side effect an agent should anticipate. It stops short of stating auth requirements or reversibility.

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 short sentences, zero filler, and the primary operation is front-loaded ahead of the side-effect caveat.

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 the description needn't explain return values, and annotations cover the safety profile. The one real gap is the missing routing guidance against sibling schedule/move tools for a mutation that overlaps with them.

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 75% and the schema already explains that a null session_id removes the contribution from its session, which is exactly what the description restates. No additional syntax, format, or edge-case meaning is contributed beyond the 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?

States a specific verb+resource pair ('Move a contribution into a session') and covers the inverse operation, so the agent knows this is the session-assignment tool. It doesn't name or contrast with close siblings like indico_schedule_contribution or indico_move_timetable_entry, leaving some ambiguity about which mover to pick.

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?

'or out of it' implies the removal case, but there is no explicit when-to-use, no prerequisites, and no routing to alternatives such as indico_schedule_contribution. Usage must be inferred from the operation itself.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the mutation/open-world profile is covered. The description contributes one genuinely additive behavioral fact — the contribution is created unscheduled and needs a separate scheduling call — but says nothing about auth requirements, defaults applied, or what happens to persons/session assignment on creation.

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 short sentences, zero filler, with the core action and the essential follow-up call front-loaded. 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?

Output schema exists, so return values need not be described, and the key state distinction (unscheduled) is covered. However, for a 7-parameter creation tool with under-half schema coverage, the description is thin on how the creation behaves relative to sessions, persons, and the later update/schedule siblings.

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 43% (title, description, duration_minutes undocumented), so the description is expected to compensate, and it offers no parameter guidance at all. It never explains persons/speaker semantics, the session_id assignment behavior, or duration handling — all left entirely to the 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?

States a specific verb+resource ('Create ... contribution') and adds a distinguishing scope qualifier ('unscheduled') that separates it from sibling indico_schedule_contribution. An agent can identify what this tool does and what it does not do without opening the schema.

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 routes the agent: create here, then use indico_schedule_contribution to place it in the timetable. It names the alternative and the sequencing, but gives no statement about prerequisites (e.g., needing a valid event_id or permissions) or when not to use it versus indico_update_contribution / indico_assign_contribution_session.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The only added disclosure is that it returns an id, which duplicates the existing output schema, and nothing is said about permissions, protection side effects, or the impact of listing/protection_mode choices.

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?

A single front-loaded sentence with no filler. Nothing is padded or buried, though the brevity is achieved by omission rather than by disciplined writing.

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 12-parameter mutation with 50% schema coverage and no use of the available description space, this is inadequate. The output schema covers the return value, but the agent still lacks guidance on instances, category requirements, and parameter interactions.

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 12 parameters and only 50% schema description coverage, the description must compensate but does not mention a single parameter. The phrase 'meeting or conference' loosely maps to event_type, but fields like protection_mode, listed, venue_name, and room_name are left entirely to the 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 gives a specific verb (create) and resource (meeting/conference, i.e. event) and states the return value. It is clear against siblings like indico_update_event and indico_create_session, though it does not explicitly name any alternative.

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?

There is no statement of when to use this tool versus indico_update_event or the session/contribution creation tools, and no mention that a category must already exist. Usage is only implied by the verb 'Create'.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context beyond annotations by revealing that the created session initially has no time slot and requires indico_create_session_block for scheduling. It does not contradict the annotations.

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 short sentences, front-loaded with the core action and followed by a critical workflow detail. Every sentence earns its place with no redundancy or filler.

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 an output schema exists and annotations cover safety, the description supplies the key scheduling dependency an agent needs to act correctly. It is complete enough for invocation, though it could still mention parameter expectations or permissions more explicitly.

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 description adds no information about any of the six parameters. With only 50% schema description coverage, the description does not compensate for undocumented parameters such as title, description, or default_contribution_minutes. It leaves parameter semantics entirely to 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?

The description states a specific verb and resource: 'Create a session.' It also distinguishes the initial state from a session block by noting the session has no time slot until indico_create_session_block is used. An agent can identify the tool's purpose and relationship to the sibling tool without inspecting schemas.

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 gives a clear workflow dependency: create a session first, then use indico_create_session_block to assign a time slot. This helps an agent understand the required sequence. However, it does not explicitly state when to use this tool versus update_session or other create tools, nor does it mention exclusions.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive write. The description adds the useful containment semantic (contributions go inside the block) but says nothing about overlap/conflict handling, permissions, or side effects beyond what annotations carry.

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?

A single front-loaded sentence with the verb and resource first and no wasted words. Dense but not padded; it could still expand briefly on scheduling behavior without bloat.

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, return values need not be described, and annotations cover the safety profile. For a six-parameter write tool the description is nearly complete, missing only conflict/overlap behavior and the relationship to update_session_block.

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 67%; start, title, event_id and instance are well documented in the schema, while session_id and duration_minutes have no descriptions anywhere. The description references sessions and time slots generically but adds no format or constraint meaning beyond the schema, so baseline 3 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?

Specific verb (Add) plus resource (session block / time slot) and placement (to the timetable), with the added detail that contributions of the session live inside it. Clear enough to distinguish from indico_create_session and indico_update_session_block, though it never names those siblings explicitly.

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?

Usage is implied by 'Add a time slot ... for a session', which suggests a post-session-creation scheduling step, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. update_session_block for editing an existing block). Minimum viable routing guidance only.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and environment. The description adds the id/db_id distinction for contributions, which is useful output semantics but not a behavioral trait like permissions or rate limits. No annotation contradiction exists.

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 the core purpose and then a targeted clarification. Every sentence earns its place; 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 an output schema exists and annotations cover safety, the description is largely complete for a fetch tool. It omits any when-to-use guidance and only partially lists the detail options, but the critical id/db_id caveat is included, making it 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?

Schema coverage is 100%, so the schema already documents all three parameters, including the detail enum and event_id/instance descriptions. The description's phrase 'optionally contributions or sessions' only partially mirrors the detail enum (omitting events and subcontributions) and adds no new parameter semantics, setting the baseline at 3.

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?

States a specific verb 'Get' and resource 'event', listing included details (dates, location, chairs, material) and optional inclusions (contributions or sessions). It does not name sibling tools, so it lacks explicit differentiation from similar getters like indico_get_timetable or indico_list_contributions.

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 over alternatives such as indico_list_contributions or indico_get_timetable. The mention of optional contributions/sessions is scoped to the detail parameter, not to tool selection, so an agent must infer appropriate usage.

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

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

Annotations supply readOnlyHint=true and openWorldHint=true, so the safety profile is already covered and the bar is lower. The description usefully discloses that form-field answers are part of the payload, but says nothing about permissions required, error behavior for missing ids, or pagination/volume concerns, and an output schema already covers return shape.

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?

A single front-loaded sentence with zero filler, which is appropriate for a simple lookup tool. It is arguably too terse for the parameter gaps it leaves behind, but nothing in the text is wasted.

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?

An output schema exists, so return-value detail is not required, and a four-parameter read tool is low complexity. However, with two required parameters undocumented and no usage guidance, the definition is only minimally sufficient for correct invocation.

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 only 50%: event_id and instance carry descriptions, while form_id and registration_id are bare integers with no explanation anywhere. The description adds no parameter meaning at all, leaving the two undocumented required identifiers unexplained.

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?

States a specific verb and resource ('Get one registration') and adds the scope detail that form-field answers are included. It implicitly separates itself from indico_list_registrations by saying 'one', but it does not name any sibling or explicitly distinguish the singular case.

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?

Usage is only implied: needing a single registration by id, including its form answers. There is no explicit when-to-use statement, no mention of when to prefer indico_list_registrations or indico_list_registration_forms, and no prerequisites such as permissions on the event.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful behavior beyond that: the result is flat, sorted by start time, and entry shape varies by kind. It does not mention pagination or size limits, but for a read-only listing this is solid added context.

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 short sentences, front-loaded with the action and result shape, then the field contract. No filler or restatement of the tool name.

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 100% schema parameter coverage, the description only needs to orient the agent, which it does by explaining ordering and the entry_id linkage to mutation tools. Minor gaps remain around instance scoping and result size, but nothing critical is missing for a read 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?

Schema description coverage is 100%, so event_id and instance are fully documented in the schema. The description adds no parameter-level meaning (no scoping, filtering, or instance-selection guidance), so the baseline 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?

States a specific verb and resource ('Get an event's timetable') and adds a distinguishing property: a flat list returned in start order, which separates it from hierarchical views. It does not, however, contrast itself with siblings like indico_get_event or indico_list_contributions, so the differentiation is only partial.

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?

There is no explicit when-to-use or when-not-to-use statement. The only routing signal is downstream: entry_id is called out as the input for indico_move_timetable_entry / indico_unschedule_timetable_entry, which implies usage but never states the condition that should select this tool over alternatives.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description does add one behavioral trait beyond annotations: that subcategories are included recursively. However, it says nothing about pagination or limit behavior, so it only partially enriches the picture.

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?

A single tight sentence with the scope front-loaded and zero filler. Every clause 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?

An output schema exists so return values need not be explained, and annotations cover safety. But for a listing tool with six parameters, the description omits sibling differentiation and pagination ordering context, leaving notable gaps.

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 67%, so several parameters (to_date, instance, from_date, category_id) carry their own descriptions in the schema. The tool description adds no parameter-level meaning, leaving limit and newest_first undocumented. Baseline 3 is appropriate given the schema does most of the work.

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?

States a specific verb ('List') and resource ('events') with clear scope: a category and its subcategories within a date range. This is precise, though it does not name a sibling to distinguish itself from indico_search_events or indico_get_timetable.

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 when-to-use guidance or alternatives are given. The phrase 'within a date range' implies a filtered-listing use case, but an agent is left to infer when this beats indico_search_events. Neither exclusions nor prerequisites are stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds a genuinely useful behavioral detail not in the annotations: it requires management rights on the event. Beyond that auth requirement it adds little, so a 3 is appropriate.

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 short sentences with no waste, front-loading the resource and scope before the permission requirement. The odd whitespace/indentation is cosmetic and doesn't hurt readability.

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?

An output schema exists, so the agent needn't be told the return shape, and parameters are fully documented. The description rounds out the picture with the required permission. It is nearly complete for a simple filtered list 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?

Schema description coverage is 100%, so both parameters (event_id, instance) are already documented in the schema. The description adds no additional parameter meaning beyond what the schema provides, which is the baseline 3 case.

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 states a specific verb (List) and resource (contributions of an event), and enumerates scope details (database ids, session, schedule, people). This clearly distinguishes it from mutation siblings like indico_create_contribution and indico_update_contribution.

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?

It gives a prerequisite ('Needs management rights on the event') which implies the appropriate context, but it names no alternatives or when-not-to-use conditions. There is no sibling that also lists contributions, so guidance is only implied.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile and the fact that reachable instances are external/undisclosed. The description adds the useful workflow context that the returned names are the input to other tools, but says nothing about ordering, filtering, or failure behavior when no instance is reachable. Adequate given annotations carry the safety burden.

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?

A single 16-word sentence, front-loaded with the action and resource, with the workflow hint appended rather than padding. Nothing is wasted.

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?

An output schema exists, so return values need not be described, and with zero parameters there is little else to specify. The definition is essentially complete, missing only minor operational context such as behavior on unreachable instances.

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 takes zero parameters, so the baseline is 4. The description does explain the semantics of the `instance` parameter on other tools, which is a small bonus, though it cannot add meaning to this tool's own (empty) argument set.

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?

States a specific verb+resource ('List the Indico instances this server can reach') and is unmistakably the discovery/enumeration tool among siblings that all operate on events, sessions, contributions and registrations. No other sibling returns instance names, so the agent can route here without checking other schemas.

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 second clause is actionable guidance: pass a returned name as the `instance` argument to the other tools, which tells the agent this is the prerequisite discovery step. It does not, however, state any exclusions or name an alternative, so it stays at 4 rather than 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the bar is lower, and the description adds an auth requirement (the 'Registrants' token scope) that an agent cannot infer from structured fields. It does not discuss pagination or result ordering, but the required-scope disclosure is genuine added value.

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 short sentences, zero filler, with the core purpose and the auth prerequisite front-loaded. Every clause 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?

An output schema exists so return values need no explanation, annotations cover the safety profile, and the schema covers both parameters. The description supplies purpose and the token-scope requirement, leaving little missing for a simple read-only list 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?

Schema description coverage is 100%, so both event_id and instance are already documented in the schema, including the /event/<id>/ hint and default-instance behavior. The description adds no syntax or format detail beyond 'an event's', so the baseline 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?

States a clear verb+resource ('List an event's registration forms') and adds scope detail ('with registration counts'), which distinguishes it from indico_list_registrations and indico_get_registration. It does not explicitly name those siblings, so it falls just short of 5.

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 only usage signal is the prerequisite 'Needs the Registrants token scope', which is helpful but is a permission gate rather than when-to-use guidance. No condition or alternative (e.g., use indico_list_registrations to see individual registrants) is offered.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful content context by naming the categories surfaced per registration, but says nothing about pagination, result volume, or permissions needed for the list.

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?

A single sentence that front-loads the verb and resource and then qualifies the returned fields; no filler. Slightly terse for what is a key lookup tool, but structurally sound.

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?

An output schema exists, so return-value detail is not required. However, for a list tool with a mandatory form_id that is undocumented anywhere, the definition leaves a meaningful gap in how an agent is expected to obtain and use that 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?

Schema coverage is 67%: event_id and instance have clear descriptions, but form_id is undocumented in both schema and description. With the schema doing most of the work and no compensating detail in the description, the baseline 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?

States a specific verb (List) and resource (registrations of a registration form), and parenthesizes the data categories returned (state, payment, check-in, tags). This distinguishes it from indico_get_registration (single) and indico_list_registration_forms (the forms themselves), though the sibling differentiation is implicit rather than stated.

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 versus indico_get_registration or indico_list_registration_forms, and no prerequisite hint that a form_id must first be obtained from indico_list_registration_forms. Usage is only implied by the tool name.

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

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

Annotations already declare this is not read-only and not destructive, so the safety profile is partly covered. The description adds a genuinely valuable side effect not in the annotations: Indico emails the registrant regardless of approve or reject, which an agent must know before acting. It still omits whether the decision is reversible and what permissions are required.

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 short sentences, zero filler, with the tool's action front-loaded and the side effect immediately following. Nothing is wasted or redundant with the title.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. For a 7-parameter mutation tool the description is adequate, though it could note that the action is not easily undone and clarify how the reason parameter interacts with send_reason.

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 57%, with form_id and registration_id undocumented and instance/event_id only lightly described. The description mentions the action and the email consequence, hinting at the send_reason/reason coupling, but adds no syntax or format detail for the undocumented identifiers. This is the baseline expected when the schema carries most of the weight.

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 gives a precise verb pair (approve/reject) and resource (pending registration), scoping the action to pending items only. This clearly separates it from sibling read tools like indico_list_registrations and indico_get_registration without needing to name them.

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 word "pending" implicitly tells the agent this only applies to registrations awaiting moderation, which is useful routing context. However, there is no explicit statement of when this should be invoked versus when to just view a registration, and no prerequisites or alternate paths are mentioned.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. Beyond that the description adds no behavior: it does not say whether duration is preserved, whether related/linked entries move, or what permissions are needed for an in-place reschedule.

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?

A single front-loaded sentence with the verb, resource and object scope, and zero 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?

An output schema exists so return values need not be described, but for a mutation tool the definition is thin: no duration/side-effect disclosure and no guidance for the undocumented entry_id leave an agent under-informed about invocation consequences.

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 75% and the crucial entry_id parameter has no schema description; the tool description does not compensate by explaining how entry_id is obtained. The 'start' semantics (local time, ISO without offset) live entirely in the schema, not the description.

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?

Names a precise verb+resource ('Change the start time of a timetable entry') and disambiguates the object by noting it can be a contribution or session block. It does not, however, explicitly distinguish itself from close siblings like indico_unschedule_timetable_entry or indico_update_session_block.

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 never states when to use this tool versus alternatives. There is no mention of the unschedule/schedule-contribution siblings or of any preconditions (e.g. entry must already be scheduled), leaving usage to inference.

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

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

Annotations already declare this is a non-read-only, non-destructive, open-world write, so the mutating nature is known. The description adds the 'unscheduled' state precondition, but omits conflict behavior (e.g., overlapping entries), whether scheduling is reversible, and any permission requirements — all relevant for a scheduling mutation.

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?

A single front-loaded sentence stating the action, the object, and the key input. No filler, 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?

An output schema exists so return values need no explanation, and annotations cover the safety profile. What is missing is the relationship to sibling scheduling/move/unschedule tools and any conflict or permission caveats, leaving an agent to infer the workflow context.

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 80%, so the schema already documents start timezone/format, instance resolution, and the session_block_id requirement. The description adds nothing beyond the schema, so the baseline 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?

States a specific action (placing an unscheduled contribution on the timetable) with a specified time, which is a concrete verb+resource pair. It is reasonably distinguishable from sibling scheduling tools, though it never names or contrasts with indico_move_timetable_entry or indico_unschedule_timetable_entry, leaving the boundary between 'schedule new' and 'move existing' implicit.

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?

'Unscheduled contribution' implies the precondition that the contribution is not yet on the timetable, which is useful context. However, there is no explicit when-to-use guidance, no mention of the alternative (move_timetable_entry) for already-scheduled items, and no note about the session-block requirement beyond the schema.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond the annotations: results are permission-filtered to what the token's user can see, which affects how the agent interprets empty results. It does not mention limit/pagination behavior, which is only found in the schema.

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 short sentences with no filler and the core action front-loaded. It is efficient, though arguably too terse to be fully front-loaded on constraints.

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?

An output schema exists, so return-value explanation is unnecessary, and annotations carry the safety profile. The visibility caveat covers the main behavioral gap; only cross-instance search semantics remain undescribed, a minor omission for this complexity level.

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 80%, with query, from_date, to_date, and instance all documented in the schema, so the baseline is 3. The description adds nothing about parameters, notably omitting any hint that instance selection may span multiple configured Indico instances.

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?

States a specific verb and resource (search events by title) with the matching scope (title matching only), which separates it from indico_get_event and indico_list_category_events. However, it never names those siblings, so the agent must infer that category listing is a different tool.

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?

There is no when-to-use or when-not-to-use guidance and no alternative named, even though indico_list_category_events and indico_get_event are plausible competitors. Usage is only implied by 'by title'.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation/safety profile is covered structurally. The description adds one genuinely useful behavioral fact beyond the annotations: the operation is reversible ('or undo it'), which matters for a toggle tool. It says nothing about required permissions or what happens if the registrant is already in the target state.

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?

A single short sentence, front-loaded with the action and resource, with the toggle behavior appended without waste. Nothing here needs trimming.

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?

An output schema exists, so return values need no explanation, which the description correctly omits. However, for a mutation tool with 40% parameter coverage and no usage guidance, the description is thinner than the tool's complexity warrants; it leaves the agent to infer which ids identify the target registration and under what conditions check-in is allowed.

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 only 40%: event_id and instance carry descriptions, but form_id, registration_id, and checked_in are bare titles, and the description adds no parameter-level information whatsoever. With three of five parameters undocumented anywhere and low overall coverage, the description fails to compensate for the schema gap.

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?

States a specific verb and resource: 'Mark a registrant as checked in at the venue, or undo it.' The toggle semantics are clear from the single sentence, so an agent knows exactly what state change occurs. It does not explicitly distinguish itself from the closest sibling, indico_moderate_registration, which is the only thing keeping it from a 5.

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?

Usage is only implied: the 'or undo it' phrasing signals this is a state toggle rather than a one-way action, so an agent can infer when to call it. There is no explicit when-to-use guidance, no mention of prerequisites such as the registration needing to be confirmed, and no routing away from related tools like indico_get_registration or indico_moderate_registration.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description usefully adds PATCH semantics ('Fields left out keep their value'), which is real context beyond the annotations, but it omits permission requirements and the fact that 'people' replaces the entire list rather than appending (that detail lives only in the schema).

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 short sentences, front-loaded with the action and field list, with the partial-update rule immediately after. Nothing is wasted and no filler is present.

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?

An output schema exists so return values need no explanation, and the annotations carry the safety profile. For a mutation tool the description covers the field list and partial-update behavior adequately, though permission prerequisites are absent.

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 a middling 57%; the description names the four optional mutable fields (title, description, duration, people) which maps to title, description, duration_minutes and persons, but adds no format or constraint detail beyond the schema. The two required identifiers are documented only in the 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?

States a specific verb ('Change') plus resource ('contribution') and enumerates the mutable fields (title, description, duration, people). This clearly separates it from indico_update_event and indico_update_session by resource name, though it never explicitly contrasts with them.

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 says nothing about when to use this versus indico_create_contribution, indico_update_event, or the scheduling tools, and gives no prerequisites such as required edit permissions on the event. The only usable guidance is the partial-update implication, which is a behavioral trait rather than a usage condition.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the write/non-destructive profile is already covered. The description adds a genuinely non-obvious side effect beyond the structured data: changing dates also shifts the timetable, mirroring the Indico UI default. Auth requirements are still unstated.

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 tight sentences, front-loaded with the action and affected fields, followed by the two most important behavioral notes. Nothing is wasted.

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, return values need no explanation, and the partial-update plus timetable-shift semantics are captured. The remaining gap is the ambiguity around which location fields are covered and the unstated auth/permission requirements.

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 only 40%, so the description must compensate. It names title, description, dates, and location, but 'location' ambiguously lumps together address, venue_name, and room_name, and says nothing about instance/timezone handling. It adds some meaning but does not close the coverage gap.

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?

States a specific verb ('Change') and resource ('event') and enumerates the mutable fields (title, description, dates, location), which cleanly separates it from create_event and the update_session/update_contribution siblings. It stops short of explicitly naming alternatives, but the scope is unambiguous.

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 partial-update contract ('Fields left out keep their value') tells the agent this is a patch, not a replace, which is useful guidance. However, there is no explicit when-to-use vs alternatives or prerequisites (e.g., permissions), leaving context to inference.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond listing updatable fields: it does not mention permissions, side effects, default handling, or what happens when optional fields are omitted.

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 a single front-loaded sentence with no wasted words. It is appropriately sized but very terse for a mutation tool with seven parameters and low schema description coverage.

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 update tool with an output schema and annotations covering safety, the description is minimally viable. It identifies the update fields but does not cover required identifiers, instance handling, or sibling differentiation, leaving notable gaps for an agent with many similar tools available.

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 only 29%, so the description should compensate. It names four updatable fields (title, description, code, default contribution length) corresponding to optional parameters, but omits required event_id/session_id and instance, and adds no format or constraint details beyond the 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 states a specific verb ('Change') and resource ('a session's title, description, code or default contribution length'), making the operation clear. However, it does not distinguish this tool from sibling update tools such as indico_update_session_block or indico_update_event.

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 gives no when-to-use guidance, no prerequisites, and no alternatives. An agent must infer that this is the correct tool for modifying an existing session rather than creating one or updating a session block.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds a genuine business rule beyond the structured fields: the block cannot become shorter than the entries it contains, which an agent could not infer from the schema.

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 short sentences, action front-loaded, with the constraint as a distinct second sentence. Nothing redundant or padded.

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 the description needn't explain returns, and the mutation semantics plus the minimum-duration rule cover the essentials. It stops short of noting that title and duration are both optional/nullable, which is only visible in the schema defaults.

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 60% and the description only names the two mutable fields (title, duration), which maps to part of the schema. entry_id, event_id and instance semantics come from the schema itself, so the description adds little beyond the stated alterable fields.

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?

Names a specific verb (change) and resource (session block) and enumerates the two mutable fields, duration and title. It is distinguishable from indico_update_session, but the description never explicitly contrasts the two siblings, so it falls short of a 5.

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 statement of when to use this versus indico_update_session or indico_create_session_block, and no prerequisites (e.g. that the block must already exist in the timetable). The constraint on duration is a rule, not usage guidance.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context by stating that the result is null when the token is anonymous.

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 one compact sentence with no wasted words. It front-loads the main purpose and includes the anonymous edge case without unnecessary elaboration.

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 read-only identity lookup with a complete input schema, output schema, and annotations, the description is sufficient. It explains what is returned and the only exceptional return case, leaving no important gap for correct invocation.

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 single optional 'instance' parameter is fully documented in the schema, including its default and fallback behavior. The description adds no further parameter details, so the baseline score of 3 is appropriate when schema coverage is complete.

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 states a specific action and resource: returning the Indico user associated with the token. It also clarifies the anonymous case, so an agent understands exactly what identity information this tool resolves.

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 purpose implies when the tool is useful, such as checking the current authenticated user, but it does not explicitly say when to use this tool versus alternatives. No sibling tool performs the same identity function, yet no alternatives or exclusions are named.

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