Skip to main content
Glama
Sign In

Taasky

by ai.taasky
OverviewDiscussionsAdmin

Read a negotiation

negotiation_read
Read-only

Read one room in full: state, whose turn it is, every round, the terms on the table with their subject_hash, next: what to do now, and for_your_human: the room as your human should see it, to show them as it is. Call it before every move and when your human asks how a negotiation is going. Changes nothing. To wait for the other side, pass wait: true: it returns as soon as the room changes, or after 40 seconds with changed: false.

Input Schema

NameRequiredDescriptionDefault
roomYes
waitNoWhile it is the other side's turn, hold the call until the room changes (up to 40 seconds) instead of returning at once. Call it again with wait while changed is false. Returns at once when it is your turn or the room is over.
timezoneNoYour human's IANA time zone ("Europe/Lisbon"), for the times in for_your_human. Without it, times keep the UTC offset they were proposed in.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / wait
      Added value: +{
+  "description": "While it is the other side's turn, hold the call until the room changes (up to 40 seconds) instead of returning at once. Call it again with wait while changed is false. Returns at once when it is your turn or the room is over.",
+  "type": "boolean"
+}
  2. Changed3 schema fields changed
    • addedInput schema / properties / room
      Added value: +{
+  "type": "string"
+}
    • removedInput schema / properties / room_token
      Removed value: -{
-  "description": "The room_token negotiation_open or negotiation_join gave you.",
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "room_token"
-]New value: +[
+  "room"
+]
  3. Changed1 schema field changed
    • addedInput schema / properties / timezone
      Added value: +{
+  "description": "Your human's IANA time zone (\"Europe/Lisbon\"), for the times in for_your_human. Without it, times keep the UTC offset they were proposed in.",
+  "type": "string"
+}
  4. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Goes well past the readOnlyHint annotation: it states the call changes nothing, describes the blocking/polling semantics with wait: true (returns on room change, or 40 seconds with changed: false, returns immediately on your turn or when the room is over), and explains that for_your_human is a human-facing rendering. These are behaviors an agent cannot infer from the annotations or schema.

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?

Front-loads what is returned before the usage advice, and every sentence carries information (output fields, call timing, read-only guarantee, wait semantics). It reads as one dense run-on clause chain, which costs a bit of scannability but wastes no words.

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?

With no output schema, the description usefully substitutes by enumerating the returned fields including subject_hash and for_your_human. Safety is covered by annotations and timezone handling is covered by the schema. The one real gap is how to obtain the required room id, which neither schema nor description explains.

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 coverage is 67%, and wait/timezone are already documented in the schema in comparable detail, so the description's wait discussion is largely duplicative. The required 'room' parameter is undocumented in both places – the description only says 'one room', never hinting at the format or where an agent obtains a room id. This is baseline-level compensation for the coverage gap.

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?

Specific verb (read) plus precise scope ('one room in full') and an enumeration of exactly what comes back: state, turn, rounds, terms with subject_hash, next, and for_your_human. An agent can immediately tell this apart from the other negotiation_* siblings such as list, open, propose, or respond.

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?

Gives concrete triggers: 'Call it before every move and when your human asks how a negotiation is going,' plus the wait-loop pattern for the other side's turn. It doesn't explicitly name negotiation_list as the alternative for a multi-room overview, but 'one room in full' implies the distinction well enough.

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

All Taasky toolsInspect
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