Trusted Vendors

Get offers

get_offers

Read-onlyIdempotent

A vendor's offers: public offers in full; network-tier offers only as "Offer available" with a banded amount; redemption URLs for VC-backed companies (redemption.vc_backed) and any other startup (redemption.public). For vendors whose startup offers only go through investor networks (flow network_only): the statement, the work-email check URL and public deals in the same category. Each public offer has about: who_qualifies, customers (new / existing), limits and stacking quoted verbatim from the terms, and the full terms, only where the data says.

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": {
      "name_or_domain": "<name_or_domain>"
    },
    "name": "get_offers"
  }
}

Input Schema

Name	Required	Description	Default
`name_or_domain`	Yes	Vendor name, domain or profile URL.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

B3.3/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), and the description adds real behavioral detail beyond them: network-tier offers are redacted to 'Offer available' with a banded amount, and network_only vendors yield the statement, a work-email check URL, and same-category public deals. This redaction and branching behavior is genuinely useful context an agent could not get from the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is front-loaded and free of filler, but it is packed into one dense, jargon-laden passage with tangled clauses like 'and the full terms, only where the data says'. It conveys a lot per sentence yet is harder to parse than a short structured list would be.

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?

With no output schema, the description carries the burden of explaining return values, and it does list fields (who_qualifies, customers, limits, stacking, terms) and their conditional presence. However, it omits the response envelope, what a 'banded amount' looks like, and error/empty behavior for an unknown vendor, leaving meaningful gaps for a data-retrieval tool.

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?

With a single parameter at 100% schema description coverage, the schema already explains that name_or_domain accepts a vendor name, domain, or profile URL. The description adds nothing about input formats or what happens for an unrecognized vendor, so the baseline of 3 applies.

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 clearly identifies the resource as a vendor's offers and specifies the sub-categories returned: public offers, network-tier offers, and redemption URLs for VC-backed vs. other startups. It is specific about scope, but the retrieval verb is only implied and terms like 'flow network_only' and 'banded amount' are never defined, so an agent must infer their meaning.

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?

There is no statement of when to call this instead of siblings such as get_vendor, get_packs, or find_vendors, and no prerequisites or exclusions are given. The conditional branches (network_only vendors, network-tier offers) describe what the tool returns, not when the agent should choose it.

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

All Trusted Vendors 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?