Skip to main content
Glama

Request User Action

request_user_action

Prefer on-platform tools when the channel is automatable: setup_linkedin_sequence for LinkedIn DMs and connection requests, the email tools (draft_email, setup_email_sequence) for email outreach, find_email for contact lookups. Use this tool only after ruling those out.

This tool is for a one-off ask about a particular prospect. When the off-platform step is a step of a sequenced campaign — every prospect reaching that point gets it, and the campaign continues once it's done — author a manual node in define_sequence instead: entry queues the same row, and marking it done advances the prospect onto the node's next step.

Dedup is per pending row on (agent, prospect, bucket_name): if the same prospect already has a pending row for the same bucket the tool returns created=False with the existing row's bucket and action_description so you can see what's already queued. Re-flagging the same prospect for a different bucket is allowed; re-flagging after the user marks a prior row done or dismisses it is also allowed. Dict with created (bool), action_id (int or None), id (int), and reason (str).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agent_idYesID of the campaign agent this request belongs to.
bucket_nameYesShort label naming the kind of ask (e.g. "voice-note", "intro-call"). Also the third dimension of the pending-dedup key — two different buckets can coexist as pending rows on the same prospect.
prospect_idYesThe prospect's `id` — the outreach_prospects primary key, as returned on every query_prospects row.
on_behalf_ofNoAn agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.
action_descriptionYesOne-line description of what the user should do.
completion_criteriaNoHow the agent should advance the prospect after the user sends an update about what they did.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / on_behalf_of
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / bucket_name / description
      Previous value: -"Short label naming the kind of ask (e.g. \"voice-note\",\n\"founder-gift\"). Also the third dimension of the pending-dedup key — two different buckets can\ncoexist as pending rows on the same prospect."New value: +"Short label naming the kind of ask (e.g. \"voice-note\",\n\"intro-call\"). Also the third dimension of the pending-dedup key — two different buckets can\ncoexist as pending rows on the same prospect."
  3. Changed1 schema field changed
    • changedInput schema / properties / bucket_name / description
      Previous value: -"Short user-facing label naming the ask (e.g. \"voice-note\",\n\"founder-gift\"). Shown in the Slack DM and home-page row. Also the\nthird dimension of the pending-dedup key — two different buckets can\ncoexist as pending rows on the same prospect."New value: +"Short label naming the kind of ask (e.g. \"voice-note\",\n\"founder-gift\"). Also the third dimension of the pending-dedup key — two different buckets can\ncoexist as pending rows on the same prospect."
  4. Changed3 schema fields changed
    • addedInput schema / properties / agent_id
      Added value: +{
      +  "description": "ID of the campaign agent this request belongs to.",
      +  "type": "integer"
      +}
    • removedInput schema / properties / task_id
      Removed value: -{
      -  "description": "ID of the campaign task this request belongs to.",
      -  "type": "integer"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "task_id",
      -  "prospect_id",
      -  "bucket_name",
      -  "action_description"
      -]New value: +[
      +  "agent_id",
      +  "prospect_id",
      +  "bucket_name",
      +  "action_description"
      +]
  5. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false, but the description discloses far more: the exact dedup key `(agent, prospect, bucket_name)`, the idempotent return path (`created=False` plus the existing row's bucket and action_description), and the conditions under which re-flagging is permitted. Nothing contradicts the annotations.

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?

The core purpose and the primary sibling exclusion (queue_gift) are front-loaded in the first sentence, and the summary/returns sections are cleanly delimited. It is on the long side, and the dedup paragraph is dense, but each segment carries distinct decision-relevant information rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter mutation tool with no output schema, the description covers everything an agent needs: routing against siblings, one-off vs campaign scoping, the dedup contract, and even an embedded returns block describing the created/action_id/id/reason dict. No material gap remains.

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 100%, so the baseline is 3, but the description adds real meaning beyond the schema by explaining bucket_name's dual role as the third dimension of the pending-dedup key and noting that two buckets can coexist as pending rows. It does not, however, explain on_behalf_of or completion_criteria beyond what the schema text already says.

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 description opens with a precise verb+resource ('Flag a prospect for the user to act on directly') and scopes it to off-platform or human-judgement asks, then enumerates concrete examples (voice memo, phone call, handwritten card, event, hiring decision). It actively distinguishes itself from named siblings like queue_gift and setup_linkedin_sequence, so an agent can route correctly without opening any 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?

Explicit when-to-use ('off-platform or genuinely needs human judgement'), explicit when-not ('Prefer on-platform tools when the channel is automatable'), and it names the concrete alternatives for each automatable channel (setup_linkedin_sequence, draft_email, setup_email_sequence, find_email). It also resolves the one-off vs sequenced-campaign ambiguity by routing the latter to a `manual` node in define_sequence.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources