Hatchable

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

Annotations include idempotentHint=true and destructiveHint=false, and the description aligns perfectly by detailing that it scaffolds a file, includes imports, method dispatch, and reserved 'auth' route. No contradiction; description adds useful behavioral context beyond 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?

Description is concise (~10 lines), with front-loaded purpose, bullet points for generated code, and clear examples. No unnecessary words; 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?

Despite no output schema, the description fully explains what is created (file with shape, imports, dispatch) and covers dynamic segments and reserved routes. Comprehensive for a scaffolding tool with straightforward behavior.

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%, but the description adds value: clarifies defaults (requires_auth default true), explains dynamic segments ([param]), and provides examples for handler_body context (user.id available). Enhances understanding beyond schema alone.

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 'Scaffold a file-routed api/ endpoint with the canonical handler shape', specifying a concrete verb and resource. It distinguishes itself from siblings like add_page (pages) and write_file (arbitrary files) by focusing specifically on API route scaffolding.

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 this tool is intended for creating API routes with boilerplate, but does not explicitly contrast with alternatives. The sibling context (e.g., add_page for pages) makes usage clear, but missing explicit when-not-to-use guidance or 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?

Describes async execution, platform-managed retries, backoff, dead-lettering, and immediate return. Annotations already provide idempotentHint: true and non-destructive, but description adds rich behavioral context. Minor lack of overwrite behavior disclosure prevents a 5.

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?

Approximately 120 words, front-loaded with purpose, followed by usage, differentiation, and example. Every sentence adds value with 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?

Given no output schema and moderate complexity, description covers structure, behavior, guidance, and example. Adequately addresses all needed information for a developer to use the 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?

Schema coverage is 80% (only project_id missing description). Description adds meaning: explains how job_name and enqueue_route map to files, gives defaults, and provides example. Sufficiently compensates for missing project_id 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?

Description states specific verb 'Scaffold a background-task pair' and resource 'api/jobs/<job_name>.js + api/<enqueue_route>.js'. Clearly distinguishes from sibling 'add_scheduled_job' with explicit comparison.

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 states when to use: 'when the user shouldn't wait for the work' and gives examples. Also contrasts with 'add_scheduled_job' by explaining difference between cron and fire-and-forget.

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?

Description provides behavioral details beyond annotations: it creates a file, uses Chromium, has three modes, and mentions shared Fly app infrastructure. Annotations indicate idempotentHint=true and destructiveHint=false, and description does not contradict them. It adds context about query parameters and return types.

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?

Description is concise yet comprehensive, using bullet points for modes and an example. It is front-loaded with the core purpose and provides all necessary details without unnecessary text.

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?

Given the tool's complexity (multiple modes, query params), the description covers most aspects. It lacks output schema but describes return types for each mode. Could mention error handling or rate limits, but overall sufficient for correct 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?

Input schema has 75% coverage; description adds meaning by explaining the three modes with their specific query parameters (?full, ?format, ?waitFor, ?size, ?landscape) and clarifies requires_auth default and usage. Route and project_id are sufficiently described in 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?

Description clearly states the tool scaffolds an api/<route>.js using hatchable.browser. It lists three distinct modes with specific behaviors, making the purpose unambiguous and distinguishing it from sibling tools like add_api_route or add_llm_endpoint.

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?

No guidance on when to use this tool versus alternatives. The description explains what the tool does but does not specify use cases, prerequisites, or when not to use it. The example demonstrates usage but lacks comparative context.

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?

The description explains memoization via ctx.step, crash recovery resuming from the last completed step, and the scaffolded file structure. Annotations already indicate idempotency, but the description adds valuable context about the behavioral guarantees beyond what annotations provide.

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 concise, with a clear opening sentence, a context paragraph, and an example. Every sentence adds value without 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?

The description covers the tool's purpose, use cases, and behavior. It does not explain the return value (no output schema) but that is acceptable for a scaffolding tool. The context is sufficient for an AI agent to decide when and how to use 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?

With 80% schema coverage, most parameters are already described. The description adds an example that uses route and workflow_name, but does not clarify project_id or requires_auth beyond defaults. Parameter semantics are adequate but not enriched significantly.

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 specifies that the tool scaffolds an api/<route>.js file using a durable workflow pattern with memoized steps. This clearly differentiates it from sibling tools like add_api_route or add_background_task by emphasizing crash recovery and multi-step orchestration.

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 states when to use this tool (operations where partial completion is dangerous) and provides examples like checkout and onboarding. It implicitly tells when not to use it (non-durable tasks) but does not name alternative tools.

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 annotations (idempotentHint=true), the description adds important behavioral details: automatic tracking of bounces/complaints, platform suppression list filtering, and the side effect of logging when log_to_table is true. It does not cover error cases or exact idempotency behavior, but the added context is valuable.

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 concise: a short paragraph followed by a single example. Every sentence contributes meaningful information without redundancy. It front-loads the purpose and then provides key details.

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?

Given 5 parameters, no output schema, and the tool's scaffolding nature, the description covers essential aspects: purpose, body shape, automatic behavior, and a prerequisite condition. It is sufficiently complete for an agent to use the tool correctly, though it could mention idempotency behavior.

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 80% (4 of 5 parameters documented), so baseline is 3. The description adds value by providing an example call and clarifying that log_to_table requires a table and default_subject is optional, but it does not explain the undocumented project_id parameter, leaving a gap.

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 explicitly states it scaffolds an API endpoint for sending transactional email, with a clear verb (scaffold) and resource (api/<route>.js for email). This purpose is distinct from siblings like add_api_route, which create generic routes, making it easy for an agent to select the correct tool.

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 clear usage context: when to use log_to_table (requires a pre-existing table) and the automatic bounce/complaint handling. It does not explicitly name alternative tools for non-email routes, but the sibling list includes add_api_route, so the guidance is implied and adequate.

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 annotations (which are minimal), the description explains the scaffold action, base64 input, storage via hatchable.storage, return of signed URL, and the parameter 'requires_auth'. 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?

The description is concise: three sentences plus an example. It front-loads the core purpose and flows naturally. No unnecessary words.

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?

