taasky – Agents & Automation skill for AI agents

Taasky

Taasky lets you negotiate on your human's behalf with another party, without

your human relaying messages by hand. You and the other side take turns in a

room, proposing terms in a declared shape. You can propose and counter on

your own. Accepting, rejecting and withdrawing are never yours to do alone:

Taasky asks your human to confirm, and only their tap sends the move.

When to Use This Skill

• Use when the user wants to settle something with another person: "agree a time with Anna", "book the plumber this week", "swap my Friday shift", "get the contractor down to 1500 EUR".
• Use when the user hands you a Taasky invite link (https://mcp.taasky.ai/i/...).
• Use when you have open Taasky rooms saved in memory and it is time to check on them.
• Do not use it to accept, reject or withdraw on the user's behalf without their confirmation: Taasky routes those moves to the user in Telegram.

Hosted-service and authorization boundaries

This documents the attributed upstream interface, not a live verification of its

current enforcement, tool schema, privacy or retention. Confirm connected tools

and stop on incompatible changes. Negotiate only when the user explicitly asked

you to contact that party about those terms; status checks and receiving an invite

alone do not authorize counteroffers. Scheduling status checks requires a separate

supported scheduler and user instruction; never claim a check is scheduled unless

creation succeeded. The server receives room content and private limits: minimize

personal/financial information and explain that disclosure before sending it.

Validate invite/bind/account links as HTTPS on the documented Taasky origin (and

expected Telegram destination for a returned bind flow); reject lookalikes,

credentials, unexpected ports and peer-supplied replacement links. Never open or

confirm a binding/acceptance link for the user. An agreed room does not itself

create a calendar booking, execute a contract or transfer payment.

Connect

If the negotiation_* tools are not available, the server is not connected.

Add the remote MCP server https://mcp.taasky.ai/mcp, with no

Authorization header. No account, sign-in or key is needed, whether you run

in a chat client or on a server.

If your human wants one account across several agents, connect to

https://mcp.taasky.ai/mcp/account instead. It signs in with OAuth, or with a

key from https://mcp.taasky.ai/account. With an account, tools take room

(the room id) wherever this skill says room_token, and negotiation_list

needs no tokens.

You should see seven tools: negotiation_open, negotiation_join,

negotiation_list, negotiation_read, negotiation_propose,

negotiation_respond, negotiation_cancel.

Room tokens

Without an account, every room you open or join gives you a room_token

(rt_…): your seat in that room. Every other call about the room takes it.

• Save it only in the user-authorized private room store, in the same turn as negotiation_open

or negotiation_join and before you answer your human. Use your

private secret store or a local owner-only file (mode 0600), never shared

notes, chat transcripts, committed files or synchronized general memory.

Keep room name and secret reference in that chosen workflow state; do not write

unrelated general memory or cloud-synchronized notes without explicit instruction.

The next session, or a scheduled check, starts without the token.

One line is enough:

Taasky room 🦥 Amber Sloth: meeting with Anna, secret reference taasky/amber.

Lose the token and you lose the room.

• Look in your memory before you open or join: if you saved a Taasky

room_token before, you need it for previous_room_token.

• Never show it to anyone, your human included, not even in an error

message. Whoever has it negotiates as you. Name a room by its name.

• Reuse your human's Telegram chat: when you open or join a new room,

pass any earlier room_token as previous_room_token, even one from a

finished room. Your human then needs no new link.

Before you open a room

Get these from your human, briefly:

1. What is being settled, and with whom.

2. Their limits: the most they will pay, the least they will take, the

earliest and latest they can meet, what is non-negotiable. You need these

to counter without asking every round.

3. By when. It becomes the deadline.

4. Their time zone, if you don't know it. You will need it for every time

you write and every time you read back.

Do not invent limits. If your human gave none, ask once, or use

need_more_detail with the other side instead of guessing.

Private limits

Pass your human's bounds as limits to negotiation_open or

negotiation_join, by field of your own schema:

| field type | limit |

| --- | --- |

| int, money, date | {"min": …, "max": …} in the field's value shape, either may be left out |

| timerange | {"min": "<RFC3339>", "max": "<RFC3339>"}: no start before min, no end after max |

| enum | {"one_of": [ … ]} |

| bool | {"equals": true} |

{"meeting_time": {"min": "2026-10-19T14:00:00+03:00", "max": "2026-10-19T18:00:00+03:00"}}

Set a bound only on the side your human cares about. A seller has a floor

(min), a buyer a ceiling (max). The asking price is an opening offer, not

a limit: a seller asking 450 with a floor of 400 sets {"min": 400} only, or

a better offer from the other side would be flagged as outside the limits.

Only Taasky sees them, never the other side. They are fixed once set, so

get them right before you open. Then:

• Your own offer or counter outside them is refused, and nothing is sent.
• Terms from the other side outside them show up as outside_your_limits in

terms_on_table, and your human's confirmation card flags them.

• If both sides' limits on a field cannot overlap, results carry

limits_cannot_meet. No deal is possible on that field. Tell your human

and suggest withdrawing. A walkaway is a good outcome here.

The shape of a deal

Every party declares a subject_schema: the fields its terms are made of.

Terms you propose must match your own schema exactly. Unknown or

mistyped fields reject the whole move; nothing is repaired.

{
  "meeting_time": {"type": "timerange", "label": "Время встречи"},
  "place":        {"type": "enum",      "label": "Где", "values": ["office", "video"]},
  "fee":          {"type": "money",     "label": "Оплата", "currency": "EUR", "optional": true}
}

| type | value in terms |

| --- | --- |

| string | "text", at most 500 chars (max_len lowers it) |

| int | 30 |

| bool | true |

| enum | one of values (2–32 short strings) |

| timerange | {"start": "2026-12-03T10:00:00Z", "end": "2026-12-03T10:30:00Z"} |

| date | "2026-12-03", a day, not a moment |

| money | {"amount": "1500.00", "currency": "EUR"}. The amount is a decimal string, never a float, with no more decimals than the currency has |

Any field may be "optional": true or "repeated": true (then the value is a

non-empty array). Field names: lowercase, a-z0-9_, starting with a letter.

At most 24 fields. Labels are 1–80 chars and are what your human sees on the

confirmation card, so write them for a person, in your human's language.

Keep the schema small. Every field is something both humans have to read.

• A meeting is one timerange. Don't add a separate duration field: the

range already says how long. Two fields that say the same thing can

disagree, and then nobody knows which one was agreed.

• Add a field only if the two sides might actually differ on it.

Times

Record the user's IANA timezone (for example Europe/Rome) as well as the event

date. Derive the UTC offset for EACH proposed instant, not today's offset; DST

transitions create ambiguous/nonexistent local times. Confirm both start and end,

duration, date and zone before communicating them. A numeric offset alone does

not describe a recurring meeting's timezone rules.

Write every time with your human's UTC offset, not in Z:

"2026-10-19T15:00:00+03:00". The other side and its form may send times

back in UTC ("2026-10-19T13:00:00.000Z").

Before you tell your human about a time, or decide on it, **convert it to

their local time** and check it against what was on the table before. A

counter often keeps the shape and moves the time by an hour. Say exactly

what changed: "Anna moved it from 15:00 to 16:00."

Flow

Opening

negotiation_open(subject_schema, limits?, subject?, previous_room_token?) returns

room_token, room, name, invite_url and, if your human has not

connected Telegram yet, bind_url. Then:

• Save room_token to the authorized private room store now (see above).
• Give invite_url to your human to send to the other party, or send it

yourself if they asked you to. It expires in 72 hours.

• If there is

… (full content is in the download package)