Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SpeechWire MCP Server list judges for the current tournament"
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.
A Model Context Protocol (MCP) server that provides AI assistants with secure, authenticated access to SpeechWire tournament data for speech-and-debate (forensics) competitions.
The server scrapes manage.speechwire.com behind an authenticated session and exposes structured tournament data through MCP tools, enabling AI assistants to help tournament directors manage judge assignments, rooms, teams, entries, and round pairings.
Judge management — list judges, contact info, availability, school associations, judge types, and add new judges
Team & entry data — team rosters, entries by team, hybrid/cross-school entries
Room management — room lists, usage grids, room-vs-section counts
Schematics — event lists, round-by-round pairings with judges, rooms, and competitors
Tournament structure — timeslots, competition groupings
Results — tab sheets with round outcomes, speaker scores, and placements
Account discovery — list and select accounts and tournaments interactively
Session management — automatic re-authentication on session expiry
Related MCP server: WebSurfer MCP
pip install speechwire-mcpSet your SpeechWire credentials as environment variables:
export SPEECHWIRE_EMAIL="your-email@example.com"
export SPEECHWIRE_PASSWORD="your-password"Tool | Description |
| List accounts available after login |
| Select an account to work with |
| List tournaments for the selected account |
| Select a tournament to activate |
| List all judges with roster details |
| Get judge email and phone |
| Get judge availability by timeslot |
| Get judge's school association |
| Add a new judge to the tournament |
| Update a judge's email address |
| Update a judge's availability slots |
| Update a judge's school/team affiliation |
| List configured judge types |
| List tournament rooms |
| Get room time-slot usage grid |
| Get rooms vs. sections per grouping/round |
| List registered teams |
| Get entries for a specific team |
| List cross-school hybrid entries |
| List tournament schedule timeslots |
| List competition groupings |
| List schematic events with available rounds |
| Get pairings for a specific event round |
| Get results tab sheet for a grouping |
Source contribution guidance, including MCP tool authoring conventions, lives
in src/README.md.
Add a new judge to the tournament.
judge_name : str Judge's full name (required). team_id : int Team/school ID (required). Get valid IDs from speechwire_list_teams. judge_email : str Email address (optional). judge_type_id : int Tournament-specific judge type ID from speechwire_list_judge_types. Use 0 when no configured judge type is selected. is_clean : bool Whether the judge is a clean/neutral judge. is_coach : bool Whether the judge is a coach. is_priority : bool Whether the judge is a priority judge. available_slots : list[int] | None Provider slot_id values from speechwire_list_timeslots for which the judge is available. If omitted, the judge is blocked for all slots.
dict
{"success": bool, "judge_id": int | None, "error": str | None}
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | ||
| is_clean | No | ||
| is_coach | No | ||
| judge_name | Yes | ||
| is_priority | No | ||
| judge_email | No | ||
| judge_type_id | No | ||
| available_slots | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains parameter behaviors, such as the default for available_slots ('if omitted, the judge is blocked for all slots') and the return format. It lacks information on auth or side effects, but covers essential behavioral traits.
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 well-structured with headers and bullet points, each sentence adds value, and it is appropriately sized given the 8 parameters. It is front-loaded with the purpose.
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 8 parameters, no output schema, and no annotations, the description covers parameter semantics and return value completely. It references sibling tools for validation, making it sufficient for an AI agent to use.
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 extensive explanations for each parameter, including how to obtain valid values (e.g., team_id from speechwire_list_teams) and default behaviors (e.g., available_slots). This adds significant meaning 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 clearly states 'Add a new judge to the tournament' with a specific verb and resource. It distinguishes from sibling update tools like speechwire_update_judge_email, making the purpose 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 description provides guidance by referencing sibling tools for parameter preparation (e.g., 'Get valid IDs from speechwire_list_teams'). However, it does not explicitly contrast when to use this tool versus other add/update tools or state prerequisites like tournament selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a judge's availability by timeslot.
judge_id : int Numeric judge identifier from speechwire_list_judges.
list[dict] Timeslot records containing: - slot_index: int — internal slot identifier - label: str — human-readable time slot description - available: bool — whether the judge is available
| Name | Required | Description | Default |
|---|---|---|---|
| judge_id | 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 bears the burden. It discloses the return format (list of dicts with specific fields) but does not mention whether the operation is read-only, rate limits, error behavior, or prerequisites beyond the ID source.
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 with separate 'Parameters' and 'Returns' sections, using bullet points for clarity. Every sentence earns its place 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 the tool's simplicity (one required parameter, output schema available), the description adequately covers input, parameter origin, and output structure. It fully addresses the agent's needs for 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 description adds meaningful context beyond the schema: it specifies that judge_id is a 'Numeric judge identifier from speechwire_list_judges', which tells the agent how to obtain the correct value. Schema coverage is 0% otherwise.
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 'Get a judge's availability by timeslot' using a specific verb and resource. Among siblings, there is 'speechwire_update_judge_availability' which is different, so the purpose is well-differentiated.
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 identifies the source of the judge_id ('from speechwire_list_judges'), which implies a prerequisite. However, it does not explicitly state when to use this tool over siblings or what contexts to avoid (e.g., for updating availability).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a judge's email and phone contact information.
judge_id : int Numeric judge identifier from speechwire_list_judges.
dict
Contact record containing judge_id (int), email (str | None), and
phone (str | None).
| Name | Required | Description | Default |
|---|---|---|---|
| judge_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description explains the return format and parameter source. It is transparent about the read-like behavior without explicitly stating read-only.
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: a one-line summary followed by structured parameter and return sections. Every sentence is essential.
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 retrieval tool with one parameter, the description fully covers the inputs, outputs, and prerequisite, compensating for the lack of 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?
The description adds meaning by specifying the judge_id originates from speechwire_list_judges, which goes beyond the bare schema. Schema description coverage is 0%, so this compensation is critical.
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 gets a judge's email and phone contact information. The verb 'Get' and resource are specific, and it distinguishes from sibling tools like speechwire_get_judge_school.
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 implies usage after calling speechwire_list_judges to obtain a judge_id. No explicit when-not-to-use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the school (team) a judge is associated with.
judge_id : int Numeric judge identifier from speechwire_list_judges.
dict
School record containing judge_id (int), school (str | None), and
team_id (int | None).
| Name | Required | Description | Default |
|---|---|---|---|
| judge_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the return type (dict with specific fields) but lacks details on side effects, authentication, or error handling. Adequate but not deep.
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 compact and front-loaded with the purpose. Uses a clear docstring format with minimal waste; every sentence adds value.
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 one required parameter and no output schema, the description adequately documents the return structure. It is mostly complete for a simple query tool, though annotations would strengthen behavioral 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 0%, but the description adds meaning by stating the parameter is a numeric judge identifier from speechwire_list_judges, which is beyond the schema's bare type definition.
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?
Description clearly states 'Get the school (team) a judge is associated with.' It uses a specific verb ('Get') and resource ('school/team'), distinguishing it from sibling tools like speechwire_get_judge_contact or speechwire_get_judge_availability.
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?
Description implies usage after listing judges, mentioning the parameter comes from speechwire_list_judges. However, it does not provide explicit guidance on when not to use this tool or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get room vs. section counts per grouping and round.
Shows how many rooms are assigned versus how many sections are needed for each competition grouping in each round. Useful for identifying rounds that are short on rooms.
list[dict]
Grouping records containing:
- grouping_name: str — competition grouping (e.g., "JV Policy Debate")
- rounds: list[dict] — per-round room and section counts with a
sufficient boolean
| 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 carries the full burden. It discloses the return structure including the 'sufficient' boolean, implying a read-only operation with no side effects. No behavioral contradictions exist.
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 front-loaded purpose, followed by a brief explanation and a structured return format. Every sentence serves a clear purpose 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 has no parameters, no annotations, and an output schema exists (though not shown in detail), the description fully covers the tool's behavior and return structure. It is complete for a simple read 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?
The tool has zero parameters, so the description adds adequate meaning beyond the schema. According to guidelines, no parameters results in a baseline score of 4.
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 verb 'Get' and the resource 'room vs. section counts per grouping and round', making the tool's purpose immediately obvious. It also differentiates from siblings by focusing on room assignment sufficiency.
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 explicitly says it is 'useful for identifying rounds that are short on rooms', providing clear context for when to use it. It does not list alternatives or when not to use, but the sibling set includes many judge and team tools, so the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get room time-slot usage showing assignments for every room.
list[dict] Room usage records containing: - room_id: int — numeric room identifier - room_name: str — room display name - time_slots: list[dict] — per-slot records with slot_index, time_label, status, event_code, and round_number
| 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 the burden. It lists all return fields (room_id, room_name, time_slots with inner fields) which is good. However, it omits behavioral details like data freshness, required permissions, or performance implications.
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: one sentence for purpose followed by a clear, structured returns section. Every sentence adds value with 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 the tool has no parameters and includes an output schema, the description is complete. It explains what the tool does and what it returns, which is sufficient for an agent to use correctly.
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 exist, so schema coverage is 100%. Baseline 4 is appropriate as description adds no parameter info beyond what schema provides (empty).
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 verb 'Get' and resource 'room time-slot usage' with scope 'for every room'. It distinguishes itself from sibling tools like speechwire_list_rooms and speechwire_list_timeslots by combining both room and time-slot 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 on when to use this tool versus alternatives (e.g., speechwire_list_rooms for just rooms, speechwire_list_timeslots for slots). The tool is simple with no parameters, but explicit context could help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full schematic (pairings/sections) for a specific event round.
grouping_id : int Event grouping identifier from speechwire_list_schematic_events. round_number : int Round number for this event.
dict | list Schematic containing: - event_name: str — event name - round: int — round number - time: str | None — scheduled time - unused_judges: list[dict] — unassigned judges - sections: list[dict] — sections with judges, rooms, and competitors
| Name | Required | Description | Default |
|---|---|---|---|
| grouping_id | Yes | ||
| round_number | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; description details return structure but does not mention side effects, permissions, or safety. It adds context beyond basic schema but insufficient for full behavioral transparency.
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 brief and well-organized with Parameters and Returns sections. Every sentence contributes necessary detail 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?
The description covers parameters and return structure, referencing a related tool. Missing error handling or edge cases, but adequate for a straightforward retrieval 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 coverage 0%, so description must add meaning. It explains grouping_id as 'Event grouping identifier from speechwire_list_schematic_events' and round_number as 'Round number for this event,' adding value over schema titles.
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 explicitly states 'Get the full schematic (pairings/sections) for a specific event round,' with clear verb and resource. It references grouping_id from speechwire_list_schematic_events, linking to sibling context.
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 specifies parameters and their origins (grouping_id from list_schematic_events), implying when to use this tool. However, it lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the results tab sheet for a competition grouping.
Includes round-by-round outcomes (W/L/BYE/FORFEIT), per-speaker scores, win-loss records, total points, and final placements.
grouping_id : int Grouping identifier from speechwire_list_groupings.
dict | list Tab sheet containing: - grouping_name: str — grouping name - round_names: list[str] — round column headers - competitors: list[dict] — team results, records, points, placements, and speaker results
| Name | Required | Description | Default |
|---|---|---|---|
| grouping_id | 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 the burden. It details the output structure but does not mention safety (e.g., that it's a read-only operation), idempotency, or potential side effects. Adding that it is a retrieval with no side effects would improve transparency.
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 well-structured with a clear purpose, parameter section, and bullet-pointed return details. It is front-loaded and every sentence adds value 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 the simple parameter (1 integer) and the presence of an output schema (implied by the detailed return description), the description is complete. It fully explains inputs, outputs, and provides a reference to a related tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 0% description coverage, but the description adds a clear explanation of the grouping_id parameter, including its source from a sibling tool. This adds meaningful context beyond the schema title.
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 'Get the results tab sheet for a competition grouping' and lists the contents (round-by-round outcomes, per-speaker scores, etc.), distinguishing it from sibling tools that deal with judges, rooms, or teams.
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 specifies that the grouping_id should come from speechwire_list_groupings, providing clear context. However, it does not explicitly state when not to use this tool or mention alternatives, though siblings are focused on different entities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get entries for a specific team.
team_id : int Numeric team identifier from speechwire_list_teams.
list[dict] Entry records containing: - event_id: int — numeric event identifier - event_name: str | None — event name - entry_number: int — entry number within the event - entry_code: str | None — entry code - competitors: list[dict] — student_id, name, and competitor_number - division: str | None — division name - division_id: int | None — numeric division identifier - is_dropped: bool — whether the entry is dropped
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description implies a read-only operation ('get entries') and details the return format. It does not mention authentication needs or side effects, but given the tool name and nature, 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 well-structured with clear sections for parameters and returns, but it is somewhat lengthy. Every sentence adds value, though it could be slightly more concise.
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 only one parameter and a full output schema description, the description is complete. It explains the input, output, and dependencies without leaving 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?
The description adds meaning to team_id by explaining its numeric identifier and source (speechwire_list_teams), which the input schema lacks. Schema coverage is 0%, so the description compensates well.
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 'Get entries for a specific team,' using specific verb+resource. It distinguishes from sibling tools like speechwire_list_teams which lists teams, not entries.
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 specifies that team_id comes from speechwire_list_teams, providing a clear dependency. However, it does not explicitly state when to use this tool over others or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List competition groupings configured for the tournament.
list[dict] Grouping records containing: - grouping_id: int — numeric grouping identifier - name: str — full grouping name - abbreviation: str — short code - event: str — event name - divisions: str — division text
| 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 carries the full burden. It discloses the return format with fields, which is helpful for a read-only list operation, but does not mention any authorization, rate limits, or side effects.
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: a single sentence for purpose followed by a structured return format. Every element is necessary 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 no-parameter list tool, the description covers the purpose and output structure completely. No additional context 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 has zero parameters with 100% coverage, so the description need not add param details. The description correctly omits param info, 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 the verb 'list' and the resource 'competition groupings', clearly distinguishing from sibling tools like list_judges, list_rooms, etc. The purpose 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?
No guidance is provided on when to use this tool vs alternatives, nor any exclusions or prerequisites. The description simply states what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all hybrid entries (cross-school team entries) for the tournament.
list[dict] Hybrid entry records containing: - comp_id: int — numeric competition entry identifier - event: str — event name - division: str | None — division name - students: list[dict] — student name and school records - code: str | None — entry code - team_blocks: list[str] — school names for team blocking
| 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 carries the burden. It accurately states it returns a list of dicts with specific fields, which is appropriate for a read-only tool. However, it does not discuss any potential side effects, authentication needs, or error handling.
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 sentence followed by a clear bullet list of return fields. No extraneous information; every part 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?
Given zero parameters and a detailed output schema in the description, the tool is fully documented. There are no missing pieces for an agent to use it correctly.
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 zero parameters, so baseline is 4. The description does not need to add param semantics.
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 verb 'List', the resource 'hybrid entries', and the scope 'all...for the tournament'. It distinguishes from siblings by specifying 'cross-school team entries', which is unique among the list tools.
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 given on when to use this tool versus alternatives like speechwire_list_teams or speechwire_get_team_entries. The description does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all judges registered for the tournament with roster details.
list[dict] Judge records containing: - judge_id: int — numeric judge identifier - name: str — judge's full name - team: str | None — school or team name - team_id: int | None — numeric team identifier - is_coach: bool — whether the judge is marked as a coach - is_active: bool — whether the judge is active - is_clean: bool — whether the judge is marked clean - is_priority: bool — whether the judge is marked priority - email: str | None — judge's email address (if present on the roster page) - unavailability: str | None — unavailability summary text - blocks: list[str] — event/team blocks (e.g. "GROUPING: Varsity Policy Debate")
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must communicate behavioral traits like read-only nature. The description only details the return format but does not explicitly state that the tool is safe, read-only, or has no side effects. This leaves uncertainty for the agent about whether invoking the tool could alter 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?
The description starts with a clear one-sentence summary. The subsequent bullet list of return fields is structured and adds useful information, but given the presence of an output schema, it could be considered slightly redundant. However, it is not overly verbose and is well-organized.
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 covers the core purpose and provides comprehensive detail on the return format. It does not mention error conditions or preconditions like requiring a tournament context, but the output schema fills in return details. Given the tool's simplicity (no parameters) and the presence of output schema, the description is adequately complete.
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 in the input schema, so parameter semantics are not applicable. Baseline score of 4 is appropriate as the tool requires no arguments. The description correctly provides no parameter-specific guidance since none exist.
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 'List all judges registered for the tournament with roster details' specifying the verb (list) and resource (judges). The tool name itself also clearly indicates the purpose, and it is distinct from sibling tools which address other resources like rooms, teams, or user accounts.
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 provides no guidance on when to use this tool versus the many judge-related siblings such as speechwire_get_judge_school or speechwire_add_judge. It does not mention prerequisites like having a tournament selected or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List judge types configured for the tournament.
If no judge types are configured for the tournament, returns an empty list.
list[dict] Judge type records containing: - judge_type_id: int — identifier to use with speechwire_add_judge - judge_type: str — name (e.g., "A", "B", "Speech judge") - groupings: list[str] — grouping codes this type can judge
| 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 carries the full burden. It discloses that the tool returns an empty list if no judge types are configured, and it details the return structure, including field meanings and cross-reference to speechwire_add_judge.
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 two short paragraphs. The first sentence states the purpose, followed by an edge case and return format. It is front-loaded and efficient, though the return structure could be referenced to the output schema rather than written out.
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, an output schema, and sibling context, the description is complete. It covers the action, the empty list edge case, and the return format with field explanations, including the identifier's use with a sibling 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?
There are no parameters, so the baseline is 4 per guidelines. The description does not need to add parameter information, and it appropriately focuses on the return value.
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 action: 'List judge types configured for the tournament.' It uses a specific verb 'List' and a specific resource 'judge types', distinguishing it from siblings like 'speechwire_list_judges' which lists individual judges, not types.
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 does not explicitly state when to use this tool versus alternatives like 'speechwire_add_judge' or 'speechwire_list_judges'. However, the context is clear from the tool name and sibling names, and the description adds a behavior note about empty lists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all rooms configured for the tournament.
list[dict] Room records containing: - room_id: int — numeric room identifier - name: str — room display name - has_constraints: bool — whether the room has availability constraints
| 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. Description includes return value structure but doesn't disclose behavioral traits like read-only nature, rate limits, or prerequisites. With no annotations, more detail expected. However, the output schema exists and description covers the key fields.
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 clear lines: purpose statement and Returns section. No fluff, efficiently structured.
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?
Complete for a simple list-all tool. Output schema exists and description outlines return fields. No obvious gaps given no parameters.
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?
Tool has 0 parameters, so baseline is 4. No parameter description 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?
Description clearly states 'List all rooms configured for the tournament' with specific verb and resource. Distinguishes from siblings like speechwire_get_room_usage which focus on usage rather than listing.
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 vs alternatives (e.g., speechwire_get_room_counts for counts, speechwire_get_room_usage for usage). No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all schematic events (debate/speech groupings) with available rounds.
list[dict] Event records containing: - grouping_id: int — numeric event identifier - name: str — event name - rounds: list[int] — available round numbers
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits like read-only nature, authentication, or rate limits. It only describes the return structure but does not mention safety or side effects. The read-only implication is weak.
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 (two sentences plus return format) and front-loaded with the purpose. Every sentence is informative 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?
While the description covers the core functionality, it lacks context on pagination, ordering, or filtering. For a list tool with no parameters, missing these details limits completeness, though the output schema description helps.
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 are present, so the baseline is 4. The description does not need to add meaning to parameters, and it correctly omits them.
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 lists all schematic events (debate/speech groupings) with rounds. It uses specific verb 'list' and resource 'schematic events', distinguishing it from sibling tools like 'speechwire_list_groupings' which may refer to different groupings.
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 such as 'speechwire_get_round_schematic' or 'speechwire_list_groupings'. The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all teams registered for the tournament.
list[dict] Team records containing: - team_id: int — numeric team identifier - name: str — team/school name - code: str | None — team code abbreviation - is_invited: bool — whether the team is invited - is_attending: bool — whether the team is attending - is_checked_in: bool — whether the team is checked in - is_udl_member: bool — whether the team is a UDL member
| 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 present, so the description carries full burden. It details the output schema with six fields and their types, providing good transparency about what the tool returns. However, it does not explicitly state that the operation is read-only or non-destructive.
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 reasonably concise with a clear heading and structured return fields. It front-loads the purpose and then lists output fields, but the return section is somewhat lengthy. Every sentence is informative.
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, an output schema exists (described in detail), and the tool is simple, the description is fully complete. It explains both purpose and return format, leaving no ambiguity about usage.
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, and the input schema has 100% coverage (empty). With zero parameters, the baseline is 4, and the description adds no parameter information, 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 clearly states 'List all teams registered for the tournament' with a specific verb ('list') and resource ('teams'). It differentiates from sibling tools like 'get_team_entries' which focus on individual team entries.
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 when-to-use or when-not-to-use guidance is provided. However, the tool has no parameters and a straightforward purpose, so the context is implied. The description does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the tournament schedule timeslots.
list[dict] Timeslot records containing: - slot_id: int — numeric timeslot identifier - time: str — human-readable time (e.g., "9:00 AM") - description: str | None — slot description - date: str | None — date for this slot - round_assignments: list[dict] — event_name and round_label records
| 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 description carries the burden. It explicitly details the return structure including fields and types, compensating well. However, it does not explicitly state that it is read-only or has no side effects, but the return format implies a query 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?
The description is concise and well-structured, with a clear purpose followed by a detailed return schema. The extra lines for return format are justified as they add value, but 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?
Given that the tool has no parameters and a fully described output schema, the description is complete. It explains what the tool does and what it returns, leaving no ambiguity for an AI agent.
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, so schema coverage is 100%. The description adds no parameter details (none needed), earning the baseline score of 4.
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 lists tournament schedule timeslots, with a specific verb ('list') and resource ('timeslots'). It distinguishes itself from siblings which focus on judges, accounts, rooms, etc.
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 use for retrieving schedule timeslots but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List SpeechWire accounts available to the authenticated user.
Call speechwire_select_user_account to choose one.
list[dict]
Account records containing account_id (int) and name (str).
| 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 behavioral traits. It implies a read-only operation by 'list' and describes the return type and fields (list of dicts with account_id and name). However, it does not disclose authentication requirements, rate limits, or behavior when no accounts exist, leaving some gaps.
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 and a brief structured return section. Every sentence provides essential information without 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 the tool has zero parameters and an existing output schema (implied by context and return description), the description is nearly complete. It includes the return type and key fields. Missing aspects like error handling or account availability are minor given simplicity.
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 has zero parameters and schema description coverage is 100%, so the baseline is 3. Since there are no parameters to document, the description adds no additional parameter meaning 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 clearly states it lists SpeechWire accounts available to the authenticated user, using the specific verb 'list' and resource 'accounts'. It distinguishes from the sibling tool 'speechwire_select_user_account' by mentioning it as a follow-up action, making the purpose 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 description explicitly tells the agent to call 'speechwire_select_user_account' to choose an account, providing clear guidance on next steps. While it does not mention when not to use this tool or list other alternatives, the single directive is helpful for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tournaments (current and past seasons) for the selected account.
Call speechwire_select_user_tournament to choose one.
list[dict]
Tournament records containing tournament_id (int), circuit_id
(int | None), name (str), date (str | None), and season
(str: "current" or "past").
| 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 carries full burden. It implies read-only (list), but does not explicitly state whether it requires a selected account or what happens if none is selected. Missing explicit mention of side effects or prerequisites.
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 two short paragraphs, front-loaded with the purpose, followed by a clear instruction and the return format. No redundant 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?
For a zero-parameter tool with output schema described, this is largely complete. However, the prerequisite of a selected account is implied but not explicitly stated, leaving a small gap.
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; the input schema is empty with 100% coverage. Baseline for 0 parameters is 4. No additional parameter explanation 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?
Description states 'List all tournaments (current and past seasons) for the selected account', providing a specific verb ('List') and resource ('tournaments'), and distinguishes from sibling 'speechwire_select_user_tournament' which is for selection.
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 instructs to call 'speechwire_select_user_tournament to choose one', clarifying when to use this list tool vs. the selection tool. Provides clear context for the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select a SpeechWire account to work with.
account_id : int Account ID from speechwire_list_user_accounts.
dict
Status record containing status (str) and account_id (int).
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the return as a status record with status and account_id, which is sufficient for a selection tool. Could mention that it sets the active account, but overall 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 and well-structured with clear Parameters and Returns sections. Every sentence adds value; no fluff.
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 (one parameter, no output schema), the description provides complete context: what it does, where the parameter comes from, and what it returns. It is sufficient for an agent to use correctly.
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 has no parameter descriptions (0% coverage). The description adds the meaning: 'Account ID from speechwire_list_user_accounts', which is essential for correct use.
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 selects a SpeechWire account, using a specific verb and resource. It distinguishes from siblings like speechwire_list_user_accounts by indicating it is for selection after listing.
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 use after listing accounts and mentions the parameter comes from speechwire_list_user_accounts. It does not explicitly state when not to use or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select a tournament to work with.
After calling this, tournament-specific tools become available.
tournament_id : int Tournament ID from speechwire_list_user_tournaments. circuit_id : int Circuit ID from speechwire_list_user_tournaments.
dict
Status record containing status (str), tournament_id (int), and
circuit_id (int).
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes | ||
| tournament_id | 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 only mentions the return status and implies a state change, but does not disclose side effects, authentication needs, or other behavioral traits.
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, front-loaded with purpose, and efficiently includes parameter documentation without unnecessary text.
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 covers purpose, parameters, and return value. It does not elaborate on session context or state persistence, but for a selection tool it is fairly complete.
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?
Despite 0% schema description coverage, the Parameters section in the description explains that tournament_id and circuit_id come from speechwire_list_user_tournaments, adding necessary context 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 clearly states the verb 'Select' and resource 'a tournament', and the note about tournament-specific tools becoming available distinguishes it from sibling tools like speechwire_list_user_tournaments and speechwire_select_user_account.
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 (before tournament-specific tools) but does not explicitly state when not to use or provide alternatives. It is clear enough for standard usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace a judge's availability slots while preserving other values.
judge_id : int ID of the judge to update. available_slots : list[int] Provider slot_id values from speechwire_list_timeslots for which the judge should be available. Replaces all current availability.
dict
{"success": bool, "judge_id": int | None, "error": str | None}
| Name | Required | Description | Default |
|---|---|---|---|
| judge_id | Yes | ||
| available_slots | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully reveals the key behavior: it replaces all current availability slots, not adding or merging. It also documents the return value structure. While it could mention prerequisites like judge existence, it provides essential behavioral transparency.
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: one sentence for purpose, a brief list of parameters with explanations, and a return value description. No redundant information; every sentence adds value. Well-structured 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?
Given the simplicity (2 parameters, no output schema, no annotations), the description covers the essential context: what it does, parameter meanings, and return format. It lacks mention of error conditions or prerequisites, but overall is adequately complete for an update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description compensates for the 0% schema description coverage by providing detailed parameter explanations: 'judge_id' is the ID of the judge, and 'available_slots' are provider slot IDs from 'speechwire_list_timeslots'. This adds critical context beyond type information.
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 explicitly states 'Replace a judge's availability slots while preserving other values,' using a specific verb and resource. It clearly distinguishes from sibling tools like 'speechwire_get_judge_availability' (read) and other update tools (email, school).
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 does not explicitly guide when to use this tool versus alternatives. While the purpose is clear, there is no mention of when to prefer this over other update tools or when not to use it. Usage is implied by context but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a judge's email address.
Replaces the email while preserving the judge's other values.
judge_id : int ID of the judge to update. email : str New email address for the judge.
dict
{"success": bool, "judge_id": int | None, "error": str | None}
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| judge_id | 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 states that the email is replaced while preserving other values, which is useful, but lacks details on permissions, side effects, or error handling beyond the return dict.
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 well-structured with clear sections, front-loaded with the main action, and every sentence adds value 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?
For a simple update tool, the description covers the action, parameters, and return format. It is complete given the simplicity and lack of 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 description coverage is 0%, but the description fully documents both parameters (judge_id and email) with their types and purposes, adding meaning beyond the schema's property titles.
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 'Update a judge's email address' with a specific verb and resource. It also notes that it preserves other values, distinguishing it from sibling tools like speechwire_update_judge_school.
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 does not explicitly provide when to use or when not to use this tool. It is implied by the name, but no alternative suggestions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a judge's school (team) affiliation.
Replaces the team affiliation while preserving the judge's other values.
judge_id : int ID of the judge to update. team_id : int New team/school ID. Get valid IDs from speechwire_list_teams.
dict
{"success": bool, "judge_id": int | None, "error": str | None}
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | ||
| judge_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states the effect (replace team) and the return dict structure. However, it does not mention permissions, whether the operation is reversible, or if the team_id must exist (though it implies validation via 'get valid IDs'). The disclosure 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 concise and well-structured with clear sections for parameters and returns. Every sentence adds value, and the format is easy to parse.
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 (2 required params, no nested objects, no output schema), the description is fairly complete. It covers the purpose, parameters, return structure, and a hint about valid IDs. It could optionally mention error cases, but the return dict includes an error field.
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 has no property descriptions (0% coverage), but the description compensates by defining each parameter: 'judge_id : int' as the judge's ID and 'team_id : int' as the new team/school ID, with a reference to 'speechwire_list_teams' for valid IDs. This adds 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 'Update a judge's school (team) affiliation', using a specific verb and resource. It distinguishes from sibling tools like 'speechwire_get_judge_school' (read) and others that update different attributes (e.g., email).
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 that the tool 'replaces the team affiliation while preserving the judge's other values', giving context on side effects. It also directs users to 'speechwire_list_teams' for valid IDs, providing helpful guidance. However, it does not explicitly state when not to use this tool versus alternatives.
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. Dates show when Glama detected each change.
v0.1.2speechwire_add_judgespeechwire_get_judge_availabilityspeechwire_get_judge_contactspeechwire_get_judge_schoolspeechwire_get_room_countsspeechwire_get_room_usagespeechwire_get_round_schematicspeechwire_get_tab_sheetspeechwire_get_team_entriesspeechwire_list_groupingsspeechwire_list_hybrid_entriesspeechwire_list_judge_typesspeechwire_list_judgesspeechwire_list_roomsspeechwire_list_schematic_eventsspeechwire_list_teamsspeechwire_list_timeslotsspeechwire_list_user_accountsspeechwire_list_user_tournamentsspeechwire_select_user_accountspeechwire_select_user_tournamentspeechwire_update_judge_availabilityspeechwire_update_judge_emailspeechwire_update_judge_schoolEach tool has a clearly distinct purpose. Judge tools are specific (list, add, get school/contact/availability, update email/availability/school), room tools (list, get usage, get counts) are separate, and team/entry/schedule/schematic tools are all unambiguous. No overlapping functionality.
All tools follow the consistent pattern 'speechwire_verb_noun' with verbs like list, get, add, select, update. No mixing of conventions (e.g., camelCase) and no irregular naming.
24 tools is well-scoped for a tournament management server covering account selection, tournament selection, judges (CRUD + queries), rooms, teams, entries, schedule, schematics, and results. Each tool serves a distinct function without bloat.
Core workflows for judge management, room allocation, scheduling, and results are covered. Minor gaps exist: no delete judge tool and no update tools for rooms, teams, or entries. However, the surface is robust for most common tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
MCP server for Argo RPG Platform — connects AI assistants to campaign data via OAuth2
A Model Context Protocol server for Wix AI tools
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jessica-writes-code/speechwire-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