Given no output schema, description adequately covers return values ('signed URL') and example return structure. It covers the tool's behavior and parameters well, though 'project_id' purpose is implicitly clear from context.

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?

With schema coverage at 50%, the description adds value by clarifying the 'route' parameter through the example and body format, and explains 'max_bytes' and 'requires_auth'. However, 'project_id' is not explained.

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 scaffolds an API route for base64 file upload. It uses a specific verb ('scaffold') and resource ('api/<route>.js'), and contrasts with the sibling 'upload_file' tool for large files.

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 when-to-use guidance: small files use this tool, large files (>5 MB) should use the 'upload_file' MCP tool instead. Also notes the canonical Hatchable upload flow.

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?

The description focuses on the generated route's behavior (cache-control, query params) but does not disclose the tool's own behavior, such as whether it overwrites existing files, error handling, or idempotency implications. Annotations indicate idempotentHint=true, but the description does not clarify if re-run is safe.

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 concise with three sentences and an example. It is front-loaded with the verb 'Scaffold' and efficiently covers purpose, query parameters, caching, and usage. No unnecessary details.

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 covers the main functionality and generated route behavior, but lacks details on error handling, auth requirements, dependencies (hatchable.images), and edge cases like missing or invalid parameters. Given no output schema, return value expectations are unclear.

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?

With only 50% schema coverage, the description compensates by explaining the 'route' parameter through an example and detailing defaults for 'default_format' and 'default_max_width'. It clarifies that 'route' becomes a path like '/api/thumbnail' and provides default values. However, 'project_id' is not covered.

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 specifies that the tool scaffolds an API route for image transformation (fetch, resize, format conversion, quality). It distinguishes itself from sibling tools like add_api_route and add_browser_endpoint by explicitly targeting image transform endpoints.

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 the use case (creating image transform endpoints) and provides an example, but it does not explicitly state when to use this tool versus alternatives or mention any prerequisites or constraints.

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?

The description details the generated files, request structure, required auth, and return format. Annotations indicate idempotentHint=true, but the description does not contradict this—scaffolding a file is idempotent if it overwrites consistently. Overall, the behavioral expectations are well communicated.

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 concise and well-structured: first sentence captures the action, followed by bullet-like list of outputs, then an example and note. Every sentence contributes useful information without 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?

The description covers the output format, required dependency, and example usage. Given the tool's scaffolding nature and no output schema, it provides sufficient context for an agent to understand the tool's purpose and results.

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?

Despite 100% schema coverage, the description adds context for parameters like purpose (label for dashboard) and provides an example usage, enriching the schema beyond field definitions. It does not fully explain all parameters' effects but adds meaningful value.

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 scaffolds an API endpoint that uses lib/llm.js for LLM calls with built-in observability. It distinguishes itself from generic route creation tools like add_api_route by specifying the LLM integration and generated file structure.

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 mentions a prerequisite (lib/llm.js must exist) and provides an example, offering clear guidance on when to use the tool. However, it doesn't explicitly contrast with alternatives like add_api_route, which could help agents choose 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?

The description adds behavioral context beyond annotations by noting that it writes a file (tools/<name>.js) and transforms the project into a tool provider. Annotations provide idempotentHint=true and destructiveHint=false, but the description clarifies the side effect, which is valuable.

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 with a clear opening sentence, followed by context and an example. While not extremely concise, each sentence adds value: core action, external access, forking implications, and file creation details.

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?

Given that the tool creates a new MCP tool and has annotations, the description provides adequate context about side effects and usage. However, it could be more complete by mentioning the return value or what happens on subsequent invocations (since idempotentHint=true).

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 description supplements the schema (75% coverage) by explaining the 'name' format, 'input' schema structure with examples, and the purpose of 'description'. It adds broader context about the file-writing effect and how parameters are used in the generated tool.

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 registers an MCP tool exposed by the project's /mcp endpoint, with a specific verb and resource. It distinguishes from sibling tools (e.g., add_api_route) by focusing on MCP tool registration, and includes an example for clarity.

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 explains when to use the tool: to make the project a tool provider for external agents. It provides context about the project's /mcp endpoint and forking behavior, but does not explicitly state when not to use it or name alternative tools for different endpoint types.

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?

The description adds behavioral context beyond annotations: it details per-user scoping ('facts from one user are never returned to another') and the use case for long-term memory. Annotations provide idempotentHint=true, which is not contradicted.

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 well-structured with a clear flow: purpose, scoping, use case, example. It is informative but slightly verbose; could be trimmed without losing meaning.

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 covers the main purpose and scoping well, but lacks information about return values (no output schema) and does not explain the required 'project_id' parameter. Error conditions or permissions are not addressed.

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 50%; the description adds meaning for 'namespace' (URL prefix) but fails to explain 'project_id', which is required. It provides partial parameter enlightenment but misses a key parameter.

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 explicitly states that the tool scaffolds two routes for remembering and recalling facts via hatchable.memory, with clear verb 'scaffold' and specific resource (memory endpoints). It distinguishes from siblings like add_api_route by focusing on memory storage.

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 recommends using the tool for chat/assistant apps needing long-term context and provides an example. However, it does not explicitly state when not to use it or compare with alternative tools like add_api_route.

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 provide basic safety traits (idempotent, non-destructive). The description adds value by detailing output structure ('max-w-3xl content shell'), tech stack constraints ('No build step. No React. No TypeScript.'), and file location. 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?

Description is moderately long but well-structured: purpose first, then details, then two examples. Could be slightly more concise, but the examples are valuable. Every sentence adds meaningful information.

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 covers purpose, parameters, and usage. However, it lacks information about return value or error handling (e.g., what if slug is missing? or idempotency behavior). Annotations partially cover safety, but return type is absent. Still, for a scaffolding tool with good annotations and schema, it is largely adequate.

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 already has complete parameter descriptions (100% coverage). The description enriches this with usage guidance: e.g., for body_html it says 'Don't include <html>/<head>/<body> — those are added', and for alpine_data it explains 'Becomes pageData() on x-data'. Examples show parameter combinations.

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 scaffolds a Tailwind+Alpine HTML page at a specific path. It distinguishes itself from siblings like add_api_route or add_table by specifying the tech stack and file type. The mention of an alternative (React-via-esm.sh) further clarifies its niche.

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 states when to use: for Tailwind+Alpine pages. Directly tells when not to use: 'For rich client state (multi-step forms, dashboards), use React-via-esm.sh'. Examples illustrate typical use cases, providing clear context.

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 provide idempotentHint=true and destructiveHint=false. The description adds value by noting upfront cron validation, file scaffold creation, and the deploy pipeline registration. It does not mention overwrite behavior, but idempotent hint covers that.

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 concise with two short paragraphs and an example. The first sentence immediately states the purpose. Every sentence contributes meaningful information without 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?

