Skip to main content
Glama
jtkehler

crowdsmart-mcp

by jtkehler

create_jam

Create a draft Jam from a plan, review and edit prompts, participants, and materials in the app, then launch it when ready.

Instructions

Create a draft Jam from a plan. Nothing is sent until you launch it with launch_jam.

Participants respond to each prompt in order, then review each other's responses. A "prediction" prompt (the default) asks for a probability and reasoning. A "reasoning", "qualitative" or "evaluation" prompt asks for reasoning only. Seed reasons are example ideas that participants review from the start. The result has the draft's green_room_url, where you can review and edit it in the app.

A Jam can have Knowledge Agents only: give agent_ids and no invite_emails. Knowledge Agents answer only the first prompt, so give a Jam of agents one prompt, and use one Jam for each question.

Args: title: The Jam's title. prompts: The prompts, in order: text, optional type and seed_reasons. description: What the Jam is about. decision_goal: The decision or learning the Jam serves. expected_output: The result that you want from the Jam. audience: Who takes part. assumptions: Assumptions that participants must know. materials: Reading material: each a name and its text. invite_emails: Email addresses of the people to invite at launch. agent_ids: Knowledge Agents that take part, from create_knowledge_agent or list_knowledge_agents. They start when the Jam launches. public: Whether anyone can find and join the Jam. community_id: The Jam's community, from list_my_communities.

Input Schema

NameRequiredDescriptionDefault
titleYes
publicNo
promptsYes
audienceNo
agent_idsNo
materialsNo
assumptionsNo
descriptionNo
community_idNo
decision_goalNo
invite_emailsNo
expected_outputNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already indicate this is not read-only and not destructive, and the description adds important behavioral context: it creates a draft, nothing is sent until launch_jam, agents start only at launch, and the result includes green_room_url. It does not cover auth or rate-limit concerns, so it is strong but not exhaustive.

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 description is front-loaded with the key distinction from launch_jam and then uses a structured Args section for the 12 parameters. It is somewhat long, but most of the length is justified by the low schema description coverage and the need to explain prompt semantics.

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 complex 12-parameter creation tool with no schema descriptions but an output schema, the description is complete: it covers draft behavior, launch behavior, prompt types, agent constraints, all parameter meanings, and the returned green_room_url. Nothing critical appears missing for correct invocation.

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?

Schema description coverage is 0%, so the description carries the full burden and does so well: it defines all 12 parameters, explains prompt types and seed_reasons, clarifies that agent_ids come from create_knowledge_agent or list_knowledge_agents, and says community_id comes from list_my_communities.

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 ('Create a draft Jam from a plan') and immediately distinguishes it from the sibling launch_jam by clarifying that nothing is sent until launch. An agent can tell exactly what this tool does and how it differs from launching or listing Jams.

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?

Explicitly explains when to use this tool versus launch_jam, and gives important usage constraints such as Knowledge Agents-only Jams requiring agent_ids with no invite_emails and only one prompt per agent Jam. It also explains prompt-type behavior and participant flow.

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