asinrating

Get Brand

get_brand

Read-onlyIdempotent

Return brand registry aggregates: product count, complete-profile count, category distribution, price bands and per-platform social coverage. Brand names are platform names; no alias merging is performed.

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_name": "<brand_name>"
    },
    "name": "get_brand"
  }
}

Input Schema

Name	Required	Description	Default
`brand_name`	Yes	platform brand name or brand slug

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 11, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- addedInput schema / properties / brand_name / description
```
Added value: +"platform brand name or brand slug"
```
- removedInput schema / properties / brand_name / title
```
Removed value: -"Brand Name"
```
- removedInput schema / title
```
Removed value: -"get_brandArguments"
```
- changedOutput schema / (root)
```
Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
```
AddedNov 4, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context, and it does: it lists exactly which aggregates come back and discloses the non-obvious rule that no alias merging occurs, which directly affects result interpretation. It doesn't mention behavior for unknown or unmatched brand names, which keeps it from a 5.

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?

Two sentences, no filler, and the return contents are front-loaded before the caveat. Every clause carries information the agent cannot get from the schema or annotations.

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?

Return values are covered by an output schema and the safety profile by annotations, so the description only needs to explain scope and the alias caveat, which it does. The remaining gap is what happens when a brand is not found or has no social coverage, which would matter for a registry lookup.

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 a single parameter and 100% schema coverage, the baseline is 3; the description earns the extra point by adding a real matching constraint the schema does not state — that the value must be a platform brand name and that no alias merging will rescue a near-miss. That changes how an agent should construct the argument.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Return') plus a specific resource ('brand registry aggregates') and then enumerates the contents: product count, complete-profile count, category distribution, price bands, and per-platform social coverage. That clearly separates it from product-level siblings like get_product or get_price. It stops short of naming an alternative, so 4 rather than 5.

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?

There is one strong usage constraint — brand names must be platform names because no alias merging is performed — which tells the agent how to call it correctly, not when to choose it. No explicit when-to-use or when-not-to-use guidance relative to siblings is given; the intended use is only implied by the enumerated aggregate fields.

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

All asinrating 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?