SkinGrind
Server Details
CS2 skin prices, case odds and ROI, Armory value, and Trade Up contracts.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 9 of 9 tools scored.
Each tool targets a distinct aspect of CS2 cosmetics: browsing categories, searching, getting details, and ROI calculations. There is no overlap as browse/get/search verbs are clearly separated by resource type.
All tools follow a consistent verb_noun pattern (e.g., browse_bargains, get_case_roi_ranking, search_skins), using underscores and clear action words.
With 9 tools, the server covers the core functionality of browsing, searching, and analyzing CS2 skins and containers without being overly large or sparse.
The tool set covers browsing, searching, detail retrieval, and ROI analysis for cases and armory. A minor gap is the lack of user account operations or direct trading, but the server's scope is well-defined.
Available Tools
9 toolsbrowse_bargainsBrowse cheap CS2 skinsAInspect
Find cheap Counter-Strike 2 skins grouped into price-threshold pages, for example AK-47 skins under 10 dollars or the cheapest knives. Without a slug it lists every available page; with a slug it returns the skins on that page with their current cheapest listing price.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Bargain page slug, for example "ak-47-skins-under-10-dollars" or "cheapest-knives". Omit to list every available page. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes behavior (grouping, listing pages, returning cheapest price) but does not disclose non-obvious traits like data freshness or potential API limits. Adequate for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. Front-loaded with main purpose, then conditional behavior. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes input/output well for a simple tool without output schema. Could clarify what 'every available page' means (e.g., page names/links), but sufficient for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with a solid description for slug. The description adds practical examples of slug values, enhancing usability beyond the schema's formal definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'browse' with resource 'cheap CS2 skins' and clear grouping into price-threshold pages. Examples like 'AK-47 skins under 10 dollars' distinguish from sibling tools like browse_cases and search_skins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains conditional behavior with and without slug, but does not explicitly state when to use this tool versus sibling tools like search_skins for general searches. Implicitly clear given the focus on cheap skins.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
browse_casesBrowse CS2 casesAInspect
List Counter-Strike 2 cases, capsules and souvenir packages, or get one container with its contents plus its drop odds and expected opening value. Odds use the standard CS2 tier weights and are renormalised over the tiers actually present.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number. | |
| slug | No | Container slug. When set, returns that container with its contents and opening odds instead of the list. | |
| sort | No | List ordering: newest, oldest or name. For a single container the contents order: rarity, name, price_asc or price_desc. | |
| type | No | Filter the list by container type. | |
| search | No | Free-text container name search. | |
| per_page | No | Results per page, 1 to 25. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses odds calculation behavior (renormalized tier weights), but does not cover error handling, authorization needs, or response structure beyond what is implied. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main purpose. Every phrase adds value (list vs. get, odds explanation). No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two modes, 6 parameters, no output schema), the description explains the dual modes and odds, but lacks details on response format, pagination behavior, or error conditions. It feels somewhat incomplete for a tool of this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning by explaining how slug switches to single-container mode and how sort behaves differently for list vs. single container. This goes beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists CS2 containers or retrieves a single container with contents and odds, using specific verbs and resources. It distinguishes from sibling tools like browse_collections or search_cosmetics by focusing on containers and drop odds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (listing vs. single container), but does not explicitly explain when to choose this over alternatives like browse_collections or search_cosmetics. No when-not or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
browse_collectionsBrowse CS2 collectionsAInspect
List Counter-Strike 2 collections, or get one collection with its contents. Optionally includes the collection Trade Up map: which rarity tiers exist in the collection and what each tier can produce. That map is catalog contract math, not scanner output.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number. | |
| slug | No | Collection slug. When set, returns that collection with its contents instead of the list. | |
| sort | No | List ordering: newest, oldest or name. For a single collection the contents order: rarity, name, price_asc or price_desc. | |
| type | No | Filter the list by what the collection contains. | |
| search | No | Free-text collection name search. | |
| per_page | No | Results per page, 1 to 25. | |
| include_tradeup_map | No | Only with slug. Adds the collection Trade Up map showing each rarity tier and its possible outputs. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries full burden. It discloses that the trade-up map is based on catalog contract math, not scanner output, which is a key behavioral trait. It does not cover response caching or real-time status, but the disclosed nuance adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. Each sentence provides essential information: purpose and optional feature. It is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no output schema, no annotations), the description covers the core modes and optional feature. It does not detail return format or pagination, but the schema covers parameter details. Reasonably complete for a browsing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions (100% coverage). The description adds context beyond schema for include_tradeup_map by explaining its content. This extra meaning justifies a score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists collections or retrieves one with contents. It uses specific verbs and resource, and the title reinforces the purpose. It distinguishes from siblings like browse_cases by focusing on collections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the trade-up map feature and implies the two modes (list vs single). However, it does not explicitly compare with alternative tools like get_tradeup_preview or search_skins, so guidance is slightly incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_armory_roiGet CS2 Armory rotation valueAInspect
List the current Counter-Strike 2 Armory rotation tiles with their credit cost and expected value, or get one tile with every item it can produce and the rarity weighting. Use this to compare what Armory credits are worth across the current rotation.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Armory tile slug. When set, returns that tile with its full item list instead of the rotation overview. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses two modes (overview vs. detail) and what each returns (credit cost, expected value, item list, rarity weighting). It implies read-only behavior but doesn't explicitly state no side effects or authentication requirements. This is adequate for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states the core functionality, second explains the optional parameter, third gives a use case. No redundant words. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter, no output schema, and no annotations, the description covers the tool's behavior adequately. It explains both modes and the use case. Could mention return format or data freshness, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter 'slug' with a description that matches the tool's behavior. Schema coverage is 100%, so the description does not need to add extra parameter info. The description reinforces the parameter's effect, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Armory rotation tiles with credit cost and expected value, or returns a single tile with full item list and rarity weighting. This distinguishes it from sibling tools like browse_cases or get_case_roi_ranking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a use case: 'compare what Armory credits are worth across the current rotation.' It implies this is for assessing value, though it doesn't explicitly say when not to use it. The sibling tools are distinct so confusion is unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_case_roi_rankingGet CS2 case ROI rankingAInspect
Rank Counter-Strike 2 cases by expected return on opening. Each entry gives the case price, expected value, return in basis points and the chance of an opening being profitable, all computed from current listing prices plus the key price. Cases whose contents are not sufficiently priced are excluded.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral details: computation uses current listing prices and key price, excludes cases with insufficiently priced contents. No annotations exist, so description carries full burden, which it meets well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, concise and front-loaded with the primary purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description fully explains the purpose, computed fields, data sources, and exclusion criteria. Nothing essential is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline is 4. Description adds no parameter information, which is appropriate. It explains what the output contains, indirectly clarifying that no input is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it ranks Counter-Strike 2 cases by expected return on opening, with specific computed fields. Distinct from sibling tools like browse_cases which likely don't provide ROI analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes what it does (rank cases by ROI) and implicitly when to use (when interested in ROI). No explicit when-not-to-use or alternatives, but context signals and sibling names make differentiation clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_skin_detailGet CS2 skin detailAInspect
Get one Counter-Strike 2 skin with its float range, per-wear prices, collections and cases. Optionally includes the catalog Trade Up context: which rarity tier the skin sits in and what it can be traded up into.
| Name | Required | Description | Default |
|---|---|---|---|
| skin_slug | Yes | Skin slug, for example "redline". | |
| weapon_slug | Yes | Weapon slug, for example "ak-47". | |
| include_tradeup_context | No | Include the catalog Trade Up context for this skin. This is contract math derived from the collection, not scanner output. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden. It describes what the tool returns but does not mention any behavioral traits like rate limits, authentication needs, or that it's a read-only operation. For a 'get' tool, the lack of transparency is acceptable but not ideal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The first sentence states the core purpose and data returned, and the second explains the optional parameter. It is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description sufficiently covers return values (float range, prices, collections, cases, optional trade-up context). It helps differentiate from sibling tools by listing specific data. Could mention that it only retrieves one skin, but that is clear from the first sentence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description adds context for the optional include_tradeup_context parameter but does not add significant meaning beyond the schema. It meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets one CS2 skin with specific data (float range, per-wear prices, collections, cases), and optionally trade-up context. The verb 'get' and resource 'skin detail' are specific, and it distinguishes from sibling tools like search_skins (which lists multiple) and browse_collections (which is about collections).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the optional inclusion of trade-up context, giving a hint about when to use that parameter. However, it does not explicitly state when to prefer this tool over alternatives like search_skins or browse_collections. It does list what data it provides, which indirectly helps with selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_tradeup_previewGet CS2 Trade Up previewAInspect
Get the free preview of the SkinGrind Trade Up scanner: the featured Trade Ups with their full recipes, the number of contracts currently active, and locked teasers for recent finds showing their economics and when they unlock. Full recipes for the whole feed need a SkinGrind account and the authenticated server.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Which Trade Up feed to preview: "profitable" for contract Trade Ups, "knife" for knife and glove Trade Ups, or "all". Defaults to all. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description covers behavioral traits: free, preview-only, requires account for full data. Discloses that it provides 'locked teasers' and active contract counts, giving a clear picture of limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no fluff. Front-loaded with main action and key details. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description adequately sets expectations for the return (recipes, contract count, locked teasers). Could mention result structure or format, but for a single-param preview tool, it's sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage and enum descriptions. The description adds meaning by explaining each feed type ('profitable' for contract trade ups, 'knife' for knife/glove, 'all' for both), which helps the agent choose correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns a free preview of the Trade Up scanner with specific components (recipes, active contracts, locked teasers). Differentiates from sibling tools by naming its unique data (preview, locked teasers), but could more explicitly distinguish from other browse tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for quick preview vs. full authenticated access, but does not explicitly state when to use this tool over alternatives. Notes that full recipes require account, providing a boundary, but lacks direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_cosmeticsSearch CS2 cosmetic itemsAInspect
Search Counter-Strike 2 cosmetic items that are not weapon skins: stickers, charms, agents, patches, graffiti and music kits. Returns names and cheapest listing prices, or one item with its full detail including per-marketplace prices.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number. | |
| slug | No | Item slug. When set, returns that single item with full detail. | |
| sort | No | Result ordering. Defaults to name. | |
| search | No | Free-text item name search. | |
| category | Yes | Which kind of cosmetic item to search. | |
| per_page | No | Results per page, 1 to 25. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses that the tool returns names and cheapest listing prices for multi-result searches, or full per-marketplace prices for single-item lookup. No destructive behavior is implied. It omits mention of rate limits or auth, but those are not expected for a read-only search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. First sentence states purpose and scope, second states return format. All key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description covers the tool's purpose and behavior adequately. It explains both list and detail modes. Lacks explicit discussion of pagination behavior, but schema covers page/per_page limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds nuance: explains that 'slug' triggers single-item detail with per-marketplace prices, and 'search' is free-text. It does not explain sort enum values beyond schema, but overall adds meaningful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Search' and clearly delimits resource: CS2 cosmetic items excluding weapon skins. It lists exact categories (stickers, charms, etc.) and states two possible return formats (list with cheapest prices, or single item with full detail). This differentiates it clearly from sibling tools like search_skins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: for non-weapon cosmetics. It explains that setting slug returns full detail, which guides the agent on when to use that parameter. However, it does not explicitly state when not to use this tool (e.g., if you need weapon skins, use search_skins).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_skinsSearch CS2 skinsAInspect
Search and filter Counter-Strike 2 weapon skins by name, weapon, rarity, collection or case. Returns skin names, rarities, wear ranges and the cheapest current listing price in cents. Use get_skin_detail for a single skin with per-wear prices.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number. | |
| sort | No | Result ordering. Defaults to name. "popularity" ranks by listing quantity. | |
| crate | No | Case or capsule slug. | |
| rarity | No | Rarity name, for example "Covert", "Classified", "Restricted", "Mil-Spec Grade". | |
| search | No | Free-text skin name search, for example "Redline". Used alone it also returns matching weapons; combined with any other argument it filters the paginated skin list instead. | |
| weapon | No | Weapon slug, for example "ak-47" or "desert-eagle". | |
| per_page | No | Results per page, 1 to 25. Defaults to 10. | |
| souvenir | No | Only skins available as Souvenir. | |
| stattrak | No | Only skins available as StatTrak. | |
| collection | No | Collection slug. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description transparently reveals the tool's read-only nature (search and filter) and the data returned. It does not mention rate limits or auth, but those are not critical for this type of tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The first sentence covers purpose and filters, the second covers return values and alternative tool. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes return values. It mentions the key output fields and the alternative tool. However, it could be more complete by noting pagination or result limits, which are defined in the schema but not reiterated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional parameter semantics beyond restating the filterable fields in the first sentence, but it does provide context on the return values, which is not parameter-specific. Hence, score remains at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search and filter'), the resource ('Counter-Strike 2 weapon skins'), and lists filterable attributes (name, weapon, rarity, collection, case). It also specifies what is returned (skin names, rarities, wear ranges, cheapest listing price in cents) and distinguishes from the sibling tool get_skin_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs to use get_skin_detail for single-skin details with per-wear prices, which helps the agent choose between tools. However, no further guidance on when not to use this tool or prerequisites, though it's sufficient for a search/filter operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!