Given the tool has no output schema and moderate complexity, the description covers the main behavior (file creation, validation, registration). It lacks details on return values or error cases beyond cron validation, but annotations fill some gaps. Overall fairly 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%, so each parameter is already described in the schema. The description includes an example that demonstrates parameter usage, adding slight value 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?

The description clearly states the tool scaffolds a cron-fired job file, validates the cron expression, and registers it via the deploy pipeline. It distinguishes itself from siblings like add_api_route and add_llm_endpoint by focusing specifically on scheduled jobs.

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 explains what the tool does but does not explicitly state when to use it versus alternatives. It implies usage for creating cron jobs but lacks guidance on when not to use or which sibling tool to choose instead.

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?

Describes default columns and index, and how migration filename is generated. Annotations provide no behavioral details; description fills most gaps. Lacks prerequisites (e.g., database setup) or conflict handling.

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?

Concise, well-structured with bullet points and example. Core action stated first, no redundant information.

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?

Covers purpose, defaults, example, and naming convention. Does not describe return value, which would help agent know success indicator.

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 covers all parameters with descriptions. Description adds value with defaults, per_user explanation, and a full example showing how columns, per_user, and name interplay.

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 clearly states it appends a migration SQL file with a new Postgres table, using specific verb and resource. Distinguishes from sibling tools that handle API routes, pages, etc.

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?

No explicit when-to-use or when-not-to-use guidance. Implies use for new tables via migrations, but doesn't mention alternatives like execute_sql for ad-hoc changes or write_file for manual edits.

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 include destructiveHint: true, which is consistent with creating a new project. The description adds detail about what is created (slug, database, project ID) but does not discuss side effects like potential resource costs or limits. There is 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?

The description is extremely long (over 2000 words) and includes extensive documentation about project structure, routing, SDK, auth, etc. Much of this content is relevant to the project platform but not specific to the create tool. This buries the key purpose and usage guidelines. A concise description (e.g., 5 sentences) would be far more helpful for an agent deciding when to call this tool.

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?

Despite the large amount of text, the description lacks certain completeness for the tool itself. It does not specify the exact return value shape (e.g., JSON fields returned), error cases (e.g., name conflicts, invalid visibility), or whether the database is immediately accessible. The output schema is absent. The description over-delivers on platform concepts but under-delivers on tool-specific behavior.

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 the parameters. The description adds value by explaining the free/$12/$39 tiers and that 'personal' is default, but does not elaborate on 'description' beyond the schema. The visibility enum is well explained in the 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 the tool creates a new Hatchable project, generating a URL slug, database, and returning IDs/URLs. It also positions this as the first step before writing files or creating tables, distinguishing it from sibling tools like deploy or write_file.

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 says 'Call this first before writing files or creating tables,' providing clear sequencing. It also implicitly contrasts with update_project (for existing projects) and deploy (for deploying after creation). No explicit alternatives are named, but the context is very 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?

The description explains idempotent behavior with 'skipped' reporting missing keys, and notes that changes take effect on next deploy. Annotations already include idempotentHint and destructiveHint, but the description adds valuable detail beyond those.

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 concise sentences, each providing unique information: action, different modes, idempotency, and timing. No redundancy or wasted words.

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?

Given no output schema, the description sufficiently explains behavior (idempotent, skipped) and timing. Could mention that missing keys are not errors, which it does. No obvious gaps for a delete 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?

Schema coverage is 100%, so schema already describes parameters. The description adds context that 'key' is for single and 'keys' for batch, but this is also implied by the schema. No additional semantic value beyond 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 action ('delete'), the resource ('environment variables by key'), and differentiates between single and batch deletion using 'key' or 'keys'. It distinguishes from siblings like 'set_env' and 'list_env'.

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 clear context for use: delete by key or keys, and notes batch behavior. However, it does not explicitly mention when not to use this tool or compare with 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 provide idempotentHint=true and destructiveHint=true, so the description doesn't need to repeat those. The description adds critical behavioral context: 'Takes effect after the next deploy' which is beyond annotations. This clarifies that deletion is not immediate, which is essential for agent understanding. No contradictions 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?

The description is extremely concise: two sentences, zero wasted words. It states the action and a crucial deferred effect. Perfectly 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?

Given the tool's simplicity (2 params, no output schema), the description is adequate but not complete. It misses mention of whether deletion is reversible, any prerequisites (e.g., file must exist), and the exact behavior after deploy (e.g., do you get a confirmation?). However, with good annotations and full schema coverage, it's minimally viable.

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 parameters well. The description does not add any extra meaning beyond what the schema provides, so 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 clearly states the verb 'delete' and resource 'project file', and adds the important qualifier 'Takes effect after the next deploy' which distinguishes it from immediate deletion. This is clear but doesn't explicitly contrast with sibling tools like write_file or patch_file.

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 for deleting a file, but provides no guidance on when not to use it or alternatives. For example, it doesn't mention that deleted files might be recoverable or that 'deploy' must be called for the deletion to take effect, nor does it contrast with tools like write_file that might overwrite or modify files.

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 mark destructiveHint=true, so the mutation is known. The description adds details about what it does (migrations, seeds, CDN, endpoints, version increment) and mentions side effects like first-deploy seed and personal project restrictions. 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?

The description is front-loaded with actions, but the last sentence about url field is somewhat tangential to the deploy action. Still efficient and well-structured.

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?

Given no output schema, the description adequately explains what happens and when to use. It covers key behavioral aspects. Could mention that it's not idempotent (but annotations already provide destructiveHint). Overall 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 coverage is 100% with a clear description of project_id. The description adds context about deployment behavior but no additional parameter semantics are needed.

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 'Deploy' and the resource 'project', and lists specific actions: runs migrations, seeds, copies files, increments version. It also distinguishes from the sibling 'dry_run_deploy' by being the actual deploy.

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 says 'Call this after writing all your files', and provides alternatives: 'To verify your functions work after deploying, use `run_function`'. Also distinguishes between public URL and personal project behavior.

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=true and destructiveHint=false, so the description adds value by detailing specific error/warning checks and the 'would_deploy' summary. It mentions runtime footguns (e.g., missing await) but could further clarify side effects or scope of validation.

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 two paragraphs: first states purpose and return values, second lists specific checks. Every sentence adds value without redundancy, and it is appropriately sized for the complexity.

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?

Given the simple input schema (one parameter) and clear annotations, the description is complete enough. It explains the output structure and examples of errors/warnings. No output schema exists, but the description compensates by listing return fields.

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 'project_id' parameter is fully described in the schema. The description does not add extra semantics for this parameter, earning a baseline of 3.

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 runs validators without deploying, distinguishing it from the 'deploy' sibling. It lists specific checks (package.json, reserved table names, auth routes, usage caps) and return types (errors, warnings, would_deploy), 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 implies use before deploying to avoid mid-flight failures, and contrasts with 'deploy' by mentioning safety. However, it does not explicitly state when not to use this tool (e.g., when no validators exist) or alternatives beyond deploying.

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 mark the tool as destructiveHint=true, which is consistent with SQL mutations. The description adds behavioral details: return formats for different SQL types, and that DECIMAL columns return as strings. With no output schema, this is valuable transparency.

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 well-structured with sections: supported statements, parameterized query guidance, and return format examples. It's concise and front-loaded with 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?

Given the tool has no output schema, the description compensates by detailing return formats. It explains supported SQL types and behavior for different statements. Missing information about error handling or permissions, but overall complete enough.

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%, but the description adds meaning by explaining the binding pattern ($1, $2) and encourages parameterized queries for safety, which is not in schema descriptions.

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 runs SQL against the project's PostgreSQL database, listing supported DML and DDL statements. It distinguishes itself from siblings like run_code or run_function which run code, not SQL.

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 usage guidelines by encouraging parameterized queries and specifying placeholders ($1, $2). It also hints at proper usage by mentioning safety, but does not explicitly say when not to use this tool vs 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 show destructiveHint=false, readOnlyHint=false. The description clarifies it copies code and schema but no data, and the fork becomes a personal project. This adds behavioral detail beyond 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?

The description is three sentences, front-loaded with the primary action, and each sentence adds value without unnecessary verbosity.

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?

Given the simple input schema, clear annotations, and no output schema needed, the description fully covers what an agent needs: action, scope, constraints, and recommendation.

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 both parameters. The description adds no additional meaning beyond the schema descriptions (overall purpose, defaults) for 'name' and 'project_id', so baseline 3 applies.

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 action ('Fork a public project into your account') and what is copied ('code and database schema without data'). It distinguishes from siblings like 'create_project' by specifying it starts from an existing app, but does not explicitly differentiate from other tools.

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 recommends when to use this tool: 'This is the recommended way to start from an existing app' and implies use before modification, providing clear 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?

Annotations already indicate read-only and non-destructive. Description adds 'Always-fresh — regenerated against live DB state' and 'Works on day-zero projects with no files yet', which are useful behavioral traits not covered by 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 concise sentences, each serving a distinct purpose: what it returns, freshness/capability, and usage directive. No wasted words; 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?

No output schema, but description exhaustively lists the manifest contents (platform support, SDK modules, file conventions, deny-list, tables, env keys, tasks, deploy info) plus freshness guarantee, providing full understanding of what the tool returns.

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 has 100% coverage, describing the single parameter as 'Public project id (proj_…)'. Description does not add additional meaning beyond what the schema provides, so 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?

Description clearly states 'Return the AGENTS.md manifest for a project' and enumerates specific contents. Positioned as the first call for a Hatchable project, distinguishing it from sibling action tools.

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 starting work on a Hatchable project' and labels it 'single source of truth'. Does not explicitly list when not to use or compare to other info tools, but the directive 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 declare readOnlyHint=true and destructiveHint=false. The description adds value by detailing return contents (file manifest, function list) and hinting at historical capture behavior. No contradictions.

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 two sentences, front-loads the purpose, and every sentence adds value. No wasted words.

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?

Given the tool's moderate complexity, schema coverage, and annotations, the description is largely complete. It could mention pagination or limits on file manifest size, but the current level is sufficient for an agent.

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%, so schema already describes both parameters. Description does not add extra meaning beyond the schema, earning a baseline of 3.

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 'Detail view of one deployment by version number' and specifies what it returns: 'full file manifest (paths, hashes, sizes) and function list'. It distinguishes from siblings like list_deployments by noting it gives detail for a specific version.

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 suggests using it with list_deployments to audit or compare versions, providing clear context. However, it does not explicitly state when not to use it or list alternatives beyond list_deployments.

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=true and destructiveHint=false, confirming it's a safe read. The description adds value by specifying what information is returned (database schema, deployed functions), going beyond the annotation signal.

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 that efficiently lists the key details returned, with no superfluous words. Perfectly sized for a focused retrieval tool.

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?

Given the simple input (one string ID) and no output schema, the description adequately covers what is returned. The lack of output schema is acceptable as the description lists the types of data included.

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% (only one parameter), and its description in the schema is clear. The description adds no new parameter-level info beyond what the schema provides, earning the baseline 3.

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 specifically states 'Get project details' and lists exact fields (slug, visibility, status, deployed functions, database schema), clearly distinguishing it from siblings like 'list_projects' or 'get_schema'.

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 it should be used when full project details are needed, but does not explicitly mention when not to use it or alternatives. For example, if only the schema is needed, 'get_schema' might be more appropriate, but this is not stated.

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=true and destructiveHint=false, so the tool is known to be safe. The description adds context about the output content (tables, columns, indexes), which is helpful beyond annotations. No contradictions found.

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 sentence that efficiently conveys the purpose and output. No extraneous words, well 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?

