Skip to main content
Glama

2ools

by app.2ools

Build conversation in 2ools

build_from_conversation
Idempotent

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.
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.
creative_system_idNoOptional account-created creative system ID returned by list_build_systems. Omit for private 2ools selection.
operating_rules_idNoOptional account-created operating rules ID returned by list_build_systems. Omit for private 2ools selection.
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.
create_separate_projectNoSet true only when the person explicitly wants a distinct project that intentionally shares an existing project's name. Changing AI providers is not a reason.

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already indicate readOnlyHint=false and idempotentHint=true. The description adds value beyond this by explaining the asynchronous workflow: it queues a build and returns job_id, with a pointer to get_build for status and preview. This clarifies the non-blocking nature and the need to poll, which is behavior not apparent from annotations alone. No contradiction with annotations.

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?

Two sentences with no wasted words. The primary action is front-loaded, and the second sentence explains the return values and the follow-up tool. It is efficient and well-structured.

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 tool with 16 parameters and a nested object, the description is minimal but captures the essential workflow: create project, queue build, retrieve IDs, poll get_build. It mentions the 'protected preview' concept and the async pattern. Given that the schema fully documents parameters, the description sufficiently covers the overall context for an agent to call the tool correctly.

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 description coverage is 100%, so every parameter is individually documented. The description adds marginal meaning by calling the conversation_summary a 'structured conversation brief' (which clarifies the expected format) and by mentioning the return of project_id and job_id. Since the schema already does the heavy lifting, the description adds only a small increment, fitting the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('create'), the resource ('new 2ools project'), and the source ('structured conversation brief'). It also mentions queuing a durable build and returning IDs, which gives a specific, actionable purpose. It does not explicitly differentiate from sibling creation tools like refine_project or continue_project, but the phrase 'from a structured conversation brief' is distinctive enough to imply the primary creation entry point.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: create a new project from a conversation brief. It recommends using get_build to check status, which is helpful follow-up guidance. However, it does not state when not to use this tool or mention alternatives such as refine_project or continue_project for existing projects. This is implied usage rather than explicit routing.

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

All 2ools toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0
Disambiguation3/5

With 74 tools, many serve similar project/version/agent workflows (e.g., get_project vs get_project_context vs get_project_activity). Detailed descriptions help but the sheer volume creates selection risk for agents, especially between approve_version/approve_artifact_version and reject counterparts.

Naming Consistency4/5

Names predominantly follow a verb_object pattern (list_projects, create_public_preview, update_project_mission). Exceptions like 'act_on_project_os_task' and 'build_from_conversation' are minor, but the strong convention overall makes it predictable.

Tool Count1/5

74 tools is extreme—more than double the typical upper bound and far beyond what an agent can feasibly consider per task. The domain is broad, but the count borders on overwhelming and suggests lack of consolidation.

Completeness3/5

The surface covers project lifecycle, versioning, builds, agents, artifacts, feedback, and work assignments comprehensively. Yet there is no explicit create/delete project tool (only via build_from_conversation or start_project_on_engine), and no direct update to project metadata beyond mission/plan, leaving minor gaps.

Resources