PWS MCP Server

by Distortik

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.1
Disambiguation3/5
The tool set is organized by clear resource domains and descriptions are detailed, but several pairs overlap (pws_get_titles vs pws_get_championships, pws_execute_action vs the purpose-built create_storyline/award_championship/sign_worker tools). With 72 entry points, an agent faces real misselection risk despite coherent naming.
Naming Consistency4/5
Virtually all tools use the pws_ prefix, lowercase snake_case, and familiar verb_noun patterns such as pws_get_*, pws_create_*, pws_update_*, and pws_set_*. A few noun-style names (pws_company_overview, pws_database_catalog, pws_contract_advice) and bare verbs (pws_search, pws_query) keep this from a perfect 5.
Tool Count1/5
At 72 tools, the server is far beyond even the 'heavy' range and into a scale that is harmful for agent tool selection. The breadth may mirror game features, but many tools could be consolidated or parameterized; this count is an extreme mismatch for a coherent MCP surface.
Completeness4/5
Coverage is impressively broad: roster, contracts, hiring, shows, segments, storylines, titles, stables, tag teams, brands, events, venues, commentary, promises, network deals, auditing, and raw SQL fallback are all represented. Minor gaps remain around network-deal negotiation and some advanced worker interactions, but pws_execute_action and query tools provide workarounds.
Average 3.7/5 across 72 of 72 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 34 commits in the last 12 weeks
- Last stable release on August 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and readOnlyHint=false, signaling that this mutates state. The description adds 'PREVIEW OR UPDATE' but does not explain what previewing entails, whether changes are irreversible, how confirmation works, or what side effects an update may have. It adds only minimal behavioral context beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the action, and wastes no words. It could earn a 5 if it added a bit more structure (e.g., separating preview from update), but as written it is appropriately terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a non-trivial mutation tool with a nested changes object, a preview boolean, a confirmed boolean, and destructive annotations. There is no output schema, and the description does not explain the preview-confirm flow or what happens on update. An agent would need more context to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists several updatable fields in plain language (e.g., 'runtime' for eventLength, 'preferred venue'), which helps, but it does not explain eventId, preview, confirmed, or the nested recurrence fields. The schema carries no descriptions, so the agent still lacks meaning for key parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('PREVIEW OR UPDATE'), a clear resource ('player-company event series'), and lists the mutable fields. This is clear and action-oriented, but it does not explicitly distinguish itself from closely related siblings like pws_create_event or pws_set_event_active.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as pws_create_event or pws_set_event_active. There is no mention of prerequisites, confirmation flow, or exclusions, leaving the agent to infer usage from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the description does not need to restate destructiveness. It does add the useful preview/update duality, but it does not disclose that changes are applied only after confirmation, what exactly gets overwritten or destroyed, or any side effects of an update. For a destructive tool with no output schema, this is insufficient context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence with no fluff or repetition. The key modes are front-loaded in uppercase, and every word earns its place. It is very easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 8 parameters, a destructive hint, and no output schema, this one-line description is insufficient. An agent would not know how to run a safe preview before confirming an update, which fields are required for changing members, or what response to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It loosely maps 'name', 'active', 'experience', and 'members' to contractId1/contractId2, but it leaves `preview`, `confirmed`, `tagId`, and the exact semantics of the contract IDs unexplained. Eight parameters cannot be understood from this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('PREVIEW OR UPDATE') on a specific resource ('player-company tag team') and lists the affected attributes: name, members, experience, active status. It is clear about what the tool does, but it does not explicitly differentiate from sibling tag-team tools like pws_create_tag_team or pws_dissolve_tag_team, so it falls just 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool as opposed to creating, registering, or dissolving a tag team. It also does not explain when a preview versus a confirmed update should be performed, which is a critical workflow decision for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds some behavioral context by listing the analysis dimensions, but doesn't explain side effects, output shape, or how the analysis behaves over time. This is consistent with annotations, so no contradiction, but the added transparency is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy, and the key verb 'Analyze' is front-loaded. It could be slightly expanded with parameter context, but as written it's clean and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain what the tool returns, but it only lists analysis topics without describing result format or how 'days' shapes the output. It leaves the agent to infer behavior. Given annotations cover safety but not return semantics, the description is incomplete for a tool with one meaningful parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'days', is not mentioned in the description, and the schema description coverage is 0%. The description therefore doesn't explain that the analysis window defaults to 90 days and is restricted to 7–730. Since the description must compensate for low schema coverage but doesn't, parameter semantics are under-specified despite the parameter name being somewhat intuitive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource ('worker usage') and an explicit verb ('Analyze'), and enumerates the data examined: roster appearances, matches, angles, last-booked dates, and rotation flags. However, it doesn't distinguish itself from siblings like pws_get_roster or pws_get_worker, which are related but presumably return raw data rather than analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no mention of what scenarios call for analysis rather than simple retrieval. The agent can infer some intent from the name and description, but the description doesn't help with routing among many similar pws_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish destructiveHint=true and readOnlyHint=false. The description adds the useful 'PREVIEW OR CREATE' distinction, but it does not explain how those modes are selected or what consequences creation has. It does not contradict the annotations, but it leaves key behavioral mechanics unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no fluff. The 'through the official PWS action' phrase is slightly unnecessary, but overall it is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no output schema, and destructive annotation, the description is too thin. It does not explain the preview/create workflow, what a preview returns, how `confirmed` and `preview` interact, or what the actual creation commits. An agent would struggle to invoke this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds essentially no parameter meaning. It repeats the 2-10 contract limit already encoded in contractIds, but does not explain the crucial preview, confirmed, name, overview, or startDate parameters, leaving the agent unable to know what values to provide for each.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('PREVIEW OR CREATE') and a clear resource ('player-company storyline'), with the meaningful constraint of 2-10 active contracts. It does not explicitly contrast with sibling tools like pws_update_storyline or pws_end_storyline, but the verb 'create' and the resource make basic differentiation clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you want to preview or create a new player-company storyline. However, it gives no explicit guidance about when not to use it, such as when an existing storyline should be updated or ended, and does not name any alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false, so some behavioral risk is exposed. The description adds the brandId-based create/update branch, which is useful, but it does not disclose what preview does, what confirmation implies, or what side effects occur on update. It adds moderate value beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action, and every sentence adds some signal. It is appropriately terse, though the extreme brevity contributes to leaving important contextual information out, so it is strong on conciseness but not perfect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no required parameters, 0% schema coverage, and a destructive annotation, the description is far from complete. A tool with preview, confirmed, and importance parameters needs explanation of how those flags interact, what preview returns, and what makes an update destructive. The current description does not give an agent enough to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only explains 'brandId' indirectly ('Omit brandId to create'), leaving name, preview, confirmed, and importance with no added meaning. This is insufficient for five parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the resource ('player-company brand') and the actions ('PREVIEW OR CREATE/UPDATE'), and adds the key distinction that omitting brandId creates a new brand. It is not a full 5 because the exact meaning of 'PREVIEW' relative to create/update is not explained, but it is still clearly differentiated from obvious sibling tools like pws_get_brands and pws_delete_brand.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives such as pws_delete_brand, pws_get_brands, or pws_assign_worker_brand. It only states a create-vs-update condition, not when this operation is appropriate or what prerequisites/confirmation flow are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and readOnlyHint=false, and the 'CREATE/UPDATE' wording aligns with that; there is no contradiction. The description adds a preview-vs-save distinction beyond the annotations, which is useful, but it fails to disclose what a preview returns, whether confirmed=true is needed to persist changes, or what an update overwrites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core mode distinction front-loaded and no filler words. A minor deduction because 'PREVIEW' occupies a prominent position without being defined, so not every word fully earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive 11-parameter tool with no output schema, no enums, and no required parameters, this is under-specified: there is no description of return values, no explanation of the preview/confirm workflow hinted at by the preview and confirmed parameters, and no parameter semantics beyond titleId. An agent would have to guess at the save transaction behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the 11 parameters, and it only explains titleId's role as the create/update discriminator. Parameters like name, type, brand, prestige, confirmed, defendable, genderLimits, weightLimits, and minWeightLimit receive no semantic explanation beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action on a specific resource: 'PREVIEW OR CREATE/UPDATE a player-company championship', and disambiguates the two modes with 'Omit titleId to create'. It is clearly the create/update tool for championships among siblings, though 'preview' is left unexplained and no differentiation from adjacent tools like pws_award_championship or pws_set_championship_active is made.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is the internal rule 'Omit titleId to create', which distinguishes create from update within the tool but says nothing about when to prefer this tool over alternatives. Several mutating siblings (pws_award_championship, pws_vacate_title, pws_set_championship_active) exist that an agent could confuse it with, and no exclusions or routing hints are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds context that the tool applies to active player-company contracts and supports a preview mode, but it does not explain how preview differs from confirmed modification or what destructive side effects may occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with a clear action verb, and most words add meaning. The phrase 'through the official PWS action' is filler, but overall the length is appropriate for a brief definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has a nested changes object, a preview/confirmed dual workflow, a destructive annotation, and no output schema, so it carries high operational complexity. The description omits nearly all of that: it does not enumerate supported terms, explain the preview gate, describe return values, or address error/validation behavior. An agent cannot reliably call it correctly from this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no parameter-level detail. It does not explain the preview/confirmed workflow, the meaning of the changes object, brand's special empty-string value, or any of the nested fields. The schema property names are somewhat self-explanatory, but the description does not compensate for the complete absence of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (PREVIEW OR MODIFY), a resource (an active player-company contract), and a scope (supported terms and management settings). It is clear enough for an agent to distinguish it from read-only contract tools, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'PREVIEW OR MODIFY' implies the tool should be used when the agent needs to preview or change contract terms, and 'supported terms' hints at a limited scope. However, it does not provide explicit when-to-use versus when-not-to-use guidance or name alternatives like pws_get_worker_contracts or pws_sign_worker.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, destructive operation, so the description does not need to restate that. The description adds the useful dual-mode behavior (preview vs create) and the contract prerequisite. However, it does not explain what happens during preview vs confirmed creation, what side effects occur, or why the operation is considered destructive beyond creating a new entity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with the main action front-loaded. It is concise and easy to parse. The phrase 'through the native PWS action' adds little value and is slightly redundant, but overall the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter destructive write tool with no output schema and no parameter descriptions, this description is materially incomplete. It omits the preview/confirmed flow, what 'confirmed' means, expected side effects, and any return-value or outcome information an agent would need to call the tool successfully in a meaningful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate for the seven parameters. It only hints that two active contracts are involved, matching contractId1 and contractId2. It does not explain the roles of preview, confirmed, active, name, or experience, leaving meaningful gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb and resource: it can preview or create a tag team from two active player-company contracts. This is specific enough to understand the core action, though it does not explicitly differentiate itself from sibling tools like pws_register_tag_team or pws_update_tag_team.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when the agent needs to preview or create a tag team from two active contracts. However, it provides no explicit guidance on when not to use it, no reference to alternatives among the many tag-team-related siblings, and no distinction between when one should create versus register or update a tag team.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by noting the beta status and listing the related entities returned. However, it does not disclose behavior such as default limit, result ordering, or that it lists all promises when no filters are applied. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the verb, and contains no filler. However, it could be slightly more informative without becoming verbose, so it is concise but not maximally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and five optional parameters, the description should explain the return structure and filtering capabilities. It lists related entities but does not describe the response format, pagination, or the meaning of includeResolved. The beta warning is helpful but insufficient for a tool with this many parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any parameter. It mentions 'status' only as part of the returned data, not as a filter. The meaning of limit, workerId, contractId, and includeResolved is entirely absent, leaving the agent with no additional guidance beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'Read' and a specific resource 'player-company worker promise requests and accepted obligations', and mentions related data (contracts, workers, titles, deadlines, status). This clearly distinguishes it from sibling tools like pws_respond_to_promise or pws_get_worker_contracts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It does not mention exclusions, prerequisites, or alternative tools. While the read-only nature is implied, there is no explicit 'use this when' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, and the description does not contradict them. However, it adds little behavioral depth: it mentions 'PREVIEW OR UPDATE' but does not explain the preview semantics, the need for `confirmed`, or what happens when preview is true versus false. This is a two-phase destructive flow, and the description leaves that largely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with the key action front-loaded ('PREVIEW OR UPDATE'). It is concise and readable, though it lacks structured detail. Its brevity does not by itself hurt this dimension, since completeness is scored separately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, five-parameter tool with 0% schema description coverage and no output schema, this description is far too thin. It does not explain the preview/confirm workflow, the required identifier, return behavior, or what makes the operation destructive. An agent cannot safely invoke this tool correctly based on the provided text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the burden for parameters. It names only `name` and `overview`, which partially explains two fields, but it does not explain the required `storylineId`, the `preview` flag's role, or the `confirmed` flag's role. With five params and no schema descriptions, this is insufficient compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('PREVIEW OR UPDATE') and a specific resource ('the name and overview of a player-company storyline'), which clearly identifies what the tool operates on. This distinguishes it from sibling tools like pws_create_storyline and pws_end_storyline, even though those siblings are not named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for updating an existing storyline's name/overview, but it does not explicitly state when to use it versus pws_get_storylines for reading, pws_create_storyline for creating, or pws_end_storyline for ending. It provides no exclusions or alternative routing, so usage 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool destructive. The description adds that a preview mode exists, suggesting a non-destructive path, but it does not explain that preview makes no changes or that confirmed=true is required to actually dissolve. The destructive target, the tag team, is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the core action front-loaded. The phrase 'through the native PWS action' adds little value but does not significantly bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is destructive, has three parameters, and no output schema, yet the description gives no return behavior, prerequisites, safe usage sequence, or side effects. The agent is left without enough context to invoke it confidently and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description needed to explain tagId, preview, and confirmed semantics, but it only vaguely maps 'preview or dissolve' to the boolean parameters. It never states that preview is a dry run or how confirmed finalizes the action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'PREVIEW OR DISSOLVE a player-company tag team.' This clearly identifies the action and object, and distinguishes it from sibling tag-team tools like create, update, get, and register.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use preview vs. confirmed dissolution, no workflow suggestions such as fetching tagId with pws_get_tag_teams, and no alternatives or exclusions. The description states the action but not the conditions for using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive and not read-only; the description adds that it can preview or cancel, which is useful. But it leaves critical behavioral details unexplained: whether preview is side-ffect-free, whether confirmed=true is mandatory for actual cancellation, whether cancellation is immediate or reversible, and what happens if the deal is already canceled. For a destructive action, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The primary purpose is front-loaded in capital letters, and the second sentence provides a boundary in one line. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, non-idempotent tool with three undocumented parameters and no output schema, the description should explain the preview/confirmed flow and cancellation consequences. It does neither fully. An agent cannot determine how to execute a cancel safely or whether the preview step is mandatory, so the definition is incomplete for real invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for explaining dealId, preview, and confirmed. It offers only the word 'PREVIEW,' vaguely suggesting the preview param's role, but it never defines confirmed, the relationship between preview and confirmed, or why confirmed exists. This is insufficient for an agent to call the tool confidently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action pair, 'PREVIEW OR CANCEL,' and identifies the exact resource (a player-company network deal). It is distinct from sibling tools like pws_get_network_options, which lists options rather than previewing or canceling them. The additional sentence clarifies that renegotiation happens elsewhere, further scoping the tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for previewing or canceling deals and states that new terms are handled inside PWS, which signals not to use this tool for negotiation. However, it does not explicitly say when to prefer this over pws_get_network_options or any other alternative, nor does it describe the preview-then-confirm workflow. Usage context is therefore more implied than fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a destructive, non-read-only operation. The description adds useful behavioral detail: it persists new segments, validates them, and rolls back newly created segments if a later addition fails. It does not describe what existing data might be affected, but it adds meaningful context beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler; the core purpose is uppercase-front-loaded and the confirmation requirement is called out. The term 'SAVE' is slightly ambiguous, but the description remains compact and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the purpose, side effects, and atomic rollback behavior of a complex five-parameter destructive booking tool. It does not explain what the result of a successful apply looks like, what 'SAVE' refers to, or how allowOverrun/allowMultipleMatches affect behavior. More would be helpful for such a potentially destructive operation, but the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions confirmed=true. The key parameters showId, segments, allowOverrun, and allowMultipleMatches are left entirely to the schema, so the description does not compensate for the lack of parameter-level guidance. Some nested fields have schema descriptions, but top-level parameter semantics are not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('BOOK') and resource ('REVIEWED CARD'), and clarifies that it adds validated match/angle segments. It does not explicitly contrast with pws_plan_show or pws_validate_show_plan, but the 'reviewed + confirmed' framing makes its commit-to-save role clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'REVIEWED CARD' and the requirement 'confirmed=true' imply this tool is used after planning/validation, but there is no explicit when-to-use vs when-not-to-use guidance or naming of alternatives. The usage context is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is known. The description adds a useful list of returned categories (contracts, storylines, history) but doesn't clarify details like the time range for 'recent history' or how relationships are represented. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action, no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only profile fetch with one obvious parameter and no output schema, the description lists the major content areas. It omits details like the shape of 'recent history' or whether 'active contracts' includes all statuses, but overall it's an adequate standalone description given the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single required workerId with no description and 0% schema coverage. The description never mentions the parameter, leaving the agent to infer that workerId identifies the worker. This fails to compensate for the lack of schema documentation, though the parameter name is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with 'worker profile' as the resource, and enumerates the contents ('all attributes, active contracts, relationships, chemistry, storylines, and recent history'). It differentiates from the targeted sibling pws_get_worker_contracts by framing itself as 'comprehensive', though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs. alternatives like pws_get_worker_contracts or pws_get_storylines. The phrase 'comprehensive worker profile' implies it's the general-purpose fetch, but there is no clear when-not or alternative mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description goes beyond annotations by noting the default preview behavior and the verification step ('verifies that the contract became inactive'). However, it does not disclose potential side effects (e.g., what happens to the contract on release) or the need for confirmation, but the destructiveness is already flagged in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence broken into three concise clauses. It is front-loaded with the core action and adds two important behavioral notes. No unnecessary words, though the use of 'PREVIEW OR RELEASE' in caps is slightly stylistic but acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not mention what the tool returns (e.g., a confirmation message or updated contract status). For a destructive tool with a confirmation flag, the lack of explanation for 'confirmed' and the absence of return value information are significant gaps. The description covers the main action and default, but omits critical operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage. The description only mentions that the tool 'defaults to preview,' which relates to the 'preview' parameter. It does not explain the 'confirmed' parameter, which is critical for a destructive operation. The 'contractId' is self-evident, but confirmed is completely undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'PREVIEW OR RELEASE an active player-company contract.' It uses specific verbs and a resource, and distinguishes from sibling tools like pws_get_worker_contracts (view) or pws_set_contract_gimmick (modify). The additional context 'verifies that the contract became inactive' further clarifies the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you want to release a player-company contract) but provides no explicit guidance or alternatives. It does not explain when to preview versus actually release, nor does it mention any prerequisites or situations where this tool should be avoided. There are no references to sibling tools for different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description adds that it 'rerun the show audit for availability,' providing useful context about the post-move validation. However, it does not disclose whether moving is a cut-and-paste or copy operation, nor what happens to the original show. With annotations covering the safety profile, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence that is efficient and front-loads the key actions. It wastes no words but could benefit from a more structured breakdown of parameters. Still, it is appropriately concise for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with four parameters and no output schema, the description leaves critical gaps: the semantics of preview vs. confirmed, what confirmation requires, and the effects on the original show. The audit rerun is mentioned but not explained. An agent would still need to interrogate the schema or server.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies showId and airDate through the action ('to another game date') but fails to explain the preview and confirmed parameters, which are crucial for invoking correctly. No details on parameter formats, defaults, or interaction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('PREVIEW OR MOVE') and resource ('unfinished player-company show') with a clear action (moving to another game date). It distinguishes from siblings like pws_schedule_show and pws_cancel_show by specifying the rescheduling context and the audit step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implicit usage context ('unfinished player-company show') but offers no explicit guidance on when to choose this over alternatives such as pws_schedule_show or pws_cancel_show. The absence of exclusions or cross-references leaves some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations by explaining the preview vs. actual scheduling distinction and noting persistence verification. The annotation destructiveHint=true is consistent with the scheduling behavior; no contradiction. However, it does not detail side effects or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core purpose and key behavioral nuance (preview vs. schedule). The 'BETA:' prefix and 'Verifies persistence' are useful but the latter is vague.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive, non-idempotent tool with six parameters and no output schema, yet the description is minimal. It omits parameter explanations, return-value expectations, and further context, making it under-specified for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only hints at the venue parameter ('optionally at a validated venue') and the preview flag ('Defaults to preview'). It does not explain eventId, airDate, confirmed, or location, and with 0% schema description coverage, this leaves most parameters semantically opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific action 'PREVIEW OR SCHEDULE' and clearly identifies the resource as 'a show instance for a player-company event series,' differentiating it from sibling tools like pws_plan_show or pws_cancel_show. It also notes optional venue validation, adding further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to schedule or preview show instances, but it does not explicitly state when to use it over alternatives like pws_plan_show or pws_validate_show_plan. No exclusions or alternative tools are mentioned, leaving the usage largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds useful context by enumerating the factors used for ranking (company size, cash, etc.), but does not disclose return format, whether it considers all workers or only free agents, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. It efficiently communicates the tool's purpose and key inputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 optional parameters and no output schema, the description is too brief. It does not clarify what the ranked output looks like, how limit affects results, or whether the ranking is based on current roster state vs. free agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage of only 13% (only 'needs' is described), the description must compensate but does not. It mentions 'requested needs' and 'wage fit', but leaves parameters like style, gender, minAge, maxAge, and limit unexplained, leaving an agent guessing about valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Rank') and resource ('realistic hiring targets'). It lists multiple criteria that distinguish it as an analysis/ranking tool, which differentiates it from sibling tools like pws_get_worker or pws_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over alternatives, but the name and the verb 'Rank' imply a use case of evaluating hiring targets. There is no mention of exclusions or alternatives, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and readOnlyHint=false. The description adds useful behavioral detail: omitting brandId clears the assignment, and there is a preview mode. However, it does not clarify what 'preview' actually returns or how the 'confirmed' parameter fits in, so the behavioral picture remains incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the core purpose with 'PREVIEW OR ASSIGN' and packs the most important usage detail about clearing into a short semicolon clause. There is no fluff or repetition of schema/annotation data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with a confirmation parameter, no output schema, and zero schema-level parameter descriptions, the definition is not complete. It leaves the preview/confirm workflow, return behavior, and required preconditions largely implicit, so an agent may not know whether to provide 'confirmed' or what the response tells it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It does clarify brandId's behavior ('omit brandId to clear it') and contractId is inferable, but it gives no semantics for 'preview' or 'confirmed', which are crucial for actually invoking the tool safely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('assign') on a specific resource ('active player-company contract') with a clear target ('a brand'), and also conveys the clearing mode. It is distinct from sibling tools like set_contract_gimmick or set_contract_persona because it names the brand assignment purpose directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: assigning or clearing a brand on an active player-company contract. It also communicates an important constraint ('active contract') and the clearing behavior, but it never names alternatives or says when not to use it, leaving sibling differentiation to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint false, so the safety profile is known. The description adds value by explaining the analysis dimensions (expiry, pay, performance, etc.) and the decision categories it outputs, providing behavioral context beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the tool's purpose and then lists decision factors. Every word contributes meaning; no fluff or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters and no output schema, the description only covers the tool's high-level purpose. It lacks information about parameter usage, return format, or how the advice is structured, making it insufficient for confident invocation in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any parameter names or semantics. Parameters like limit, workerId, usageDays, horizonDays, and includeStaff are entirely unexplained, leaving the agent to guess their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Review') and resource ('player-company contracts') and clearly lists the output types (renewal, retention, renegotiation, release). It distinguishes itself from sibling tools like pws_get_worker_contracts by focusing on advice rather than retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: this tool is for contract advice. However, there is no explicit statement about when to prefer it over alternatives like pws_get_worker_contracts or pws_analyze_hiring, and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the destructive nature is covered. The description adds the dual modes 'PREVIEW OR SET' but does not clarify what preview does vs set, nor the need for 'confirmed' to commit changes. This is a behavioral gap beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is easy to parse. It front-loads the action ('PREVIEW OR SET') and includes key constraints (up to four, brand or event) without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, the description is insufficient. It does not explain how preview/confirmed work, how contractIds relate to commentators, or the exclusivity of brandId/eventId. An agent would struggle to invoke the tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It provides some context: 'up to four' maps to contractIds maxItems, and 'brand or event' maps to brandId/eventId. However, it leaves preview and confirmed entirely unexplained, and contractIds is not explicitly tied to commentators. The description only partially compensates for the schema's lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: preview or set up to four default commentators for either a brand or an event. It uses specific verbs ('PREVIEW OR SET') and identifies the resource ('default commentators'), distinguishing it from all sibling tools that deal with other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when setting or previewing commentator defaults), but it does not explicitly state alternatives or exclusions. It also fails to mention the workflow of previewing first and then confirming the actual set, leaving the agent to infer this from parameter names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive, and the description adds that awards apply to active player-company contracts and preserve title history, which is useful behavioral context. However, it never explains that preview mode is non-committing and that a real award likely requires preview=false or confirmed=true, which is a meaningful behavioral gap for an agent deciding how to invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one front-loaded sentence with the core action capitalized and the purpose stated immediately. 'Through PWS' is slightly redundant since the tool name already indicates the system, but the sentence is otherwise efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, a destructive annotation, no output schema, and no parameter descriptions, the description is not complete enough. An agent needs to know the preview-then-confirm workflow, what happens to the previous champion, and what the preview output represents; none of that is stated. The brief purpose sentence is clear but leaves too much essential invocation context implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the four parameters, but it does not explain preview, confirmed, titleId, or contractIds directly. It vaguely implies the contractIds count through 'singles, tag, or trios,' but the critical distinction between previewing and confirming an award is absent. This leaves the agent to guess the workflow semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the imperative 'PREVIEW OR AWARD' and explicitly targets 'a singles, tag, or trios championship to active player-company contracts.' This names a concrete action and resource and semantically separates it from read-only/get tools and from vacating. It could name a sibling explicitly, but the meaning is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool when awarding or previewing a championship to active contracts, with title history preservation. It does not provide explicit when-not/alternative routing, such as pointing to pws_vacate_title for vacating, but the intended usage is still evident. No misleading guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds 'active' roster scope and enumerates returned fields, but does not disclose behavioral details like pagination limits or default parameter effects. With annotations present, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that enumerates all return fields without repetition or fluff. Every phrase adds information, making it highly concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with no output schema, the description gives a good overview of what is returned, but lacks guidance on how to use the many optional parameters. The presence of annotations reduces some burden, but the overall completeness is only adequate for a tool with 11 params.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for 11 undocumented parameters. It mentions some attributes (alignment, push) that map to filter parameters, but does not explain parameters like lean, brand, search, usageDays, includeStaff, or offset. The description adds minimal semantic value beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the active player-company roster with a broad set of attributes (contracts, alignment, push, wages, etc.). This specific verb+resource distinguishes it from sibling tools like pws_get_worker (single worker) and pws_get_worker_contracts (contracts only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing roster data but does not explicitly state when to use this tool versus alternatives. For example, it does not say 'use this instead of pws_get_worker for list views'. Context is present but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds useful behavioral context: it defaults to preview mode (safety guard) and verifies the segment no longer exists after removal. It also constrains usage to unfinished shows. However, it does not disclose the full confirmation flow (e.g., that confirmed=true is needed to finalize), which is a meaningful behavioral gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and scope. 'Verifies that the segment no longer exists' and 'Defaults to preview' add essential behavioral and safety context without waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description covers the core operation, the unfinished-show constraint, preview default, and post-removal verification. However, it lacks detail on the confirmation flow, potential side effects, and return behavior. Given the tool's moderate complexity and rich sibling set, more completeness is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must explain parameters. It clarifies that 'segmentId' refers to an existing match/angle and that 'preview' defaults to true. However, it completely omits the 'confirmed' parameter, which is crucial for executing the actual removal. This partial coverage is insufficient given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('PREVIEW OR REMOVE'), the exact resource ('ONE EXISTING MATCH/ANGLE'), and the context ('from an unfinished player-company show'). This distinguishes it from sibling tools like pws_update_segment (which modifies rather than removes) and other removal tools (which target workers, stables, or storylines, not segments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: previewing or removing a segment from an unfinished show, with a default to preview for safety. However, it does not explicitly contrast with alternatives (e.g., when to use pws_update_segment instead) or state exclusions (e.g., finished shows). The context is clear but lacks explicit when-to-use/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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds that the tool verifies persisted membership and defaults to preview, meaning no mutation occurs unless explicitly confirmed. This is valuable behavioral context, though it doesn't detail post-add effects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three terse sentences with all information front-loaded; no wasted words. Every sentence adds a distinct piece of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with a confirmation flow, the description omits the role of 'confirmed' and doesn't explain what happens after a successful add. With no output schema and 0% schema coverage, this leaves significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies contractId and storylineId from the phrasing, and mentions 'Defaults to preview' for the preview parameter, but the confirmed parameter is entirely unexplained. No per-parameter details are given for the optional boolean.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds an active player-company contract to an active storyline, with preview as the default mode. This specific verb+resource combination distinguishes it from sibling tools like remove_storyline_worker and add_stable_worker.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding contracts to storylines and notes the preview default, but it doesn't explicitly state when to use this over alternatives or when not to use it. No exclusions or alternatives are mentioned, though 'Verifies persisted membership' hints at a precondition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, but the description adds useful behavioral context: the dual preview/cancel modes, the default preview behavior, and the verification of a cancellation flag. This goes beyond the structured hints without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the core purpose and key defaults. The phrase 'Verifies the cancellation flag' is a bit cryptic but still earns its place by hinting at the confirmation mechanism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (dual preview/cancel), has 3 parameters, and no output schema. The description does not explain what the call returns, what cancellation actually does (beyond destructive), or the exact role of the 'confirmed' flag. For a potentially destructive action, this is insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for parameter meaning. It explains 'Defaults to preview' (relating to preview) and 'Verifies the cancellation flag' (likely confirmed), but it doesn't fully clarify how confirmed works or what showId represents. Some meaning is added, but gaps remain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact actions 'PREVIEW OR CANCEL' and targets 'an unfinished player-company show', making it distinct from sibling tools like pws_get_show or pws_plan_show. The verb+resource pairing is clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for unfinished shows and indicates a preview default, but it doesn't explicitly contrast with alternatives like pws_get_show or pws_apply_show_plan. No when-not-to-use or alternative tool guidance is provided, leaving the decision partially implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds that deletion also clears contract/event assignments and uses 'PWS native cleanup behavior.' This is useful behavioral context. It does not mention irreversibility or the confirmation requirement, but annotations already signal destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence with no filler. The central action is front-loaded, and every phrase adds meaningful information about scope and cleanup behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with three parameters, no output schema, and only minimal annotations, the description is too sparse. It omits how to perform a safe preview versus an actual deletion, what happens if 'confirmed' is absent, and what the caller should expect in response. An agent would be uncertain about the exact invocation flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It indirectly maps 'brand' to brandId and 'PREVIEW' to preview, but it never explains the confirmed parameter, the preview default behavior, or the relationship between preview and confirmed. This leaves a significant semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('PREVIEW OR DELETE') and a specific resource ('player-company brand'), and further clarifies that it clears contract/event assignments. This distinguishes it clearly from siblings like pws_get_brands, pws_save_brand, and pws_assign_worker_brand.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied: use this tool when you need to preview or delete a brand. However, it does not explicitly state when not to use it, nor does it direct the agent to alternatives such as pws_save_brand for edits or pws_get_brands for reads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that confirmed=true is required and that sign_worker inputs are read back and verified, adding behavior beyond the destructiveHint annotation. It also notes the sandbox-only restriction, which is useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a colon and a list, which is compact and easy to scan. It front-loads the tool's purpose and includes the critical confirmation requirement without extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six actions and no output schema, the description does not explain the arguments or side effects for most actions. It only details sign_worker behavior (in the schema), leaving significant ambiguity for create_storyline, award_title, create_news_item, and create_email, making the tool hard to invoke correctly across its full range.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description lists the supported actions and mentions the confirmation requirement, but the input schema already covers the action enum and confirmed const. The arguments schema description is detailed for sign_worker, but the description adds little beyond the schema and does not compensate for the overall low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as an 'ADVANCED SAVE ACTION' for PWS operations and lists six specific supported actions, making its scope clear. The phrasing 'operations that do not yet have a purpose-built verified tool' also distinguishes it from sibling tools, but it is slightly roundabout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool for operations without a purpose-built verified tool, giving a clear selection criterion. It also requires confirmed=true and flags update_worker_attribute as sandbox-only, but it does not name alternative tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: the query runs against the 'loaded save' and 'results are capped', which are important traits not stated in annotations. It does not expose every nuance but goes beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that conveys the core purpose, constraints, and a key behavior (capping). Every word earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and moderate parameter complexity, the description leaves out essential details such as how to supply parameters, the result format, error behavior, or the exact cap semantics (e.g., maxRows default/limits). It covers allowed SQL but not enough for an agent to confidently construct valid calls in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for missing parameter explanations. It only mentions 'parameterized' without detailing the parameters array or maxRows behavior, and it does not explain placeholder syntax or how values bind. The schema gives types/defaults but no semantics, and the description adds little beyond 'parameterized'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a parameterized read-only SQL query against the loaded save, with explicit allowed SQL constructs (SELECT, WITH, safe schema PRAGMAs). This specific verb+resource+scope distinguishes it from sibling tools that target specific data or actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for ad-hoc SQL queries by listing allowed statements, but it does not explicitly state when to use this tool versus the many sibling tools or when it is inappropriate. There is no guidance on alternatives or exclusions beyond the SQL restriction, so it is clear but lacks explicit decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare destructiveHint: true, but the description adds important nuance by stating 'Defaults to preview,' indicating that the destructive removal is not the default action and likely requires explicit confirmation (confirmed parameter). 'Verifies removal' also discloses post-action verification behavior, which goes beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of three short sentences. It front-loads the core purpose ('PREVIEW OR REMOVE'), then adds verification and default behavior. No unnecessary words or repetition of schema details; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema and only 0% schema description coverage, this description is too sparse. It does not explain return values, any prerequisite conditions beyond 'active storyline,' what 'confirmed' does, or the implications of removal. The preview default mitigates risk but the description still leaves significant gaps for an agent to safely invoke the destructive path.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for parameter explanation, but it does not. It mentions 'worker' and 'active storyline,' which loosely hint at storylineId and contractId, but it fails to explain the meaning of 'preview' and 'confirmed' flags, especially how confirmed triggers the destructive action. Minimal additional semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'PREVIEW OR REMOVE a worker from an active storyline.' It uses a specific action verb and resource, and further clarifies that it 'Verifies removal' and 'Defaults to preview.' This distinguishes it from sibling tools by focusing on storyline worker removal specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'active storyline' and the preview/remove distinction, but it does not explicitly state when to use this tool versus alternatives like pws_remove_stable_worker or pws_end_storyline. It provides no exclusions or alternative tool references, leaving the agent to infer from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as readonly, idempotent, and non-destructive. The description adds the scope of the search and the entry-point hint, but does not disclose behaviors like result format, pagination, or matching rules. With annotations covering safety, this is adequate but lacks rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the verb 'Search', and contains no filler. It efficiently states the scope and the primary use case, making every word value-bearing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not explain what the search returns, how results are structured, or how to refine searches with categories. While the 'name to ID' hint suggests output includes IDs, the lack of behavioral detail makes the description incomplete for a search tool with three parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no guidance on the query, limit, or categories parameters. The schema's property names and enum values are self-explanatory, but the description does not compensate for the absence of parameter documentation, leaving the agent to rely solely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches across a broad set of PWS entities and explicitly identifies the primary use case ('Start here when resolving a name to an ID'). This distinguishes it from sibling getter tools, which focus on retrieving specific entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for when to use this tool ('Start here when resolving a name to an ID'), implying it is the entry point for name resolution. However, it does not explicitly name alternative tools or state when not to use it, which would make it fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, so the description doesn't need to re-state destructiveness. It adds value by clarifying that the operation does NOT delete history, which is a significant behavioral guarantee. It also mentions the preview capability, providing transparency about a non-destructive first step. This goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core action and its key outcome. Every word earns its place: 'PREVIEW OR' signals the two modes, 'RETIRE/REINSTATE' states the verb, and 'without deleting its history' provides a critical constraint. There is zero waste, and the structure immediately informs the agent of the tool's nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 4 parameters, no output schema, and no parameter documentation, the description is incomplete. It does not explain the safe execution flow (preview then confirm), the meaning of the boolean flags, or the exact effect of 'active'. An agent cannot determine how to correctly invoke the tool (e.g., whether preview must be called with confirmed, or if active is true for retire or reinstate) from this description alone. Substantial details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The description does not explain the meaning of 'active' (whether true means retire or reinstate), the role of 'preview' (beyond the vague word), or the purpose of 'confirmed'. It relies entirely on parameter names for semantics, which is insufficient for a 4-parameter mutation tool. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (retire/reinstate) on a specific resource (player-company championship) and adds a key qualifier ('without deleting its history'). It also mentions a preview mode, clearly distinguishing it from read-only tools like pws_get_championships and from other mutation tools like pws_award_championship or pws_vacate_title. The purpose is unambiguous and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to change the active status of a championship) but provides no explicit guidance about when NOT to use it or how it compares to similar siblings like pws_vacate_title. The mention of 'PREVIEW OR' hints at a workflow but doesn't explain when preview is appropriate versus direct execution. Usage context is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds useful behavioral context: this is the official action rather than a simulation, and it can be run in preview mode or as an immediate sign. It does not detail consequences of a real sign or confirmation flow, but the annotations carry the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and mode distinction. Every sentence earns its place; the negation about negotiation prevents a likely misuse without adding unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive 13-parameter tool with no output schema and no per-parameter descriptions, this is too thin. It leaves the preview/confirmed workflow, required parameter semantics, return behavior, and side effects unstated. The clear one-line purpose keeps it from being completely unusable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and none of the 13 parameters are explained in the description. The only hint is 'PREVIEW', loosely mapping to the preview boolean, but required fields like workerId, contractType, and role, and important optionals like confirmed, wagePerMonth, and contractLength, remain undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact action ('SIGN a worker'), the target resource ('worker'), and the two modes (preview or immediate). The clause 'does not simulate offer/counter-offer negotiation' distinguishes it from negotiation/advice-type tools among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool for actual signing rather than negotiation, but it never explicitly states when to use it or names an alternative tool for negotiation scenarios. The 'does not simulate' clause provides a negative usage signal only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description doesn't need to restate that. It adds context beyond annotations by revealing the dual preview/create modes, verification behavior, and BETA status. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, front-loaded sentences. 'BETA: PREVIEW OR CREATE' gives immediate context, and each sentence contributes unique information (action, verification, default). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify return values and side effects. It covers the core behavior but omits behavior around 'confirmed' and 'heat', and doesn't state what the tool returns after creation or preview. It's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It explains contractIds ('at least two active contracts'), leaderContractId ('optional leader'), and preview ('Defaults to preview'), but leaves 'heat' and 'confirmed' completely unexplained. This is insufficient for a 6-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'PREVIEW OR CREATE' a player-company stable, with precise constraints (at least two active contracts, optional leader). This differentiates it from siblings like pws_get_stables or pws_dissolve_stable, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (create or preview a stable) and notes the default preview behavior, but it does not explicitly state when to choose this over alternatives, nor does it provide exclusions or prerequisites. The guidance is present but implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds the dual behavior of listing all tables or describing a single table's columns. However, it does not explain includeSql behavior or output format, so the added context beyond annotations is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and no unnecessary words. The structure is exemplary for a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Core behavior (list vs. describe columns based on table param) and the relationship to pws_query are covered. However, includeSql semantics and return value format are not described, leaving noticeable gaps for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 'table' with a description, but 'includeSql' lacks schema description. The description clarifies that 'table' selects a specific table for column details, but entirely ignores 'includeSql', leaving a significant parameter unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'List' and 'describe' with a clear resource (PWS database tables/views/columns). It also distinguishes the tool from the sibling pws_query by positioning it as a preliminary step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this before a custom pws_query,' giving a clear when-to-use directive. It does not list alternatives or exclusions, but the context is sufficient for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds context: 'BETA' signals instability, 'VERIFIES deletion' indicates the tool confirms the action, and 'Defaults to preview' explains a safer default behavior. This goes beyond annotation basics, though it does not detail irreversible consequences beyond 'permanently dissolve.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the core action and key qualifiers (preview, permanent, verifies, default). No redundant words; every part contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavior but omits important context: it does not explain what a preview returns, how 'verified deletion' is reported, or the precise roles of preview and confirmed. With no output schema, these gaps are noticeable, though the tool is relatively simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only mentions 'Defaults to preview,' which gives minimal meaning to the preview boolean, but leaves stableId and confirmed unexplained. The interaction between preview and confirmed is ambiguous, making the parameter semantics insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'PREVIEW OR PERMANENTLY DISSOLVE a player-company stable.' This clearly distinguishes it from sibling tools like pws_create_stable (creation) and pws_get_stables (listing), leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a stable needs to be dissolved, and no sibling tool covers this operation. However, it lacks explicit guidance on choosing between preview and permanent modes, and does not mention alternatives or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so no safety disclaimer is needed. The description adds scope behavior (only active and retired championships) and content details (rules and champions), which is useful beyond annotations. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence that front-loads the action and resource and then adds relevant details. No filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list operation with no output schema, this description is sufficient: it states the object type, filtering scope, and the meaningful fields returned. There are no missing parameters, side effects, or prerequisites to disclose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so there are no parameters whose semantics need explanation. The description appropriately avoids inventing parameters; the 0-parameter baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies a clear resource ('player-company championships') with scope ('active and retired') and included data ('rules and champions'). It is unambiguous against most siblings, though it does not explicitly distinguish itself from pws_get_titles, which could be a related concept in wrestling context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over alternatives such as pws_get_titles, pws_save_championship, or pws_award_championship. The description only states what the tool returns, leaving the agent to infer usage context from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the 'active' filter but doesn't mention return format, ordering, or edge cases. With good annotations, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It front-loads the verb and resource, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only list tool, the description covers scope ('all active') and target ('worker'). It doesn't detail return fields, but given the simple semantics and no output schema, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for workerId (0% coverage), but the parameter name and the tool description ('for a worker') establish its role. No additional format or source detail is given beyond the name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and a clear resource 'all active contracts for a worker,' distinguishing it from sibling tools like pws_get_worker (worker details) and pws_get_roster.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need a worker's contracts, but it offers no explicit guidance on when to use this tool versus alternatives, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to repeat safety traits. It adds minimal behavioral context beyond mentioning data fields (requirements, preferred disposition). There is no mention of pagination, default limits, or search behavior, but for a simple read-only tool this is acceptable. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates purpose and usage context, earning every character.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (3 optional parameters, no output schema, strong annotations), the description covers the essential purpose and usage context. It hints at returned data (gimmicks, requirements, disposition) and timing, making it sufficiently complete. It could mention that all parameters are optional, but that is already evident from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters. It mentions 'preferred disposition,' which maps to the 'disposition' parameter, but does not clarify 'limit' or 'search.' The parameter names are somewhat self-explanatory, but the description offers minimal added meaning over the schema, leaving the agent to infer how to use the filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Browse PWS gimmicks, requirements, and preferred disposition.' The verb 'browse' is specific and the resource (gimmicks) is distinct from sibling tools like pws_get_roster or pws_get_worker. It also hints at specific attributes (requirements, disposition) that make its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before assigning one to a contract' provides a clear usage context, implying this tool should be used prior to pws_set_contract_gimmick. It does not explicitly name alternatives or exclusions, but the temporal guidance is sufficient to differentiate from other getters and setters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds contextual behavior by listing the returned fields (gimmick, mask, picture, etc.) and explaining the effect of contractId, going beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action and resource. Every word earns its place, including the beta flag and the conditional contractId behavior, with no padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 optional parameters and no output schema. The description explains the main returned data and the contractId condition, but doesn't cover parameter behaviors (limit, search, workerId filtering) or the output structure beyond the listed fields. Given the complexity, there are notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It explicitly explains the contractId behavior ('also returns the active contracted identity') but remains silent on limit, search, and workerId semantics, though these are partially self-explanatory. The description doesn't fully compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Browse' with a clear resource 'worker's native PWS alter egos/personas' and enumerates included attributes. It distinguishes itself from siblings by noting the 'native' scope and the conditional 'active contracted identity' with contractId, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than explicit; the description states what the tool does but doesn't provide when-to-use or when-not-to-use guidance, nor does it mention alternative sibling tools. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint=true and idempotentHint=true, so the safe nature is covered. The description adds value by specifying what data is returned (card, participants, results, ratings, location, runtime), which is not available from the schema or annotations. It does not discuss edge cases, but for a read-only getter 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence, front-loaded with the core action 'Get any show' and followed by a concise list of returned data. Every word contributes meaning with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a simple one-parameter schema and read-only annotations, the description covers the main purpose and enumerates the key return fields. There is no output schema, but the list of returned content helps fill the gap. It does not address pagination or error behavior, but for a get-by-ID tool this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description has 0% schema description coverage and does not explicitly mention the showId parameter. It says 'any show' which implies an identifier but does not clarify the parameter's role or constraints. This fails to compensate for the lack of schema descriptions, leaving the agent to infer from the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a specific show, enumerating the comprehensive data returned (complete card, participants, results, ratings, location, runtime). This distinct verb+resource pairing differentiates it from sibling tools like pws_get_upcoming_shows or pws_get_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied by the name and description: retrieve a particular show by its ID. However, there is no explicit guidance about when to choose this tool over alternatives, nor any exclusion like 'for lists use pws_get_upcoming_shows'. The description does not mention or contrast siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description need not repeat those. It adds no further behavioral details such as pagination, return format, or rate limits, but it is consistent with 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no wasted words, front-loading the verb and resource while adding a useful contextual phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 optional parameters and no output schema, so the description is the only guidance. It provides a high-level purpose but lacks parameter-level details and return value expectations, making it adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It maps broad filter categories (name, geography, type, capacity) to most params, including search, region/country/continent, type, and min/maxCapacity, but omits limit and gives no value formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool browses venues using specific filter dimensions (name, geography, type, capacity) and situates it in a workflow ('before assigning one to a show'), clearly distinguishing it from other get tools and search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before assigning one to a show' implies a clear use case and ties to a follow-up action (likely pws_set_show_venue). However, it does not explicitly name alternatives or exclusion criteria, so it stops at clear context rather than full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavior beyond the destructiveHint=true annotation: it preserves experience, defaults to the established name, and can be run as a preview. It does not contradict the annotation, and the extra context helps an agent understand side-effect mitigation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence with no filler. Key action words are front-loaded, and the statement earns its place by conveying scope, persistence, and naming behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has five inputs, no output schema, and no parameter descriptions, yet the description leaves the preview/confirmed workflow implicit. An agent cannot reliably know whether to set preview=false, confirmed=true, or both to perform the actual registration. The description is too thin for the operational complexity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining parameters, but it only indirectly hints at tagId and name. It does not explain the roles of active, preview, or confirmed, especially the preview-to-confirm flow, which is critical for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (register/preview), a specific resource (an existing global tag team), and the key behavioral constraints (with the player company, preserving experience, defaulting name). This distinguishes it from sibling tools like pws_create_tag_team, which would be for creating a new team.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear it operates on an existing global tag team and registers it with the player company, which gives solid context for when to use it. It does not explicitly name alternatives or list exclusion cases, but the 'existing global tag team' phrasing effectively rules out creation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds key context: it defaults to preview, supports both preview and set modes, and verifies persistence. This helps the agent understand side effects and safety posture. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The BETA warning and action verb are front-loaded, and the description is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, 0% schema coverage, and no output schema, the description provides some useful context (active contract, preview default, persistence verification) but omits details about the 'confirmed' parameter and what exactly is returned after preview vs. set. It is minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden. It explains the gimmick and contractId implicitly, and the preview default, but leaves the 'confirmed' parameter entirely unexplained. The preview-or-set semantics add value, but incomplete parameter documentation prevents a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (PREVIEW OR SET) and resource (gimmick on an active player-company contract). It distinguishes from sibling pws_set_contract_persona by specifying the field being modified, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (for setting/previewing contract gimmicks) and notes the 'active contract' qualifier, but it does not explicitly mention alternatives or provide when-not-to-use guidance. Compared to examples like 'use search_calls_extensive instead', this lacks explicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, and the description adds valuable context: the global worker identity is never renamed, supplied fields override defaults, and exact restoration is possible via preview before-state. However, it doesn't explicitly warn that a confirmed switch permanently changes the contract presentation or describe any irreversible aspects, so it only partially enhances the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with 'BETA' and the core action, with no wasted words. It packs relevant nuance about overrides, restoration, and the global identity into a compact structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, destructive effect, no output schema), the description covers purpose and key behaviors but misses the confirmation flow (how to actually commit the switch) and does not mention expected return values or prerequisites. It's adequate for a preview, but not fully complete for executing a destructive change.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description partially compensates by explaining name ('custom ring name'), gimmick, picture, mask, and preview ('Defaults to preview'). However, it leaves 'confirmed' and 'personaId' semantics under-specified, and these are central to actually performing a switch versus a preview.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'PREVIEW OR SWITCH an active worker's contract identity to a native PWS alter ego.' It specifies the resource (active worker's contract identity), the operation, and the scope, which distinguishes it from sibling tools like pws_set_contract_gimmick or pws_set_persona_availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'PREVIEW OR SWITCH' and 'Defaults to preview,' but it does not explicitly state when to prefer this tool over alternatives or when not to use it. It also doesn't explain the relationship between 'preview' and 'confirmed' as a workflow, leaving the when-to-use guidance incomplete for a destructive action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond annotations: 'PREVIEW OR ADD' and 'Defaults to preview' clarify that the tool may act destructively only when explicitly used to add, while 'Verifies membership' reveals a validation step. No contradiction exists with the destructiveHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with 'BETA: PREVIEW OR ADD' and includes only essential details like membership verification and default preview. Every sentence contributes value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core purpose and preview default but omits important context: what 'confirmed' does, what the preview output looks like, prerequisites, and post-add effects. Without an output schema, these gaps matter for a mutation-capable tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'preview' and 'leader' indirectly, but does not clarify the 'confirmed' parameter or provide explicit meaning for stableId and contractId beyond their names. This is insufficient for a 5-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'PREVIEW OR ADD an active player-company contract to a stable, optionally as a leader,' identifying the action and target resource. It distinguishes this tool from siblings like pws_remove_stable_worker and pws_get_stables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives implicit context via 'Verifies membership. Defaults to preview.' but does not explicitly state when to use this tool over alternatives or when not to use it. It suggests a safe preview default but lacks clear exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint. The description adds value by specifying the concrete audit categories, giving the agent an idea of what behaviors to expect. It doesn't describe return format, but given annotations, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no fluff, front-loaded with the action 'Audit a player-company show' and then lists specific checks. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only audit with one parameter and rich annotations, the description is largely complete. It lacks return format details, but the listed checks imply what the output covers. No critical information is missing for calling it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the single parameter showId is self-explanatory from its name and type (integer, minimum 1). The description does not add further semantics, but none are necessary for this simple parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'audit', the resource 'player-company show', and enumerates specific checks (empty cards, invalid winners, title-match risks, repeated workers, runtime readiness). This distinguishes it from generic show tools and provides a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are mentioned. The description implies usage for validating a show, but does not compare to related tools like pws_validate_show_plan or explain when this audit is appropriate versus other show-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds a list of returned content categories but does not disclose additional behavioral traits such as response size, pagination, or any prerequisites. With annotations covering the safety profile, the description is consistent but does not add significant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists all key segments without wasted words. Every element adds value, and the sentence structure is clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides a comprehensive list of what the dashboard contains (size, money, finance history, roster balance/payroll, availability, shows, titles, storylines, alerts). This is adequate for an agent to understand the tool's scope, though it could explicitly state that it returns a single aggregated snapshot.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description needs no parameter explanation, and the empty schema provides complete coverage. The absence of parameters is consistent with the description's 'Get a management dashboard' framing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('management dashboard for the player company'), followed by an explicit list of included components (size, money, finance history, roster balance/payroll, availability, shows, titles, storylines, alerts). This clearly distinguishes it from sibling tools that focus on individual aspects like roster, shows, or titles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a broad overview use case, but it does not explicitly state when to prefer this over specific sibling tools (e.g., 'use this for a consolidated view instead of fetching each detail separately'). No exclusions or alternative guidance is provided, making usage guidance only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing the safety profile. The description adds behavioral insight beyond the annotations: it specifies the exact audit logic (requires two storyline members) and the intended action ('flag likely missing... attribution'). This is useful context, though it doesn't elaborate on output format or what 'flag' concretely entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence with no redundancy. Every phrase adds necessary detail—the resource, the criterion, and the outcome—while remaining readable and front-loaded with the verb. It wastes no words and is appropriately compact for the tool's moderate complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain the return value; it only implies via 'flag' that some list of flagged segments is returned, without describing format or content. The 'limit' parameter is also unaddressed, and the meaning of 'recent completed' is unspecified. Given the moderate complexity, the description is adequate but leaves notable gaps a user would need to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the single 'limit' parameter is not mentioned in the description at all. The schema provides type, default, min, and max, which helps, but the description must compensate for the low coverage by explaining what the limit applies to—it does not. The parameter name 'limit' is somewhat self-explanatory, but the tool's behavior (limiting the number of segments audited) is only inferable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Audit') and a precise resource ('recent completed player-company segments'), then adds clear criteria (contained at least two members of an active or ended storyline) and the deliberate outcome (flag likely missing storyline-history attribution). This fully distinguishes it from all sibling tools, none of which perform this diagnostic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys a clear context: an audit tool for identifying potential attribution gaps in completed segments. It implicitly tells the agent when to invoke it (when investigating storyline-history attribution issues) and the specific criteria involved, but it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds the list of returned data but discloses no extra behavioral traits such as internal multi-query behavior, rate limits, or prerequisites. With annotations covering safety, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence starting with the action ('Get everything needed'), followed by a concise itemized list. No redundant wording, every element adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining return content. It lists all major components (existing card, eligible roster, titles, storylines, recent matches, runtime, company preferences), giving a solid overview. It could specify structure or format, but the list is sufficiently complete for an agent to understand what will be retrieved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter showId is fully described in the schema with 'Defaults to the next unfinished show,' giving 100% schema description coverage. The tool description does not add parameter-level details, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'Get everything needed to book a show intelligently.' It also lists the components (existing card, roster, titles, etc.), distinguishing it from sibling tools that fetch individual pieces like pws_get_roster or pws_get_titles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context for using this tool is clear: it's for booking a show, providing all necessary context. However, it doesn't explicitly mention when not to use it or name alternatives (e.g., using individual retrieval tools) for more focused queries. No misleading guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the specific output scope (brands and default commentary teams) but does not disclose additional behavioral details such as pagination, ordering, or whether inactive brands are included. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and the primary output without any filler. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only list tool, the description adequately conveys the core purpose. The lack of an output schema is partially mitigated because the description names what is returned, though it does not detail the output structure. Still, given the simplicity of the operation, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are trivially satisfied. The schema description coverage is 100%, and the description correctly focuses on what the tool returns rather than input fields. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the resource ('player-company brands and default commentary teams'). It clearly distinguishes itself from other sibling tools like pws_save_brand or pws_assign_worker_brand by focusing on retrieval of brand/commentary data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for listing brands and their default commentary teams, but it does not explicitly state when to use it versus alternatives or mention any exclusions. Since there is no direct get_brands sibling, the lack of explicit routing is still acceptable but leaves guidance implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds value by disclosing the scope ('active and archived') and the content returned ('recurrence, defaults, and show counts'), which is meaningful behavioral context for a no-parameter read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one tight, front-loaded sentence that states the action, scope, and expected result fields without any filler. Every word contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only list tool with a small resource scope, the description is nearly complete. It lacks an explicit note about the output shape or ordering, but the stated fields and the absence of parameters make the behavior understandable without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100% and there is no parameter ambiguity to resolve. The description appropriately omits parameter details because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('List') and resource ('player-company event series'), and narrows scope with 'active and archived' plus the returned aspects ('recurrence, defaults, and show counts'). This clearly differentiates it from sibling tools like pws_get_upcoming_shows or pws_get_show, which target individual upcoming shows rather than event series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description implies a read-only listing context, but it does not mention exclusions, prerequisites, or sibling tools such as pws_get_upcoming_shows or pws_set_event_active, leaving the agent to infer the appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description adds value by reinforcing the 'dry-run' nature and the explicit guarantee 'This never changes the save.' It also reveals that the tool uses roster ranking, alignment, and other factors, giving a sense of what the agent can expect. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. Every word earns its place: the first sentence states what the tool does, and the second provides a critical safety guarantee. Well-structured and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (9 optional parameters, no output schema), and while it mentions the core purpose, it does not describe the return format or what a 'card' contains beyond the listed factors. The annotations help clarify safety, and the description gives enough to understand the core action, but given the lack of an output schema and the breadth of options, more guidance on expected output or parameter relationships would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is very low (11%), with 9 parameters and none described in detail. The description mentions high-level concepts like 'roster ranking' and 'runtime' but does not map them to specific parameters such as showId, minutes, matchCount, or avoidContractIds. The description fails to compensate for the lack of schema-level parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Generate') and resource ('complete dry-run card'), and lists the inputs considered. It distinguishes itself from siblings by explicitly noting this is a dry-run that never changes the save, setting it apart from apply_show_plan and validate_show_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: for generating a dry-run plan without modifying anything. It does not explicitly name alternatives, but the 'never changes the save' clause strongly signals that this is for previewing, not finalizing, and sibling names like apply_show_plan reinforce that. Clear context but no explicit 'use this instead of X' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true, but the description adds valuable behavioral context: it 'Validates the venue and verifies persistence' and 'Defaults to preview'—implying the default mode is non-destructive. It does not, however, explain the role of the 'confirmed' parameter in the actual mutation, which keeps it from being fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loaded with the primary action, and each sentence adds unique information: what it does, validation/persistence, and default behavior. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 preview default, but omits the semantics of the 'confirmed' parameter, any indication of return values, and the side effects of actually setting the venue. Given there is no output schema, these are meaningful gaps for an agent using the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0% and 5 parameters, the description must compensate, but it only explains the preview default and the event-default option. It leaves 'confirmed' completely unexplained and gives no additional meaning for 'showId' and 'venueId' beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'PREVIEW OR SET the venue for an unfinished player-company show'. The verb 'SET' and resource 'venue' are specific, and the context 'unfinished player-company show' distinguishes it from sibling tools like pws_schedule_show or pws_create_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context ('for an unfinished player-company show') and notes an optional mode ('optionally making it the recurring event series default'). However, it does not explicitly mention when not to use this tool or name alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool readOnly and idempotent, and the description reinforces this with 'without changing the save'. It also adds what is validated: live show, roster availability, duplicates, and runtime, which is valuable beyond the annotations. It does not describe how validation failures are returned, but this is a minor gap given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the action and states scope and side-effect behavior with no waste. Every phrase carries meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a complex segments schema and no output schema, the description covers the core validation intent but leaves out what a successful or failed validation returns and does not explain the optional parameters' effect on validation. It is adequate but not fully complete for an agent to anticipate tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not clarify the meaning of showId, segments, allowOverrun, or allowMultipleMatches. The schema provides names and types, but the description fails to compensate for the lack of parameter descriptions, leaving important semantics like allowOverrun and allowMultipleMatches ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (Validate) and resource (proposed show card) and lists the exact validation dimensions: live show, roster availability, duplicates, runtime. It also states the key differentiator 'without changing the save', so an agent can distinguish it from persistence tools like pws_apply_show_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies a pre-persistence validation step by saying 'without changing the save'. This gives context on when to use it. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to avoid calling persistence tools instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=false and destructiveHint=true, but the description adds useful context beyond that: 'BETA' warns of instability, 'Defaults to preview' signals the non-destructive default, and 'does not schedule an instance' clarifies the tool's limited scope. This exceeds the minimal information from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the primary purpose. Every sentence carries essential information with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters and no output schema, the description is too sparse. It fails to explain how parameters relate to preview/create behavior, what the response contains, or how recurrence settings work. It only covers the high-level workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate for the 10 parameters. It only mentions the 'preview' default, which is already in the schema. No meaning is added for important parameters like recurrenceType, importance, or eventLength.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'PREVIEW OR CREATE a player-company event series through PWS.' It distinguishes from scheduling by explicitly noting that this does not schedule an instance and that pws_schedule_show should be used afterward. The verb 'create' and resource 'event series' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: it says 'use pws_schedule_show afterward' and states 'Defaults to preview.' This tells the agent when to use this tool versus the sibling pws_schedule_show, and indicates the default safe behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description adds valuable behavioral context: 'Defaults to preview' clarifies that the tool is not destructive by default, and 'Verifies that it became inactive' explains that the tool checks the outcome. This goes beyond what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the core action ('PREVIEW OR END'). Every clause adds value, with no filler or repetition. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the main action, default behavior, and verification, it omits the 'confirmed' parameter semantics and does not describe the return value or response format. With no output schema, this leaves gaps for an agent to understand what to expect when actually ending a storyline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the preview behavior and its default ('Defaults to preview'), which maps to the 'preview' parameter. However, it does not explain the 'confirmed' parameter, which is crucial for actually ending a storyline (likely a safety confirmation). Thus, it partially compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'PREVIEW OR END an active player-company storyline.' It uses a specific verb ('end') and resource ('storyline'), and the preview mode is highlighted. This distinguishes it from sibling tools like pws_get_storylines or pws_diagnose_storyline_attribution, which are read-only or diagnostic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying 'active player-company storyline', indicating this tool is intended for active storylines that need to be ended or previewed for ending. It does not explicitly mention alternatives or when not to use it, but the purpose is unique among siblings, making the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context such as response format or pagination, which is acceptable for this simple no-parameter read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states exactly what the tool does without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only getter with no output schema, this description is sufficiently complete. The resource name and scoping phrase ('for this plugin') provide all necessary context for an agent to understand the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description cannot add parameter details. Per the guidelines, a baseline of 4 is appropriate when there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('PWS action audit log') and scopes it to 'this plugin.' This distinguishes it clearly from sibling tools like pws_get_state or pws_search, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need the audit log, but it provides no explicit context, alternatives, or exclusions. It does not guide the agent on when this tool is preferred over sibling tools like pws_search or pws_get_state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds concrete scope about what is listed, but does not describe additional behavioral details such as rate limits, data freshness, or output size. This is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and resource. Every phrase earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with complete annotations, the description covers all the essential information an agent needs: what is listed, the scope, and the intended use case. No output schema exists, but the listed data categories provide sufficient context for calling the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so the schema fully defines the input contract. With 0 params, the baseline is 4, and the description appropriately focuses on what the tool returns rather than parameter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource (networks, regional availability, current television/network deals) and a stated purpose ('for negotiation analysis'). It clearly differentiates from the action-oriented sibling pws_cancel_network_deal by being a read-only listing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for negotiation analysis' implies this tool should be used when preparing for television/network deal negotiations, but it does not explicitly state when to use it versus alternatives or when not to use it. The usage context is implied rather than directly specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read operation. The description adds behavioral context by specifying the filtering criteria ('upcoming', 'unfinished') and the included fields ('duration and booking progress'), which is useful beyond what annotations provide. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that is front-loaded with the action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with annotations and a minimal schema, the description covers the key aspects: what is listed, for whom, and what is included in the result. The absence of an output schema is mitigated by mentioning the output fields. However, it could be more explicit about the limit parameter's effect, which still appears only in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (limit) with well-defined constraints, but the description does not mention or explain it. Since schema description coverage is 0%, the description should have compensated, but it does not, leaving the agent to infer the parameter's role from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('upcoming unfinished shows') and context ('for the player promotion'), and mentions output attributes ('duration and booking progress'). This distinguishes it from sibling tools like pws_get_show which retrieves a single show.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is for listing upcoming unfinished shows in the player promotion, implying use when you need an overview. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true; the description adds context about global effect and preview default. However, it doesn't explain the confirmed flag or what preview returns, which would be useful for behavioral transparency beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded and concise, with no redundancy. Each sentence adds essential information, and the BETA warning is useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no output schema, the description discloses global impact but omits confirmation workflow and expected result. The 'BETA' warning is present, but the agent may lack understanding of how to execute actual changes or read preview results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20%, so the description carries the burden. It explains availability enum and promotionId use for specific-promotion, but leaves personaId and confirmed semantics unexplained. 'Defaults to preview' partially covers preview parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool previews or changes a persona's availability, with specific scope (global within save) and differentiates from contract-level changes by saying 'not merely one contract'. The verb 'PREVIEW OR CHANGE' plus resource 'native alter ego definition' is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies use for global persona availability changes and distinguishes from contract-specific tools like pws_set_contract_persona. However, it lacks explicit when-not/alternatives guidance. 'Defaults to preview' suggests a preview-first workflow but doesn't say when to actually confirm.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly and idempotent hints, so the description adds value by disclosing that it lists only active storylines and that lean=true reduces output to heat/status. This provides useful behavioral context beyond the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the main purpose and then efficiently adds parameter guidance. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and param descriptions, the description effectively conveys the main purpose, the filterable storyline, and the lean option. However, it does not explicitly state whether promotionId is required or what the response structure contains beyond participants, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains 'filter one storyline' (storylineId) and 'lean=true' (lean), but does not explicitly describe promotionId, which is implied by 'for a promotion' but not fully specified. This partial coverage earns a mid score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists active storylines and participants for a promotion, with a specific verb and resource. It also distinguishes itself by mentioning filtering and lean mode, making its purpose unambiguous even among many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on what the tool does (lists active storylines for a promotion) and how to use parameters (filter one storyline, lean=true). It does not explicitly mention alternatives or when not to use this tool, but the context is strong enough for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only flag destructiveHint=true, but the description adds crucial nuance: the default is preview (non-destructive) and the operation 'verifies removal.' This goes beyond the annotation by clarifying the dual-mode nature and safe default, making it a notable behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short sentences with no wasted words. It front-loads the core purpose and immediately highlights the default behavior, which is exactly what an agent needs for a quick assessment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary purpose and preview default, but it omits details about the 'confirmed' parameter, the return value, and the behavior when minimum stable membership cannot be preserved. Given the tool's destructive potential and complexity, this is a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description bears the full burden of explaining parameters. It hints at the 'preview' parameter via 'Defaults to preview' but completely ignores 'stableId', 'contractId', and 'confirmed'—leaving the agent without a clear understanding of how to execute the actual removal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool can preview or remove a worker from a stable while preserving a minimum stable membership. It uses a specific verb ('remove') and resource ('stable worker'), and the mention of 'preview' distinguishes it from other mutation tools like pws_add_stable_worker.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for removing a stable worker while maintaining minimum membership, and it defaults to preview, implying a safe exploratory use. However, it does not explicitly contrast with alternatives such as pws_release_worker or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by detailing the atomic side effects: 'Atomically updates the promise, decision email, and native PWS relationship consequence, then verifies all three.' This provides critical behavioral insight not available in the annotations (which only mark destructiveHint=true). The preview default is also a behavioral nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and preview default. Every sentence adds value; there is no fluff or repetition of schema fields. The structure clearly separates the action from the atomic side-effect explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the atomic write behavior and preview default, but it does not describe the output/return value, which is relevant given there is no output schema. It also lacks details about the confirmed parameter and when to use preview vs. a confirmed action. Overall it is adequate but has clear gaps for a destructive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate for parameter meaning. It does explain 'accept/decline' for the decision parameter and 'Defaults to preview' for the preview parameter, but it does not clarify the confirmed parameter (likely a confirmation flag) or the promiseId semantics beyond what the schema implies. Missing confirmed is a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: to preview or accept/decline a pending player-company worker promise request. It uses specific action verbs ('accept/decline') and names the resource ('promise request'), distinguishing it from read-only siblings like pws_get_promises. 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Defaults to preview' which implies a workflow of previewing before confirming, and it names the context ('pending player-company worker promise request'). It does not explicitly list when not to use it or name alternative tools, but the context is clear and sufficient for an agent to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive, but the description adds valuable context: it verifies that all current champion slots were cleared and defaults to preview mode, providing a safety mechanism. This goes beyond the simple destructiveHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with the key action ('PREVIEW OR VACATE') front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, preview default, and verification behavior, and the annotations provide safety context. However, it does not explicitly state how to confirm the action (e.g., setting preview=false or confirmed=true), which is a notable gap for a destructive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that the preview parameter defaults to true, which is helpful. However, it does not explain the required titleId, the confirmed flag for actual execution, or the reason parameter, leaving significant gaps in parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it can preview or actually vacate a player-company championship. It uses a specific verb ('vacate') and identifies the resource ('player-company championship'), distinguishing it from read-only sibling tools like pws_get_titles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates that the tool defaults to preview, suggesting a safe workflow where the user should preview before executing a vacation. However, it does not explicitly mention alternatives or when not to use this tool, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds value by enumerating the specific data fields returned, which goes beyond the annotations and clarifies the tool's scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence lists all returned data without filler. Every phrase adds information, and it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only getter with strong annotations, the description fully covers the returned values. No return format or error cases are necessary given the annotations and the tool's straightforward nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. The description does not need to explain parameters, and the baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and enumerates exactly what state is returned (loaded save, current date, player promotion, PWS popularity-derived size, continental popularity, cash, home market). This clearly distinguishes it from sibling tools that target specific entities like roster, worker, or shows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. However, the description implies this is the general state getter for the game, and siblings are more specific, so the intended use is reasonably inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite destructiveHint=true in annotations, description adds crucial behavioral context: archiving is reversible, retains completed/cancelled show history, is blocked under specific conditions, and defaults to preview. This goes beyond the annotation and helps the agent understand the risk and preconditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and BETA warning, and each sentence conveys essential usage and constraint information without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers the key behavioral constraints and preview default, but with no output schema it leaves some ambiguity about what preview/confirmation returns or requires. However, it is adequate for understanding the tool's core function and preconditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; description only explains the preview parameter ('Defaults to preview') but does not explain active (true=restore, false=archive) or confirmed semantics. With low schema coverage, this is insufficient parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear action (archive/restore with preview option) on a specific resource ('player-company event series'), distinguishing it from sibling tools like pws_create_event or pws_cancel_show. It also clarifies preview mode and the reversible, conditional nature of archiving.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: defaults to preview, archiving is reversible and blocked while an unfinished non-cancelled show exists. Does not explicitly name alternatives or exclusions, but among siblings this is the only event-series archive/restore tool, making usage context reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds value by specifying that the tool returns both stables and their members, and that stableId scopes the result. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. It states the action, resource, and optional filter in an efficient manner, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description provides enough context for an agent to invoke it correctly. It could mention that omitting stableId returns all stables, but this is reasonably implied by 'List player-company stables' and the optional filter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a parameter name and type (stableId integer, minimum 1) with no description, leaving 0% schema coverage. The description compensates by clarifying that stableId is an optional filter, which is the key semantic needed to use the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('player-company stables and their members'), which distinguishes it from sibling tools like pws_get_roster (likely worker roster) and pws_get_worker. It also notes an optional filter by stable ID, further clarifying scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'or filter by stable ID' gives a clear usage context for the parameter, and the resource focus on stables implies when this tool is relevant versus worker-specific tools. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, non-destructive behavior. The description adds meaningful scoping context beyond those annotations: the result deliberately includes unregistered global teams whose contracted members make them eligible, not just currently registered teams. This is a non-obvious inclusion behavior that helps an agent predict results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-front-loaded sentence with no filler. The primary subject ('registered player-company tag teams') comes first, and the secondary inclusion criterion is expressed in one dependent clause without redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list tool, the description sufficiently defines what will be returned and which entities are included. There is no output schema, so exact field-level return details are absent, but the tool's simplicity and the description's clear scoping make it adequately complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4; there is no parameter semantics for the description to clarify or supplement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly defines the resource: registered player-company tag teams plus established global teams with contracted members that are not yet registered. It distinguishes this read operation from sibling mutation tools like pws_create_tag_team, pws_register_tag_team, and pws_dissolve_tag_team without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes the tool's intended use: retrieving the current set of relevant tag teams, including both registered company teams and eligible unregistered global teams. It does not explicitly name alternative tools or state when not to use it, but the narrow scope and read-only nature make the appropriate context obvious among the listed siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations by noting that the tool reports loaded-save state and does not fail when no save is loaded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences and wastes no words. The primary purpose is front-loaded, and the second sentence efficiently enumerates the reported fields without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only diagnostic tool with annotations covering the safety profile, the description is complete. It explains what will be reported and the key edge case (no save loaded), which is sufficient for an agent to invoke and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there are no parameter semantics to document. The description correctly focuses on behavior and output rather than parameters, meeting the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Diagnose') and resource ('MCP connection and version pair'). It further enumerates the exact data reported — client and in-game plugin versions, transport, and loaded-save state — making it easy to distinguish from sibling tools like pws_get_state or pws_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the appropriate use case: diagnose or check the MCP connection and version compatibility. It clearly identifies what the tool is for, though it does not explicitly name alternatives or specify 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, which the description aligns with. Beyond that, it adds a useful behavioral detail: the tool defaults to the player promotion when no promotionId is supplied. This context is not available from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the action and object, with no filler. Every word contributes meaning, and the default behavior is stated compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with a single optional parameter and no output schema, the description fully covers what is returned (active championships and current champions), the scope (promotion), and the default behavior. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must explain the promotionId parameter. It does so by indicating that the tool operates 'for a promotion' and that it defaults to the player promotion, clarifying that the parameter is optional and controls the promotion context. This compensates well for the schema's lack of description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('active championships and current champions') and scope ('for a promotion'). This distinguishes it from sibling tools like get_roster or get_worker_contracts, leaving no ambiguity about what it returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the default behavior ('defaults to the player promotion') and implies the promotionId parameter overrides this default. It provides clear context for when to use the tool, though it does not explicitly 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only declare destructiveHint=true and readOnlyHint=false, but the description adds substantial operational context beyond that: it preserves unrelatted fields (partial update), validates the live show, writes transactionally, verifies the saved segment after writing, and gates mutation behind a preview=false+confirmed=true requirement. These are meaningful behavioral facts an agent needs to call the tool safely, and none 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense, front-loaded sentence that states the core purpose first, then packs five behavioral guarantees into compact clauses. Every clause earns its place: preservation, validation, transactionality, verification, and the confirmation gate. No fluff or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, nested-schema tool with no output schema, the description covers the essential operational aspects: what it mutates, how partial updates behave, the validation/write/verification pipeline, and the safety gate. It does not describe return values or error behavior (e.g., what happens when validation fails), which would have been valuable given there is no output schema. Still, the core calling contract is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% — preview and confirmed have descriptions, but segmentId and changes do not. The description compensates by clarifying the critical parameter relationship ('requires preview=false plus confirmed=true to mutate') and the partial-update semantics of the changes object ('Preserves unelated fields'). The many sub-fields inside changes rely on the schema's type/constraint info, which is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb pair ('PREVIEW OR UPDATE') and a specific resource ('ONE EXISTING MATCH/ANGLE'), making the tool's scope immediately clear. It distinguishes itself from siblings like pws_remove_segment (deletion) and the many pws_get_* read tools. The 'ONE EXISTING' qualifier also disambiguates it from creation tools like pws_create_event or pws_apply_show_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear workflow context: preview first, then mutate only with preview=false plus confirmed=true. It also implies partial-update usage via 'Preserves unelated fields' — send only the fields you want changed. However, it does not explicitly name alternative tools or state when not to use this tool versus siblings like pws_remove_segment or pws_get_state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![pws-mcp-server MCP server](https://glama.ai/mcp/servers/Distortik/pws-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Distortik/pws-mcp-server)

Score Badge

Copy to your README.md:

[![pws-mcp-server MCP server](https://glama.ai/mcp/servers/Distortik/pws-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Distortik/pws-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Distortik/pws-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server