Skip to main content
Glama

Build conversation in 2ools

build_from_conversation
Idempotent

Create a new project from a structured conversation brief and queue a durable build. Returns project and job IDs for tracking.

Instructions

Create a new 2ools project from a structured conversation brief and queue one durable build. Returns project_id and job_id; use get_build to retrieve completion status and the protected preview.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNoGeneration engine. studio is keyless; other models require an available account provider or linked Engine.studio
pagesNoPages to generate. Use Home for a one-page site or widget.
entityNoGrounded identity facts that must survive the build.
audienceNoPrimary audience and the job they need to complete.
headlineNoExact hero headline to preserve verbatim in the generated site.
skill_idsNoExact compatible Skill IDs from list_build_systems. When supplied, replaces the Rulebook's default Skill set.
curator_idNoExact Curator ID from list_build_systems. Omit for automatic selection.
rulebook_idNoExact compatible Rulebook ID from list_build_systems. Overrides the Curator's default Rulebook.
project_nameYesShort name for the new 2ools project.
requirementsNoConcrete functionality, content, and section requirements.
output_targetNoDelivery target: site, browser game, desktop wrapper, embeddable component, floating overlay, or standalone HTML.web
max_iterationsNoHard project cap for later outside-agent child revisions. Defaults to 6 and cannot exceed 12.
idempotency_keyYesCaller-generated unique key. Reusing it returns the original project/job instead of creating a duplicate.
visual_directionNoDesired visual character, composition, color, typography, or references.
content_constraintsNoClaims, wording, exclusions, or fidelity constraints the build must obey.
conversation_summaryYesFactual build brief distilled from the conversation, including the intended artifact and key decisions.
Behavior4/5

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

The description discloses the asynchronous 'queue one durable build' behavior, the returned project_id and job_id, and the need to use get_build for completion status and the protected preview. Since annotations already cover idempotency and non-destructiveness, this adds useful lifecycle context without contradicting them.

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?

The description is two concise sentences, front-loaded with the action and followed by the necessary outcome details and follow-up tool reference. Every sentence earns its place with no wasted words.

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 complex 16-parameter tool with nested objects and no output schema, the description covers the essential lifecycle: creation, queued build, returned IDs, and status retrieval via get_build. The schema is exhaustive and annotations clarify safety behavior, though terms like 'durable build' and 'protected preview' could be explained slightly more.

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

Parameters3/5

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

Schema coverage is 100%, so the input schema already explains all parameters in detail. The description only adds a general 'structured conversation brief' reference and does not elaborate beyond schema descriptions, meeting the baseline but not exceeding it.

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 uses a specific verb ('Create'), identifies the resource ('a new 2ools project'), and adds scope by mentioning the structured conversation brief and queued durable build. It differentiates from siblings by explicitly directing status/preview retrieval to get_build.

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?

The description clearly implies when to use this tool: when you have a structured conversation brief and want to create a project and queue a build. It points to get_build for follow-up but does not explicitly name alternatives like refine_project or list_build_systems.

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/2ools/mcp-server'

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