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

With no annotations provided, the description carries the full burden and does well: it discloses that the AI agent 'will start building immediately' (asynchronous kickoff) and that the return is a job ID rather than the completed project. This reveals important behavioral traits beyond the simple action of creating a project, such as the non-blocking nature of the operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, each earning its place: the first states the core action, the second explains immediate startup behavior, and the third covers the return value. The information is front-loaded and there is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is generally complete for a create-type tool: it covers the purpose, the async behavior, and the return value. It could optionally point to the specific sibling tool to monitor the job, but the job ID reference makes the next step inferable. Since the schema handles parameter details and no output schema exists, the description adequately covers what an agent needs to call this tool correctly.

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

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

The input schema already provides detailed descriptions for both parameters: the 'prompt' description explains how to be specific, and 'modelName' includes an enum with a default. The tool description adds no additional parameter semantics beyond the phrase 'submitting a prompt,' so it stays at the baseline for full schema coverage.

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

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

The description states a specific verb ('Create'), a specific resource ('a new project on Emergent.sh'), and the mechanism ('by submitting a prompt'). This clearly distinguishes it from sibling tools like emergent_list_projects and emergent_get_project, which are read operations, and from wait_for_build/respond_to_agent, which handle later phases of a project lifecycle.

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

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

The description makes it obvious this tool is for starting a new build by submitting a prompt, and the sentence 'Returns a job ID you can use to monitor progress' implicitly routes the agent to later use tools like emergent_wait_for_build or emergent_get_project. It does not explicitly name these alternatives or provide when-not-to-use guidance, but the context is clear enough.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It conveys that the result is human-readable and short, which implies a safe read-only operation, but it does not explicitly state side-effect-free behavior or system implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler, fluff, or redundant restatement of the tool name. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool, the description is mostly sufficient, but it leaves ambiguity with the sibling emergent_get_credits and provides no output schema to clarify the return structure. The 'human-readable' qualifier helps, but an agent would benefit from a brief distinction from the credits tool.

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

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

The input schema has zero parameters, so there is no parameter ambiguity for the description to clarify. The baseline of 4 applies because there is nothing for the description to add.

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

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

The description names a specific action ('get') and a specific resource ('credit balance summary'), and adds useful qualifiers ('short human-readable'). It is clear on its own, but it does not differentiate itself from the similarly named sibling emergent_get_credits.

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

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

The description gives no guidance on when to use this tool versus emergent_get_credits or any other sibling. An agent cannot tell whether it should choose this tool or emergent_get_credits for a credit-related query.

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

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

With no annotations, the description is the only behavioral source. 'Discover and document' suggests a non-mutating lookup, and the [Browser] prefix adds context, but the description does not specify return format or whether any persistent documentation is written. This leaves minor ambiguity but is not misleading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two terse sentences with no redundancy, and the action is front-loaded before the usage condition. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter, no-output-schema discovery tool, the description provides enough to know when to call and what the call accomplishes. It does not specify the exact returned artifact, but that is a minor gap given the tool's simplicity and lack of input requirements.

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

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

The tool takes zero parameters, so there are no parameter semantics to explain; the schema is empty and 100% covered. The baseline for a no-parameter tool applies here.

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

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

States a specific verb ('Discover and document') with an explicit resource ('available Emergent.sh features') and a clear scope restriction ('only needed for features not yet in the REST API'). This clearly differentiates it from sibling tools that create/get/list projects, builds, previews, and credits.

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

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

The second sentence explicitly says when this tool is needed: only for features not yet exposed in the REST API, which is a clear exclusion condition. It does not name a specific alternative tool, so it stops slightly short of full routing guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses the read-only nature implicitly by saying 'Get' and lists return fields, but it does not state whether this incurs cost, requires authentication, has rate limits, or whether the credit balance is real-time or cached.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: the first states the action and target, the second lists return fields. Every word earns its place, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless read-only tool, the description covers the core need. However, it lacks information about credential requirements, whether the balance reflects real-time usage, and relationship to the sibling emergent_credit_summary, which may be the more appropriate tool in some contexts.

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

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

There are zero parameters, so the description needs to compensate little. It goes beyond the schema by explicitly listing the returned data fields, which helps the agent understand the output shape despite no output schema being present.

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

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

