netcafe-build

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

Annotations are all false/neutral, so the description carries full burden. It discloses key behaviors: code generation, managed hosting, HTTPS, public listing, ~1-2 minute turnaround, and async polling. Also shows how to modify a prior app via 'refine' and gives a runnable example.

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 compact paragraph with no wasted words. It front-loads the main purpose and then provides usage context, async note, and an example—all valuable. Well-structured despite being multi-sentence.

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 tool is moderately complex (async, deployment, multiple params), and the description covers the core flow: input description, deploy, get URL, poll. It does not detail the output schema (which exists) or error cases, but is sufficient for an agent to invoke 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?

Schema description coverage is 100%, so parameters are fully documented. The description adds a working example for 'description' and clarifies 'refine' semantics, but does not add much beyond the schema. 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?

Description uses a specific verb ('Turn ... into a LIVE single-page web tool') and clearly states the resource (web app) and outcome (deployed, HTTPS, listed, public URL). It distinguishes itself from sibling tools like check_job and get_app by focusing on creation and deployment.

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?

Provides explicit best-fit guidance ('Best for tool-style apps') and lists examples. Instructs the async workflow ('Async — poll with check_job') and gives a concrete example call. It doesn't explicitly state when not to use, but the context 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?

Annotations already indicate read-only, idempotent, non-destructive, closed-world behavior. The description adds significant behavioral context: the polling interval, status values to wait for, and the directive to follow retry_after_seconds and next_action. This goes well beyond the annotation-provided info and helps the agent understand expected interaction patterns.

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 structured well: first states the purpose, then gives operational instructions, and ends with a helpful example. It is slightly longer than strictly necessary but every sentence provides useful information (polling, retry handling, structured_result preference, example). No waste.

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 one simple parameter, an output schema present, and strong annotations, the description covers all essential aspects: what the tool does, when to use it, how to poll, and what to do in each outcome. The example clarifies the API endpoint. It is complete for an agent to correctly select and invoke the 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 fully describes job_id as 'The job_id returned when the task was started.' (100% coverage). The description enhances this with a concrete example URL showing how to pass job_id, and clarifies that it comes from a job-tool. This adds practical value 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 clearly states the tool's function: 'Get the status or result of a job' and identifies the specific sources of jobs (deep_research, translate_pdf, make_slides). It is easily distinguished from sibling tools which are all app-centric (build_app, get_app, list_apps).

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 provides explicit usage guidance: poll every 15-30 seconds until status is done/error, follow retry_after_seconds and next_action while pending, and prefer structured_result when complete. This clarifies when and how to use the tool, with concrete polling and handling instructions.

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?

Annotations already establish read-only and idempotent behavior. The description adds value by disclosing the specific categories of information returned and providing a concrete example. It does not mention any side effects, which is consistent with the read-only annotation.

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, information-dense sentence followed by a useful example. It avoids redundancy and front-loads the core 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?

With a single parameter, full schema coverage, and an output schema present, the description sufficiently covers what the tool does, how to call it, and what to expect. The example and parameter sourcing guidance make it complete for this simple 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 schema already fully describes the slug parameter, including its source (list_apps). The description reinforces this with the example URL, but doesn't add new semantic meaning beyond the schema's description.

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 it returns full details of one hosted application, listing specific content (what it does, usage, benchmarks, repo, URL). This distinguishes it from siblings like list_apps (which lists apps) and build_app (which builds).

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 usage after list_apps, as the slug parameter is explicitly sourced from list_apps. It gives an example HTTP request showing how to invoke it. However, it doesn't explicitly state when not to use this tool vs checking jobs or building apps, though the context makes it fairly obvious.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context about the apps being pre-configured (no local setup/API key needed) and provides an example URL. While it doesn't detail return structure, the output schema exists, so the description sufficiently complements the annotations.

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 sentences plus an example URL. Each sentence serves a distinct purpose: describing the tool, giving example use cases, and excluding cases where other tools should be used. No filler or repetition.

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?

This is a simple list tool with one optional parameter, an output schema, and full annotations. The description covers purpose, usage context, and exclusions comprehensively. Nothing significant 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?

