LicenseSaaS

make_offer

Make an offer on a listing as a buyer: the total amount (USD), deal type and terms. The seller (or their agent) can accept, counter or decline. Ask your user for the amount before offering. An accepted offer still needs its owner's confirmation before it becomes a deal, and payment is always made by a person.

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": {
      "listing": "<listing>",
      "amount": "<amount>",
      "deal_type": "<deal_type>"
    },
    "name": "make_offer"
  }
}

Input Schema

Name	Required	Description	Default
`amount`	Yes	Total offered in USD, e.g. 5000.
`listing`	Yes	Listing slug or id, e.g. "textback".
`message`	No	What you need and why; shown to the seller.
`timeline`	No	When you need it, e.g. "within 1 month".
`use_case`	No	How you'll use or resell it.
`agent_key`	No	Your agent key (register_agent gives one). Over REST or A2A, send it in the X-Agent-Key header instead.
`deal_type`	Yes	Must be allowed by the listing (licensing, white-label or both).
`company_name`	No	Buyer company shown to the seller.
`payment_terms`	No	Payment terms, e.g. "50% upfront, 50% on launch".
`geographic_scope`	No	Where the licence applies, e.g. "worldwide" or "United States".
`payment_structure`	No	How the amount is paid.	one_time
`exclusivity_requested`	No	true to ask for exclusivity.

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedNov 6, 2026

changedInput schema / properties / amount / description

Previous value: -"Total offered, in USD."New value: +"Total offered in USD, e.g. 5000."

addedInput schema / properties / company_name / description
```
Added value: +"Buyer company shown to the seller."
```

addedInput schema / properties / deal_type / description

Added value: +"Must be allowed by the listing (licensing, white-label or both)."

addedInput schema / properties / exclusivity_requested / description
```
Added value: +"true to ask for exclusivity."
```

changedInput schema / properties / geographic_scope / description

Previous value: -"Where the licence applies, e.g. worldwide or United States."New value: +"Where the licence applies, e.g. \"worldwide\" or \"United States\"."

changedInput schema / properties / listing / description

Previous value: -"Listing slug or id."New value: +"Listing slug or id, e.g. \"textback\"."

addedInput schema / properties / payment_structure / description
```
Added value: +"How the amount is paid."
```

addedInput schema / properties / payment_terms / description

Added value: +"Payment terms, e.g. \"50% upfront, 50% on launch\"."

addedInput schema / properties / timeline / description

Added value: +"When you need it, e.g. \"within 1 month\"."

addedInput schema / properties / use_case / description
```
Added value: +"How you'll use or resell it."
```

AddedNov 3, 2026

TDQS

A4.1/5.0

Behavior4/5

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

The annotations already establish that this is a non-destructive, non-idempotent, open-world write. The description adds valuable workflow context beyond that: the seller can accept, counter, or decline; an accepted offer still needs the owner's confirmation before becoming a deal; and payment is always made by a person. It does not cover error behavior or rate limits, but it meaningfully clarifies the negotiation lifecycle.

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?

The description is front-loaded with the core action and four short sentences, each adding something useful: the offer terms, the seller response, the user-amount prerequisite, and the post-acceptance/human-payment caveat. It is efficient, though slightly dense and could be tightened marginally.

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?

For a 12-parameter write tool with no output schema, the description covers the essential workflow, negotiation outcome, and human confirmation requirements. It still omits what the tool returns and how errors or duplicate offers are handled, but it is complete enough for an agent to call it correctly.

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?

Schema description coverage is 100%, so the schema already carries the parameter semantics. The description only summarizes amount, deal type, and terms, without adding syntax or constraints beyond what the schema provides, which is the baseline case for full-coverage schemas.

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?

The description states a specific verb and resource: 'Make an offer on a listing as a buyer,' and names the core fields amount, deal type, and terms. The 'as a buyer' framing distinguishes it from respond_to_offer, which handles the seller side of the same workflow.

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

Usage Guidelines4/5

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

It gives clear context for when to use the tool and adds a concrete prerequisite: 'Ask your user for the amount before offering.' It does not name alternatives or exclusions, such as using send_inquiry for questions or create_buyer_request for non-offer requests.

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

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