The description clearly states the tool's purpose with a specific action ('Get the current credit balance') and resource ('the Emergent account'). It then enumerates the exact return fields (ECU balance, monthly credits, daily credits, plan name, refresh date), leaving no ambiguity about what the tool does.

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

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

The description implies a natural use case (checking credits before resource-intensive operations) but does not explicitly state when to use it over siblings. Given sibling tools like emergent_credit_summary exist, the description does not differentiate when to choose this tool versus that one.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the core function and adds no depth: no mention of response format, failure modes, authentication requirements, or whether the call has any side effects. The word 'Get' implies a read operation, but that is not enough on its own.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no filler, front-loading the main action and the key prerequisite ('built Emergent project'). Every word contributes to the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter getter, the description plus full schema coverage is mostly adequate, but without an output schema it does not explain the returned structure or behavior when the project is not yet built. The presence of sibling wait_for_build suggests a workflow dependency that is only implied, not stated.

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

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

Schema description coverage is 100%, so the schema already documents both jobId and includeVscode, setting the baseline at 3. The description does not add parameter-level meaning beyond the schema.

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

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

The description uses a specific verb ('Get') and resource ('live preview URL') and adds the scope 'for a built Emergent project,' which is unambiguous. It naturally distinguishes from the sibling emergent_screenshot_preview by emphasizing URL rather than an image.

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

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

The phrase 'for a built Emergent project' implies the project must have been built first, providing implicit usage context. However, it does not explicitly say when to use this tool instead of alternatives like emergent_screenshot_preview or whether wait_for_build is a prerequisite.

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

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

With no annotations, the description bears the burder of disclosing behavior; it does convey that this is a retrieval operation and names the returned content. It does not discuss staleness, authentication needs, or whether the call affects the project, but for a simple read-like GET this is an acceptable minimum.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One efficient sentence front-loads the verb and resource ('Get full details'), listes the key output fields, and contains no filler. Every word contributes to the agent's understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a single required parameter already documented by the schema and no output schema required, the description supplies enough context for an agent to call the tool appropriately. It could be slightly more complete by describing return shape or warning about prerequisites, but those are not essential for basic invocation.

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

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

The only parameter, jobId, already has a schema description ('Job ID (UUID)'), so schema coverage is 100%. The tool description adds no additional semantic detail about the parameter beyond the implicit 'specific project' relationship, matching the baseline for full schema coverage.

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

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

The description clearly says 'Get full details for a specific project' with a list of content fields (status, preview URL, credits used), so the action, resource, and scope are unambiguous. It does not explicitly differentiate from sibling tools such as emergent_get_preview, which also relate to preview URLs, but the singular 'specific project' makes it clearly distinct from list_projects.

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

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

It implies this should be used when a single project's full details are needed, and the one required jobId reinforces that. However, it does not explicitly say when to prefer this over siblings like emergent_get_preview or emergent_get_creadits, nor does it provide exclusion criteria.

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

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

No annotations are provided, so the description carries the disclosure burden. 'List' implies a non-mutating read operation, and the mention of status and preview URLs tells the agent what to expect. However, it says nothing about ordering, pagination beyond the optional limit, or whether jobs and projects are mixed in the same result set.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one concise sentence that front-loads the action and resource and attaches only the most relevant result information. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool, the description covers the operation, scope, and expected contents. An output schema is absent, so mentioning status and preview URLs is valuable. It could still note the ordering or that only recent items are returned, but the essential call-time information is present.

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

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

Schema coverage is 100% since the only parameter, limit, has a description in the schema. The tool description adds no parameter-specific details, so it does not exceed the baseline for a fully documented schema.

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

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

The wording 'List your recent Emergent.sh projects/jobs' specifies the operation and resource, and mentioning status and preview URLs clarifies what the caller gets. This separates it from singular, create, or preview tools without ambiguity.

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

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

The description clearly implies a read/recent-listing context, so an agent would know to call it when it needs an overview of existing projects. It does not explicitly contrast with siblings like emergent_get_project, but the plural 'projects/jobs' and 'recent' establish the appropriate use case.

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

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

There are no annotations, so the description carries the behavioral burden. It explains that the agent is paused and waiting for input, and that responding enables the build to continue. This discloses the core behavioral effect without only restating the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The primary purpose is front-loaded, and the usage condition is stated directly afterward. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool with no output schema, the description plus schema fully covers what an agent needs: what the tool does, when to use it, and what inputs are required. Nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already documents jobId and response adequately. The description adds minimal extra meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Respond' and the resource: 'a HITL question from the Emergent agent.' It distinguishes itself from siblings like emergent_wait_for_build and emergent_wake_environment by specifying this is for human-in-the-loop responses, not waiting or environment actions.

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

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

The description gives a clear condition: 'Use when the agent has paused and is waiting for your input to continue building.' It does not explicitly mention when not to use it or name alternatives, but the trigger is specific enough for an agent to select this tool correctly.

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

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

Without annotations, the description carries the behavioral transparency burden. It usefully discloses the Playwright dependency and that it is installed automatically, which helps an agent anticipate setup. However, it does not mention whether the tool returns file paths, whether it performs network requests, or how failures are surfaced.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, both useful: the first front-loads the core behavior and viewport scope, the second adds a relevant prerequisite. There is no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a relatively simple screenshot tool, the description covers the main purpose, viewport options, and an important runtime prerequisite. Since there is no output schema, it could mention what the tool returns or that screenshots are saved to outputDir, but the available schema and description are sufficient for basic invocation.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds context about the viewport names but does not provide additional parameter-level meaning beyond what the input schema already offers.

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

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

The description states a specific action ('Take screenshots'), a clear resource ('the live preview'), and a specific scope (multiple viewport sizes: phone, tablet, laptop, TV). This clearly distinguishes it from sibling tools like emergent_get_preview, which is about retrieving preview information rather than capturing images.

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

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

The intended use is implied: use this tool when screenshots of a live preview at various viewport sizes are needed. However, the description gives no explicit guidance on when to prefer this over alternatives or when not to use it, and the sibling tool emergent_get_preview is not contrasted.

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

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

With no annotations provided, the description correctly carries the behavioral burden: it discloses that the tool polls, blocks until completion, and can fail or time out. This informs the agent that the operation is not instantaneous and may be long-running.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, with the action front-loaded and the usage context second. Every phrase contributes necessary information and there is no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter polling tool, the description covers what it does, when to use it, and the failure/timeout behavior. The absence of an output schema is a minor gap since the description doesn't describe the return payload, but the core call context is complete.

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

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

The input schema already documents both parameters fully (jobId and timeoutMinutes) with 100% coverage. The description adds only minimal context about job/build semantics, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Poll a job until it completes (or fails/times out)' and clearly identifies the target as a build job. It is distinct from the sibling tools, though it does not explicitly name the sibling it differs from.

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

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

'Use after emergent_create_project to wait for the build to finish' provides explicit contextual usage guidance. It doesn't mention when not to use it or name alternative polling tools, but the intended placement in the workflow is clear.

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

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

With no annotations provided, the description bears the responsibility for behavioral disclosure. It explains the core behavior and the auto-sleep rule, but does not disclose whether waking is idempotent, whether it costs credits, how long waking takes, or what happens if the environment is already awake. This is adequate but not rich in behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single well-structured sentence with no filler. The core action comes first, and the useful sleep-threshold context is appended parenthetically without distracting from the primary purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, no-output-schema tool, this description is largely sufficient: it states the operation and the condition under which it is needed. It could mention side effects or error behavior, but the low complexity and clear purpose keep the definition reasonably complete.

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

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

Schema description coverage is 100%, with jobId documented as 'Job ID of the sleeping environment'. The tool description adds no additional parameter meaning, but because the schema already carries full parameter documentation, the baseline 3 is appropriate.

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

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

The description uses a specific verb 'Wake up' with a clear resource, 'sleeping Emergent environment', and adds the auto-sleep-after-30-minutes context. This immediately distinguishes it from sibling tools like emergent_create_project or emergent_list_projects, making the purpose unambiguous.

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

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

The description explicitly frames the tool's use case: waking an environment that is sleeping due to inactivity, with the 30-minute threshold making the condition concrete. It does not explicitly name alternatives or when-not-to-use, but the conditional context is clear enough for an agent to decide when this tool applies.

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