The description is complete for a read-only retrieval tool with one parameter and no output schema. It covers the main output aspects (tables, columns, types, indexes). A minor gap is that it doesn't specify if the schema is for the entire project or specific parts, but the context (project_id) implies project-wide.

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?

Input schema has 100% coverage with a single required parameter (project_id). The description does not elaborate on the parameter beyond what the schema provides, but the schema is already clear. Therefore, 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 clearly states the tool returns database schema including tables, columns with types, and indexes. It specifies the resource (PostgreSQL database schema) and verb (return), and is distinct from siblings like execute_sql or run_function.

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 for obtaining schema details but provides no guidance on when to use this versus alternative tools (e.g., execute_sql for running queries). No exclusions or special conditions are mentioned.

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=true, so the description doesn't need to restate non-destructive behavior. It adds behavior details: Postgres backend, defaults (head_limit=250), error behavior (2s timeout), and glob support. Minus one point because it doesn't clarify whether result ordering is deterministic or mention any rate limits.

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 well-structured with a summary sentence followed by bullet points (rendered as a list in plain text). It is front-loaded with the core purpose. Slightly long but each sentence adds value.

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?

Given the complexity (8 parameters, 3 output modes) and no output schema, the description covers the major behavioral aspects and defaults. It could mention that output is not sorted or explain the Postgres regex syntax more, but it's sufficient for most use cases.

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%, so the description can be brief on params. It adds value by explaining output modes and default head_limit, but doesn't elaborate beyond the schema for each parameter. 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 clearly states it performs regex content search across project files, with specific verb 'search' and resource 'project files'. It distinguishes itself from sibling tools like 'search_documentation' or 'search_projects' by focusing on file content and specifying the regex backend and scoping.

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 on when to use this tool, including the three output modes, head_limit for broad patterns, glob filtering for narrowing paths, and how to handle regex errors. It implies it's for file search vs. other search tools.

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 include 'destructiveHint: true' and 'idempotentHint: true', but the description adds valuable behavioral details: the file is created server-side, bytes never pass through context, has size and timeout limits, and rejects private addresses. It also specifies allowed paths, which is critical for understanding side effects.

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 concise (three sentences) and front-loaded with the primary action and benefit. Every sentence adds necessary information: purpose, use cases, and constraints. No fluff.

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?

Given the tool's complexity (3 params, no output schema, but with constraints), the description fully covers what the tool does, its boundaries (size, timeout, network restrictions), and allowed paths. It is complete for an agent to decide and 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 covers all three parameters with descriptions, but the description adds context that 'url' is a remote URL to fetch, 'path' is a destination path with constraints (must be under specific directories), and 'project_id' is for project identification. Since schema coverage is 100%, baseline is 3; the description adds extra value about path restrictions, raising the score to 4.

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 'Fetch a remote URL and save the response body as a project file' with the specific verb 'Fetch' and resource 'remote URL' and 'project file'. It distinguishes itself from siblings like 'upload_file' or 'write_file' by mentioning server-side fetching and avoiding the context window.

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 mentions use cases ('seed data, vendor libs, and asset migration') and constraints ('Capped at 10 MB and 10s timeout', 'Private/loopback addresses are rejected', 'Path must live under...'). However, it does not explicitly state when NOT to use this tool versus alternatives like 'write_file' or 'upload_file'.

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 mark it as readOnlyHint=true and destructiveHint=false. The description adds value by specifying the data returned (7-day run count, error count, last_run_at) and the context (scheduled functions).

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: first states what it does, second gives a specific use case. No wasted words.

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?

Given simple input (single required param), no output schema, and good annotations, the description is complete. It explains the output fields and typical usage. Slight lack of detail on expected output format (e.g., is it a list? what if empty?).

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% with a single parameter project_id. The description doesn't elaborate on the parameter, but the schema is minimal and clear. The description adds value by explaining what the tool returns, which is not in 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 it lists cron jobs with specific fields (cron expression, run count, error count, timestamp), which is specific and differentiates from siblings like list_functions or list_deployments.

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 says to use this to verify cron jobs are firing without tailing logs, providing a clear use case. However, it doesn't mention when not to use it or 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=true and destructiveHint=false, which covers non-destructive behavior. Description adds ordering and included summary counts, which are useful but not critical. No contradictions.

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 concise paragraphs: first explains what and how, second explains why. No unnecessary words. Could be slightly tighter, but effective.

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 read-only list tool with 2 parameters, the description covers purpose, output fields, ordering, and use cases. Lacks pagination behavior beyond limit, but sufficiently complete for agent decision-making.

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% with descriptions for both parameters (limit, project_id). Description does not add parameter-specific meaning beyond schema, so baseline 3 applies.

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 states specific action (list deployments), resource (project), ordering (reverse-chronological), and included fields (version, status, etc.). Clearly distinguishes from sibling tools like get_deployment which retrieves a single 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?

Explicitly suggests use cases: understand deploy history, identify known-good version for rollback, debug regression. Lacks explicit when-not-to-use or alternatives for similar purposes.

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=true and destructiveHint=false. The description adds transparency by explicitly stating that values are never exposed, confirming that this is a read-only operation without side effects.

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, front-loaded with the main action, no redundancy. Every sentence adds useful information.

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 no output schema, the description adequately explains what is returned (key names and is_secret flag). It also tells the agent how to get actual values, which is valuable context. However, it doesn't mention any pagination or limits.

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 100% coverage with a single project_id parameter described as 'Project ID'. The description adds context about the tool's scope (listing keys for that project), which is helpful but not strictly necessary 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 lists environment variable keys for a project, specifying what is returned (key names and is_secret flag) and what is not (values). This distinguishes it from siblings like set_env or delete_env.

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 explains when to use this tool (to list env var keys) and what not to expect (values), and provides an alternative method to read actual values (process.env.KEY). However, it does not explicitly contrast with siblings like get_project or other tools.

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=true, destructiveHint=false, so the description adds little beyond confirming read-only. It does not mention performance or pagination, which might be relevant for large projects. No contradictions 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?

Single sentence, concise and front-loaded. Could be slightly more structured (e.g., bullet points), but adequate for its length.

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?

Given that there is no output schema and annotations are minimal, the description provides basic output info (paths, sizes, hashes) but misses return format details, pagination, and sorting behavior. Adequate for a simple list 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?

