good_wook

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct query type: specific date setlists, random/latest showcases, historical calendar lookup, search, song history/stats, jam charts, venue info, and upcoming shows. Even the setlist-returning tools are clearly differentiated by their selection criteria.
Naming Consistency3/5
Tool names are all lowercase snake_case and mostly descriptive, but they mix verb-prefixed names (get_setlist, search_shows) with bare noun phrases (random_show, latest_show, song_history). This inconsistency is noticeable but the meaning is still clear.
Tool Count5/5
11 tools is well within the ideal 3-15 range. Each tool serves a specific fan-facing query need, and there is no bloat or redundancy in the count.
Completeness4/5
The surface covers the core Phish setlist database use cases: specific dates, random/latest, historical day, search, song-level history/stats, jam charts, venue info, and upcoming shows. Minor gaps exist like tour-based filtering or setlist-by-ID, but agents can generally accomplish what they need.
Average 3.2/5 across 11 of 11 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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?
With no annotations, the description carries full burden. It does not explicitly state that the tool is read-only, does not mention the meaning or effect of 'include_related', and provides no details on output behavior or edge cases. The bare noun phrase adds little beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise, but it is under-specified. It lacks an action verb and essential context, crossing from conciseness into minimalism.
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?
An output schema exists, so return values are covered, but the description omits usage guidance, parameter semantics, and clarity on what 'latest' means. This is insufficient for a tool with a parameter and a set of siblings.
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?
The schema has one parameter, include_related, with 0% description coverage. The description does not mention this parameter at all, leaving its semantics completely unexplained.
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 the resource ('most recent show's setlist') and scope ('most recent'), which distinguishes it from siblings like random_show and search_shows. However, it lacks an explicit verb like 'get' or 'retrieve', making it a noun phrase rather than a clear action.
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 provided on when to use this tool versus alternatives such as get_setlist or search_shows. There are no exclusions, prerequisites, or contextual cues for selection.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state that this is a read-only operation, any error conditions, or what the response contains beyond 'setlist', leaving the agent without important 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 concise phrase with no unnecessary words, but it is perhaps too terse to fully convey the tool's behavior and parameters.
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 simplicity of the tool, one sentence covers the core purpose, but it omits the include_related parameter and fails to differentiate from sibling tools, making it incomplete for an agent to use effectively.
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 explains the date format ('YYYY-MM-DD') but makes no mention of the optional 'include_related' boolean parameter, which is left completely unexplained. Since schema coverage is 0%, the description must compensate but only covers one of two 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 identifies the resource (Phish setlist) and the key parameter (date) with format, but lacks an explicit verb; the tool name supplies it. It distinguishes from siblings like random_show and latest_show by specifying 'a given date'.
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 usage for a specific date but offers no guidance on when to use an alternative tool, such as random_show for random shows or search_shows for finding shows by criteria.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the ordering (most recent first) and says nothing about the required 'song' parameter, the effect of 'limit' or 'include_related', or the nature of the output. This is a significant gap for a tool with three parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, but it is under-specified to the point of being a fragment rather than a complete tool description. It is concise but not sufficiently informative for a tool with multiple parameters.
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 tool has three parameters, no annotations, and an output schema, the description is incomplete. It does not explain what data is returned, how to use the parameters, or any constraints. The single clause about ordering is not enough to fully understand the tool's behavior.
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 or explain any of the three parameters. The parameter names are self-descriptive to a degree, but 'include_related' is ambiguous and no compensation is provided by the description.
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 tool as providing a history of song plays, ordered most recent first. Though it lacks an explicit verb like 'retrieve' or 'list', the noun phrase is understandable and distinguishes this from siblings like song_stats or jam_chart.
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 view a song's play history, but gives no explicit guidance on when to use it over alternatives such as song_stats or get_setlist. There are no exclusions or alternative references, so usage context is only implied.
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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only names the stats but doesn't state whether this is a safe read operation, if any side effects exist, or what 'current gap' specifically means. It doesn't mention permissions, reversibility, or behavior beyond the stat names. While the output schema may clarify return values, the description itself adds little 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, efficient sentence with a colon and list. It is extremely concise and front-loaded, with no wasted words or fluff. 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?
Given the tool has a simple 2-parameter schema and output schema exists, the description doesn't need to explain return values, but it should clarify the meaning of the stats (e.g., 'current gap') and the purpose of include_related. It also lacks usage context relative to sibling tools. The description is too sparse to be considered complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 parameters. The 'song' parameter is implied but not detailed, and 'include_related' is completely unexplained. The description mentions stats but not how the parameters affect the output. Since the schema provides only names/types, the description must compensate, and it fails to do so.
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 indicates the tool returns stats for a song, enumerating the specific stats: times played, debut, last played, current gap, jamchart count. This distinguishes it from sibling tools like song_history (which focuses on history) and jam_chart (which focuses on jamcharts). However, the description uses the noun 'Stats' rather than an explicit verb like 'Get' or 'Retrieve', which slightly reduces clarity.
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. For example, it doesn't clarify when to use song_stats instead of song_history or jam_chart, nor does it mention any context or prerequisites. There is no exclusion or alternative guidance, but the lack of any usage direction makes it hard for an agent to decide.
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?
With no annotations, the description must carry the burden of behavioral disclosure. It only mentions the output content and does not disclose side effects, safety profile, input format expectations, or error behavior. This is insufficient for a tool that could be queried with different venue representations.
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 concise sentence that directly states the essence of the tool. No 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?
Despite having an output schema (which reduces the need to document returns), the description lacks parameter explanation, usage guidance, and behavioral context. For a tool with one parameter and no annotations, this is incomplete.
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?
The schema has one parameter 'venue' with zero description coverage. The description does not explain what format 'venue' should take (e.g., name, ID, city). It only describes the output, so the parameter remains ambiguous and 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (venue) and the output (metadata + play count). It distinguishes from sibling tools like get_setlist or song_history because it focuses on venue stats. However, it lacks a specific verb like 'retrieve' or 'get', so it stops 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?
No guidance is provided for when to use this tool versus alternatives. The description only states what the tool returns, with no context about typical use cases, prerequisites, or exclusions from sibling tools.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic search function and does not mention any behavioral traits such as being read-only, how results are ordered, what 'include_related' does, or any other limitations. This is a significant gap for a search tool with hidden complexities.
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 conveys the tool's purpose. It avoids unnecessary detail and every word earns its place, achieving maximum conciseness.
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 tool has five parameters, no required inputs, and an output schema, the description is too sparse. It does not explain the behavior of 'include_related' or 'limit', and the lack of usage guidance leaves the agent without a complete picture. The output schema might clarify return values, but the description fails to cover key parameters and behavioral 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?
The description mentions three of the five parameters (year, city, venue), giving them some semantic meaning as filter criteria. However, it completely omits 'limit' and 'include_related', leaving those parameters unexplained. The schema coverage is 0%, so the description only partially compensates for the lack of 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 ('Find') and resource ('shows'), and specifies the search criteria ('by year, city, and/or venue name'). This distinguishes it from sibling tools like 'random_show' or 'latest_show', which serve different purposes.
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 explicit guidance on when to use this tool versus its alternatives. It does not mention that 'random_show' or 'latest_show' are alternative ways to find shows, nor does it give any context for when a search is appropriate. Without such direction, the agent is left to infer usage entirely.
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?
Without annotations, the description carries the full burden. It discloses the key date-filtering behavior but does not explicitly state read-only nature or other potential side effects. For a simple listing operation, this is adequate but not rich in 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 extremely concise, using just a few words to convey the core function. Every word earns its place, with no unnecessary detail.
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 tool's simplicity and the presence of an output schema, the description covers the main purpose, but it fails to explain the only input parameter. Without schema descriptions, the parameter semantics are a significant gap, making the tool incompletely specified.
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, 'include_related', is not explained in the description at all. With schema description coverage at 0%, the agent has little guidance on what this boolean does, making the description insufficient for 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 tool as listing upcoming shows with a date filter ('dates on or after today'). It distinguishes from siblings like 'latest_show' and 'random_show' by focusing on announced future dates, though it uses a noun phrase rather than an explicit verb.
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 (for future shows) but does not explicitly discuss alternatives or when not to use it. There is no mention of sibling tools like 'search_shows' for more specific queries.
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?
With no annotations provided, the description carries the full burden of disclosing behavior. It merely states what the tool returns ('notable jams'), but does not explain potential side effects, permissions, or any nuances like how 'notable' is determined, whether results are ordered, or how the limit parameter affects output. For a read-only data retrieval tool, this is a significant omission.
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, concise sentence that front-loads the core function. There is no redundant information, and every word contributes to understanding the tool's purpose. It is both efficient and clear.
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 that an output schema exists, the description does not need to explain return values. However, the description is quite minimal and leaves out important context such as what 'notable' means, any limits on the number of jams returned, and whether the tool supports further filtering beyond song. This is sufficient for a simple query but not rich enough for full contextual completeness.
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 descriptions, so the description must compensate. It does clarify that 'song' is an optional filter, but it fails to explain the 'limit' parameter, which is present in the schema with a default of 25. This leaves the agent uncertain about how to use limit or what its effect is. The description adds some meaning but not enough to fully compensate for the 0% 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 tool returns 'Notable jams from the Phish.net jam charts' with an optional filter by song. The verb 'returns' is implied, and the resource is specific (jam charts), making it easy to understand what the tool does. This also distinguishes it from sibling tools like get_setlist or song_stats, which focus on other data types.
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 a hint of when to use the tool (when you want jam chart data) but provides no explicit guidance on when not to use it or how it compares to alternatives like song_history or song_stats. The 'optionally filtered to one song' implies a use case, but there are no exclusions or alternative tool references, leaving usage somewhat 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?
With no annotations provided, the description carries the burden. It reveals that the tool returns a health status and a list of capabilities, but doesn't elaborate on side effects (likely none), authentication requirements, or exact behavioral nuances. This is adequate for a simple ping tool but not rich in 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 a single, front-loaded sentence that states the tool's dual purpose without unnecessary verbosity. Every word earns its place, making it highly concise and well-structured.
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?
Given the tool's simplicity (zero parameters, output schema present), the description is sufficiently complete. It explains what the tool does and the output schema covers return values, so no further elaboration is needed for an agent to select and invoke it 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 there are no semantics to clarify. The description doesn't need to compensate for missing parameter documentation; the baseline of 4 applies since the schema is empty and no parameter guidance is required.
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 tool as a health check and capability manifest. It uses specific terms ('health check', 'manifest') that convey the tool's purpose, though it doesn't explicitly distinguish itself from sibling tools by name.
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. The description doesn't mention any context, prerequisites, or exclusions, leaving the agent to infer usage based on the generic 'health check' label.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions the 'across years' scope but does not state read-only behavior, ordering, pagination, or the effect of the include_related parameter, leaving significant behavioral gaps.
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 redundant information. It conveys the core purpose compactly and efficiently.
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 main output concept but leaves out details about the optional include_related parameter, result ordering, or edge cases. The existence of an output schema mitigates the lack of return format explanation, but the tool is not fully self-contained for nuanced agent usage.
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 adds valuable ranges for month (1-12) and day (1-31) beyond the bare integer schema types, which is helpful. However, it omits the optional include_related boolean entirely. Since schema coverage is 0%, this partial compensation is useful but incomplete.
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 returns every show played on a given month/day across all years. This is specific and distinguishes it from sibling tools like get_setlist (single show) or search_shows (filtered 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 use for historical date-based lookups, and its behavior is distinct from other show-listing tools. However, it does not explicitly mention alternatives or when not to use it, so it lacks formal exclusion 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?
With no annotations, the description is the sole source of behavioral information. It clearly indicates a read operation that returns a random show and its setlist, which is sufficient for a simple query tool. It adds the detail of 'full setlist' beyond the tool name.
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, concise sentence that conveys all essential information without unnecessary words. It is perfectly front-loaded and easy to parse.
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 tool with an output schema, the description is complete. It states what is returned, and the output schema covers the structure of the result. No additional context is necessary.
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 score is 4. The description adds no parameter information, which is appropriate since none exist and the schema footprint is empty.
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 that the tool returns a random Phish show with its full setlist. This identifies the specific resource (Phish show) and the action (random selection), distinguishing it from siblings like get_setlist (specific show) and latest_show (most recent).
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 random show is desired, but it does not explicitly state when to use this tool versus alternatives such as get_setlist or search_shows. No exclusions or alternative guidance is provided.
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:

[![good_wook MCP server](https://glama.ai/mcp/servers/dmpeters/good_wook/badges/card.svg)](https://glama.ai/mcp/servers/dmpeters/good_wook)

Score Badge

Copy to your README.md:

[![good_wook MCP server](https://glama.ai/mcp/servers/dmpeters/good_wook/badges/score.svg)](https://glama.ai/mcp/servers/dmpeters/good_wook)

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/dmpeters/good_wook'

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