Skip to main content
Glama

Red by Big Red Cloud

List Customer Quotes

brc_list_customer_quotes
Read-only

Gets quotes for a specific customer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemIdYesCustomer item id.
companyNameYesCompany context name, for example YOUR-COMPANY-NAME.
connectionRefNoOpaque Red connection reference returned by brc_confirm_company_connection. Pass this exact value on every later tool call when the MCP client rotates session ids (for example Vibe/Mistral). Keep reusing the same connectionRef after successful tool calls — do not start a new connection because a lookup returned empty or partial data. It is not an API key and does not contain credentials.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description's 'Gets' aligns with those. It adds no further behavioral context, such as empty-result behavior, pagination, or relationship to the caller's connection.

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 a single focused sentence with no filler. The scoping word 'specific' is meaningful and front-loaded, making the description appropriately compact.

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 read-only list tool, the bare description is borderline sufficient, but with no output schema, the agent still receives no guidance about return shape or empty-result semantics. It also doesn't mention how this list tool relates to the broader connection/session guidance already present in the parameter schema.

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

Parameters3/5

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

The description itself adds no parameter-level meaning, but schema description coverage is 100% and the input schema already explains itemId, companyName, and connectionRef in reasonable detail. The connectionRef description is especially useful.

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 states a clear action ('Gets quotes') and a clear resource ('quotes for a specific customer'), which distinguishes it from generic quote-listing tools. However, it does not explicitly contrast with a sibling like brc_list_quotes or brc_get_quote, and 'Gets' is slightly less specific than the title's 'List'.

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?

The phrase 'for a specific customer' gives only a weak usage context. The description does not tell the agent when to choose this over brc_list_quotes, how to obtain the required itemId, or how connectionRef relates to the tool operation.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.