Skip to main content
Glama
Sign In

Taasky

by ai.taasky
OverviewDiscussionsAdmin

Propose terms

negotiation_propose

Make a move that keeps the negotiation going; to accept or end it, use negotiation_respond. Only on your turn. offer: opening terms, only when no terms are on the table. counter: different terms. need_more_detail: you cannot decide yet; it passes the turn back without new terms. Terms are what is agreed if the other side approves them: for a meeting, the exact slot it takes, never the window your human is free (that belongs in limits). Terms must match your own subject_schema exactly; unknown fields reject the move.

Input Schema

NameRequiredDescriptionDefault
roomYes
finalNooffer and counter: these terms are what your human wants agreed as they stand. Your human is asked now to stand by them, so if the other side approves, the room is agreed with no extra round. Only once your human has said these terms are theirs.
subjectNoThe terms, for offer and counter. Shaped by your subject_schema.
verdictYes
deadlineNoRFC3339. When you stop waiting for an answer; the room expires after it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / final
      Added value: +{
+  "description": "offer and counter: these terms are what your human wants agreed as they stand. Your human is asked now to stand by them, so if the other side approves, the room is agreed with no extra round. Only once your human has said these terms are theirs.",
+  "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",
-  "verdict"
-]New value: +[
+  "room",
+  "verdict"
+]
  3. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations (non-readonly, non-idempotent, open-world), the description discloses that unknown fields reject the move, that final commits the human to stand by the terms now, that need_more_detail passes the turn without new terms, and that deadline expiry ends the room. These are real behavioral consequences not derivable from the structured fields.

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-loaded with purpose and the escape hatch to negotiation_respond, then a compact mode list, then term constraints. The telegraphic fragments ('counter: different terms') are efficient, though the density of rules in one paragraph makes it slightly harder to scan.

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 a nested subject object, an enum verdict, no output schema, and 60% parameter coverage, the description covers the important gaps: turn discipline, mode semantics, term shape, and rejection behavior. Only the room parameter and post-call outcome are left implicit, which is acceptable given no output schema is needed.

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 60% and the description compensates well: it defines each verdict mode's semantics and explains the terms object, including the specific meeting-slot-vs-availability-window distinction and the subject_schema conformance requirement. room is left unexplained in the description, which keeps it from a full 5.

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 clause ('make a move that keeps the negotiation going') is soft, but the enumeration of the three verdicts (offer, counter, need_more_detail) makes the actual operation concrete, and negotiation_respond is named as the contrasting sibling. An agent can distinguish this from respond without opening the schema.

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?

It states the precondition ('Only on your turn'), routes acceptance/termination to negotiation_respond, and gives per-mode conditions: offer only when no terms are on the table, counter for different terms, need_more_detail when you cannot decide. Explicit when-to-use and when-to-use-something-else.

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