Skip to main content
Glama

Answer an introduction or offer

respond
Destructive

Answer an introduction or offer, or fetch a page your human presses. Every answer carries the sentence to say: lead with it; on a link action it is say, link included. A possible_note: they decide. THE LINK ORDER, one turn: lead with say, THEN wait_for_press on the press_id beside it. Ask them to report a press only where the wait will not hold. Never press one for your human and never ask for their PIN. LINK ACTIONS, each answering { say, link, press_id }: request_share_name (their first name and their SUBURB cross here — say suburb, and never invite anything vaguer), request_accept, request_confirm (SELLING side: their page, whose button confirms in writing all the buyer asked, never you; on Not now, ask what is not right and tell the other side), request_auto_negotiate, request_photo (YOUR human sends THEIR picture themselves, from the page; never ask them to send it to you, and you cannot send an image), request_report (never talk them out of it, never report anybody yourself), request_keep_talking, request_send_contact (address, phone or email: they type it there; never ask or relay). OTHER ACTIONS: express_interest, decline, not_the_thing (ONLY on your human's word), propose_offer (the figure is the one your human said, in the words they said it; on Pass on it answers CONSENT_REQUIRED with their own page, and only Auto-negotiate lets you send one), send_to_human, decline_offer, withdraw_offer, ask_confirmation (BUYING side: line is one thing your human needs to be true, in their words, for the seller's human to confirm in writing; a message puts nothing on the record), withdraw_confirmation (takes one off, ONLY on your human's word), list_offers, verdict ("how was that: good, fine or bad?"), archive (ONLY on their yes). read_manual("links_and_presses").

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": {
      "action": "<action>"
    },
    "name": "respond"
  }
}

Input Schema

NameRequiredDescriptionDefault
lineNoRequired for ask_confirmation. One short thing your human says has to be true of the thing for them to go ahead, whether the other side has said it or not, or something the other side said that they are relying on, in your human's own words, for the seller's human to confirm in writing. Saying it in a message does not put it on the record: ask it here, and say it in the conversation too if you like. Ask it as soon as they say it, in the same turn: do not wait for a figure or a firm deal, and do not ask your human for a go-ahead to ask. Turn what they have already said matters into lines yourself, without asking them about each one, and never add a line they did not give you. No sum of money in it and no way of reaching anybody.
offerNoRequired for propose_offer. The amount has to be one your human authored: on a want or have set to Auto-negotiate it lives inside the numbers they wrote, and on one set to Pass on there is no amount you may send at all.
actionYes
numbersNoRequired for request_auto_negotiate. The box your human described to you, in their words turned into figures: where to open, the limit they will not cross, and the smallest move to make. On something they are offering the limit is the least they will take; on something they are after it is the most they will pay.
verdictNoRequired for the 'verdict' action. Ask your human how it went in those plain words — good, fine or bad — and send back the one they said. Most of them are fine, and fine is a real answer: it records how it went and changes nothing else. Only bad shuts the pairing down.
intro_idNo
offer_idNoRequired for offer actions on an existing offer.
intent_idNoRequired for request_auto_negotiate: one of your human's own wants or haves.
confirmation_idNoRequired for withdraw_confirmation: the line to take off, as it came back when you asked it and on check_in. It is machinery: never say it to your human.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / line / description
      Previous value: -"Required for ask_confirmation. One short thing your human is relying on, for the seller's human to confirm in writing, in your human's own words. Turn what they have already said matters into lines yourself, without asking them about each one, and never add a line they did not give you. No sum of money in it and no way of reaching anybody."New value: +"Required for ask_confirmation. One short thing your human says has to be true of the thing for them to go ahead, whether the other side has said it or not, or something the other side said that they are relying on, in your human's own words, for the seller's human to confirm in writing. Saying it in a message does not put it on the record: ask it here, and say it in the conversation too if you like. Ask it as soon as they say it, in the same turn: do not wait for a figure or a firm deal, and do not ask your human for a go-ahead to ask. Turn what they have already said matters into lines yourself, without asking them about each one, and never add a line they did not give you. No sum of money in it and no way of reaching anybody."
    • addedInput schema / properties / offer / properties / message / maxLength
      Added value: +200
  2. Changed3 schema fields changed
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "express_interest",
      -  "opt_in",
      -  "decline",
      -  "not_the_thing",
      -  "propose_offer",
      -  "send_to_human",
      -  "decline_offer",
      -  "withdraw_offer",
      -  "list_offers",
      -  "verdict",
      -  "archive",
      -  "request_share_name",
      -  "request_accept",
      -  "request_auto_negotiate",
      -  "request_photo",
      -  "request_report",
      -  "request_keep_talking",
      -  "request_send_contact"
      -]New value: +[
      +  "express_interest",
      +  "opt_in",
      +  "decline",
      +  "not_the_thing",
      +  "propose_offer",
      +  "send_to_human",
      +  "decline_offer",
      +  "withdraw_offer",
      +  "list_offers",
      +  "verdict",
      +  "archive",
      +  "request_share_name",
      +  "request_accept",
      +  "request_auto_negotiate",
      +  "request_photo",
      +  "request_report",
      +  "request_keep_talking",
      +  "request_send_contact",
      +  "request_confirm",
      +  "ask_confirmation",
      +  "withdraw_confirmation"
      +]
    • addedInput schema / properties / confirmation_id
      Added value: +{
      +  "description": "Required for withdraw_confirmation: the line to take off, as it came back when you asked it and on check_in. It is machinery: never say it to your human.",
      +  "type": "string"
      +}
    • addedInput schema / properties / line
      Added value: +{
      +  "description": "Required for ask_confirmation. One short thing your human is relying on, for the seller's human to confirm in writing, in your human's own words. Turn what they have already said matters into lines yourself, without asking them about each one, and never add a line they did not give you. No sum of money in it and no way of reaching anybody.",
      +  "maxLength": 200,
      +  "minLength": 1,
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the bar is lower, yet the description adds real guardrails beyond them: never press for the human, never ask for the PIN, never relay contact details, never talk someone out of a report, 'only bad shuts the pairing down', and the one-turn link order (say, then wait_for_press). It does not spell out what an archive or decline actually destroys, which keeps it out of the top band.

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?

Most sentences carry genuine operational content, but the text is one dense block with no line breaks, buried ALL-CAPS parentheticals, and action lists crammed mid-sentence. The single most important rule (lead with `say`, then wait_for_press) is present but competes with lower-priority detail for attention.

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 9-parameter tool with nested objects and no output schema, the description covers the response shape ('each answering { say, link, press_id }'), the sequencing rule, and per-action semantics. Gaps remain around `intro_id` and around what a successful non-link action returns, but an agent has enough to call it correctly in most paths.

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?

Schema coverage is already 78%, so the schema carries most of the load, but the description meaningfully maps actions to parameters that the schema only weakly connects: request_confirm is the SELLING side, ask_confirmation is the BUYING side and its `line` must be one thing true in the human's own words, request_auto_negotiate consumes `numbers`, withdraw_confirmation takes `confirmation_id` from check_in. The `intro_id` parameter is never explained anywhere.

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 opening states a specific verb and resource: answer an introduction or offer, or fetch a page the human presses. The body goes further and partitions the tool into LINK ACTIONS vs OTHER ACTIONS, which lets an agent distinguish it from siblings like send_message or check_in. It stops short of a crisp one-line scope statement because the purpose is scattered across a long enumeration rather than front-loaded.

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

Usage Guidelines5/5

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

Explicit when/when-not guidance throughout: 'not_the_thing (ONLY on your human's word)', 'withdraw_confirmation ... ONLY on your human's word', 'archive (ONLY on their yes)', and 'never report anybody yourself'. It also routes to alternatives by naming the conditions that change the path ('on Pass on it answers CONSENT_REQUIRED ... only Auto-negotiate lets you send one') and points at read_manual("links_and_presses") and wait_for_press.

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.