Drop Beacon

get_brand_info

Read-onlyIdempotent

Retrieve a public brand profile and see how many products it has available. Use it to check brand details without accessing internal analytics or customer records.

Instructions

Find a public brand profile and its available-product count. No internal analytics or customer records.

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": "get_brand_info"
  }
}

Input Schema

Name	Required	Description	Default
`brand`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.3.0Oct 20, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- removedInput schema / properties / api_key
```
Removed value: -{
-  "description": "Optional API key for authenticated access.",
-  "type": "string"
-}
```
- removedInput schema / properties / brand / description
```
Removed value: -"Brand name or URL slug to look up (e.g., 'Spyderco', 'chris-reeve', 'Benchmade')"
```
- addedInput schema / properties / brand / maxLength
```
Added value: +120
```
- addedInput schema / properties / brand / minLength
```
Added value: +1
```
First observedv0.2.0Apr 12, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description usefully adds that only public data is exposed and internal analytics/customer records are out of scope, but says nothing about lookup failure behavior, fuzzy matching, or data freshness.

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?

Two short sentences with the primary capability front-loaded and the scope exclusion second. No padding, though the second sentence is a bare negation that could carry more routing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool with annotations covering safety, the description does state the return content (brand profile plus available-product count), which partly offsets the missing output schema. However, the input's meaning is left entirely unexplained and no not-found/error behavior is described, leaving it only minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden for the single 'brand' parameter, and it provides nothing: no indication whether 'brand' is a name, slug, or ID, and no format or matching guidance. This is a clear gap the description should have compensated for.

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 names a specific verb ('Find') and resource ('public brand profile and its available-product count'), so an agent can distinguish it from product-search siblings like search_products. It stops short of naming or contrasting any sibling explicitly, so it lands at 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?

The clause 'No internal analytics or customer records' draws a boundary that implies when this tool is appropriate (public brand data lookups only), but it never states when to use it over search_products or check_availability, nor any prerequisites. Usage is implied rather than instructed.

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

Deploy Server