Skip to main content
Glama

respond

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").

Input Schema

TableJSON 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

A3.6/5.0
Behavior4/5

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

With no annotations, the description must carry the full behavioral burden. It discloses many non-obvious behaviors: the link order (lead with say, then wait_for_press), never pressing for the human, never asking for a PIN, who confirms on request_confirm, consent requirements for propose_offer, and return shape features like say, link, press_id, and possible_note. It stops short of describing error handling or authentication/rate limits, so a 4 is appropriate.

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

Conciseness2/5

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

The text is a dense, run-on block with heavy capitalization, parentheticals, and sentence fragments. While some sections are front-loaded (general answer, link order, link actions, other actions), the overall effect is difficult to parse and far from concise. Many sentences do earn their place for a 21-action tool, but the structure and brevity are poor.

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?

Given the tool's complexity (21 enum actions, nested objects, 9 parameters, no output schema), the description is remarkably thorough on usage rules and per-action behavior. However, it omits the `opt_in` action entirely and does not explain `intro_id`, leaving an agent without guidance for two enum values. The absence of return value details is acceptable since no output schema exists, but the action gap keeps this from a 5.

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 description coverage is 78%, so the baseline is 3. The description adds substantial meaning beyond schema: the `line` semantics for ask_confirmation, the source and limits of the `offer` amount for propose_offer, the negotiated box for `numbers`, the three verdict words, and the machine-only nature of `confirmation_id`. It does not explain `intro_id` at all, preventing a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a broad verb and resource ('Answer an introduction or offer, or fetch a page your human presses'), but the purpose is immediately buried under an exhaustive enumeration of 21 actions. It does not clearly distinguish this tool from siblings like send_message or wait_for_press, though it does mention read_manual and wait_for_press relationships later.

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?

The description provides extensive when-to-use and when-not-to-use guidance for specific actions: 'ONLY on your human's word' for not_the_thing and withdraw_confirmation, 'never press one for your human', 'on Pass on it answers CONSENT_REQUIRED', etc. It lacks a high-level routing statement for choosing this tool over alternatives, but the per-action conditions are rich and explicit.

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.