Skip to main content
Glama

Respond to My Statements

respond_to_my_statements
Read-only

Record the person's own answer to proposed statements: affirm, correct (corrected_text), expand (addition), reject, remove, place (grouping, the person's own choice), or attach_evidence (a document passage). person_words, their reply as they said it, is required for every action but attach_evidence. A correction or expansion stays unaffirmed unless affirmed is true because the person affirmed the new wording in the same reply.

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": {
      "package": "<package>",
      "responses": "<responses>"
    },
    "name": "respond_to_my_statements"
  }
}

Input Schema

NameRequiredDescriptionDefault
packageYesThe package the last GoldSeam Selfie answer returned (goldribbon_package_v1 with its selfie_interview part). Keep it for the person and send it back whole; GoldSeam keeps no copy.
responsesYes

Output Schema

NameRequiredDescriptionDefault
limitsNoWhat this answer could not do, each { code, statement }
statusNoWhat happened, or needs_attention with a problem
appliedNo
packageNoThe person's package with the interview; absent when the call could not use it
problemNoWhen status is needs_attention: code, statement, what_to_do
contractYes
statementYes
not_appliedNo
next_actionsNo
awaiting_responseNo
needs_clarificationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.5/5.0
Behavior3/5

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

Annotations only supply readOnlyHint=true, so the description does well to add a real behavioral rule: person_words is mandatory for every action except attach_evidence. However, the verb 'Record' sits in mild tension with readOnlyHint and the description never clarifies that the package is transformed and returned rather than persisted (the schema's 'GoldSeam keeps no copy' note carries that load, not the description). Nothing is said about what happens on unknown statement_id or malformed actions, or how multiple responses are validated.

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?

Two front-loaded sentences with no filler; the action list plus parenthetical payloads is an efficient mapping table in prose. The second sentence is slightly tangled, repeating 'affirmed' three times ('stays unaffirmed unless affirmed is true because the person affirmed'), which costs a beat of clarity but not space.

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?

The tool has a nested responses array with seven action-dependent field bindings, and the description covers the per-action mapping and the required-field rule well. With an output schema present, return values need no explanation. What remains missing is the multi-response contract: whether every proposed statement must be answered, whether unanswered ones are silently kept, and the stateless package-in/package-out behavior that a caller must understand.

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 only 50%, and several fields (corrected_text, addition, grouping, passage, affirmed, statement_id) have no schema descriptions at all, so this description has to compensate. It does so effectively by binding each action to its payload — correct→corrected_text, expand→addition, place→grouping as the person's own choice, attach_evidence→a document passage — and by spelling out the affirmed semantics. The 'responses' array itself is not described (batching, ordering, whether all statements must be answered), leaving a gap.

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 gives a specific verb ('Record') plus the exact resource ('the person's own answer to proposed statements') and enumerates the seven permissible actions with their payloads. That is far more specific than the bare title. It stops short of naming or contrasting any sibling (e.g., add_to_my_selfie, draft_my_claims), so the agent must infer the boundary from the action list alone.

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

Usage Guidelines3/5

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

Usage is only implied: the schema reference to 'the package the last GoldSeam Selfie answer returned' signals this is a follow-up step to the selfie flow, but the description never states when to call this versus related tools, nor any when-not condition. It does provide one piece of genuine conditional guidance (a correction/expansion stays unaffirmed unless both the new wording is affirmed in the same reply), but that governs a field, not tool selection.

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.