Search disc golf discs, compare Speed/Glide/Turn/Fade flight ratings, and find similar alternatives across brands. Free, public, read-only.
Scored across 9 tools
Each tool targets a distinct workflow: disc lookup/search, head-to-head comparison, similarity search, and market/rank analytics. get_weekly_rankings and get_market_movers both surface risers/fallers, but they differ in time window and output focus, so ambiguity is low.
All tools use lowercase snake_case with a clear verb_noun structure such as compare_discs, get_disc, list_brands, and search_discs. The get_ prefix is used consistently across lookup tools, while specialized actions use distinct verbs, creating a predictable pattern.
With 9 tools, the server is well-scoped for its domain. It covers disc reference features and market analytics without unnecessary duplication or missing essential actions.
The server provides a complete read-only surface for disc golf disc data: entity lookup, search, comparison, similarity, flight matrix, brand listing, and market rankings. No obvious dead ends exist in the core query workflows, and write operations are not expected for a public data API.
Compare 2 to 4 discs side-by-side, computing exact flight rating deltas and stability spread relative to the primary baseline disc.
| Name | Required | Description | Default |
|---|---|---|---|
| disc_ids | Yes | Array of 2 to 4 disc IDs or slugs to compare |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It outlines the computation performed (deltas, stability spread) and implies a read-only operation, but does not explicitly state side-effect-free behavior or return format, though that is less critical for a comparison tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It efficiently communicates the core functionality and the key constraint (2 to 4 discs).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description sufficiently covers what the tool does and what it computes. It provides enough context for an agent to decide when to invoke it and what to expect in terms of results (deltas and stability spread).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the disc_ids parameter (array, 2-4 items). The description adds meaningful context by indicating that the primary baseline disc is the first in the array, which is not in the schema. This enhances understanding without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: comparing 2 to 4 discs and computing flight rating deltas and stability spread. This is distinct from the sibling tools (get_disc, search_discs, find_similar_discs), making its role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comparison scenarios but does not explicitly contrast with sibling tools. It does not specify when to prefer this over find_similar_discs or search_discs, leaving 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.
Find alternative replacement discs matching a target disc's category, speed, and flight profile based on weighted Euclidean flight distance.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of similar discs to return (1..20, default 5) | |
| disc_id | Yes | Target disc ID or slug to find replacements for | |
| target_brand | No | Optional target brand filter for cross-brand replacements (e.g. find Discraft alternative to Innova TeeBird) | |
| exclude_same_brand | No | If true, exclude discs from the same manufacturer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral aspects such as whether the operation is read-only, potential side effects, or data source limitations. The name suggests read-only, but that is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is well-structured and front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not specify the return format (e.g., list of discs, ordering, or any additional metadata). Since there is no output schema to fill this gap, the description should have provided some indication of the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all four parameters, covering their meaning and default values. However, the description itself does not add additional context beyond the schema, leaving potential ambiguity about how parameters like target_brand or exclude_same_brand interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: finding alternative discs similar to a target based on category, speed, and flight profile. It distinguishes this from sibling tools (e.g., search_discs, compare_discs) by focusing on similarity matching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is implied by the description, but no explicit guidance is given on when to use this tool versus alternatives. It lacks statements like 'use this when you need replacements for a disc' or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve comprehensive details for a specific disc by numeric ID or string slug, including flight ratings, stability score, flight class, flight tag, available plastics, and current market rank.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Stable disc ID or slug (e.g. 'innova-destroyer', 'discraft-buzzz', 'axiom-crave') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the burden. The verb 'Retrieve' clearly indicates a read-only operation with no side effects, which is sufficient disclosure for a retrieval tool. It doesn't mention potential limitations like caching or data freshness, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that lists the purpose and the data fields. No unnecessary words or repetition, making it concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one input parameter) and that the output fields are enumerated (flight ratings, stability score, etc.), the description provides sufficient context for an agent to know what to expect. It doesn't need an explicit output schema because the description already outlines the return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the 'id' parameter already covers the input format with examples and clarification that it accepts stable ID or slug. The tool description adds nothing beyond that, so it meets the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves comprehensive details for a specific disc by ID or slug, listing the types of information returned. This distinctly differentiates it from siblings like search_discs (which likely searches) and list_brands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions input via numeric ID or string slug, which is a usage guideline. However, it does not explicitly compare with alternatives (e.g., 'use this when you have an exact ID, not when searching'), so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a specific disc golf disc's current weekly retail sales rank across regions (Global, Europe, Americas, Oceania, Asia) and its 4-week market momentum status.
| Name | Required | Description | Default |
|---|---|---|---|
| disc_id | Yes | Target disc ID or slug (e.g. 'innova-destroyer', 'discraft-buzzz', 'axiom-envy') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the data is current weekly retail sales rank and 4-week momentum, which is useful context. However, it does not mention error behavior for invalid disc_id, whether the operation is read-only, or how 'momentum status' is defined. The description only partially carries the transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every phrase adds information: specific resource, regions, time frame, and momentum context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no output schema, the description states what is returned (rank per region and momentum status) and names the regions. It omits response shape and error handling, but these are minor for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes disc_id with examples and formats, and schema coverage is 100%. The tool description adds no parameter-level details beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the verb 'Retrieve' and specifies the exact resource: a single disc's weekly retail sales rank across named regions (Global, Europe, Americas, Oceania, Asia) and its 4-week market momentum status. This clearly differentiates it from siblings like get_weekly_rankings (list-oriented) and get_market_movers (market movers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for a single disc's ranking/momentum but never explicitly states when to choose it over siblings like compare_discs, find_similar_discs, get_disc, get_market_movers, or get_weekly_rankings. No exclusions or alternatives are mentioned, so usage guidance relies on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a 2D Speed vs Stability Flight Grid for any brand, category, or specific speed rating, grouping discs into understable, straight, stable, overstable, and very overstable columns.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | Filter matrix by manufacturer/brand name (e.g. 'Innova', 'Discraft', 'Axiom') | |
| speed | No | Filter matrix to a specific speed rating (e.g. 7 or 9) | |
| category | No | Filter matrix by disc category (putter, midrange, fairway_driver, distance_driver) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the output shape (a 2D grid grouped by stability categories) and the filtering dimensions, but it does not explain edge cases, return format details, or what happens when no filters are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence. It front-loads the core purpose and packs the filter dimensions and output grouping into one clean statement with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a tool with three optional filters and no output schema, but it leaves gaps: the response format is not described, and there is no mention of defaults or constraints. For a medium-complexity tool with no annotations, a bit more context would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters already have clear descriptions in the input schema, so schema coverage is 100%. The description essentially restates the same filter concepts without adding new parameter-level meaning, which meets the baseline but adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate') and names the exact resource ('2D Speed vs Stability Flight Grid'), including the stability groupings. This clearly distinguishes it from sibling tools that look up individual discs, compare discs, or provide rankings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool: for any brand, category, or specific speed rating. It does not explicitly mention alternatives or when-not-to-use scenarios, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve rolling 4-week disc golf market movers including biggest disc risers, fallers, breakout discs entering the top 100, and brand momentum shifts.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Mover filter: 'all' (default), 'risers', 'fallers', 'breakouts', 'brands' | all |
| limit | No | Maximum number of mover items to return per category (1..20, default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the rolling 4-week window and enumerates the mover categories, but doesn't mention response format, pagination, auth, or other behavioral traits. For a read-only retrieval tool, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that conveys the core action, time window, and all relevant categories without any fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two well-documented parameters, and the description covers the conceptual scope. It doesn't specify the exact response structure (there is no output schema), but for a list-style movers endpoint this is likely sufficient. Minor gaps like default behavior are already covered in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because both type and limit have descriptions. The description's mention of disc types mirrors the enum values and adds no extra meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description has a clear verb and resource: 'Retrieve rolling 4-week disc golf market movers' and lists specific categories. It is easy to understand what the tool does, but it doesn't explicitly differentiate from sibling tools like get_weekly_rankings, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'rolling 4-week' provides helpful context for when to use this tool, but no alternatives or exclusion criteria are mentioned. An agent must infer that this tool is for market movers rather than weekly rankings, disc comparisons, or searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the latest weekly disc golf retail sales rankings (Top 10) and weekly top risers/fallers by region (global, europe, americas, oceania, asia) based on aggregated sales from 40+ worldwide retailers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of top discs to return (1..10, default 10) | |
| region | No | Geographic sales region: 'global' (default), 'europe', 'americas', 'oceania', 'asia' | global |
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 discloses that the data is aggregated from 40+ retailers and is weekly, but does not clarify whether the operation is read-only (highly likely for a retrieval tool), whether results are limited to the Top 10 by default, or how risers/fallers are computed. The absence of annotations but a plain retrieval description makes a score of 3 appropriate – it is transparent about what it returns but lacks depth on behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the primary purpose and scope, then the region list. Every word earns its place, no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with fully documented parameters, the description covers the essential context: what is returned (rankings, risers/fallers), the regional scope, and the data source. The output schema is absent, so the description does not need to explain return values, but the tool also lacks guidance on how this relates to get_market_movers or get_disc_ranking, which likely overlap. Slight gap in distinguishing from siblings prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds context by mentioning 'Top 10' and regional values, which aligns with the limit and region parameters. However, it does not add much semantic nuance beyond the schema – e.g., what happens when limit is reduced, how risers/fallers interact with the limit, or whether region values are case-sensitive. Baseline 3 is correct since the schema already documents both parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('Retrieve'), a specific resource (weekly disc golf retail sales rankings), and precise scope (Top 10, top risers/fallers by region). It also names the data source (40+ worldwide retailers), which distinguishes it from sibling disc-related tools that likely focus on individual discs or market movers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is clear about what data the tool returns and specifies the region options, but it does not explicitly state when to use this tool versus the sibling tools like get_disc_ranking or get_market_movers. The context is implied (weekly rankings vs possibly daily rankings or individual disc details), but no exclusions or alternative routing are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List and filter disc golf manufacturers/brands in the database, including active mold counts, speed ranges, category breakdowns, and top popular molds.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of brands to return (1..100, default 20) | |
| query | No | Search query to match brand name or slug (e.g. 'Axiom', 'Latitude', 'Innova') | |
| offset | No | Pagination offset (default 0) | |
| category | No | Filter brands that manufacture discs in this category (putter, midrange, fairway_driver, distance_driver) | |
| min_discs | No | Minimum number of active molds manufactured by the brand |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It conveys a read-only listing/filtering operation and previews key output fields, but it does not explicitly state that no mutation occurs, how results are ordered, or how filtering behaves for partial matches.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence that front-loads the action and target resource, then appends the key result details. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list/filter tool with fully documented optional parameters, the description covers the main purpose and output highlights. It could be more complete by noting pagination defaults and the exact result shape, but these are largely covered by the schema and implied by the listed output fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter already has a clear description with defaults and examples, so the description adds no new parameter semantics. The baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (list and filter), a clear resource (disc golf manufacturers/brands), and the scope of returned data (mold counts, speed ranges, category breakdowns, and top molds). This clearly differentiates it from the disc-focused sibling tools, since list_brands is the only brand-level tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is the tool for brand-level overviews and filtering, while all siblings are disc-focused. It does not explicitly provide when-not-to-use guidance or route to alternatives, but the context is clear enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and filter disc golf discs by text query, brand, category, speed/glide range, stability score range, flight tag, and canonical flight class. Returns up to 50 bounded results with stable IDs and canonical URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Filter by flight tag (e.g. 'Lockdown Fade', 'True Flight', 'Progressive Turn', 'Early Turn', 'Assured Fade') | |
| brand | No | Filter by manufacturer/brand name (case-insensitive, alias-tolerant) | |
| limit | No | Maximum number of discs to return (1..50, default 10) | |
| query | No | Text query to match disc name, brand, model, or slug | |
| offset | No | Pagination offset (default 0) | |
| category | No | Filter by disc category (putter, midrange, fairway_driver, distance_driver) | |
| fade_max | No | Maximum fade (0..6) | |
| fade_min | No | Minimum fade (0..6) | |
| turn_max | No | Maximum turn (-5..1) | |
| turn_min | No | Minimum turn (-5..1) | |
| glide_max | No | Maximum glide (1..7) | |
| glide_min | No | Minimum glide (1..7) | |
| is_ranked | No | If true, only return discs currently holding a global Top 100 sales ranking | |
| speed_max | No | Maximum speed (1..15) | |
| speed_min | No | Minimum speed (1..15) | |
| flight_class | No | Filter by canonical flight class (e.g. 'understable', 'straight', 'stable', 'overstable', 'very_overstable') | |
| stability_max | No | Maximum stability score (turn + fade) | |
| stability_min | No | Minimum stability score (turn + fade) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It adds genuinely useful facts — results are bounded to a 50-cap, IDs are stable, and URLs are canonical — which help an agent reason about pagination and result identity. However, it remains silent on filter combination semantics (AND vs OR), default sort order, and empty-query or no-filter behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler. The action and scope are front-loaded in the first sentence, and the second adds the return contract. Every word earns its place; it is efficiently sized given the 18-parameter schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 18 optional parameters, no annotations, and no output schema, the description covers the essential return contract but omits operational details an agent would need: default sort order, whether combined filters are ANDed, pagination semantics beyond offset/limit, and behavior when no filters are supplied. Adequate but with clear gaps for a tool this complex.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's filter list merely paraphrases the schema's property descriptions (brand, category, speed/glide range, stability range, flight tag, flight class) without adding any new parameter-level meaning, syntax details, or interaction caveats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Search and filter') on a clear resource ('disc golf discs') and enumerates the filter dimensions (text query, brand, category, speed/glide range, stability score range, flight tag, canonical flight class). The purpose is unmistakable and intuitively distinct from siblings like compare_discs, get_disc, or find_similar_discs, though it never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. With 8 siblings including find_similar_discs, compare_discs, and get_disc, an agent receives no direction on which tool fits which intent, nor any exclusions, prerequisites, or conditions for choosing an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_disc1 field changedInput schema / properties / id / descriptionPrevious value: -"Stable disc ID or slug (e.g. 'innova-destroyer', 'discraft-buzzz')"New value: +"Stable disc ID or slug (e.g. 'innova-destroyer', 'discraft-buzzz', 'axiom-crave')"get_flight_matrixlist_brandssearch_discs10 fields changedInput schema / properties / brand / descriptionPrevious value: -"Filter by manufacturer/brand name (case-insensitive)"New value: +"Filter by manufacturer/brand name (case-insensitive, alias-tolerant)"Input schema / properties / fade_maxAdded value: +{
+ "description": "Maximum fade (0..6)",
+ "type": "number"
+}Input schema / properties / fade_minAdded value: +{
+ "description": "Minimum fade (0..6)",
+ "type": "number"
+}Input schema / properties / flight_class / descriptionPrevious value: -"Filter by canonical flight class (e.g. 'Early Turn', 'Progressive Turn', 'True Flight', 'Assured Fade', 'Lockdown Fade')"New value: +"Filter by canonical flight class (e.g. 'understable', 'straight', 'stable', 'overstable', 'very_overstable')"Input schema / properties / glide_maxAdded value: +{
+ "description": "Maximum glide (1..7)",
+ "type": "number"
+}Input schema / properties / glide_minAdded value: +{
+ "description": "Minimum glide (1..7)",
+ "type": "number"
+}Input schema / properties / is_rankedAdded value: +{
+ "description": "If true, only return discs currently holding a global Top 100 sales ranking",
+ "type": "boolean"
+}Input schema / properties / tagAdded value: +{
+ "description": "Filter by flight tag (e.g. 'Lockdown Fade', 'True Flight', 'Progressive Turn', 'Early Turn', 'Assured Fade')",
+ "type": "string"
+}Input schema / properties / turn_maxAdded value: +{
+ "description": "Maximum turn (-5..1)",
+ "type": "number"
+}Input schema / properties / turn_minAdded value: +{
+ "description": "Minimum turn (-5..1)",
+ "type": "number"
+}get_disc_rankingget_market_moversget_weekly_rankingscompare_discsfind_similar_discsget_discsearch_discs
Add one secure layer between your agents and this server.