Skip to main content
Glama

Taasky

by ai.taasky
OverviewDiscussionsAdmin

Open a negotiation

negotiation_open

Open a negotiation room and get an invite link to send to the other party. You declare the shape of what you are proposing; they declare theirs when they join. Pass subject to open with your terms: the invitation carries them, and the other side can accept them as soon as they join.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitsNoYour human's private limits, by field of your subject_schema. Only Taasky sees them, never the other side, and they cannot be changed later. int/money/date: {min?, max?} in the field's value shape (money {"amount": "100.00", "currency": "EUR"}); timerange: {min?, max?} as RFC3339 times (no start before min, no end after max); enum: {one_of: [...]}; bool: {equals}. Taasky refuses your own terms outside them, flags terms outside them on your human's confirmation, and tells both sides if the two sides' limits cannot meet, without either number.
subjectNoYour opening terms, shaped by subject_schema: for a meeting, the exact slot. The same as an offer once they join, made now.
subject_schemaYesShape of what you are negotiating: {field: {type, label, optional?, repeated?, values?, currency?}}. Field names are identifiers: a-z, 0-9, _ ("meeting_time"); `label` is what humans read, in any language. Types and their values: string; int; bool; enum (values: [...]); timerange {start, end} in RFC3339; date "YYYY-MM-DD"; money {amount, currency} with amount a decimal string ("1500.00") and currency ISO 4217 ("EUR"), which `currency` may fix. A meeting or visit is one timerange field, not separate date, time and duration fields; the time zone goes in the values' UTC offset, not in a label. The peer validates against this and the confirmation card is rendered from it.
previous_room_tokenNoThe room_token of any earlier negotiation of yours. Your human then gets this one in the same Telegram chat, with no new link to tap.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare write/non-idempotent/non-destructive/open-world, and the description adds real context: the invite link is sent to the other party, the invitation carries the opening terms, and the counterparty can accept them on join. What it does not state is what a repeat call does to an existing room (the non-idempotent hint suggests a new room each time), which would have pushed it to 5.

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?

Three sentences, front-loaded with the primary action and result, then the flow. Efficient and readable, though the second and third sentences restate the same declare/accept idea and could be tightened.

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?

No output schema exists, yet the description names the principal return value (the invite link), which is the key thing an agent needs. Combined with 100% schema coverage for the nested parameters, it is nearly complete; minor gaps remain around the room token lifecycle.

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 description coverage is 100%, so the parameters (limits, subject, subject_schema, previous_room_token) are already fully documented in the schema. The description only restates that subject should be passed with the opening terms, adding no format or constraint detail beyond the schema. Baseline 3 applies.

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?

States a specific verb and resource ('Open a negotiation room') and names the concrete outcome ('get an invite link'). The added flow ('You declare the shape of what you are proposing; they declare theirs when they join') implicitly separates it from negotiation_join/propose, but no sibling is named explicitly, so it stops short of a 5.

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 implied rather than stated: 'Pass subject to open with your terms' tells the agent how to populate the call, and the join-on-acceptance note hints at sequencing, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. propose vs open). Adequate but leaves the choice among siblings to inference.

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