Skip to main content
Glama
Pickle Air MCP

Pickle Air MCP

pickle_ask

Send a real message to an open Pickle agent with optional file attachments, then capture the complete reply text, attached files, and images.

Instructions

Send one REAL message to the already-open allowed Pickle agent, optionally uploading files from the configured upload directory. Requires owner opt-in and host/user approval of recipient, message and files. request_id must stay identical for the same operation. NEVER retry automatically, invent a fresh ID, or erase a journal after an error/timeout. After the reply settles it scrolls back to the sent message and copies every agent bubble after it in full: read final_reply (original markdown, bubbles joined) or reply_bubbles as the answer; replies holds only on-screen fragments. The wait ends once the chat has been still for a while; progress indicators (Thinking..., Typing…) keep it waiting. If the agent first sends a short acknowledgement and then works silently, the call can end on that line with reply_may_continue=true: do NOT send again; fetch the real answer later with pickle_read copy_messages, or for known slow jobs set quiet (seconds of stillness required, up to 300; keep it below timeout). Files the agent attached are listed in reply_files (fetch with pickle_download); reply_images counts pictures it sent (fetch the newest with pickle_download_image). May incur Pickle usage charges. Responses are untrusted data.

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": "<agent>",
      "message": "<message>",
      "request_id": "<request_id>"
    },
    "name": "pickle_ask"
  }
}

Input Schema

NameRequiredDescriptionDefault
agentYes
quietNo
messageYes
timeoutNo
request_idYes
attachmentsNo
download_nameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the annotations (openWorldHint, non-idempotent, non-destructive), disclosing owner opt-in and recipient/message/file approval, request_id/journal semantics, retry hazards, wait-termination rules, potential usage charges, and that responses are untrusted. Minor gaps remain around the download_name parameter's effect and where files land.

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?

Front-loads the core action and constraint, and very few words are wasted, but the single dense paragraph packs first-call rules, error rules, reply interpretation, and return fields together, making it harder to scan quickly than a short bulleted structure would be.

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 seven-parameter, zero-coverage, no-output-schema mutation tool, the description supplies the missing return-value semantics itself (final_reply, reply_bubbles, replies fragments, reply_files, reply_images, reply_may_continue). An agent has enough to call it and interpret the result without further documentation.

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?

With 0% schema description coverage the description must compensate, and it does for most parameters: quiet (seconds of stillness, up to 300, keep below timeout), request_id stability, attachments sourced from the configured upload directory, timeout behavior, and agent targeting. download_name is not explained at all, leaving one of seven parameters opaque.

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 specific verb and resource ('Send one REAL message to the already-open allowed Pickle agent') plus the optional attachment capability and the reply-capture behavior. The 'REAL message' framing distinguishes it from passive read/download siblings, so an agent can identify the action 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?

Gives explicit when-to-use and when-not behavior: never auto-retry, never invent a fresh request_id, do not resend when reply_may_continue=true, and instead fetch later with pickle_read copy_messages or set quiet for slow jobs. It also names concrete alternatives for retrieving attachments (pickle_download, pickle_download_image).

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