discorg-mcp

Server Quality Checklist

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

Latest release: v0.1.4
Disambiguation4/5
Each tool targets a distinct resource/action, and descriptions clearly clarify differences (e.g., release vs master, collection vs wantlist). The only mild overlap is between update_order and add_order_message, both of which can change order status, but their primary purposes differ.
Naming Consistency4/5
Most tools follow a verb_noun pattern (get_release, create_listing, add_to_collection), but discogs_whoami and get_seller_inventory deviate slightly from the dominant verb_noun consistency.
Tool Count3/5
With 30 tools, the set is on the heavy side, but each tool covers a distinct part of the Discogs API (database, collection, wantlist, marketplace, orders). While above the typical well-scoped range, the count is justified by the API's breadth, though it remains high.
Completeness4/5
The tool surface covers the main CRUD operations for collection, wantlist, listings, and orders, plus robust search and lookup. Missing operations like moving a collection item between folders or updating a wantlist item can be worked around (remove/add), so no critical dead ends.
Average 3.7/5 across 30 of 30 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- Last stable release on August 10, 2026
- 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?
The readOnlyHint annotation already indicates a safe read operation. The description adds no behavioral context beyond 'fetch details,' such as what fields are returned, whether authentication is required, or error behavior. It provides no information beyond what the annotation already conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no wasteful words, and front-loaded with the verb and resource. It is as concise as possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is thin for a tool with no output schema. It doesn't describe the return value structure, potential errors, or prerequisites (e.g., having an order_id from list_orders). Given the simple one-parameter nature, a bit more explanation of what 'details' includes would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate but doesn't. The order_id parameter is not explained; the agent must infer its meaning from the tool name. The description provides no additional meaning about the parameter's format, source, or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and names the resource 'details for a single marketplace order,' clearly distinguishing it from list/update operations like discogs_list_orders and discogs_update_order. The 'single' qualifier differentiates from bulk-list siblings.
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 on when to use this tool versus alternatives. It does not mention that discogs_list_orders should be used to obtain order IDs first, nor does it state when not to use this tool. The intended context is only implied by sibling tool names.
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 only states the action and does not mention authentication requirements, duplicate handling, side effects, or the response format. This is a mutation tool, so such details are important.
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 sentence with no filler or redundancy. It is extremely concise and front-loaded, earning a perfect score for 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?
The tool has no output schema and no annotations, so the description should cover prerequisites, side effects, and return behavior. It only states the core action, leaving the agent to infer authentication requirements, duplicate handling, and expected outcomes. The simplicity of the operation mitigates this slightly, but important context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (folder_id is described, release_id is only typed). The description adds implicit meaning by mapping 'release' to release_id and 'collection folder' to folder_id, but it does not explain optionality or defaults beyond the schema. It partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and resource ('release to collection folder'), making the tool's purpose immediately clear. It distinguishes itself from sibling tools like discogs_remove_from_collection and discogs_add_to_wantlist by specifying the exact target.
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, nor are prerequisites or exclusions mentioned. There is no indication that the operation applies to the authenticated user's collection or any constraints such as existing folder ownership.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint: true already declares the operation as read-only, so the safety profile is known. The description adds that the response includes both releases and masters, which is useful context. However, it does not disclose pagination behavior, sortability, or response structure beyond that, so no additional behavioral traits are revealed beyond what the annotation and the basic description supply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the verb and resource clearly. It is front-loaded and contains no filler or redundant information. Every word earns its place, making it appropriately concise for the level of detail provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and only a readOnly annotation, the description is too minimal to be considered complete. It does not explain return value shape, pagination/sorting semantics, or clarify the meaning of artist_id and sort parameters. The description only covers the basic resource, leaving significant gaps for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40% (only page and per_page have descriptions). The description does not compensate for the missing parameter details: artist_id is required but has no description, and sort/sort_order are enums without semantic explanation. The description adds no parameter-level meaning, so the agent is left to infer from types and names, which is insufficient for correct invocation.
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 'List releases and masters credited to an artist' clearly states the action (list) and the resource (artist's releases and masters). It is specific enough to convey the tool's core function, but it does not explicitly differentiate from sibling tools like discogs_get_master_versions or discogs_search, which could overlap in certain use cases.
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: use this tool when you need an artist's discography. However, it does not provide explicit guidance on when to prefer this over alternatives, nor does it mention exclusions or prerequisites. The context is implied by the tool name and description, but no concrete when-to-use or when-not-to-use scenarios are given.
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 disclosing behavioral traits. It only states that the release is added, without mentioning authentication requirements, idempotency, error handling (e.g., if the release is already in the wantlist), or return value. This is a significant gap for a mutation tool.
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 action and resource. Every word adds value, and there is no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and three parameters with zero schema descriptions, this description is inadequate. It does not explain what happens on success, what the response looks like, or any side effects, leaving significant gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only mentions 'notes and a rating' without explaining their format or constraints (e.g., rating range 0-5). It fails to even mention the required release_id parameter, leaving its meaning and required format unclear in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and resource ('release to the authenticated user's wantlist'), clearly distinguishing it from sibling tools like discogs_add_to_collection or discogs_get_wantlist. It also mentions optional notes and rating, which are distinctive features.
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 for adding releases to one's own wantlist, but it does not explicitly state when to use it versus alternatives like discogs_add_to_collection or discogs_remove_from_wantlist. No exclusions or prerequisites are mentioned, leaving the usage context somewhat implicit.
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?
The description adds no behavioral context beyond what the readOnlyHint annotation already provides. It does not disclose what fields are included in the profile details, whether authentication is required, what happens for invalid IDs, or any rate-limiting considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no filler. It front-loads the core action and resource, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description is adequate but lacks nuance. It does not mention what the response contains beyond 'profile details', nor does it address error cases or any special behavior. Given the absence of an output schema, a bit more detail would improve 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 0% description coverage, leaving the description to compensate. It clarifies that label_id is a Discogs label ID, which adds meaning beyond the bare integer type. However, it does not explain the expected format (e.g., numeric string vs integer) or any range constraints, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Fetch), the resource (profile details for a record label), and the identifying mechanism (by Discogs label ID). This distinctly separates it from siblings like discogs_get_label_releases and discogs_search, which have 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?
No guidance is provided on when to use this tool instead of alternatives. It does not mention that this is for profile metadata only, whereas discogs_get_label_releases would be used for the label's releases, nor does it indicate any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, covering safety. The description adds the default username behavior, which is useful scoping context, but provides no other behavioral details such as pagination, rate limits, or response structure. This adds some value beyond annotations, consistent with a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without extraneous text. Every word contributes, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six optional parameters and no output schema, yet the description omits any mention of pagination, filtering, sorting, or response characteristics. While the read-only annotation is present, the description is too sparse to give a complete picture for a listing endpoint.
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?
Only the username parameter has a schema description. The tool description does not explain page, sort, status, per_page, or sort_order. With schema coverage at 17%, the description fails to compensate for the undocumented parameters, leaving the agent to infer meanings from enums alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'marketplace listings' and scope 'for a given Discogs username', distinguishing it from singular listing tools like discogs_get_listing. It also notes the default behavior, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like discogs_get_listing or discogs_create_listing. It does not mention exclusions or scenarios, leaving selection to the agent based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares the tool is read-only, and the description adds the specific outputs (quantity and price). However, it does not disclose potential behavioral nuances, such as the role of the currency parameter or whether the price is returned in the requested currency, which would be valuable context for the agent.
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 purpose and specifies the exact data returned. No unnecessary words or redundant information—every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description covers the core outputs, but the lack of an output schema and unclear parameter semantics (especially currency) leave gaps. The agent doesn't know the response format or how the currency parameter affects the result, so the description is not fully complete for a tool without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies that release_id identifies the release ('for a release'), but it does not explain the 'currency' parameter at all, leaving its purpose and allowed values (beyond the length constraint) undocumented. This is a significant gap for a low-coverage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: getting the number of copies for sale and the lowest current price for a release. It uses a specific verb ('Get') and resource ('marketplace stats for a release'), and explicitly lists the two data points, distinguishing it from sibling tools like price suggestions or release details.
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 discogs_get_price_suggestions or discogs_get_release. The description does not mention alternative tools, prerequisites, or typical scenarios, leaving the agent to infer usage from the name and description.
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 must carry full behavioral disclosure. It states that the action is removal from the authenticated user's wantlist, but it does not disclose potential side effects (e.g., what happens if the release is not present), permission requirements beyond authentication, or whether the operation is reversible. This leaves significant ambiguity for a mutation tool.
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, clear sentence that efficiently conveys the action and target. It is appropriately sized for a simple tool and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), but the description is minimal. It does not address edge cases like removing a non-existent item, authentication requirements beyond implying 'authenticated user', or what the response looks like. While adequate for a basic removal, it lacks the detail needed for fully informed invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the release_id parameter at all. Since the schema has zero description coverage and the parameter is a bare integer, the description should provide meaning, but it only says 'a release' without mapping to release_id. The parameter name is somewhat self-explanatory, but the description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove' and the specific resource ('a release from the authenticated user's wantlist'), which distinguishes it from sibling tools like add_to_wantlist and get_wantlist. The purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when removing a release from a wantlist, but it does not explicitly mention when to use it versus alternatives or any preconditions. It does not reference sibling tools or exclusion cases, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states 'update' but does not mention whether fields not provided are preserved, whether this overwrites existing data, if special permissions are required, or what the response looks like. This is a significant gap for a mutation tool.
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 sentence, front-loaded with the action and resource, with no unnecessary words. Every word contributes to meaning, making it highly effective.
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 5 parameters, 3 required, no output schema, and no annotations, the description is too brief. It lacks important context about update semantics (e.g., merge vs replace), prerequisites, or response behavior. A more complete description would include such details, especially for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only notes has a description). The tool description adds context by naming 'rating and notes' but does not explain folder_id, release_id, or instance_id beyond their self-evident names. The rating constraint (0-5) is only in the schema, not reinforced in the description. It provides some value but does not fully compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'update' and identifies the resource as a 'collection item instance' with the fields 'rating and/or notes', which clearly distinguishes it from sibling tools like add_to_collection and remove_from_collection. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying existing collection items, but does not explicitly state when to use it versus alternatives or provide preconditions like needing an instance_id from get_collection_items. It gives no exclusions or alternatives, 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.
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 says 'update existing marketplace listing' and lists some fields. It fails to mention whether partial updates are supported (though the optional schema suggests so), what happens if the listing does not exist, any authentication requirements, or potential side effects. This is a significant gap for a mutation tool.
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 sentence of 11 words, front-loaded with the action and object, and uses a compact parenthetical list. There is absolutely no wasted wording; 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's complexity (9 parameters, no output schema, no annotations, low schema coverage), the description is far too minimal. It provides no information about return values, error handling, concurrency, or the behavior when only some fields are supplied. A useful description would at least state partial update semantics, required identifiers, and what the response contains.
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?
Input schema has only 11% description coverage (only release_id has an explanation). The tool description merely recites a few parameter names ('price, condition, comments, status, etc') without adding any meaning about formats, constraints, or relationships. It does not compensate for the low schema coverage, leaving the semantics of fields like listing_id, allow_offers, sleeve_condition, and location unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'update' with the resource 'existing marketplace listing', clearly distinguishing it from sibling tools like discogs_update_collection_item (which targets collection items) and discogs_create_listing/delete_listing. The parenthetical list of fields (price, condition, comments, status) reinforces the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing marketplace listing' implies this is for modifying an already-created listing, clearly separating it from creation or deletion. However, it does not explicitly name alternatives (e.g., 'use discogs_create_listing for new listings') or state when not to use it, so it falls short of the explicit guidance seen in top-tier examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation, and the description's 'Fetch details' is consistent. It adds context by clarifying that a master release is an abstract grouping, which is useful. However, it does not disclose any additional behavioral details such as response format or potential limitations, so it adds only modest value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that immediately states the core purpose. The parenthetical adds essential context without unnecessary verbosity, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only tool, the description gives enough to understand the basic operation, but it lacks any information about return values or how this interacts with related tools. The lack of an output schema and minimal sibling differentiation makes the description adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (master_id, integer, required) with 0% description coverage. The tool description does not mention or explain this parameter, relying on the parameter name and tool title for inference. Given the low schema coverage, the description should compensate but does not, leaving the parameter semantics shallow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch details') and the resource ('a master release'), with a clarifying definition ('the abstract release grouping all its pressings/versions'). This distinguishes it from related tools like discogs_get_release, which fetches a specific release rather than the master grouping.
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 definition of a master release implies when this tool should be used (when you need the abstract grouping rather than an individual pressing), but there is no explicit guidance on when to use this vs. alternatives like discogs_get_release or discogs_get_master_versions. Usage context is present but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds that it covers both messages and status changes, but lacks details on pagination, ordering, or response structure, leaving some behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the verb and resource. Every word is useful, and there is no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and readOnlyHint annotation, the description gives a basic idea of the tool's function. However, it does not describe the output format or return structure, which could be important for an agent expecting to parse the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not mention the order_id parameter at all. While the parameter name is self-explanatory, the description adds no semantic value beyond the schema, failing to compensate 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 action (list) and the specific resource (message/status-change history for a marketplace order). This distinguishes it from siblings like list_orders (lists orders) and get_order (gets order details), and add_order_message (adds a message).
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 that this tool is for retrieving message/status-change history for an order, but it does not explicitly state when to use it over alternatives like get_order or list_orders, nor does it mention any exclusions or prerequisites.
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, the description carries the burden of disclosing mutating behavior. It explicitly mentions that the status can be changed, which is a key side effect. However, it omits details such as required permissions, response format, or any potential consequences beyond the status change.
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 filler words. It efficiently conveys the primary action and the optional status change.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no output schema or annotations, the description covers the core operation but leaves out any mention of return behavior, permissions, or preconditions. It is adequate but not thoroughly complete for autonomous agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent, but the description provides meaning for 'message' (the content to post) and 'status' (the optional new status), and 'order_id' is implied via 'order's'. It does not add constraints or formats, but it does clarify the relationship between message and status, providing moderate value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Post a message to a marketplace order's message thread' and also identifies the optional side effect of 'changing its status'. It distinguishes itself from siblings like discogs_list_order_messages and discogs_update_order by specifying the exact resource and type of operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the description: use when you need to post a message to an order's thread. However, it does not explicitly state when not to use it, nor does it compare with alternatives like discogs_update_order, which might also change status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which covers the safety profile. The description adds the scoping detail that it fetches a single listing by ID, but does not disclose any additional behavioral traits such as authentication requirements, error behavior, or rate limits. With annotations covering the main concern, this is adequate but not additive.
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 sentence, contains no fluff, and effectively communicates the tool's purpose. It is concise without being under-specified as a tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with readOnly annotation and no output schema, the description provides the core information. However, it omits any indication of the response content or when to use it relative to list/search tools, making it minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description clarifies that listing_id is the identifier used to fetch the listing. It does not explain the optional currency parameter, which remains undocumented. This partial compensation earns a mid score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Fetch' with resource 'marketplace listing' and specifies 'single' and 'by its listing ID', clearly distinguishing it from sibling tools like discogs_get_seller_inventory or discogs_search. It directly states the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific listing ID and need its details, but it does not explicitly mention when to prefer this over discogs_get_seller_inventory or search, nor does it state any exclusions. Context 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation declares this as a read operation, and the description's 'List' aligns. It adds the 'authenticated user' context, indicating an auth requirement, but does not disclose pagination behavior, response shape, or error handling. Given the annotation covers safety, the description adds limited value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one short sentence, front-loaded with the verb and resource, with no filler or redundant detail. It is optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two pagination parameters and a read-only annotation, the description is mostly adequate: it states the resource and authentication scope. However, it omits any mention of pagination mechanics or that an empty list is possible, but given the output schema is absent and the tool's simplicity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), and the description does not explain page or per_page or their role in pagination. Although the parameter names and constraints are self-explanatory, the description fails to compensate for the missing schema coverage, leaving parameter semantics to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource 'releases on the authenticated user's wantlist', clearly distinguishing this from wantlist add/remove tools. It is unambiguous and directly matches the tool's name.
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 the authenticated user's wantlist, but does not explicitly state when to use it over siblings like discogs_add_to_wantlist or discogs_remove_from_wantlist, nor does it mention alternatives for collection items. This leaves usage context implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a safe read operation. The description adds no additional behavioral details such as rate limits, error handling, or response format. It does not contradict the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. There is no redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema, no nested objects), the description is adequately complete. It states the action and the key identifier. It could optionally mention that the response contains profile details, but this is implied. The readOnly annotation covers the safety aspect.
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 only defines artist_id as an integer with no description. The description clarifies that this is a Discogs artist ID, which adds essential meaning beyond the schema. However, it does not elaborate on how to obtain the ID or any formatting details, and with 0% schema coverage, more compensation would be ideal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (fetch), resource (profile details for an artist), and method of identification (Discogs artist ID). It is specific and differentiates from siblings like discogs_get_artist_releases or discogs_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use this tool when you have an artist ID and need profile details. However, there is no explicit guidance on when to use it over alternatives (e.g., discogs_get_artist_releases for releases), nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds no behavioral details beyond that, such as authentication, rate limits, or response format. It does not contradict the annotation, but also does not enrich it with additional 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 sentence of 14 words, front-loaded with the verb. Every word earns its place; it is concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 optional parameters and no output schema. The description gives a basic purpose but omits crucial context such as folder_id default (0 = All folder) and pagination limits (per_page max 100). It also doesn't describe the return structure, which would be needed given no output schema. It is minimally viable but with evident gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only folder_id has a description). The description mentions 'sort and pagination options' but does not explain any specific parameters, nor does it mention folder_id or its default of 0. The enums and types are in the schema, but the description fails to compensate for the low 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 uses the specific verb 'List' with the resource 'releases in a collection folder', clearly distinguishing it from sibling tools like discogs_list_collection_folders (which lists folders) and discogs_get_collection_value. It also mentions sort and pagination options, further clarifying scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to list releases in a collection folder with sorting and pagination. It does not explicitly name alternatives or exclusions, but the purpose is specific enough for an agent to infer when to use it. No when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation aligns with the 'List' operation, and no side-effect warnings are needed. The description adds label scoping but no additional behavioral context such as pagination behavior or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with pagination params in the schema and no output schema, the description adequately conveys the primary purpose. It doesn't describe return structure, but that's not essential for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers page and per_page with descriptions; label_id lacks description but is obvious from the tool's purpose. The description does not directly elaborate on parameters, so it adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List releases put out on a record label', using a specific verb and resource. It distinguishes from sibling tools like discogs_get_label (label details) and discogs_get_artist_releases (artist-specific list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description—use this tool to list releases for a label. However, there is no explicit guidance on when to use it over alternatives like discogs_get_label or discogs_get_artist_releases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint annotation, indicating a read-only listing operation. However, it does not add behavioral details beyond what is already conveyed by the annotation (e.g., it does not mention pagination, rate limits, or the response format). The phrase 'all known' suggests exhaustive listing but does not elaborate on behavior like automatic paging.
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 is front-loaded with the action and resource. It contains no filler or redundant wording, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with pagination parameters in the schema and a read-only annotation, the description is adequate. It clearly identifies the scope ('all known pressings/versions') but does not specify the return format or pagination behavior, which is a minor gap given the presence of pagination parameters. Overall, the tool is well-contextualized within its sibling set.
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 input schema already provides descriptions for 'page' and 'per_page', covering 67% of the parameters. The description adds no additional parameter-level meaning, but the purpose and tool name make 'master_id' self-explanatory. Given the schema coverage is not extremely low, the description does not need to heavily compensate.
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 'List all known pressings/versions of a master release' clearly specifies the action (list) and the resource (master versions). It distinguishes from sibling tools like discogs_get_master (which fetches master details) and discogs_get_release (which fetches a specific release), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used to enumerate all versions of a master release, but it does not explicitly state when to use it over alternatives or provide exclusion criteria. There is no direct mention of when to prefer this over discogs_get_master or discogs_get_release, so usage context 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description aligns with a safe read operation. It adds minimal behavioral context beyond the annotation, just that it fetches full details and requires a release ID; no extra info on auth, rate limits, or payload shape is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no filler, front-loading the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch-by-ID tool with readOnly annotation and full schema coverage, the description is adequate but slightly vague about the extent of returned data ('full details') and doesn't mention response shape or any pagination concerns, so a 4 is appropriate.
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 already describes both parameters with 100% coverage (release_id and currency), so the description adds little beyond reinforcing the release_id role. The baseline of 3 applies because the schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and identifies the resource as 'full details for a single release' by Discogs release ID, clearly distinguishing it from sibling tools like discogs_get_master or discogs_get_artist.
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 for fetching a release when you have its release ID, but it does not explicitly compare with alternatives such as discogs_get_master or discogs_get_master_versions, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It explicitly states that the listing is 'real, publicly visible' and advises user confirmation, which is a significant caveat. However, it does not mention authentication requirements, side effects beyond visibility, or reversibility, though the warning partially compensates for this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. It front-loads the primary action and includes the essential warning without 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?
Given the complexity (9 parameters, mutation, no output schema, no annotations), the description is too brief. It covers the core purpose and a critical caution, but omits details about parameters, return values, error scenarios, or prerequisites. The warning is helpful but not sufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 44%, leaving several parameters (e.g., release_id, comments, allow_offers) without descriptions. The tool description does not mention or clarify any parameters, so it fails to compensate for the low schema coverage. It adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'List a release for sale on the Discogs marketplace.' It also adds that the listing is 'real, publicly visible,' which distinguishes it from similar tools like update_listing or get_listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (creating a marketplace listing) and includes a strong practical guideline: 'confirm details with the user before calling.' It does not explicitly name alternatives, but the purpose is clear enough that an agent would not confuse it with update or delete operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description's 'List' operation aligns. The description adds the seller context and optional status filter, but does not reveal other behavioral aspects like pagination defaults, sorting options, or response structure. This is acceptable for a simple read-only list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no filler. It front-loads the primary action and resource, then adds the key modifier (status filter). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation with a well-defined schema and read-only annotation, the description covers the essential purpose and key modifier. It doesn't mention pagination or return format, but the schema covers the parameters and the tool's name indicates the resource. This is sufficiently complete for an agent to select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It only mentions the 'status' filter, while page, per_page, sort, and sort_order are left entirely to the schema. The schema is self-explanatory, but the description fails to add value beyond it for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the exact resource 'marketplace orders', and the scope 'authenticated user's (as a seller)'. It distinguishes the tool from siblings like discogs_get_order (single order) and discogs_get_seller_inventory (inventory items).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it lists the authenticated seller's orders and supports an optional status filter. It doesn't explicitly name alternatives or when not to use it, but the seller scope implies a distinct use case from related order tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing side effects. It does disclose the key behavioral trait that changing status notifies the buyer, which is valuable. However, it doesn't mention other potential behaviors, such as validation of status transitions, reversibility, or immediate effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and the second sentence provides a crucial safety note. Every word adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a straightforward mutation tool: it names the resource, updatable fields, and a key side effect. However, given no output schema and no annotations, it lacks details on status transition constraints, expected response, or error handling, which could leave an agent uncertain about edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'shipping' has a description). The description adds meaning for 'status' and 'additional_instructions' by naming them, but 'order_id' remains implied. It partially compensates for the low schema coverage by clarifying the purpose of three of the four parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('marketplace order'), and lists the specific fields being updated: status, shipping price, additional instructions. This distinguishes it from sibling tools like discogs_get_order or discogs_update_listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use by specifying what can be updated and includes a critical guideline: confirming with the user before changing status because that notifies the buyer. It doesn't explicitly name alternatives, but the scope is well-defined.
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 full burden. It discloses the key nuance that instances are unique and a release can appear multiple times, preventing accidental removal of all copies. However, it doesn't mention whether the removal is irreversible, whether it affects other folders, or what the response contains. For a destructive action, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the primary purpose, the second provides essential prerequisite context. There is no redundant information or fluff, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter mutation with no output schema, the description covers the core operation and a critical prerequisite. It lacks details about return values or failure modes, but these are less critical for this tool. Overall, it provides sufficient context for an agent to execute the tool correctly.
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 zero descriptions for parameters. The description explains instance_id in depth, but folder_id and release_id are left to inference from their names and the tool context. While the names are intuitive, the description only partially compensates for the lack of schema documentation, especially since folder_id's role is not explicitly stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Remove'), a specific object ('a specific instance of a release'), and a location ('from a collection folder'). It clearly distinguishes this from sibling tools like discogs_add_to_collection and discogs_update_collection_item by focusing on removal of a particular instance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions the prerequisite of instance_id from discogs_get_collection_items, which tells the agent when to use this tool (after fetching collection items) and why (multiple instances). It doesn't explicitly exclude alternatives, but the context is clear enough that the agent can infer this is the tool for removing a single copy.
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, the description carries the burden. It discloses the output fields but lacks any mention of authentication requirements, failure modes, or side effects. For a simple read operation, it provides basic transparency but is not rich in 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 sentence that is direct and free of unnecessary wording. It front-loads the verb and lists the expected return fields, achieving maximum clarity in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter identity check, the description is nearly complete: it states what is returned and for whom. It lacks mention of what happens if the user is not authenticated, but given the tool's simplicity and lack of an output schema, the description is sufficient for an agent to understand and invoke it.
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 schema is empty and fully covered. Per the rubric baseline for 0 parameters is 4. The description adds context that the operation concerns the currently authenticated user, but there are no parameter semantics to clarify.
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 the Discogs identity (username, id, resource_url) of the currently authenticated user. The verb 'Return' is specific, and the resource is explicitly defined, distinguishing it from sibling tools that handle releases, listings, and other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The tool's uniqueness among siblings implies its usage (e.g., to verify the authenticated user), but the description does not state this explicitly or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description shoulders the responsibility for behavioral disclosure. It explicitly states 'This is irreversible,' which is critical safety information for a delete operation. The instruction to 'confirm with the user before calling' adds a procedural behavioral expectation. It does not mention auth requirements, rate limits, or side effects, but for a simple delete, irreversibility is the key trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and every word earns its place. It front-loads the purpose and immediately follows with the critical safety warning. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with one parameter and no output schema, the description is quite complete: it explains the action, the irreversibility, and a required pre-condition (user confirmation). It lacks a description of what happens after deletion (e.g., confirmation response) but that is not essential given the absence of an output schema and the simplicity of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter, listing_id, with no description, and schema description coverage is 0%. The description does not mention the parameter at all, merely referring to 'a marketplace listing.' This fails to compensate for the lack of schema documentation; the agent must infer from the tool name and property name that listing_id identifies the listing to delete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Remove a marketplace listing,' which is a specific verb ('remove') and resource ('marketplace listing'). It clearly distinguishes from sibling tools like discogs_create_listing, discogs_update_listing, and discogs_get_listing by indicating the destructive action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear precondition: 'This is irreversible — confirm with the user before calling.' This tells the agent when to use the tool (only after user confirmation) but does not explicitly mention alternatives or when-not-to-use scenarios. A slight upgrade would be naming discogs_update_listing as an alternative for non-destructive changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, matching the read-only nature of 'Search'. The description adds minimal extra behavioral context—it does not mention pagination, result format, rate limits, or any limitations. With the safety already covered by annotation, the description contributes only slightly beyond that, so a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and the second sentence efficiently enumerates filter types. No redundant wording or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 14 optional parameters and no output schema, the description explains the search domain and filter capabilities but omits what the response looks like (e.g., paginated list of matches) and does not mention pagination behavior. This leaves a moderate gap, though the tool's purpose as a search is unambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only 43% coverage, leaving many parameters undocumented. The description compensates by listing most of the structured filters (artist, title, label, genre, style, year, format, country, barcode) and introduces 'free-text queries', which clarifies how to build a search. This adds meaning beyond the sparse schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Search' and identifies the resource types (releases, masters, artists, labels), which clearly distinguishes it from sibling retrieval tools like discogs_get_release or mutation tools. It precisely states the tool's function and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes that this tool is for searching the database with free-text and structured filters, providing clear context for its use. However, it does not explicitly contrast with direct getters (e.g., discogs_get_release) or state when to prefer search over exact-ID retrieval, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true; description adds that it requires authentication and shows example folder names. However, it doesn't disclose return format, pagination, or error behavior. With annotations covering read-only safety, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, 13 words, front-loaded with the verb and resource. Every word earns its place, and the examples are helpful without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter list tool, this description is sufficient: it states what it returns (folders) with examples. However, without an output schema, it doesn't detail the exact structure of the response (e.g., folder IDs), which would help an AI agent use the result in downstream calls.
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?
Input schema has zero parameters, so baseline is 4. The description adds context that the operation targets the authenticated user's folders, which clarifies the implicit scope without needing 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?
Description uses specific verb 'List' and resource 'collection folders' for authenticated user, with examples ('All', 'Uncategorized', custom folders). This clearly distinguishes the tool from siblings like discogs_get_collection_items, which lists items within a folder.
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?
Clear context (authenticated user's collection folders) implies when to use, but no explicit alternatives or exclusions are mentioned. Could be improved by noting that discogs_get_collection_items is for items inside a folder, but the purpose is straightforward enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description needs only to add context. It does add that values are 'estimated' and specifies the three metrics, but provides no further behavioral detail (e.g., error handling, rate limits). This is adequate for such a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One direct, front-loaded sentence with no filler words. Every word contributes to understanding the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no output schema, the description fully covers the return values (minimum, median, maximum) and the applicable scope (whole collection), making it self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to explain. The description adds the 'whole collection' scope, which might be implicit from the tool name, providing minor additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves estimated minimum, median, and maximum marketplace values for the user's entire collection. This specific verb+resource+outcome combination distinguishes it from sibling tools like get_collection_items or get_marketplace_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear context for use: it targets the whole collection and returns financial estimates. However, it does not explicitly mention alternatives or state when not to use this tool, so it falls 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds that results are per condition grade, derived from recent marketplace sales, and that seller settings must be configured. This is meaningful behavioral context, though it does not cover response format details beyond the per-condition hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core function and followed by the requirement. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only), the description covers the purpose, data source, and a key prerequisite. No output schema exists, but the return structure is hinted at by 'suggested price per condition grade'. It lacks error behavior details but is sufficiently complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only one parameter (release_id) and 0% schema coverage, the description compensates by saying 'for a release', making it clear that release_id identifies the release being queried. The parameter is simple and self-evident, so this minimal clarification suffices.
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 'Gets Discogs' suggested price per condition grade for a release', which is a specific verb+resource combination. It distinguishes itself from siblings like get_marketplace_stats or get_listing by focusing on per-condition price suggestions based on recent sales.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by noting it is based on recent marketplace sales and requires the authenticated user to have marketplace seller settings configured. This implies when the tool is appropriate, though it does not explicitly name alternatives or exclusions.
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:

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

Score Badge

Copy to your README.md:

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

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/Spiegelberg/discogs-mcp'

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