Skip to main content
Glama
Sign In

Taskriz

by com.taskriz
OverviewDiscussionsAdmin

Send a Request

send_request

Send a request from an Agent to the people named in to (emails, or connection ids from list_recipients). Each gets it in Taskriz (end-to-end encrypted) and can answer through its interface. Someone not yet paired with the Agent who has a Taskriz account is emailed an INVITATION: the request waits (up to 3 days) until they accept, then reaches them; you get an invitation event (accepted / declined / expired). Someone with NO account answers as a guest — no account or app needed: they're emailed the request's link (invited with guest: true), open it with one tap (on another browser, or with verify: true for a sensitive request: a one-time code), and it reaches them (up to 30 days). A mobile number in international form (+61…) works the same by text; give BOTH as one entry ("sam@example.com +61412345678") and the link goes by email and by text, and the code by text. A later request to a guest waits until they open it (held). How many people an account can reach (paired or invited) follows its plan (Free 10, Builder 100, Business 1,000). Someone who declined an Agent can’t be invited again by it; someone who blocked everything from this account can’t be invited by any of its Agents: tell the person you’re helping — never create another Agent to get round a decline. Answers come back as events: see get_replies. Use thread to continue an earlier conversation. To ask someone for a file or photo, put a DocumentPickerMorph / PhotoPickerMorph in the UI (see get_ui_guide) — the file reaches you as an attachment (get_attachment); don’t ask them for a link. In a connected Slack workspace, to can name a member or channel by its slack_id (list_recipients): the request is shown and answered in Slack — members need no Taskriz account. A request Slack can’t show (a map, a photo or file picker, a slider…) isn’t sent there (not_sent_in_slack says why), and files can’t be sent to Slack yet. Answers come back as replies from slack:T…:U….

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": {
      "agent_id": "<agent_id>",
      "to": "<to>",
      "subject": "<subject>",
      "ui": "<ui>"
    },
    "name": "send_request"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYesRecipients: their email, mobile (+61…), both in one entry ("sam@example.com +61412345678"), connection_id, a Slack slack_id or a Google Chat gchat_id (list_recipients).
uiYesThe interface (Smalltalk Morphs — see get_ui_guide).
threadNoAn earlier request’s thread, to continue that conversation.
verifyNoFor someone without an account: they enter a one-time code (sent to them) before it opens, even the first time — for sensitive requests (health, money, documents). Otherwise the first browser opens it with one tap.
repliesNoAnswered once (single — the default) or any number of times.
subjectYesThe inbox subject line.
summaryNoThe inbox preview text.
agent_idYesThe Agent (from list_agents or create_agent).
expires_atNoISO time after which it can no longer be answered.
importanceNoDecides which notification channels carry it (default high).
may_answerNoA Slack channel request: only these members (their slack_id) may answer it; otherwise anyone in the channel, first answer wins.
attachmentsNoFiles to send with it: attachment ids from create_attachment (each recipient gets its own copy).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / to / description
      Previous value: -"Recipients: their email, mobile (+61…), both in one entry (\"sam@example.com +61412345678\"), connection_id, or a Slack slack_id (list_recipients)."New value: +"Recipients: their email, mobile (+61…), both in one entry (\"sam@example.com +61412345678\"), connection_id, a Slack slack_id or a Google Chat gchat_id (list_recipients)."
  2. Changed2 schema fields changed
    • addedInput schema / properties / may_answer
      Added value: +{
+  "description": "A Slack channel request: only these members (their slack_id) may answer it; otherwise anyone in the channel, first answer wins.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedInput schema / properties / to / description
      Previous value: -"Recipients: their email, mobile (+61…), both in one entry (\"sam@example.com +61412345678\"), or connection_id (list_recipients)."New value: +"Recipients: their email, mobile (+61…), both in one entry (\"sam@example.com +61412345678\"), connection_id, or a Slack slack_id (list_recipients)."
  3. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only give the generic write/open-world profile; the description supplies the real behavioral model: invitation wait up to 3 days with accept/decline/expire events, guest links up to 30 days, one-time-code verification, `held` for later guest requests, plan-based reach limits, permanent decline blocking, and the Slack limitation with a `not_sent_in_slack` reason. That is substantive disclosure an agent could not infer from 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action is front-loaded, but the remainder is one dense run-on paragraph mixing invitation lifecycle, plan limits, guest flow, Slack constraints and UI guidance, so key rules are hard to retrieve. Every clause is substantive, yet the structure does not earn its length—splitting into 'who receives it', 'limits', and 'Slack' would preserve content and improve scannability.

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?

For a 12-parameter, open-world, non-idempotent send tool with no output schema, the definition covers delivery paths, waiting states, failure events and policy constraints thoroughly. The one real gap is that it never says what send_request itself returns (e.g., a request id or thread id) that the agent would need for follow-up calls.

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% and the parameter descriptions are themselves detailed, so the baseline is 3. The prose mostly restates schema content (both-format `to` entries, verify, thread), adding only marginal framing such as tying `verify` to sensitive requests; it does not, for example, clarify multi-recipient semantics where one entry fails.

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?

The opening sentence names a specific verb (send), the resource (a request), the origin (an Agent) and the addressing surface (`to`), and immediately distinguishes this tool from reply-readback by naming get_replies. An agent can tell what this does and what it does not do (no reading of answers) 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 routes the agent conditionally and explicitly: use `thread` to continue a conversation, use get_replies to read answers, use DocumentPickerMorph/PhotoPickerMorph in the UI rather than asking for a link, use slack_id for Slack targets, and never create another Agent to bypass a decline. Both when-to-use and when-not-to-use are covered.

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

All Taskriz 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