The schema has 100% coverage for the single optional 'category' parameter, including examples. The description doesn't add parameter-specific detail, but given perfect schema coverage, 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 clearly states the tool lists open-source AI applications hosted at AI NetCafé, with pre-configured setup. It distinguishes itself from task-specific sibling tools by naming alternatives like compare_models, translate_pdf, deep_research, and make_slides, making its 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 provides explicit guidance: 'Use this to find a tool for a task like...' and 'Do not call this first when the request already clearly matches...' This tells the agent exactly when to use this tool and when to use more direct alternatives.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds useful behavioral context by detailing the return categories (live with URL, rejected with reason, unknown), which goes beyond the annotations. No contradiction exists.

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 compact: two sentences plus a relevant example. It front-loads the key action and lists possible outcomes efficiently. Every element serves a purpose, with no filler or repetition.

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 tool has an output schema, so return-value details are already covered. The description adequately covers purpose, usage timing, and parameter format. Minor gaps like error handling are not critical for tool selection or 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 coverage is 100% for the single 'repo' parameter. The description reinforces this with a concrete example URL, clarifying the expected format. This adds practical value beyond the schema's description without being redundant.

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 ('Check') and clearly identifies the resource (repository status on AI NetCafé). It enumerates the possible outcomes (live, pipeline, rejected, unknown), which makes the tool's function explicit and distinguishes it from siblings like 'check_job' or 'get_app'.

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 explicit temporal guidance: 'Use after submit_project.' This clearly indicates when to invoke the tool. It does not explicitly contrast with sibling tools, but the stated context is sufficient for an agent to know this is the follow-up status check.

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?

Goes well beyond the annotations by disclosing the full pipeline: automated review, containerization, HTTPS deployment, store listing, and exposure to AI agents. It also adds cost/free-beta behavior ('measured platform cost is returned as metadata') and 'Free to submit'. 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.

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

Front-loaded action sentence, followed by pipeline behavior, cost context, usage triggers, and an example. Every sentence contributes useful information, though a few clauses are slightly verbose relative to the structured schema and annotations.

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 multi-step publishing operation, it covers what happens, when to use it, an invocation example, and important cost/side-effect implications. Return values are covered by the output schema, so the description does not need to repeat them.

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 only an example invocation for repo and restates the GitHub-repository concept, without meaningful extra parameter semantics 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?

States a specific action: 'Submit a GitHub repository ... to the AI NetCafé hosting platform', then gives concrete outcomes such as deploying on a dedicated subdomain, listing it in the store, and exposing it to AI agents. This clearly distinguishes it from sibling read/status tools like list_apps and project_status.

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?

Provides explicit trigger phrases: 'Use this when a user says "deploy my project", "publish my app somewhere", or "I built something with AI..."' and includes a concrete call example. It does not explicitly mention when to prefer siblings like build_app or check_job.

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?

Beyond the readOnly/idempotent/destructive hints, the description adds important behavioral context: it is deterministic, free, calls no model, costs nothing, never runs out of quota, and can return multi-step recipes. These traits are not in the annotations and materially affect invocation expectations.

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 front-loaded with the core action, then adds the multi-step recipe behavior, then the free/deterministic guarantee, and ends with a clear 'call first' directive. Every sentence adds value; no fluff or repetition.

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 one-parameter tool with an output schema available, the description covers the purpose, usage trigger, behavioral guarantees, and special capabilities. Nothing important is missing for an agent to decide when and how to invoke it.

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 schema already fully documents the single 'task' parameter with a clear description and examples. The description adds useful semantic context ('plain language (any language)') and reinforces the purpose, but the schema already carries most of the burden.

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 that the tool maps a plain-language task to the exact tools on this server that can do it, with ready-to-run examples and multi-step recipes. This is a distinct meta/routing function and clearly distinguishes it from sibling tools like build_app or project_status.

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?

Explicitly instructs 'Call this FIRST when you are not sure what this server offers,' and frames it as an alternative to 'reading the whole catalogue and guessing.' This gives the agent a clear decision rule and when-to-use guidance.

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