Schema coverage is 100% (one parameter with description). The description does not add extra meaning beyond the schema's description of project_id. 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 it lists files in a project and mentions the output fields (paths, sizes, hashes). It distinguishes from siblings like get_project (project-level) and read_file (single file). However, it could be more specific about which files (e.g., all files recursively?).

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?

No guidance on when to use this tool versus alternatives. For example, when to use list_files over grep or read_file. No explicit context about prerequisites (e.g., project must exist).

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 provide readOnlyHint=true and destructiveHint=false. The description adds that it is an 'introspection tool' and discloses the returned data cost (cheaper than reading files). No behavioral contradictions, but could mention if it requires specific permissions.

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: first explains what it does and returns, second gives usage context. No fluff, front-loaded with key information.

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?

Given there is no output schema, the description helpfully lists returned fields (route, method, etc.) which is sufficient for an introspection tool. Could mention pagination or filtering, but the simplicity and annotations make it complete enough.

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%, so the schema already documents the single required parameter (project_id) with description. The description does not add extra parameter semantics beyond the schema, earning a baseline of 3.

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 'every deployed API function for a project' and enumerates specific fields returned (route, method, runtime tier, cron schedule, invocation/error counts). It differentiates from siblings like list_deployments and list_files by focusing on functions, and from read_file by being cheaper.

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 states when to use: 'after a fork, after picking up an unfamiliar project, or to verify a deploy registered the endpoints you expected.' It also contrasts with read_file as 'much cheaper,' guiding the agent to prefer this over alternatives for overview purposes.

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=true and destructiveHint=false, so the description adds value by disclosing an expiration behavior ('Uploads expire 10 minutes after the last chunk was added'), which is critical for understanding data staleness. Would be a 5 if it also explained pagination or maximum list size.

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: first states the purpose, second gives usage scenario, third conveys an important behavioral detail. Each sentence serves a distinct purpose without 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?

Given the tool's simplicity (1 param, no output schema), the description covers the key aspects: what it does, when to use it, and a time-bound behavior. Minor omission: no mention of how to commit the upload (but that might be another tool's job).

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?

With 100% schema description coverage and only 1 parameter, the schema already documents 'project_id' as a string. The description does not add extra meaning or constraints for the parameter, so 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 ('Show') and resource ('multipart uploads currently staged for this project that haven't yet been committed'). It clearly distinguishes from sibling operations like 'upload_file' by focusing on pending/uncommitted uploads rather than initiating new ones.

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 states when to use ('recover from a disconnect') and how to proceed ('find the upload_id and resume from the next chunk_index'). This provides actionable guidance beyond the purpose.

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=true and destructiveHint=false, so the tool is safe. The description adds value by listing returned fields (visibility, tier, role, version), which goes beyond annotations, but does not disclose pagination or rate limits.

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?

Single sentence, no waste, front-loaded with verb and resource. Every word adds value.

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 tool with 0 parameters, no output schema, and clear annotations, the description is nearly complete. It could mention that it returns a list, but that is implied by 'list'. The returned fields are specified, which suffices.

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 0 parameters, so description cannot add parameter meaning beyond what schema provides. Schema coverage is 100%, making a baseline score of 4 appropriate, but since there are no parameters to explain, a 3 is reasonable for neutral impact.

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 a specific verb ('list') and resource ('projects you own or collaborate on'), and distinguishes what properties are returned (visibility, tier, role, current version). This differentiates it from sibling tools like 'search_projects' which likely involve filters.

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 for retrieving all projects you are involved in, with no explicit when-not or alternatives. However, given the sibling 'search_projects', it contrasts by not offering search capabilities, which 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?

The description discloses that the tool is destructive (matches annotation `destructiveHint: true`) and explains the replacement logic and error condition. It adds context beyond annotations by specifying that only the first occurrence is replaced and that the old_string must match exactly. Slightly lower score because it does not mention whether the operation is idempotent (though annotation says false) or if there are side effects like file locking.

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 three sentences, each adding essential value: purpose and comparison to write_file, usage guidelines with exact match requirement, and insertion technique. No fluff.

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?

Given the simple tool (4 parameters, no output schema), the description covers most necessary context: when to use, how it works, error condition, and insertion trick. Minor gap: no mention of encoding or file size limits, but that is acceptable for a straightforward edit operation.

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% with descriptions for each parameter. The description adds context about exact match requirement and insertion technique but does not provide additional semantic 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 ('Patch file') and resource ('existing project file'), and clearly states that it replaces the first occurrence of `old_string` with `new_string`. It distinguishes itself from the sibling `write_file` by noting it is intended for targeted edits without rewriting the entire file.

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 states when to use this tool ('instead of write_file when modifying large files') and provides guidance on how to insert at a specific position. It also warns about the requirement for exact match and error behavior, giving clear context for appropriate usage.

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 readOnlyHint true, so no destructive behavior. Description adds that offset/limit return line-numbered content for patch_file, which is useful beyond 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, front-loaded with purpose, then usage. Could be slightly more concise, but no wasted words.

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?

Given simple read operation and full schema coverage, description is complete. No output schema needed since return is just file content.

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 already describes all 4 parameters clearly (100% coverage). Description adds context about line numbers for offset/limit but doesn't add meaning beyond 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?

Clearly states it reads a project file, distinguishes from siblings like write_file, patch_file, and grep. Specific verb+resource.

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 when to use offset/limit (for large files), but doesn't explicitly mention when not to use this tool or alternatives like grep for content search.

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?

The description details runtime environment (same bindings, non-persistent), but the destructiveHint annotation already indicates potential side effects (e.g., database writes). The description adds value by clarifying scoping (isolate runtime), timeout, and source length caps, and that nothing is persisted. It does not contradict 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?

The description is concise with front-loaded purpose, clear guidelines, caps, and an example. Every sentence adds value, no 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?

Given no output schema, the description explains return value ('result' field) and provides context about environment, caps, and example. It is complete for understanding the tool's behavior and constraints.

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 covers all 3 parameters with descriptions. The description adds context beyond schema: code snippet environment and return behavior, timeout range, and an example. However, the example is redundant with the param description for 'code'.

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 executes arbitrary JS in an isolate runtime with specific bindings, distinct from siblings like run_function or execute_sql. It uses a specific verb (Execute) and resource (JS in isolate runtime with bound APIs), leaving no ambiguity about what it 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 explicitly says to use this as a REPL for probing, verifying, testing, and notes that nothing is persisted. It implicitly differentiates from siblings like run_function (deployed functions) and write_file (persistence), and sets clear expectations for when to use it.

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 include destructiveHint: true and openWorldHint: true, which are well-addressed by the description (executing a function). The description adds return structure and example usage, but does not elaborate beyond annotations. No contradiction.

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?

Description is concise: three sections in two paragraphs. Front-loaded with purpose, then returns, then examples, then best-practice callout. Slightly verbose in the last sentence, but still efficient.

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?

Tool is medium complexity with 6 parameters. Without an output schema, the description does well to list the return object. However, it could mention error handling or rate limits, but the examples partially compensate.

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%, so baseline is 3. The description does not add extra parameter-level details beyond examples; the schema already describes each parameter sufficiently.

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 the tool executes a deployed function and returns the real response, with a clear verb ('Execute') and resource ('deployed function'). The sibling tools include 'list_functions' and 'deploy', so 'run_function' is unambiguously distinct.

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?

Explicit guidance: 'Use this to test your API endpoints' and 'Always run_function on your API endpoints after writing them.' No alternatives are needed among siblings; this is the unique tool for testing.

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=true and destructiveHint=false, so the tool's safety is clear. The description adds behavioral details beyond annotations: it explains how results are ranked ('by term frequency across headed sections') and what is returned ('source file, section heading, and a snippet'). This helps the agent understand the search mechanics and result format. No contradictions 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?

The description is extremely concise: two short paragraphs. The first paragraph states purpose and usage guidance. The second paragraph explains behavior. Every sentence adds value. 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?

Given the tool's complexity (simple search with two parameters), the description is complete. Annotations cover safety. The description covers purpose, when to use, ranking behavior, and return format. No output schema exists, but the description explains what is returned (source file, section heading, snippet), which is sufficient for an agent to understand and invoke the 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?

Schema description coverage is 100%, so the baseline is 3. The description does not directly describe parameters, but it adds value by explaining the ranking method and result structure, which helps the agent infer how 'query' will be interpreted. The 'limit' parameter is already described in the schema. The description compensates slightly by providing context on result format, but does not elaborate on parameters beyond what's in 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 ('Search') and resource ('Hatchable's own documentation'), and clearly distinguishes the tool's purpose from sibling tools by explaining what topics it covers (routing, SDK, deploy semantics, etc.). It explicitly contrasts with guessing, making the tool's scope 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 tells when to use the tool: 'Call this instead of guessing when you're unsure how a Hatchable feature works.' This provides clear guidance on when the tool is appropriate and implicitly when not (e.g., for non-Hatchable documentation). No alternative tools named, but the list of sibling tools includes general search (grep, search_projects) and the description positions this as the specific search for platform docs.

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 readOnlyHint=true and destructiveHint=false, so description does not need to restate safety. Description adds value by clarifying the scope (public marketplace) and note about searching own files. No contradictions. A 4 reflects rich contextual addition beyond 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?

