Search Assetzaar's catalog of UI components, agent skills, SaaS kits and automations.
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.
Average 4.3/5 across 7 of 7 tools scored.
Most tools have clearly distinct purposes, but there is some overlap: search and search_components both find products (one whole marketplace, one UI components only), and get_component and inspect both retrieve product information (one for source, one for manifest). These are distinguishable by their descriptions and use cases.
The tools follow a mostly consistent verb-based pattern with snake_case (check_purchase, get_component, search_components), but three tools are single verbs without an object (inspect, install, purchase). This is a minor deviation from the verb_noun convention used by the others.
Seven tools is well-scoped for a marketplace server. Each tool covers a necessary step in the workflow (search, evaluate, purchase, install) without bloat, and there are no redundant utilities.
The tool set covers the full marketplace lifecycle: discovery (search, search_components), evaluation (inspect, get_component), acquisition (purchase, check_purchase), and installation (install). The flow from search to install is seamless, with no obvious dead ends or missing critical operations.
check_purchaseAInspectCheck whether a purchase started with the purchase tool has been approved and paid. Returns status: pending | paid | expired. Once paid, the entitlement is granted and install returns the source or signed download URL.
| Name | Required | Description | Default |
|---|---|---|---|
| purchase_id | Yes | The purchase_id returned by the purchase tool. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly says this is a check ('Check whether') and discloses the three possible statuses and the consequence of a paid status. It does not mention side effects or error conditions, but for a simple status check this is sufficient.
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 long, front-loaded with the primary purpose, and every phrase adds value: the statuses, the entitlement effect, and the install connection. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status-check tool with one well-documented parameter and no output schema, the description fully covers the essential behavior: what it checks, possible outcomes, and what happens when paid. It is complete without needing further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the only parameter (`purchase_id`) with a clear description ('The purchase_id returned by the purchase tool'), achieving 100% schema coverage. The description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check whether') and clearly identifies the resource (a purchase started with the `purchase` tool). It also differentiates from siblings by explicitly referencing the purchase flow and the resulting status values.
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: after starting a purchase with the `purchase` tool, to check its status. It also ties to the `install` tool outcome ('Once paid, the entitlement is granted and install returns...'), providing clear context. No explicit exclusions or alternatives are stated, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_componentAInspectGet a component by slug. Free components return installable source. With an agent key (Authorization: Bearer azr_…), paid components the account owns and Pro components covered by an active membership return source too. Otherwise returns how to buy (see the purchase tool).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The component slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It transparently states the auth requirement (Bearer azr_…), conditional returns for free/owned/pro components, and the fallback to purchase info, covering all key behaviors.
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, front-loaded with the core action, and packs auth, conditions, and alternatives without redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description adequately explains return values (source vs how to buy) and access conditions. For a simple one-parameter retrieval tool, it is complete and contextual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the slug parameter with 100% coverage. The description merely repeats 'slug' without adding extra semantic detail, fitting the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with resource 'component by slug', clearly distinguishing it from search/install tools. It further clarifies scope by stating which components return source and references the purchase tool for others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly outlines conditions for source access (free vs paid/pro with agent key) and directs users to the purchase tool for non-source cases. However, it does not explicitly mention when to use search or inspect instead, 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.
inspectAInspectGet the full machine-readable manifest for one product by slug — type, version, author (verified?), license, price, dependencies, security-scan status, compatibility and install command — so you can evaluate it before installing.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The product slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It clearly indicates a read-only 'get' operation and lists the returned data fields, but does not explicitly state the absence of side effects, permission requirements, or any potential rate limits. It provides a moderate level of transparency about what the tool does and returns, but lacks explicit safety/behavioral disclaimers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that leads with the primary action and resource, then uses an em-dash to enumerate contents. No wasted words; every part adds value. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema and absence of an output schema, the description compensates well by listing the manifest's contents (type, version, license, etc.) and its intended use. It tells the agent what to expect without over-specifying. Minor gap: it does not specify the exact output format (e.g., JSON), but 'machine-readable manifest' is reasonably clear.
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% (slug has a description), so the baseline is 3. The description adds 'by slug' and that it targets one product, but does not elaborate further on the slug parameter beyond what the schema already states. It adds a slight contextual framing but does not significantly compensate beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a full machine-readable manifest for one product by slug, listing specific fields (type, version, author, etc.). It distinguishes itself from siblings like install (which would install) and search (which searches) by focusing on inspection/evaluation.
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 explicitly says 'so you can evaluate it before installing', giving a clear use case. It implies it should be used for pre-install evaluation, though it does not explicitly contrast with alternative tools. The guidance is sufficient for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
installAInspectInstall any agent-installable Assetzaar product by slug. Free products return source or a short-lived signed download URL. Paid products require an agent key plus ownership; Pro products require an agent key plus active membership. For paid products, call purchase/check_purchase first.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The product slug to install. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses return behavior for free products ('source or a short-lived signed download URL') and licensing requirements for paid/Pro products, but does not specify what the return value is for paid products or any side effects of installation.
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 concise, two sentences long, and front-loaded with the core purpose. Every sentence provides useful information 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 tool with one parameter, no annotations, and no output schema, the description covers the main aspects: what it does, variant behavior (free vs paid), prerequisites, and a required pre-call. It does not describe the output format for paid products, which is a minor gap but not critical for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'slug' parameter, so the schema already defines it. The description adds context about 'agent-installable' and the slug's role, but this is minimal beyond what the schema provides, hence the baseline score.
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 'Install any agent-installable Assetzaar product by slug' with a specific verb and resource, and it distinguishes itself from sibling tools like check_purchase, get_component, and purchase by focusing on installation.
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?
Provides explicit guidance: 'For paid products, call purchase/check_purchase first' and outlines the different requirements for free/paid/Pro products, giving clear direction on when and how to use the tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchaseAInspectStart a purchase of a paid Assetzaar product for the connected account. Requires an agent key (Authorization: Bearer azr_…, created at assetzaar.com/account/agent-keys). Returns a Stripe approval URL — the HUMAN must open it and approve payment; the agent can never charge anyone by itself. After approval, call check_purchase, then install.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The product slug to buy. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses the need for an agent key, the return of a Stripe approval URL, and that the agent cannot charge anyone by itself. It also outlines the post-approval steps, providing strong behavioral context beyond basic 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?
The description is three sentences: purpose, auth/return value, and next steps. Each sentence adds distinct value with no redundancy, making it highly concise 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?
Despite lacking an output schema and annotations, the description supplies the essential return value (Stripe approval URL), required authentication, and the follow-up workflow. This is sufficient for a tool with one parameter and a simple flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the 'slug' parameter with 'The product slug to buy,' achieving 100% coverage. The description adds little beyond this, only framing it as a paid product, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Start a purchase of a paid Assetzaar product for the connected account,' using a specific verb and resource. It distinguishes itself from siblings like check_purchase, install, and search by focusing on initiating the purchase flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly requires an agent key and instructs the user to 'call check_purchase, then install' after approval. This provides a clear workflow and tells the agent when to use this tool relative to alternatives, along with the critical human-approval step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchAInspectSearch the whole Assetzaar marketplace (agent skills, UI components, production modules, SaaS kits, automations and services). Returns machine-readable manifests with type, price, security-scan status, compatibility and install command. Use this to find a product to build with.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional filter: components | agent-skill | saas-kit | landing | automation | service. | |
| limit | No | Max results (1-25, default 10). | |
| query | No | What to search for (name, summary, technology). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden and does well by disclosing that the tool returns machine-readable manifests and lists specific fields (type, price, security-scan status, compatibility, install command). This gives the agent concrete expectations about the output, though it omits any mention of rate limits or auth requirements.
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 and immediately states the action, scope, and return value. Every sentence adds value, and the structure is front-loaded with 'Search the whole Assetzaar marketplace' before listing details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, optional-parameter search tool with no output schema, the description adequately covers what the tool does, what it returns, and when to use it. It could mention pagination or behavior with no query, but the given details are sufficient for basic 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?
Schema description coverage is 100%, so the schema already provides clear meanings for 'type', 'limit', and 'query'. The description reiterates the categories but adds no additional parameter-level semantics beyond what the schema offers, warranting the baseline score.
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 a specific verb ('Search') and the resource ('whole Assetzaar marketplace'), naming the categories it covers. It distinguishes itself from the narrower sibling 'search_components' by emphasizing the entire marketplace, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this to find a product to build with,' providing clear usage context. It does not explicitly mention when not to use it or name alternatives like search_components, but the scope (whole marketplace) implies its broad applicability, earning a solid 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_componentsAInspectSearch Assetzaar's marketplace for UI components by name, category or technology. Returns matches with slugs and install commands.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior. It states that the tool 'returns matches with slugs and install commands', providing some insight into output. However, it does not mention other behavioral aspects like whether it requires authentication, pagination, or ordering. It adds some value beyond the schema but does not fully compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action ('Search') and the resource ('Assetzaar's marketplace for UI components'). It contains no filler words and conveys both purpose and return type in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately covers the essential aspects: what to search, the context (marketplace for UI components), and what is returned (matches with slugs and install commands). It could mention edge cases or additional constraints, but it is sufficiently complete for a straightforward search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the single parameter 'query' as 'What to search for', which is generic. The description adds meaning by specifying that the search can be 'by name, category or technology', giving the agent useful context for constructing queries. Since schema coverage is 100%, this extra guidance raises the score above 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 explicitly states 'Search Assetzaar's marketplace for UI components' with a specific verb and resource, and mentions searchable attributes (name, category, technology). It distinguishes itself from the sibling tool 'search' by narrowing scope to marketplace UI components and noting the return type (slugs and install commands).
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 makes clear the tool is for searching UI components in Assetzaar's marketplace, which implies when to use it. However, it does not explicitly mention any exclusions or alternatives, such as advising to use the generic 'search' for other types of searches. This is clear context but lacks explicit 'when-not-to-use' guidance.
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.
No comments yet. Be the first to start the discussion!