Obriym CRM

Check Amazon brand access

check_amazon_brand_access

Read-only

Ask Amazon whether this seller account may list a brand: allowed, approval_required (with the link to apply), not_eligible, or unknown. Amazon answers such questions per ASIN only (Listings Restrictions API) — there is no account-level brand query — so the answer is read for a SAMPLE ASIN of the brand: the one you pass, else the first catalog match whose brand equals the name. The result names the sampleAsin it was read for; when no item of the brand is found the status is unknown. Amazon has no 'application pending' state: until Amazon approves, the status stays approval_required. Reads Amazon, never writes. Use search_amazon_catalog to pick a sample ASIN, and check_amazon_readiness for a product.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "brand": "<brand>"
    },
    "name": "check_amazon_brand_access"
  }
}

Input Schema

Name	Required	Description
`brand`	Yes	The brand name as Amazon shows it, e.g. 'DEMI Design Milano'.
`sampleAsin`	No	An ASIN of the brand on this store, when you already have one (from search_amazon_catalog).
`marketplaceId`	No	One Amazon store by its id (APJ6JRA9NG5V4 is amazon.it, A1PA6795UKMFR9 is amazon.de). Omit for the main store.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, but the description adds substantial behavior beyond them: the answer is derived from a per-ASIN Listings Restrictions query, a sample ASIN is chosen (yours, else the first catalog match), the returned sampleAsin identifies the basis, and no match yields unknown. It also discloses the absence of an "application pending" state, a non-obvious quirk that prevents misinterpreting approval_required.

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?

Purpose and outcome set come first, followed by the ASIN-sampling caveat and then tool routing — a sensible front-loaded order with no filler sentences. It is dense (long em-dash clauses, several facts per sentence), which costs a small amount of readability but not accuracy.

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?

With no output schema, the description carries the return contract itself and does so fully: it names the status values, the sampleAsin field, and the unknown condition. Combined with the mutation-free, external-system framing, an agent has everything needed to call and interpret this tool.

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 coverage is 100%, so 3 is the floor, but the description goes further by explaining the role of sampleAsin (the ASIN the answer is read for) and the fallback selection when it is omitted — meaning the schema itself does not convey. marketplaceId semantics (per-store scoping) remain carried only by the schema example, keeping this just short of a 5.

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?

Opens with a specific verb and resource ("Ask Amazon whether this seller account may list a brand") and enumerates the exact outcome space (allowed, approval_required, not_eligible, unknown). This is clearly distinguishable from sibling tools like check_amazon_readiness and inspect_amazon_listings, which operate at product or listing level.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent to siblings: "Use search_amazon_catalog to pick a sample ASIN, and check_amazon_readiness for a product" — naming both the prerequisite tool and the alternative for a different scope. The account-vs-ASIN framing also tells the agent when this tool's answer is an approximation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Obriym CRM tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?