Description is concise with two clear sentences, front-loading the main purpose. Could be slightly more compact but no redundant information. Loses a point for not being maximally dense.

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?

Given the simple tool (3 optional parameters, no output schema), description fully covers purpose, scope, and usage boundaries. No additional information needed for an agent to use 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 coverage is 100%, so parameters are well-documented. Description does not add extra meaning to parameters (e.g., format of query, allowed categories). Baseline 3 is appropriate since schema covers all details.

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 clearly states it searches the public Hatchable project directory for other people's projects, contrasting with internal project search using grep. The verb 'search' and resource 'public project directory' are specific and distinct from sibling tools like search_documentation.

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 says when to use (find existing apps to fork) and when not to use (for internal project files, use grep instead). Provides clear context for choosing this tool over 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?

Description discloses key behavior: variables are available in functions, and automatic secret marking based on key naming conventions. This adds context beyond annotations, which only indicate destructiveHint=true and idempotentHint=true. The description explains the destructive aspect (secrets behavior) and idempotency implicitly.

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, efficiently conveying purpose, usage context, and important behavioral detail. No fluff.

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?

Tool is fairly simple (2 params, no output schema). Description adequately explains what the tool does and a key side effect (secret auto-marking). Could mention scope (project-level) and if it overwrites or appends, but schema clearly indicates overwrite (vars object). Lacks mention of no return value (implied).

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%, so description need not repeat. However, description adds no extra detail on parameters beyond schema. A slight bonus for linking to functions usage, but not necessary. Baseline 3 is appropriate; score 4 because description context justifies secret handling which parameter semantics benefit from.

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 clearly states 'Set environment variables for a project', which is a specific verb+resource combination. It distinguishes from sibling tools like list_env (which lists variables) and delete_env (which deletes variables).

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?

Description implies when to use: when you need to set environment variables. It lacks explicit guidance on when not to use or alternatives, but naming convenience (e.g., 'Available in functions via process.env.KEY') helps. No sibling comparison mentioned.

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 indicate destructiveHint=true, which is consistent with account modification. The description adds behavioral context: sending verification code, two-step process, and permanent handle. However, it does not disclose if setup can be undone.

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?

Very concise: three sentences effectively convey purpose, usage steps, and outcome. No unnecessary information.

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?

Given no output schema, description explains what happens (code sent, verification completed, permanent handle set). Could mention that setup is irreversible or session-related details.

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%, and description supplements it by explaining the role of each parameter in the multi-step flow (e.g., omitting code to request a code). The handle validation (3-30 chars, lowercase, starts with letter) is only in schema, but description adds context about completion.

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: associate an email and handle with your account, with a step-by-step process for requesting and verifying a code. It distinguishes from sibling tools as no other tool relates to account setup.

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 outlines a two-step usage pattern: first call with only email, then second call with email, code, and handle. It also states the purpose of the setup (logging in, setting permanent handle). No alternatives needed.

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 indicate destructiveHint=true and idempotentHint=true. The description adds context on plan requirements and auth implications, which are beyond annotations. No contradiction.

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 concise, uses bullet points for readability, and front-loads the purpose. Every line adds value without verbosity.

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?

