Guitar pedal specs, new and used prices, price history, review scores, board checks, buying guides.
Scored across 7 tools
Each tool has a distinct primary purpose: search, single-pedal detail, multi-pedal comparison, price history, guide listing, guide detail, and pedalboard checking. Minor overlap exists because get_pedal, compare_pedals, and get_price_history all surface price and spec information, but their scope and use cases are clearly differentiated by the descriptions.
All seven tools use a consistent snake_case verb_noun pattern: check_board, compare_pedals, get_guide, get_pedal, get_price_history, list_guides, search_pedals. Verbs are predictable and nouns clearly identify the target resource.
Seven tools is well-scoped for a pedal reference and buying-guide server. Each tool covers a distinct user workflow—search, inspect, compare, price-check, browse guides, read a guide, and validate a pedalboard—with no redundant or trivial additions.
The surface covers the core domain workflows: discovery via search, detailed pedal info, side-by-side comparison, price history, guide browsing, and pedalboard validation with power checks. Minor gaps include no dedicated browse-by-category or brand-listing tool, though search_pedals can approximate those needs.
Check a set of pedals as a pedalboard: a suggested signal-chain order with reasons, total current draw against a power supply, and a count of power and compatibility issues.
| Name | Required | Description | Default |
|---|---|---|---|
| pedals | Yes | Pedal slugs from search_pedals, in any order | |
| usesFxLoop | No | True if the amp's effects loop is used, so time-based effects can go in the loop | |
| supplyOutlets | No | How many outputs the power supply has | |
| supplyTotalMa | No | The power supply's total current in mA, if known |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds value by disclosing the return content (suggested signal-chain order with reasons, total current draw, issue count) in the absence of an output schema. It omits any note on validation failures or error 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?
A single front-loaded sentence with a colon-delimited list of outputs; every clause earns its place. Slightly dense but 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?
With no output schema, the description usefully summarizes the three result components an agent should expect, and annotations cover safety. Minor gaps remain around output format and error/validation behavior for a 4-parameter analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented in the schema. The description reinforces the power-supply framing but adds no syntax or format detail beyond what the schema provides, making the baseline 3 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?
States a specific verb ('Check') and resource ('a set of pedals as a pedalboard') and enumerates the three analysis outputs, which cleanly separates it from siblings like compare_pedals or get_pedal. An agent can identify the operation without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (building/validating a pedalboard with a power supply) but never names an alternative or states when-not-to-use. No mention of how it differs from compare_pedals, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Two to five pedals side by side: score, what each is best for, lowest new price, used median and key specs.
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context about what the comparison returns (score, best-for, lowest new price, used median, specs), but says nothing about failure behavior when a slug is unknown or about result ordering.
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 enumerating the returned dimensions with zero filler; every clause carries information an agent can use to decide whether to call it.
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?
There is no output schema, so listing the compared fields in the description is the right compensating move, and annotations cover safety. Minor gaps remain around slug validation and behavior on invalid input, but the definition is usable as-is.
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 reported at 0% for the parameter level, so the description carries some burden. It does add the meaningful 'two to five' cardinality constraint, but the crucial detail that slugs must come from search_pedals is supplied by the schema's item description, not the tool description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (compare) and resource (pedals) and even enumerates the comparison dimensions returned (score, best-for, prices, specs), which clearly separates it from single-pedal tools like get_pedal. It stops short of naming a sibling explicitly, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Two to five pedals side by side' implies the batch-comparison use case versus get_pedal for a single pedal, but there is no explicit when-to-use, when-not-to-use, or prerequisite statement. Usage is only inferable from the phrase itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One buying guide: who it is for, what matters when choosing, the three picks (best overall, budget, step up) with strengths, flaws and current prices, and the other pedals considered.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | A guide slug from list_guides |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the payload shape — three picks with strengths, flaws, and current prices, plus 'other pedals considered' — which is the only place this information appears since there is no output schema. It says nothing about error behavior for an unknown slug, but the added return-content detail earns a 4.
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 opens with the scope ('One buying guide') and then itemizes contents efficiently; nothing is wasted. It is dense to the point of being a run-on list, which slightly hurts scanability, but every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, one-parameter tool with no output schema, the description covers the essential unknown — what the returned guide actually contains — and the schema covers the slug sourcing. Remaining gaps (behavior on an invalid or stale slug) are minor for a non-destructive lookup.
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% for the single slug parameter, and the schema itself already explains that the slug comes from list_guides. The description adds no format, constraint, or sourcing guidance beyond that, so the schema is doing all the work. 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 states a specific resource and its scope — 'One buying guide' — and enumerates its contents (who it's for, three picks, prices), which implicitly distinguishes it from the multi-item sibling list_guides. It is clear what the agent gets back, though it never uses an explicit verb like 'retrieve' or 'fetch'. A reader can tell this apart from get_pedal and compare_pedals without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'One buying guide' contrasted with the sibling list_guides suggests the list-then-get workflow, and the schema's slug description ('A guide slug from list_guides') reinforces it. However, the description itself states no when-to-use condition, no alternative tool (e.g., get_pedal for a single pedal), and no prerequisite. Adequate but with a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything PedalBro knows about one pedal: specs (power, size, bypass, controls), a plain-language summary, the PedalBro review score, what players say, professional review ratings with links, current new and used prices with buy links, and similar pedals.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | A pedal slug from search_pedals, e.g. boss-ds-1-distortion |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond them by enumerating the payload (specs, summary, review score, player sentiment, pro reviews with links, new/used prices with buy links, similar pedals), which matters because there is no output schema. It omits auth/rate-limit/error behavior, so it is not a 5.
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 names the resource first and then enumerates returns. The enumeration is long but every item earns its place given the absence of an output schema; there is no 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?
With no output schema, the description carries the return-value burden and does so comprehensively. The only prerequisite, obtaining a slug, is handled by the schema's own parameter description, so nothing an agent needs is missing.
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?
One parameter with 100% schema coverage, and the schema already documents the slug format and its origin in search_pedals. The description adds no additional parameter meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Everything PedalBro knows about one pedal') and enumerates exactly what that entails. It is clearly the single-pedal detail lookup as opposed to list-oriented siblings, though it never names search_pedals or compare_pedals to sharpen the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance and no alternatives: it never says to call this after search_pedals resolves a slug, nor when compare_pedals is preferable. Usage is only weakly inferable from the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How a pedal's new and used prices have moved over the last 90 days (weekly points), recent sold used listings, and current prices. Useful for 'is this a good price' and 'should I buy used'.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | A pedal slug from search_pedals, e.g. boss-ds-1-distortion |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds behavioral detail annotations cannot: the 90-day window, weekly sampling granularity, and the inclusion of sold-listing data, which materially shapes what the agent should expect.
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, no filler. The data payload is front-loaded and the use cases follow, so an agent gets scope and applicability immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully characterizes the return content (weekly points, sold listings, current prices), which is the important burden here. Minor gaps remain around units/currency and behavior when the slug is unknown, but the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter at 100% schema description coverage, and the schema already explains it is a pedal slug sourced from search_pedals with an example. The description adds nothing about the parameter, so the 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?
The description names a specific resource (price history for a pedal) and enumerates the payload: new/used price movement over 90 days, sold used listings, and current prices. That is far more specific than the title, though it does not explicitly distinguish itself from sibling get_pedal, which could also surface price data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete user-intent triggers ('is this a good price', 'should I buy used'), which tells the agent when this tool is the right call. It stops short of naming when NOT to use it or pointing at an alternative sibling for raw spec/description lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PedalBro's buying guides ('best overdrive pedals', 'best delay under $200', ...), each with its top pick. Use get_guide for the full picks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds useful behavioral context that a list returns only summaries with a top pick rather than full detail, which shapes what the agent should expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler; the resource and its distinguishing feature are front-loaded, and the pointer to get_guide is appended efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully indicates the return shape (per-guide top pick) and where to get deeper data. It leaves the exact fields of each guide unspecified, but for a zero-parameter read-only list tool it is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so the baseline is 4 and there is nothing parameter-related the description could clarify. No compensating detail is needed or expected here.
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 names the exact resource (PedalBro's buying guides) with concrete examples and states what each item includes ('each with its top pick'). It also implicitly separates this listing tool from get_guide, which returns the full picks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly routes the agent to get_guide when the full picks are needed, which is the key alternative for this resource. It does not cover other potential paths (e.g., search_pedals for ad-hoc queries), so it stops short of a full when-to-use map.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search guitar and bass pedals by brand, model, nickname or type (typos are fine), optionally only those buyable new under a price. Returns names, slugs and lowest new prices.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | Brand slug, e.g. boss, strymon, electro-harmonix | |
| limit | No | ||
| query | Yes | e.g. 'tube screamer', 'strymon delay', 'fuzz' | |
| category | No | Category slug to narrow to, e.g. overdrive, fuzz, distortion, delay, reverb, chorus, compressor, looper | |
| maxPriceUsd | No | Only pedals buyable new and in stock at or under this price |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context: fuzzy/typo-tolerant matching and the fact that only in-stock, new-condition items count toward the price filter. Since there is no output schema, its statement of the returned fields (names, slugs, lowest new prices) is also valuable.
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 dense sentences with no filler; the searchable facets are front-loaded and the return-value note is appended where it belongs. 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?
With no output schema, the description correctly compensates by naming the returned fields, and the annotations carry the safety profile. Facet and price-filter semantics are covered; only result ordering/pagination for the limit parameter is left implicit, which is a minor gap for a read-only search.
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 80% and the schema already documents brand, query, category and maxPriceUsd. The description adds the typo-tolerance behavior of the query parameter and restates the in-stock constraint of maxPriceUsd, which the schema mentions but does not fully explain. The limit parameter's semantics remain undocumented in both places, keeping this short of a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (guitar and bass pedals) plus the searchable facets (brand, model, nickname, type). It is clearly distinct from the singular get_pedal and the pairwise compare_pedals siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It notes the price filter is optional and that matching is typo-tolerant, which implicitly tells the agent this is the broad discovery entry point. However, it never names when to prefer get_pedal or compare_pedals, so the routing decision is left to inference.
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.
check_boardcompare_pedalsget_guideget_pedalget_price_historylist_guidessearch_pedals52,000 musical instruments: prices, deals, bundles, open-box, alternatives, accessories, guides.
Sold comps and active listings from eBay, Poshmark, Mercari, Depop, Vinted, TCGplayer and more.
Real US store prices with shipping, daily price history and real-deal checks. Never paid rankings.
Price history, store prices near a ZIP and in-store clearance at major US retailers.
Add one secure layer between your agents and this server.
