Skip to main content
Glama
simplepush

Simplepush MCP Server

Official
by simplepush
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Hybrid

Send a task (a question, form or checklist item that needs an answer)

send_task

Create tasks on phones and collect responses in one submission. Define text, choice, action buttons, sliders, photos, voice, files, or locations, and wait up to a deadline for per-recipient answers.

Instructions

Create a task on people's phones and wait for the answers. content says what to do or answer; inputs says how to answer: one or more of text, choice (single or multi), action buttons, slider, photo, voice recording, file, location, all answered in one submission. reply opens a comment thread on the task instead of, or in addition to, inputs. By default every recipient gets their own copy of the task, tied together by a group; the call waits up to wait_seconds (default 90s) for ALL of them to answer and returns per-recipient results, with whoever has not answered yet marked pending — a timeout is not a cancellation, the tasks stay live and get_group_status or get_task_answer resolve them later. shared: true sends ONE task that all recipients see and answer together (the first answer resolves it) — use it for questions where any one person's answer settles the matter. Every result carries an append_token for append_subtask.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagNoA label for grouping and filtering related tasks (e.g. a site or job number); shown on task summaries.
linksNoPublic https URLs attached to the task as links.
replyNoLet recipients reply with comments, photos, files or voice notes: `one-shot` (one reply closes the task), `sticky` (thread stays open), `one-time-per-user` (each recipient replies once).
titleNoShort heading. Always set one: task listings and activity overviews show only titles, tags, topics, status, input and attachment kinds, never content, so an untitled task is unreadable there — for people scanning their phone as much as for query_tasks later.
topicNoDeliver to this topic instead of the user's own devices. Omit for a self-send.
inputsNoThe inputs the recipient fills in, in display order.
memberNoUnavailable in personal mode — requires an org integration token.
sharedNoDefault false: an independent copy per recipient, answers collected per person. true: ONE task all recipients see and answer together; the first answer resolves it.
contentNoBody of the task: what to do or answer. Required unless `inputs` is given.
markdownNoRender `content` as Markdown.
broadcastNoUnavailable in personal mode — requires an org integration token.
expires_atNoISO-8601 deadline. After it the task counts as expired and can no longer be answered.
auto_commitNoDefault false: the task is a form — all inputs are submitted together with one Submit button. true: each input is submitted as it is filled.
wait_secondsNoHow long to block. Default 90; 0 returns right after sending. With per-recipient copies (the default) it waits for everyone's answer and reports partial results at the deadline.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

No annotations exist, so description carries the burden. It discloses that a timeout is not cancellation, tasks stay live, unanswered recipients are marked pending, `shared: true` resolves on first answer, and every result carries an append_token — genuinely useful behavioral facts beyond 'creates a task'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Four dense sentences, front-loaded with the core action and then adding mode/wait/append semantics in a logical order. No filler or repetition of schema field names.

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 14-parameter write tool with no output schema and no annotations, it covers the send/wait/timeout lifecycle well and mentions per-recipient results and append_token. It still leaves recipient-targeting mechanics (topic/member/broadcast) and the exact result payload mostly to the schema, which is a minor gap at this complexity.

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 already covers 100% of parameters, so baseline is 3; the description adds real cross-parameter meaning (content vs inputs, reply thread behavior, shared semantics, wait_seconds timeout semantics). It does not walk through every parameter, but it clearly compensates for the most decision-critical ones.

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?

States a concrete action ('Create a task on people's phones and wait for the answers') and scopes the resource type via the title/description (a question, form or checklist item), which is distinct from notification-style siblings. The `content` vs `inputs` split and per-recipient vs shared mode make the tool's purpose unmistakable.

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?

Provides clear decision context: default per-recipient copies vs `shared: true` for matters one answer settles, and points to get_group_status/get_task_answer for late answers. It does not explicitly contrast with send_notification or state when not to use the tool, so not a full 5.

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

Install Server

Other Tools