hatchable-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes (e.g., write_file vs patch_file, deploy vs dry_run_deploy, list_files vs grep). A few could be confused by an agent, such as run_code vs run_function (one simulates, one runs deployed) or get_project vs get_schema (both provide project details), but descriptions help differentiate them.
Naming Consistency4/5
Tools predominantly follow a verb_noun pattern (e.g., create_project, delete_file, list_projects), with some using underscore for multi-word names (search_documentation, dry_run_deploy). The naming is mostly consistent, though a few tools like get_deployment and get_schema use a slightly different pattern (get_* vs *_project/schema). Overall, readable and predictable.
Tool Count3/5
With 33 tools, the count is on the higher side for a single server, but given the comprehensive platform features (project management, file operations, deployments, database, auth, cron, logs), each tool serves a unique purpose. Some overlap exists (e.g., write_file/write_files/upload_file for different file sizes), but this is justified. The count is borderline for coherence but not excessive.
Completeness4/5
The tool set covers the full lifecycle of a Hatchable project: creation, file management, SQL execution, deployment, logging, environment variables, and project forking. Minor gaps include no explicit tool for deleting a project (aside from delete_file which only deletes individual files), and no rollback tool for deployments. However, the core workflows are well-supported and agents can work around missing operations.
Average 4.2/5 across 33 of 33 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds that it returns paths, sizes, and hashes, but does not disclose pagination, performance implications for large projects, or whether it returns only top-level or recursive contents. Without output schema, more detail on return format would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single clear sentence with no fluff. It front-loads the action and specifies output fields. Could be slightly more efficient by removing 'their' but still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema), the description is adequate but missing details on recursion depth or pagination. Siblings like delete_file or patch_file have no additional context needed, but for a list operation, knowing default sorting or limits would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one required parameter with description). The description adds no additional info about the project_id parameter beyond what the schema provides. Baseline 3 is appropriate when schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('list') and resource ('files in a project'), clearly distinguishing it from siblings like list_projects, list_env, or list_deployments. It also specifies the data returned (paths, sizes, hashes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. For example, there's no mention of filters (like by path) or when to use grep or read_file instead. The context of listing all files in a project is implied but not explicitly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, which align with a read-only schema retrieval. The description adds that it returns schema with columns and types, but does not mention any limitations (e.g., size of result, access restrictions, or whether it includes views or foreign keys). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the core purpose. It efficiently covers what the tool returns without extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema), the description is complete enough: it explains the return value (tables, columns, types, indexes). With no output schema, this provides necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, describing the project_id parameter with an example. The description does not add additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns the database schema (tables, columns with types, and indexes) for a project's PostgreSQL database. It is distinct from sibling tools, which mostly deal with project management, file operations, or execution tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent needs to understand the database structure, but it does not explicitly say when to use this tool versus alternatives like execute_sql or list_functions. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates safe read-only behavior. The description adds value by listing the specific fields (visibility, tier, role, version) returned, but does not disclose additional behavioral traits like pagination, sorting, or rate limits. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the purpose and output fields. It is front-loaded with the action and resource. However, it could be slightly more concise by omitting 'with their' and using a colon.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and is a simple list operation, the description adequately covers the basic functionality. However, it does not mention whether filtering or sorting is possible, or how many projects are returned. The presence of a sibling 'search_projects' suggests additional context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100% (0 params). The description clarifies what the tool returns but parameter details are not applicable. Baseline 4 is appropriate since description adds context about the output beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists projects the user owns or collaborates on, specifying attributes like visibility, tier, role, and current version. It distinguishes itself from the sibling tool 'search_projects' by indicating it shows all projects without filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a broad overview of all projects, but does not explicitly state when to use this tool versus the sibling 'search_projects' (which likely supports filtering) or 'get_project' (for a single project). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description's statement 'execute and return real response' aligns. The description adds return fields (status, headers, body, logs, error, duration_ms) and mentions 'real response' implying it actually runs the function, which is consistent with destructive hint. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with examples and an important usage note. Front-loads purpose and return structure. Could be slightly more concise but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, nested objects) and no output schema, the description adequately explains return structure and provides examples. It covers the essential information for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all parameters. Description adds examples and clarifies that body is for POST/PUT, but schema already covers that. Parameter descriptions are clear, so additional value is modest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute a deployed function and return the real response' and provides examples showing usage for testing API endpoints, which is specific and distinguishes from siblings like 'run_code' or 'execute_sql'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Always run_function on your API endpoints after writing them' and instructs to inspect response body to match frontend, which provides clear context for when to use this tool, though it doesn't explicitly mention 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and idempotentHint=true. Description adds the key behavioral trait that deletion takes effect only after the next deploy, which is not obvious from annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences without any waste. Every sentence adds value: first states action, second clarifies when effect occurs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters with full schema coverage, no output schema, and clear annotations, the description is sufficiently complete. The deploy timing is the critical missing piece that is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters have descriptions in the schema). Description does not add meaning 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb ('Delete') and resource ('project file'). The phrase 'Takes effect after the next deploy' adds important context. However, it does not differentiate from siblings like patch_file or write_file, though those likely have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage (when you need to delete a file) but does not provide explicit guidance on when not to use it, prerequisites, or alternatives (e.g., if you want to just remove content, write_file might be more appropriate).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is clear. The description adds value by specifying exactly what data is returned (schema, functions, etc.), which annotations don't cover. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists what information is retrieved. No filler words. It is front-loaded with the core action 'Get project details'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, high schema coverage, and no output schema, the description sufficiently covers what the tool returns. However, it could mention that the output may include multiple entities (e.g., functions, schema) and confirm it returns the entire project object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already defines the parameter well. The description adds no extra meaning beyond the parameter's description, warranting a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves project details and lists specific resources: slug, visibility, status, deployed functions, and database schema. It distinguishes itself from siblings like 'list_projects' (which lists all projects) by focusing on a single project's detailed info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need detailed project info, but does not explicitly state when not to use it or mention alternatives. Since 'list_projects' exists for listing, using 'get_project' for listing would be inefficient. No guidance on prerequisites like project_id validity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and idempotentHint=true. The description adds atomic behavior: 'if any path is invalid, none are written'. This is valuable beyond annotations, though doesn't detail what happens on partial success scenarios. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each essential: purpose, use case, structure, atomicity. No fluff, well structured, and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 params, no output schema, and good annotations, the description covers atomicity and use case. Might lack detail on error handling or return value, but for this complexity it's sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description doesn't need much. It mentions 'path and content' per entry but adds no extra semantics beyond the schema's descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool writes multiple files in a single call, distinguishing itself from write_file by mentioning batching and use case (scaffolding, updating several files). Could be slightly more specific about 'project files' but still effective.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'faster for scaffolding a new project or updating several files at once', implying batch writing. Mentions atomicity condition but doesn't compare to alternatives like patch_file or delete_file, though sibling list includes write_file which is directly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive (destructiveHint: true), and the description adds that DDL operations are supported and return format details. It also notes that DECIMAL columns return as strings, which is valuable behavioral insight 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for supported operations, parameter usage, and return formats. It is concise but informative, though the return format section could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple SQL operations, return formats) and the absence of an output schema, the description adequately explains the behavior. It could mention error handling or transaction behavior, but it covers the core functionality well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so the description adds no parameter-level detail beyond what the schema provides. The description does explain how to use the params array with placeholders, which is helpful but does not substantially exceed the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs SQL against a dedicated PostgreSQL database. It lists supported SQL operations (CREATE TABLE, SELECT, etc.), making the purpose highly specific and distinguishing it from sibling tools like run_code 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on using parameterized queries for safety, which is a key usage guideline. However, it does not explicitly state when to use this tool versus alternatives like run_code or get_schema, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=false and idempotentHint=false. The description adds that it copies code and schema but no data, and creates a personal project. However, it does not mention any side effects or limits (e.g., fork count, public requirement beyond 'public project').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a usage tip, all relevant and front-loaded. No wasted words, but marginally more verbose than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 params, no output schema) and good annotations, the description covers the key points: what is copied, what is not, and the recommended use case. It could mention if the fork retains visibility settings or that only public projects can be forked, but overall complete for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the two parameters are already documented. The description adds no additional meaning beyond what the schema provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'fork' and resource 'public project', and distinguishes it by specifying what is copied (code and schema) and what is not (data). It also clarifies the result: a personal project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'This is the recommended way to start from an existing app', providing clear guidance on when to use this tool over alternatives like create_project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true and idempotentHint=true. The description adds auto-secret-marking behavior for keys containing specific substrings. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then behavior. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema and annotations, the description is sufficient. Missing details about possible side effects (overwriting existing variables) or access patterns (bulk set). Output schema is absent but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% but parameters are simple: project_id and vars (key-value pairs). The description adds minimal additional semantics beyond the schema; it explains how vars are accessed (process.env.KEY) and secret auto-marking, but this is more behavioral than parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Set environment variables for a project') and the resource ('environment variables for a project'). It distinguishes from siblings like list_env (listing) and delete_env (deletion).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that variables are accessible via process.env.KEY and that certain keys are auto-marked as secrets. However, it does not explicitly state when to use this vs. other tools like delete_env or set_visibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to reiterate safety. It adds context such as the derived level field and log structure, which is helpful but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but front-loaded with the tool's purpose. Every sentence adds value, though it could be slightly more concise by avoiding full sentence repetition of parameter details already in schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters) and absence of output schema, the description provides enough context for filtering and common use cases. However, it lacks information about pagination beyond limit, and no details about the return format or ordering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds meaning beyond the schema by explaining the derived field, wildcard support in status_code, and relative times. This enriches parameter understanding beyond bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it views function execution logs with rich filtering, explicitly listing available fields (status_code, duration_ms, log_output, error, level). It distinguishes itself from sibling tools like run_function by focusing on log viewing, not execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage examples (e.g., debugging with `level='error'` + `since='1h'`), but does not specify when NOT to use this tool or mention alternatives among siblings. It could be more direct about exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. Description adds detail on what actions happen (migrations, seed, CDN, endpoints, version increment) and clarifies the 'url' field's behavior for personal projects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each adding essential information. Front-loaded with core actions, then usage guidance, then return value clarification. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deploy tool with one parameter and no output schema, the description covers the deployment process, usage timing, and public URL behavior. It assumes some context about migrations/seed but is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'project_id' with its description. The tool description adds no further parameter semantics 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Deploy' and specific actions like running migrations, seed.sql, copying files, and incrementing version. It distinguishes from sibling tools like 'dry_run_deploy' and 'run_function'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 contrasts with 'run_function' for verification. Provides guidance on when to use the tool vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's job is lighter. The description adds that it returns details from 'when that version shipped' and includes specific data types (paths, hashes, sizes), but doesn't mention pagination, rate limits, or permissions beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each essential: first explains purpose and return value, second gives usage guidance. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 simple parameters, full schema coverage, and annotations providing safety hints, the description is nearly complete. It lacks only an explicit mention of auth requirements or error scenarios, but those are implied by the readOnlyHint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters (project_id and version). The description adds no extra semantic detail beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a 'detail view of one deployment by version number' and specifies it returns 'the full file manifest (paths, hashes, sizes) and function list'. This clearly distinguishes it from list_deployments, a sibling tool for listing all deployments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to 'use it with list_deployments to audit or compare what changed between versions', providing a clear usage pattern and when-not-to-use (i.e., for listing, use list_deployments).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false, which the description aligns with. The description goes beyond annotations by explicitly stating that values are never exposed, adding important safety context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words. Each sentence adds value: first sentence states purpose and return data, second clarifies what is not returned, third gives usage guidance. Well-structured and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (1 parameter, no output schema), the description is complete enough. It covers purpose, return data, and guidance on actual value retrieval. No output schema means the description must cover return values, which it does sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaning beyond the input schema, but schema coverage is 100% so the baseline is 3. The schema already describes the project_id parameter, and the description focuses on tool behavior rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list env var keys) and resource (project) and explains what is returned (key names and is_secret flag). It distinguishes itself from other env-related tools like set_env and delete_env by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to use process.env.KEY inside a deployed function to read actual values, providing clear guidance on when to use this tool vs alternatives. However, it does not explicitly state when not to use it or mention siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds value by explaining offset/limit behavior and cross-reference to patch_file. Does not disclose rate limits or file size limits, but adequate for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear paragraphs: first defining purpose, second explaining advanced usage. Front-loaded, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description explains that line-numbered content is returned when offset/limit are used. However, it doesn't confirm the return format for full file reads. Still complete enough for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already fully describes parameters (100% coverage). Description adds meaning about offset/limit being 1-indexed and omitting them meaning read from start/to end, but this is already inferable from schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes reading file content, specifying project_id and path, which is clear. However, with siblings like list_files and grep, it doesn't explicitly distinguish its purpose from them (e.g., single-file full content vs. listing or searching).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use offset/limit (to avoid large files blowing context), and mentions that line-numbered output aids subsequent patch_file calls. This provides clear context-aware guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read behavior is known. The description adds that results are ranked 'by term frequency across headed sections' and returns 'source file, section heading, and a snippet', which goes beyond annotations. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first sentence defines purpose and usage context, second explains ranking and output. No redundancy or filler. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage guidelines, ranking method, and return structure. With simple parameters and no output schema, the description is nearly complete. It lacks explicit mention of error behavior or authentication, but these are less critical for a read-only search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters ('Search terms' and 'Max results'). The description does not add new parameter-level details beyond the schema, but the ranking and return format context (part of description) indirectly informs parameter usage. Given high schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches 'Hatchable's own documentation' for 'platform behavior', listing specific topics (routing, SDK surface, deploy semantics, etc.). It distinguishes itself from sibling tools like 'search_projects' by specifying the source (Hatchable docs vs project files) and provides a use case (call when unsure how a feature works).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this instead of guessing when you're unsure how a Hatchable feature works', providing clear guidance on when to use the tool. It implies not to use it for searching project code (which would be 'search_projects' or 'grep'), but does not explicitly list alternatives or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true. Description adds context about plan requirements and auth implications. However, it doesn't disclose side effects like potential service disruption or permission requirements beyond plan.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-line bulleted format is highly concise. Every sentence adds new information: first sentence states purpose, subsequent bullets detail each option. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has clear schema and annotations, the description is nearly complete. It covers visibility options and their constraints. Missing mention of return value (likely success/failure) but acceptable since no output schema and it's a setter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds value by explaining the real-world meaning of each visibility option (login-gated, public web, etc.) beyond enum values, which is helpful but baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool changes a project's visibility, with specific verb 'change' and resource 'project's visibility'. It distinguishes from siblings like update_project, which likely adjusts other project attributes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance by detailing each visibility option's constraints (plans, auth needs). It implies when not to use (e.g., if project lacks required plan, this will fail), which helps agent avoid errors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint: true, but the description adds context: it generates a URL slug, creates a database, and should be called first. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely long (detailed docs for project structure, routing, etc.) which goes beyond the function's scope. While the first sentence is clear, much content belongs elsewhere, making it less concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the platform and the tool's role as an initial setup, the description provides extensive context about what happens after creation (routing, static files, SDK, auth, deploy), ensuring the agent understands the full workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context about the visibility enum (personal default) and mentions the 'name' generates a slug. It adds meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new Hatchable project, generates a URL slug, creates a PostgreSQL database, and returns project ID and URLs. It explicitly says to call this first before writing files, distinguishing it from other setup actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Call this first before writing files or creating tables,' providing clear ordering. However, it does not mention alternatives or when not to use it, given siblings like update_project or fork_project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, implying account modification. The description doesn't contradict annotations. It adds transparency by explaining that the tool sends a verification code, requires a two-step process, and sets a permanent handle. Could be slightly improved by noting that handle becomes permanent and cannot be changed via this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 3 sentences, but could be more succinct. The step-by-step list is clear, but the last sentence could be merged with the step description. No wasted words, but could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2-step process, 3 params), the description covers the essential workflow and outcomes. There's no output schema, but the description explains what happens (login enabled, handle set). Could be more complete by noting that handle must be unique, but the schema constraint (3-30 chars, lowercase) covers some of that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter is described in the schema. The description adds value by clarifying the role of 'code' (omit to request a code) and the handle purpose, but doesn't add significant new semantic meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: associating an email and handle with an account. It outlines a two-step process (request code, then verify) and explains the result (login enabled, permanent @handle set). This differentiates it from sibling tools like create_project or deploy which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit step-by-step usage instructions: first call with just email to get a verification code, then call with email+code+handle to complete setup. It also mentions the outcome (login to console, sets permanent handle), guiding the AI on when to use this tool. No exclusions are needed as it's a one-time setup process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description complements the destructiveHint annotation by explaining that files are overwritten (not appended) and stored awaiting deployment. While the annotation already indicates destructive behavior, the description adds context about the deployment dependency and valid path constraints. However, it could be more transparent about whether previous versions are kept or overwritten entirely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear first sentence that states the purpose, followed by a structured list of valid locations. The final note about deployment is efficient. Minor inefficiency: the bullet list could be more concise, but it's still well-organized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no output schema and only moderate complexity, the description adequately explains what the tool does, where files can be written, and the deployment dependency. It misses details about file size limits, encoding, or what happens on success/failure, but these are covered by the schema's implicit completeness. Overall, it provides enough context for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions, so the schema description coverage is 100%. The description adds meaning by explaining path conventions (relative to project root) and valid path structures, but it does not detail the content parameter beyond 'File content'. With full schema coverage, a baseline of 3 is appropriate, and the description does not significantly augment parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb ('Write or overwrite') and resource ('project file'), immediately establishing the tool's action and target. It distinguishes itself from siblings like 'patch_file' by indicating it overwrites, and from 'upload_file' and 'import_file_from_url' which handle external files. The detailed path breakdown effectively scopes the tool to specific project directories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists valid locations and file types, providing clear guidance on where files can be written. It also states that files are stored but not live until 'deploy' is called, which is a crucial usage hint. This differentiates it from deployment-related tools and sets expectations about the lifecycle, which is excellent guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the tool is safe and non-destructive. The description adds transparency by specifying that it returns a 7-day run count, error count, and timestamp, clarifying the scope and freshness of the data. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first clearly states the action and output, the second provides a practical use case. Every word serves a purpose; there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no nested objects, no output schema) and rich annotations, the description is largely complete. It explains what data is returned and why to use it. However, it does not mention any pagination or limits (e.g., if there are many cron jobs), but this is a minor gap for a list tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with one required parameter (project_id). The description does not reiterate the parameter, but the schema already fully documents it. The description adds value by explaining the output fields, which compensates for the lack of parameter elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description combines a specific verb ('list') with a clear resource ('every scheduled cron function') and details the exact data returned (expression, run count, error count, last_run_at). It distinguishes from siblings like list_functions or view_logs by focusing on cron jobs and their execution statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers a concrete use case: 'Use this to verify a cron job is actually firing without tailing logs manually.' While it does not explicitly state when not to use this tool or list alternatives, the context of sibling tools suggests it is specialized for cron monitoring, and the description implies it is preferable to manual log inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 limited additional behavioral info. It does mention the sorting (reverse-chronological) which is helpful and not obvious from schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs. First sentence clearly states the core function. Second sentence gives usage examples. No filler or redundant explanations. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by listing the fields included. It's complete for the tool's purpose, though could mention pagination or default limit details, but the schema covers limit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are well-documented in the schema (project_id, limit). The description doesn't add new parameter-level details beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists deployments, specifies the ordering (reverse-chronological) and the fields included (version, status, deployed_at, description, summary counts). Distinguishes itself from siblings like get_deployment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states three use cases: understanding deploy history, identifying a known-good version for rollback, and debugging regressions by comparing versions. No need for exclusion criteria as it's a read-only list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds critical behavioral detail: uploads expire 10 minutes after last chunk. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words, front-loaded with purpose and actionable instructions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple schema (1 param, no output schema), description covers purpose, usage, and key behavior (expiry). Missing output format description is minimal gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with description for project_id. Description adds no further parameter semantics beyond schema, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool shows staged multipart uploads, uses specific verb 'Show', and distinguishes from siblings like upload_file by focusing on pending/resume use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to recover from a disconnect — find the upload_id and resume from the next chunk_index', giving clear when-to-use and how-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. Description adds context that it searches public marketplace and is for finding apps to fork, which aligns with annotations. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs: first states purpose and use case, second contrasts with sibling. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 100% schema param coverage, description sufficiently covers scope and usage. Could add note about category values, but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions. Description does not add param details beyond schema, which is acceptable. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb+resource: 'Search the public Hatchable project directory'. Clearly distinguishes from siblings like 'grep' (search own files) and 'list_projects' (lists own projects).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool (find existing apps to fork) and when not to (use 'grep' for own files), naming the alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly indicates a destructive operation (destructiveHint=true) and confirms the tool is idempotent. It adds behavioral details not in annotations: only passed fields are modified, and slug/tier are immutable. However, it does not mention any specific side effects or error conditions, and the return value is not described. With annotations already covering safety (destructive, idempotent), the description adds useful but not exhaustive context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words. The first sentence states the primary function and lists fields. The second clarifies partial updates and references sibling tools. Information is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (5 parameters, all simple strings, with no output schema) and the presence of sibling tools with similar names, the description is sufficiently complete. It covers what the tool does, when to use it, and what it cannot do. The only minor gap is that it doesn't mention the return value or potential error scenarios, but the annotations (destructiveHint, idempotentHint) mitigate the need for deeper behavioral description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a description in the schema. The description reinforces which fields are updatable but does not add new semantics beyond what the schema provides (e.g., no examples, constraints, or formatting rules). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Update project metadata' which clearly identifies the verb (update) and the resource (project metadata). It explicitly lists the fields that can be updated (name, tagline, description, category), distinguishing it from sibling tools like set_visibility. The scope is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 and when not to: 'For visibility changes use set_visibility; slug and tier are immutable.' It also clarifies that 'only the fields you pass are touched,' which helps the agent understand partial update behavior. This clearly differentiates from sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, confirming no side effects. Description adds rich behavioral details: returns specific error/warning categories, lists concrete checks (package.json, reserved table names, auth routes, usage caps), and specifically warns about async footguns (missing await on auth calls). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with purpose and return values, then logically grouped error and warning categories. Every sentence adds unique value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter, full annotations (readOnlyHint, destructiveHint), and no output schema, the description is complete. It explains what the tool does, what it returns, and specific checks performed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with only one required parameter ('project_id'). The description does not add additional semantics beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool runs deploy-time validators without deploying, lists return values (errors, warnings, would_deploy), and distinguishes itself from sibling 'deploy' by explicitly noting it does not actually deploy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly suggests use before deploying to catch issues, but no explicit when-not-to-use or comparison to other validation tools. The context of avoiding 'deploy blindly' provides good usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds key behavioral details beyond annotations: mentions idempotency, skipped keys (no error), and that it takes effect on next deploy. Annotations already mark destructiveHint and idempotentHint; description enriches with 'skipped' behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: operation description, usage modes, behavioral nuance. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Coverage is high given annotations and schema. The description clarifies the behavior for missing keys and the effect timing. Minor gap: could mention if the tool requires specific permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so parameters are documented. Description adds meaning by explaining the relationship between `key` and `keys`, and the side-effect of 'skipped'. Could mention that `key` and `keys` are mutually exclusive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Delete), resource (environment variables), and specifies the two modes (single via `key`, batch via `keys`). It distinguishes from sibling tools 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains that missing keys are reported in `skipped` without error, making the tool idempotent. Does not explicitly mention when not to use, but the context is clear for a delete operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's addition of the data scope (24-hour counts, cron schedule) and its cost comparison to read_file add valuable behavioral context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences with no fluff. The first sentence states what it lists; the second provides usage scenarios. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, read-only), the description is sufficient. It explains what data is returned and when to use it, but could optionally mention if there are pagination limits or if the counts are real-time. However, the annotations and schema cover the basics, making this complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter (project_id) with a clear description. The description adds no additional semantics for the parameter, but given full schema coverage, the baseline is 3; the description adds extra usage guidance that elevates it to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact verb 'list' and resource 'deployed API functions', detailing the fields returned (route, method, runtime tier, cron schedule, invocation/error counts), and explicitly distinguishes it from siblings like list_files 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.
Usage Guidelines5/5
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: 'after a fork, after picking up an unfamiliar project, or to verify a deploy registered the endpoints you expected.' It also suggests alternatives (read_file) with a cost comparison, making the usage context very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, and description confirms mutation. Adds detail on first-occurrence behavior and exact match requirement, but no info on rollback or preview.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences front-loading key information without fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description covers usage and constraints well. Minor gap: doesn't mention if change is applied immediately or previewable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 'first occurrence' behavior for old_string and insertion strategy using old_string+new_string, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it applies a targeted edit by replacing text, distinguishes from write_file which rewrites entire files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends use over write_file for large files, warns about exact match requirement and error behavior, and provides insertion strategy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by disclosing key behavioral traits: the default head_limit mechanism, the ability to narrow results with glob, the Postgres regex syntax and associated limitations (2s timeout for catastrophic patterns), and the three output modes. Annotations only indicate readOnly and non-destructive, but the description adds crucial details for effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (four short paragraphs) and front-loaded with the core purpose. The bullet list of output modes is clear. Every sentence adds value; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, multiple output modes) and the lack of an output schema, the description is complete. It covers all essential behavioral aspects, usage guidelines, and error conditions. The sibling context is well-handled by distinguishing grep from other search tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 100% and each parameter is described, the description adds significant value by explaining the default head_limit, how glob interacts with the search, and the formatting of output modes. However, a 4 is appropriate because the description doesn't add new parameter-level details beyond the schema for some parameters (e.g., '-i' and '-n' are already clear from their descriptions).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb ('search'), the resource ('project files'), and the method ('regex content search'). It distinguishes itself from siblings like 'read_file' and 'search_documentation' by focusing on regex-based content search with multiple output modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-not-to-use guidance: it warns about the default head_limit of 250 to prevent context blowups, suggests using glob to narrow by path, and advises simplifying patterns if they cause errors. This helps agents decide when to use grep vs other tools like search_documentation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true (creates a file) and idempotentHint=true (safe to retry). Description adds important behavioral details: server-side fetch, 10 MB cap, 10s timeout, private/loopback rejection, path restrictions. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs: first explains purpose and benefit, second lists constraints. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description still feels complete: it explains the behavior, constraints, and allowed paths. Parameter count (3) is low and well-covered. No need for additional return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% but descriptions are brief ('Full http(s) URL to fetch', 'Destination path in the project'). Description adds path restrictions and URL format hints, but could add more about URL validation and path relative to what.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Fetch a remote URL and save the response body as a project file', with a specific verb ('import') and resource ('file from URL'). Distinguishes from sibling tools like upload_file (local file) and write_file (direct content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes it is 'server-side, so the bytes never pass through your context window', which is a key differentiator. Also lists constraints (10 MB, 10s timeout, rejected private addresses) and allowed paths. This helps the agent decide when to use this vs other file creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint true), description adds: snippet runs once and disappears, environment bindings, timeout caps (5s default, 30s max), 256KB source limit, return value becomes result field. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences plus a code example. Every sentence adds value: first sentence defines tool, second guides usage, third lists constraints. Example demonstrates return pattern. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a REPL tool: purpose, bindings, safeguards, example. No output schema needed since return value is described as result field. All critical info present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 value by explaining that code must use `return` to produce result, and that timeout_ms has a max of 30000. However, no additional meaning beyond what schema provides for project_id or code besides the return convention.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it executes arbitrary JS in an isolate runtime with specific bindings (db, auth, etc.), distinguishes from siblings like run_function (which runs deployed functions) and execute_sql (which runs SQL only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use as a REPL: probe database, verify computation, test API shape. Notes nothing is persisted. Implicitly contrasts with run_function (deployed) and write_file (persisted).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent, but description adds rich context: staging in Redis with 10-min TTL, chunk overwrite safety, final concatenation semantics. No annotation contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then concise flow explanation, then constraints. Every sentence adds distinct information with zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete: covers purpose, multi-call protocol, state management (Redis TTL), failure handling, size limits. With 6 params, 100% schema coverage, clear sibling differentiation, no output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so descriptions already explain each parameter. The tool description adds value by clarifying the chunk_index and upload_id usage pattern (first vs subsequent calls). Could briefly note that path is relative to project root, but schema already clarifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it uploads files exceeding a single model's output token cap, explicitly mentioning common use cases (big SPA bundles, large seed data, inline vendor libs). Clearly distinguishes from write_file or other upload tools by specifying multipart chunked upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes exact workflow: first call without upload_id, subsequent calls with upload_id, final call with final=true. Provides error handling guidance (chunk overwrite safe to retry) and mentions TTL constraints. Implicitly distinguishes from write_file (inline limit) and import_file_from_url (single request).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![hatchable-mcp MCP server](https://glama.ai/mcp/servers/Woobox/hatchable-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Woobox/hatchable-mcp)

Score Badge

Copy to your README.md:

[![hatchable-mcp MCP server](https://glama.ai/mcp/servers/Woobox/hatchable-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Woobox/hatchable-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Woobox/hatchable-mcp'

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