Skip to main content
Glama

create_survey

Convert a confirmed survey plan into a live human annotation task with immediate credit reservation and dispatch.

Instructions

Create a survey from a plan generated by plan_survey.

⚠ Only call this after the user has explicitly confirmed the plan summary and cost from plan_survey. This reserves credits immediately and dispatches paid human annotation work — there is no draft or staging state, and it cannot be undone.

Pass the plan dict as returned by plan_survey. You may edit it first if anything is off — this is a regular Python dict.

Supports both standalone plans and chain plans (with a top-level steps array alongside datapoints). For chain plans, the backend dispatches each step of each datapoint as a linked task; the full sequence is served together, in order, to one annotator per response.

MEDIA VALIDATION: every media entry must use either:

  • a dp://media/… reference returned by upload_media, or

  • a public https:// URL the annotator's browser can reach.

Media lives at datapoints[*].media (shared across steps) OR datapoints[*].media_per_step["0"], ["1"], ... (one entry per step when steps need different media shapes). The two are mutually exclusive per datapoint.

Local paths, file:// URLs, and private/auth-gated URLs will be rejected or served broken to annotators. If the plan came back with wrong refs (e.g. the planner invented a URL because the description didn't supply one), fix the refs before calling this:

# shared media
plan["datapoints"][0]["media"]["candidates"][0]["url"] = "dp://media/real.png"
# per-step media (chain)
plan["datapoints"][0]["media_per_step"]["1"]["subject"][0]["url"] = "dp://media/real.mp3"

Args: plan: The survey plan dict (typically from plan_survey). Contains name, summary, datapoints, and either task_type + instruction (standalone) or a steps array (chain).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
planYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations provided, the description fully discloses behavior: immediate credit reservation, no draft/staging, irreversibility, human annotation dispatching, chain plan task linking, and media validation rules (dp:// references or public HTTPS URLs). This is comprehensive beyond what annotations would typically cover.

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?

Despite being long, the description is well-structured and front-loaded: the core purpose and critical warning appear first, followed by media validation and parameter details. Every sentence adds necessary information for correct usage, and the bullet-style media notes improve readability.

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?

The description thoroughly covers input semantics and behavioral caveats, but does not mention the tool's return value or output structure. Given that an output schema exists (as per context signals), this gap is mitigated, but a brief note on what the tool returns would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema only defines 'plan' as an object with no description (0% coverage). The description compensates fully by explaining the plan structure (name, summary, datapoints, task_type/instruction or steps), how to edit it, media organization (shared vs per-step), and providing concrete examples of fixing references.

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 clearly states that the tool creates a survey from a plan generated by plan_survey. It uses specific verbs and resources, and the purpose is immediately distinguishable from sibling tools like plan_survey (planning) and cancel_survey (cancellation).

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?

The description provides explicit when-to-use guidance: only after user confirms the plan summary and cost from plan_survey. It warns about credit reservation and irreversibility, gives examples of editing the plan dict, and clarifies media requirements. It also explains chain plan usage, making it clear when and how to use this tool.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/impel-intelligence/datapoint-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server