Catalog Services MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct resources (products, variants, overrides, categories, environments, store views). One pair, get_environment_details and get_environment_store_views, has overlapping functionality but is differentiated by output structure.
Naming Consistency4/5
All tools use snake_case with a verb-noun pattern. The slight inconsistency of 'find_' versus 'get_' for one tool is minor.
Tool Count5/5
With 7 tools covering environment info, store views, products, variants, overrides, and permissions, the count is well-scoped for a read-only catalog service.
Completeness4/5
The tool set covers key read operations for a catalog service. Missing search or mutation capabilities, but those may be out of scope for this server.
Average 4.1/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses the HTTP endpoint, return structure (status, environments, count), and example output. However, no annotations exist, and the description lacks details on authentication, rate limits, side effects, or error handling. The read-only nature is implied by 'Get' but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with Args, Returns, and an Example section. It is relatively concise for the information provided, though the example could be shortened. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the siblings cover narrower use cases, the description fully covers input, output, endpoint, and usage example. No gaps remain 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description adds crucial meaning: environment_ids gets a realistic example and explanation; timeout gets default and units. Both parameters are well described beyond the bare schema.
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?
Description clearly states the tool retrieves environment details from Catalog Service, naming the endpoint and specifying content (websites, store views, export details). It distinguishes from more specific siblings like get_environment_store_views, though not explicitly limiting scope.
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: call when environment details are needed. However, no explicit guidance on when to use this tool vs. siblings (e.g., get_environment_store_views for store views only) or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return structure and includes an example, which is helpful. But with no annotations, it does not explicitly state read-only nature or potential side effects, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections and an example, but the first two sentences are slightly redundant. Overall, it is appropriately 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?
Provides purpose, parameters, return structure, and an example. For a query tool, this is adequate. Lacks error handling details but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema coverage is 0%, the description fully compensates by clearly explaining each parameter's meaning, including defaults and role (filter by, timeout).
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?
Clearly states the tool finds and filters store views by website and/or store code, with a specific use case. However, it does not explicitly differentiate from sibling tool get_environment_store_views, which may also list store views.
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?
Provides a specific use case for discovering store view codes when website and store codes are known. However, it does not discuss when not to use this tool or mention alternatives explicitly.
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 full burden. It states it retrieves product information, implying no destructive actions, but lacks details on authentication, rate limits, error handling, or data freshness. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a heading, Args/Returns/Example sections. Front-loaded with purpose. Slightly long but each part earns its place; could be condensed slightly but remains clear.
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?
Covers parameters, return structure, and an example. The output schema exists (though not shown) so return values need not be fully explained. Missing details like error codes or pagination, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description provides meaningful parameter descriptions for all 7 parameters (e.g., 'environment_id: Adobe Commerce Cloud environment ID') and specifies defaults for timeout and use_tls, adding 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 it gets product details from Catalog Service via gRPC, citing the GetProducts RPC method. It distinguishes from siblings like get_category_permissions by focusing on products.
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 the sibling tools. It does not mention alternatives or contexts where this tool is preferred, merely documenting the function.
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?
No annotations are provided, so the description carries full burden. It describes the tool as retrieving environment details and extracting store views, and mentions the return structure. However, it does not disclose any behavioral traits like idempotency, side effects, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Example sections. It is somewhat lengthy but each part is relevant. The example is helpful. Slight over-explanation could be trimmed, but overall effective.
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?
The tool has two parameters and no output schema in the data, but the description defines the return structure in detail. It provides enough context for an agent to understand inputs and outputs. However, it does not mention any prerequisites or typical usage patterns relative to sibling tools.
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?
Schema description coverage is 0%, so description must compensate. It provides clear semantics for both parameters: environment_id is an Adobe Commerce Cloud environment ID, and timeout is in seconds with a default of 15.0. This adds meaning beyond the minimal 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 gets all store views for a specific environment, using a specific verb and resource. It distinguishes itself from sibling tools like find_store_view_codes by focusing on a flattened structure of store views, websites, and codes.
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 explains it is a 'convenience tool' that retrieves environment details and extracts store views, implying it is an alternative to get_environment_details. However, it does not explicitly state when to use this tool vs alternatives, nor does it provide exclusions or prerequisites.
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 exist, but the description fully discloses the operation (read via gRPC), the parameters, and the return format. It implies a read-only action without explicit statement, but the 'Get' verb and the example output suggest no side effects. One could argue a 5, but the lack of explicit statement on mutability or error behavior keeps it at 4.
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 well-structured with clear sections (Args, Returns, Example) and is appropriately sized. Every sentence adds value, with no fluff. The most important information (what, how, params) is front-loaded.
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?
The description includes parameter details, return format, and an example, making it complete for a retrieval tool. However, it does not mention error handling or edge cases (e.g., what happens if environment_id is invalid), and with no annotations, a bit more context on expected status codes could be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the tool description provides thorough explanations for all four parameters, including defaults, optionality, and examples (e.g., environment_id format, category_ids as optional list, use_tls default, timeout default). This adds significant semantic 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 action ('Get category permissions'), the service ('Catalog Service via gRPC'), and the resource ('category permission information'), distinguishing it from siblings which deal with store views, environments, products, etc.
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 explains what the tool does but does not provide explicit guidance on when to use it versus alternatives or when not to use it. The purpose is clear enough to infer usage, but no comparative context is given.
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 carries the full burden. It discloses the RPC method used (GetVariants), the return structure with keys and example values, and includes an example. However, it does not mention side effects, authentication needs, error handling, or rate limits. Overall, it provides good behavioral context for a 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (Args, Returns, Example) and is appropriately detailed. However, it is slightly longer than necessary; for example, the full example could be shortened. Still, the organization aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters (5 required), no output schema, and no annotations, the description is very complete. It documents all parameters, provides a return value schema, and includes a usage example. It leaves no significant gaps for an agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description's Args section adds detailed explanations for all 7 parameters, including environment_id, store_view_code, skus, etc., with examples. This fully compensates for the missing schema descriptions and adds meaning beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves product variants from Catalog Service via gRPC, explains what product variants are (configurable product options), and provides specific verbs and resource names. It distinguishes from siblings like get_products by focusing specifically on variants of configurable products.
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 does not explicitly state when to use this tool versus alternatives like get_products. It implies usage through the context of retrieving variants, but lacks guidance on prerequisites or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It explains that this is a retrieval operation (non-destructive), describes the return format in detail, provides an example with decoding of customer_group_code, and lists all parameters with defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes an Args section, Returns section, and an Example, which is well-structured. It is somewhat verbose but every sentence adds value, especially the example and hash codes. Slightly longer than necessary but not wasteful.
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 tool with 6 parameters (3 required) and an output schema, the description fully covers the input parameters, output structure, and usage. The example and hash code mapping provide additional context that compensates for the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully explains each parameter: environment_id, website_code, skus, filter_virtual_cgs, use_tls, timeout, with defaults and types. This adds significant meaning beyond the bare 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 it gets product overrides for all customer groups in a website, using the verb 'get' and specifying the resource. It distinguishes itself from sibling tools by emphasizing 'all customer groups', which is unique.
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 says 'Useful when you need to see pricing across all customer segments', which provides usage context. However, it does not explicitly mention when not to use it or suggest alternative tools for single-group queries, but the sibling tools list does not have an obvious single-group counterpart.
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:

[![catalog-services-mcp MCP server](https://glama.ai/mcp/servers/kavingas/catalog-services-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kavingas/catalog-services-mcp)

Score Badge

Copy to your README.md:

[![catalog-services-mcp MCP server](https://glama.ai/mcp/servers/kavingas/catalog-services-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kavingas/catalog-services-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/kavingas/catalog-services-mcp'

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