Given the tool has only 2 parameters and no output schema, the description covers the key behavioral aspects. It could mention that the change is immediate or any side effects, but overall sufficient for agent selection.

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 100% description coverage, with clear descriptions for each parameter. The description adds value by explaining the meaning of each visibility value, going beyond the schema's enum listing.

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 changes a project's visibility and lists the three visibility options with their implications, distinguishing it from sibling tools like create_project or update_project.

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 explains the differences between personal, public, and app visibilities, including requirements like plans and auth. However, it doesn't explicitly state when not to use this tool or provide 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?

Disclosures beyond annotations: mentions that only passed fields are touched (partial update behavior) and that slug and tier are immutable. Annotations already indicate destructiveHint=true (mutation) and idempotentHint=true, which aligns with the 'only fields you pass are touched' behavior. No contradictions.

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, efficient and front-loaded with the verb 'Update' and resource 'project metadata'. Every clause adds value: what can be updated, partial update behavior, which tool to use for visibility, and immutability of slug/tier. Could be slightly more concise but well-structured.

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?

Given 5 parameters (all described in schema), annotations providing mutation and idempotency info, and no output schema, the description covers purpose, partial update behavior, and boundaries (visibility via set_visibility, immutable slug/tier). Missing details like required permissions or error conditions, but acceptable for a metadata update 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?

Schema coverage is 100% with descriptions for each parameter. The description adds value by summarizing which fields can be updated (name, tagline, description, category) but doesn't add additional constraints like limits (max chars) already in schema, so 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?

Clearly states it updates project metadata and enumerates specific fields (name, tagline, description, category). Distinguishes from sibling tool set_visibility by noting that visibility changes should use that tool instead. Also mentions immutability of slug and tier, adding further specificity.

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 states when to use this tool (for updating metadata fields) and when not to use it (for visibility changes, use set_visibility; slug and tier are immutable). This provides clear guidance and directs the agent to alternative tools, making the decision straightforward.

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 indicate destructiveHint=true (file creation/modification) and idempotentHint=true (safe retries). The description adds details: chunk TTL (10 min), max chunk size (64 KB), max assembly (20 MB), and overwrite safety, which go beyond 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?

Description is concise with three sentences: first states purpose, second details flow, third adds constraints. Every sentence is necessary and 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?

Given no output schema, the description answers key questions: how to start, continue, finish, constraints (size, TTL), and retry safety. For a complex multipart tool, this 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?

Schema coverage is 100% with clear descriptions. The description adds nuance: upload_id omitted for chunk 0, chunk_index 0-based, and final=true role. However, the description does not add significant meaning beyond the schema for most parameters.

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: multipart file upload for large content exceeding token caps. It distinguishes from siblings like write_file and patch_file by specifying the multipart flow and chunk commitment mechanism.

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 step-by-step flow: first call without upload_id, subsequent calls with it, and final=true to commit. It also mentions retry safety and TTL, guiding when to use this tool instead of 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=true and destructiveHint=false, so the description adds value by detailing the log entry fields (status_code, duration_ms, etc.) and derived `level` field. It does not mention pagination or sorting behavior, which could be useful, but overall it provides sufficient behavioral context beyond 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?

The description is well-structured with clear sections: a statement of what is returned, a list of filtering capabilities, and a usage example. It is concise (3 sentences) but front-loads key information. Minor improvement could be to break into bullet points for even easier scanning.

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?

Given the tool's complexity (11 parameters, no output schema), the description covers the main aspects: what logs contain, how to filter, and a practical usage example. It lacks details on default sort order and potential performance implications, but is largely complete for a debugging 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?

Schema coverage is 100%, so baseline is 3. The description adds significant meaning by explaining the derived `level` field and providing examples of wildcards for status_code ('4xx', '5xx') and relative time formats ('1h', '30m', '7d'). It also describes full-text search across log_output and error, enriching the 'query' parameter semantics.

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 the specific verb 'View' and the resource 'function execution logs', accurately reflecting the tool's purpose. It clearly distinguishes from sibling tools by focusing on log viewing, while siblings like 'run_function', 'get_deployment', and 'read_file' serve different purposes. The detailed filtering options further clarify 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 provides explicit guidance on when to use the tool, including a concrete example: 'Use this to debug production issues: e.g. level='error' + since='1h''. It also implicitly excludes other tools by describing rich filtering, which is unique among siblings.

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 destructiveHint=true and idempotentHint=true. Description adds key context: files are stored but not live until 'deploy' is called, and overwrites existing files. No contradiction.

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?

Description is compact, front-loaded with purpose, and uses bullet points for valid locations. Could be slightly more concise by removing the 'each file is one endpoint' note in api/ line, as that's implementation detail.

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?

Given no output schema, description covers input constraints (valid paths, relative root) and post-write behavior (deploy needed). Could mention character encoding or max file size, but not necessary for typical use.

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%; the description re-iterates valid paths but does not add new meaning beyond the schema's 'description' fields for parameters. 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 starts with a clear verb-resource pair: 'Write or overwrite a project file'. It specifies scope ('relative to project root') and lists valid locations, distinguishing it from tools like patch_file (partially modify) or upload_file (likely binary).

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 lists valid directories and file types, informing when to use this tool. However, no explicit when-not-to-use or alternatives mentioned among 30+ sibling tools.

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?

Discloses atomicity (if any path invalid, none written) which adds value beyond annotations. The destructiveHint is true, and the description confirms it modifies files, consistent 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?

Two short paragraphs, no fluff, front-loaded with key purpose. Every sentence adds value.

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?

Covers purpose, usage, and key behavior. Could optionally mention the number of files limit, but not necessary.

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%, so baseline is 3. Description adds context about atomicity and the files array structure, but does not add new meaning beyond 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?

Clearly states the tool writes multiple project files in a single call, distinguishing itself from the sibling 'write_file' tool by highlighting batching and atomicity.

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 states it is for scaffolding or updating multiple files at once, implicitly suggesting use over 'write_file' when batching is beneficial, but does not specify when not to use it.

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