Supabase

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

Annotations show idempotentHint=true and readOnlyHint=false, but the description adds practical details: browser login flow, token permanence (non-expiring vs session-only), and behavior with no args. This exceeds annotation coverage and no contradiction is present.

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

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

Two sentences deliver the essential information without filler, but the structure is a bit run-on. It could be improved with bullets for the two modes, but it remains concise and front-loaded with the core purpose.

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

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

The description covers usage modes and token handling adequately, but it does not explicitly describe the return value or error scenarios. Since there is no output schema, the description should mention what the tool returns (e.g., a link or success message), which is a minor gap.

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

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

The schema has one optional token parameter with no description and 0% coverage. The description fully explains the parameter: passing a JWT enables session login, while omitting it returns a link. This completely compensates for the schema gap.

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

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

The description clearly states the tool's purpose: authenticating MCP.AI for IDE agents by logging in and obtaining an access token. It uses a specific verb ('log in') and resource ('access token'), and it distinguishes from sibling tools by focusing on auth, not on other supabase operations.

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

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

The description explains two usage modes: permanent via config header and session-only via token argument, and notes the no-arg case for getting a link. It gives clear context on when to use each approach, though it does not explicitly mention when not to use the tool or alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds value by explaining the conditional behavior (when all providers connected vs. missing credentials) and what the return values mean (authenticated:true, empty pending[], connect_url). This goes beyond the annotations.

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

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

The description is two sentences, front-loaded with the core purpose, and every sentence adds value. It efficiently covers the main behavior and the conditional case without redundancy.

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

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

Given the tool's simplicity (no params, no output schema), the description is complete enough. It explains the two main states (all connected vs. missing credentials) and what the response contains. It could mention the format of per-install URLs, but that's a minor gap.

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

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

The tool has zero parameters, and schema coverage is 100% (vacuously). The description explains the output semantics, which is the main value since there are no parameters to document. The baseline for 0 params is 4, and the description adds meaningful context about the return values.

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

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

The description clearly states the tool returns connection status and URLs, with specific details about authenticated state and pending connections. It distinguishes itself from siblings like 'authenticate' by focusing on status/URLs rather than the authentication action itself.

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

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

The description implies usage for checking connection status, but does not explicitly state when to use this tool versus alternatives like 'authenticate' or 'toolkit_info'. It provides context on what the tool returns but lacks explicit when-to-use or when-not-to-use guidance.

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

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

The description discloses substantial behavior beyond the sparse annotations (readOnlyHint=false, openWorldHint=true): it explains that invoke runs tools without installing them, returns a connect link when credentials are needed, returns a checkout link when the wallet is empty, and that all write operations require workspace owner/admin. No contradiction with annotations.

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

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

The description is roughly 430 words in a single running paragraph with no sections or bullets, making it dense to parse. That said, nearly every sentence adds distinct information for a 14-action tool, so it earns its length; it just badly needs structural organization (e.g., separating the marketplace flow from the prompt-library flow).

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

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

Given the tool's high complexity (14 actions, 23 params, no output schema, thin annotations), the description thoroughly covers the flagship search/describe/invoke/install workflow and its auth/billing nuances. But side actions get minimal treatment: subscribe/cancel mechanics, the resume action is never mentioned, list_tools returns are vague, and request_mcp/report_bug flows lack practical details.

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

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

With 0% schema description coverage across 23 parameters, the description must carry the burden, and it does explain the core ones conceptually (action's 14 values, tool_id, mcp_id, arguments, prompt_slug, prompt_vars). However, many parameters are left unexplained — query, limit, immediate, tier_slug, request_name, cancel_reason, cancel_comment, prompt_body, report_context, and several prompt_* fields get no semantic mapping beyond what the schema's names imply.

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

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

The description opens with a crisp resource+verb definition — "The official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them." It names the concrete capabilities (search MCPs, run tools, manage subscriptions, host a prompt library) and clearly differentiates from the sibling supabase_* suite and authenticate/connect tools.

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

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

Exceptional when-to-use guidance. It spells out the core flow (search → describe → invoke), explicitly contrasts invoke vs install ("Use install only to make an MCP PERMANENT... prefer invoke for a single/occasional use"), names alternatives (list_tools, subscribe/cancel, report_bug, request_mcp), and even gives recovery guidance (if empty wallet, user opens link, then you retry).

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

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

Annotations already mark the operation as non-read-only, idempotent, and non-destructive, so the safety profile is known. The description adds that the tool can 'send' feedback and use the conversation array for 'reproduction,' revealing an external or internal transmission aspect. Still, it does not detail side effects, who receives the report, privacy, or rate limits, so it provides only a moderate level of behavioral context.

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

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

The description consists of two concise sentences with no fluff. It front-loads the action ('Report a bug, missing feature, or send feedback') and immediately adds the most important usage detail (include the conversation array). Every sentence earns its place, making this efficient and easy to parse.

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

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

The tool is moderately complex with 3 parameters and no output schema. The description covers the core purpose and highlights the key reproduction ingredient, but it neglects to clarify the required 'message' parameter and the optional 'context' parameter. For a simple bug-report tool, this is workable but leaves obvious semantic gaps.

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

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

Schema description coverage is 0%, so the description is the only source for parameter meaning. It explicitly comments on the conversation parameter but calls it an 'array' while the schema declares it as a string (likely a JSON-encoded array), which is misleading. It also leaves 'message' and 'context' unexplained, so the agent must infer their semantics from names alone. This is insufficient compensation for zero schema descriptions.

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

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

The description clearly names a specific verb and resource: 'Report a bug, missing feature, or send feedback.' Among the sibling tools, which are mostly Supabase management actions, no other tool handles bug reporting or feedback. This function is instantly distinguishable, so purpose clarity is high.

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

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

The description establishes clear usage contexts: bug reports, missing features, and general feedback. It also provides a concrete usage instruction by asking the caller to include the conversation array for reproduction. It does not explicitly list when-not-to-use or alternatives, but given no sibling tool competes with it, this is a minor gap.

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

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

The annotations already indicate read-only, idempotent, and non-destructive behavior. The description is consistent with these, and while it doesn't add extra context about return values or side effects, the annotations cover the key aspects.

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

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

The description is a single, clear sentence with no unnecessary words. It is well-structured and to the point.

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

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

Given no parameters and no output schema, the description fully covers what the tool does. It is complete for its intended purpose.

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

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

The tool has no parameters, so there is nothing to explain. The description does not need to add any parameter semantics.

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

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

The description clearly states the tool's function: showing versions. It is specific and distinguishes it from other tools that perform actions like authentication or database operations.

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

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

While the description does not explicitly mention when to use it versus alternatives, the purpose is self-evident and no parameters are needed. It implies usage for checking versions, which is sufficient for such a simple tool.

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

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

The annotations declare destructiveHint=false, but the description states the tool can execute DDL operations, which often include destructive actions like DROP or ALTER. This contradicts the non-destructive hint. Additionally, the description adds no further behavioral context beyond the warning about hardcoded IDs and bulk support, which are not enough to compensate for the contradiction.

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

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

The description is extremely compact yet packs in purpose, usage guidance, a caution, and bulk-support callout. Every sentence earns its place without redundancy, and the information is front-loaded with the core purpose.

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

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

Despite having no output schema, the description does not explain return values, idempotency, error behavior, or the meaning of required parameters. It also does not mention that migrations may have side effects (destructive or irreversible). For a mutation tool, this leaves significant gaps in understanding the full context.

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

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

Schema description coverage is 0%, and the description only partially explains parameters. It mentions that 'project_ids' enable bulk execution, which adds some meaning, but 'name', 'query', and 'project_id' remain unexplained. Without elaboration, the agent cannot fully understand what values to provide, especially for 'name' and 'query'.

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

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

The description clearly states the tool's function: 'Applies a migration to the database.' It uses a specific verb ('Applies') and resource ('migration'), and also provides context by mentioning 'DDL operations.' However, it does not explicitly differentiate from sibling tools like supabase_execute_sql, which could also execute DDL queries.

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

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

The description gives an explicit when-to-use directive: 'Use this when executing DDL operations.' It also adds a guardrail for data migrations and mentions bulk support. However, it does not explicitly state when to avoid this tool or name alternative tools, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating no side effects. The description adds context by explaining it returns a unique confirmation ID and that it is a prerequisite for creation. It does not contradict annotations and clarifies the interactive nature (asking the user) beyond the structured hints.

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

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

Two sentences, no filler. Front-loaded with the primary action and immediately provides the prerequisite call and output usage. Every sentence adds value.

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

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

The tool is simple, and annotations cover safety. The description covers workflow and return value, but parameter semantics are entirely missing. Since schema coverage is 0%, the description should explain what `amount` and `recurrence` represent. Without that, the tool is only partially usable.

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

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

Schema has no descriptions and coverage is 0%. The description mentions 'cost of creating a new project or branch' which hints at the `type` parameter, but does not explain the meaning of `amount` and `recurrence`. It fails to compensate for the lack of schema documentation, leaving agents uncertain about expected values.

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

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

The description clearly states the tool's purpose: asking the user to confirm cost understanding before creating a project or branch. It is distinct from siblings by referencing the confirmation ID flow and explicitly naming the dependent tools (`create_project`/`create_branch`). The verb 'confirm' and resource 'cost' are specific.

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

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

Explicitly instructs to call `get_cost` first, providing clear sequencing. Also states the output should be passed to `create_project` or `create_branch`, defining when this tool is used in the overall workflow. This differentiates it from alternatives and gives actionable guidance.

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

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

Annotations already indicate it's not read-only, not idempotent, not destructive, so the description adds value by clarifying data migration behavior (does not carry production data) and that it creates a new branch with its own project_ref. However, it could disclose more about side effects like cost implications (given confirm_cost_id) or whether this is reversible, but the core behavioral trait is covered.

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

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

The description is relatively concise with two paragraphs, front-loading the main purpose and key caveat (no production data). It adds bulk support at the end. Every sentence provides useful information, though the bulk mention could be integrated earlier. Slight redundancy: 'The branch will get its own project_id via the resulting project_ref' could be simplified, but overall it's well-structured.

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

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

Given the tool's complexity (5 parameters, no output schema, no parameter descriptions), the description leaves gaps: it doesn't explain what happens after cost confirmation, how to specify the branch name, or what the successful response looks like. It covers the essential steps (apply migrations, get project_ref) but not edge cases or error conditions. Adequate for basic use but not comprehensive.

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

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

Schema coverage is 0%, meaning parameters are only named in the schema without descriptions. The description mentions 'project_ref' but does not link it to the 'project_id' parameter or explain the purpose of 'name' or 'confirm_cost_id' beyond implicit context (cost confirmation). It partially compensates by mentioning bulk support (project_ids, confirm_cost_ids) but leaves ambiguity about required vs optional parameters and their roles.

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

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

The description clearly states the tool creates a development branch on a Supabase project, applying migrations from the main project to a fresh branch database. It differentiates from siblings like supabase_delete_branch and supabase_merge_branch by focusing on creation, but does not explicitly contrast with supabase_create_project. The verb 'creates' and resource 'branch' are specific, though 'development' could be ambiguous.

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

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

The description explains when to use the tool (to create a branch for development) and notes important usage details: production data does not carry overigham and that the branch gets a project_id for subsequent queries/migrations. However, it does not mention when not to use it or alternatives, and bulk support is mentioned but not how to choose between single and bulk parameters.

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

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

The description discloses that the project 'can take a few minutes to initialize' and tells the agent to check status with `get_project`, which is valuable behavioral context beyond the annotations. The annotations only state readOnlyHint=false, which implies mutation, so the description adds timing and fallback information. It doesn't mention cost implications or confirmation details, but the annotations already indicate non-read-only, so this is above baseline.

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

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

The description is concise, with two short paragraphs that are front-loaded. The first sentence states the core purpose, the second provides critical user interaction guidance and status-check instructions, and the third efficiently adds bulk support information. Every sentence adds value, and there is no redundant detail.

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

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

Given the tool's complexity—6 parameters, no output schema, and mutation with long initialization—the description covers key operational aspects: asking the user for organization, initialization delay, and status-check fallback. It also notes bulk parameters. However, it doesn't explain what to do with the `confirm_cost_id` (e.g., need to get cost first), which is a gap given the sibling tool `supabase_get_cost` existschers. Still, it provides a solid foundation for an agent to proceed.

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

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

The schema covers 0% of the parameters in descriptions, but the tool description mentions 'organization_ids' and 'confirm_cost_ids' in the bulk support note, adding meaning to those specific parameters. However, it does not explain 'confirm_cost_id' or 'region' values beyond the enum list, leaving the agent to infer their purpose. With 6 parameters and no schema-level descriptions, the tool description partially compensates but not fully, so a baseline of 3 is fair.

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

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

The description clearly states the tool's purpose: 'Creates a new Supabase project.' It identifies the verb (creates) and resource (Supabase project), and it distinguishes itself from siblings like 'supabase_pause_project' or 'supabase_restore_project' by the action. However, it doesn't explicitly contrast with `supabase_create_branch` or other creation tools, so sibling differentiation is not fully achieved.

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

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

The description gives explicit usage instructions: 'Always ask the user which organization to create the project in,' which provides a required prerequisite for invocation. It also directs the user to use `get_project` to check status after creation, indicating a follow-up action. This clearly guides when to use the tool and what to do next, though it doesn't explicitly say when not to use it, but the alternatives are covered by the follow-up instruction.

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

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

The description states 'Deletes a development branch,' which directly implies a destructive action, but the annotations declare destructiveHint=false. This is a clear contradiction. Additionally, the description provides no context about irreversibility, cascading effects, or required permissions.

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

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

The description is two sentences: one clear main purpose and one focused bulk-support note. Every sentence earns its place, and the key verb appears immediately.

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

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

With only 0% schema coverage, no output schema, and annotations that contradict the described behavior, the description is incomplete. It does not explain success/error behavior, whether branch deletion is reversible, or how branch_ids interacts with the required branch_id parameter.

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

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

Schema description coverage is 0%, so the description must compensate. It does clarify that branch_ids enables batched execution, but it does not explain branch_id semantics or the relationship between the required branch_id and the optional branch_ids field, leaving ambiguity about whether batch mode can omit the singular id.

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

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

The description begins with 'Deletes a development branch,' using a specific verb and resource. This clearly distinguishes it from sibling tools like supabase_create_branch, supabase_merge_branch, and supabase_reset_branch.

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

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

The description implies usage through the word 'Deletes' and adds bulk execution guidance via 'accepts branch_ids for batched execution.' However, it does not explicitly state when to prefer this tool over alternatives or provide exclusions such as 'use supabase_pause_project/restore_project for project-level operations.'

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

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

Annotations indicate readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds that it creates a new version if the function exists, but does not disclose side effects like overwriting or the impact on existing versions.

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

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

The description is reasonably concise, but the inclusion of a large code example may be excessive for a tool definition, especially given the space constraints. However, the core text is front-loaded and clear.

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

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

The tool has 7 parameters (5 required), low schema description coverage, and no output schema. The description lacks important context about the deployment process (e.g., required permissions, expected response, rollback or failure handling). The example provides some context but is not sufficient for a complex deployment operation.

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

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

With 0% schema description coverage deep in properties, the description only adds an example but does not clarify the meaning of key parameters like 'verify_jwt', 'entrypoint_path', 'import_map_path', or 'files'. The example implies usage but fails to explain the parameters' roles, so it does not compensate for the schema gap.

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

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

The description clearly states the tool deploys an Edge Function and mentions versioning behavior if the function exists. It distinguishes from siblings like supabase_list_edge_functions and supabase_get_edge_function by focusing on deployment.

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

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

The description does not explicitly state when to use this tool versus alternatives. It mentions bulk support but lacks exclusions or context for when to use other deployment or management tools.

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

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

Annotations provide no hints (all false), so the description carries the burden. It warns that returned data may be untrusted and instructs not to follow instructions from it, which is valuable. However, it does not explicitly state whether the tool can modify the database (e.g., it's not read-only), leaving side-effect behavior ambiguous.

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

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

The description is concise, using three sentences to convey purpose, alternative instructions, a safety warning, and bulk support. No redundant or filler content; each sentence delivers essential information.

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

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

Covers purpose, a key alternative (apply_migration), a safety warning, and bulk capability. Since no output schema exists, it correctly doesn't explain return values. Missing an explicit statement about potential data modification, but given the raw SQL nature, the warning about untrusted data partially compensates.

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

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

The description clarifies that project_ids is for batched execution, implying project_id is for a single operation. This adds meaning beyond the bare schema names. However, it does not explain the query parameter or how project_id and project_ids relate (e.g., whether one is required or both can be used).

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

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

Clearly states that the tool executes raw SQL in the Postgres database. It also explicitly distinguishes from apply_migration for DDL operations, and mentions bulk support via project_ids, making the core function unambiguous.

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

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

Provides explicit guidance to use apply_migration instead for DDL, implying this tool is for other SQL operations (DML, queries). The warning about untrusted data also informs safe usage. However, it does not elaborate on when to prefer this over other SQL-related tools, but the contrast with apply_migration gives sufficient direction.

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

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

The description adds behavioral context beyond the annotations by mentioning that it accepts project_ids for batch execution. This supplements the readOnly and idempotent hints from annotations, though it does not elaborate on side effects 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.

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

The description is extremely concise, consisting of two short sentences with no fluff. It efficiently conveys the core purpose and the bulk capability without unnecessary details.

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

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

For a simple tool, the description covers the main purpose and batch feature. It does not mention output format or return value, but given the simplicity and annotations, it is reasonably complete. The lack of parameter explanations is a gap, but that is partially covered in parameter semantics.

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

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

The schema provides no descriptions for parameters, and the description only vaguely refers to 'project' and 'batch'. It does not clarify the distinction between project_id and project_ids, their requiredness, or their exact roles beyond being project identifiers. This adds minimal value.

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

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

The description clearly states that the tool generates TypeScript types for a project, which is a specific action and resource. It distinguishes itself from sibling tools like supabase_get_project or supabase_list_tables by indicating a generation task rather than retrieval or management.

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

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

The description mentions bulk support for multiple project_ids, giving a hint about when to use this tool for batched operations. However, it does not explicitly state alternatives or when NOT to use it, though the context of generating types is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, indicating safety. The description adds behavioral specifics: instructs to include the remediation URL as a clickable link for the user, and mentions bulk support via project_ids. No contradiction with annotations.

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

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

The description is concise, front-loaded with the main purpose, and includes only relevant information. The bulk support note is a separate line, making it easily scannable with no redundant text.

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

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

For a tool with 3 simple parameters and no output schema, the description covers the primary purpose, usage context, and an optional bulk feature. It implies the return type (list of advisory notices) and remediation URLs, which is adequate for a low-complexity tool.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'project_ids' for bulk execution but does not elaborate on project_id or the 'type' enum. The schema is simple and self-explanatory, but additional parameter details would improve the score.

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

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

The description clearly states the tool 'Gets a list of advisory notices for the Supabase project' with a specific verb and resource. It also specifies the purpose of checking security vulnerabilities and performance improvements, distinguishing it from other Supabase tools like get_logs or get_project.

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

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

Provides explicit guidance: 'Use this to check for security vulnerabilities or performance improvements' and recommends running it 'especially after making DDL changes to the database'. While it does not compare to alternative tools, the context is clear and actionable.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds behavioral warnings (don't assume organization) and a confirmation requirement, which are important for correct agent behavior. No contradictions with annotations.

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

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

The description is concise, with the main purpose in the first sentence, followed by two key behavioral notes, and a brief bulk-support statement. Every sentence adds value; no filler or repetition.

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

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

For a simple read-only tool with good annotations, the description is sufficiently complete: it states what the tool does, provides a crucial warning, and includes bulk execution. No output schema exists, but the return value (cost) is straightforward. Could have mentioned error conditions, but not required given the simplicity.

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

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

Schema description coverage is 0%, so the description carries the burden. It implicitly covers 'type' by mentioning project/branch, and organization_id via the warning about organization variability. It mentions 'organization_ids' for bulk. However, it doesn't explicitly state that package_id is required or explain the relationship between organization_id and organization_ids, leaving some ambiguity.

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

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

The description clearly states the tool 'Gets the cost of creating a new project or branch.' It uses a specific verb ('Gets') and resource ('cost'), and distinguishes itself from sibling tools like supabase_create_project and supabase_confirm_cost by focusing on cost retrieval. The scope is explicit.

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

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

The description provides clear usage context: never assume the organization (costs vary by org) and to repeat the cost and confirm understanding before proceeding. It also mentions bulk support. It doesn't explicitly name alternatives or when not to use, but the guidance is sufficient for the typical workflow.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the key behavioral context of 'Bulk support' (batched execution), which is valuable. It does not, however, explain return format (file contents as string? metadata?) or error behavior when a function_slug is not found.

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

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

The description is concise and front-loaded: the first line states the core purpose, and the second line adds important bulk support information. No fluff, every sentence earns its place.

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

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

For a simple read operation with three parameters and no output schema, the description covers the basics: what and batch capability. However, it lacks clarification on whether project_ids replaces project_id or is additional, what kind of file contents are returned (e.g., raw source, metadata), and potential size limits. Given the operation's simplicity, this is adequate but not complete.

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

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

Schema description coverage is 0%, so the description must compensate, but it only explains the 'bulk' aspect of the parameters. It does not elaborate on what project_id or function_slug represent beyond their names, nor does it clarify the relationship/usage of project_ids array, such as whether it is a shorthand for multiple projects or a full batch mode. The schema properties are bare, and the description adds minimal semantic value.

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

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

The description uses a specific verb ('Retrieves file contents') and identifies the resource ('Edge Function in a Supabase project'), clearly indicating the tool's read operation. However, it does not explicitly differentiate from sibling tools like supabase_list_edge_functions (which lists functions) or supabase_deploy_edge_function (which deploys), though 'file contents' implies a fetch of source code.

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

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

The description implies usage for retrieving file contents of an Edge Function, and the 'Bulk support' note hints at when to use project_ids for batch operations. It does not explicitly state when to use this tool over alternatives (e.g., when you need code vs. a list), but the verb 'Retrieves' and resource context provide clarity.

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

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

The description aligns with annotations (readOnly, idempotent, non-destructive) and adds the specific behavior of returning logs only from the last 24 hours. It does not contradict annotations and provides useful operational details. No side effects are mentioned, which is consistent with the read-only nature.

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

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

The description is concise and well-structured, consisting of two brief sentences. It covers the core function, the use case, the time constraint, and bulk support without redundant information. Every sentence adds value, making it highly efficient.

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

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

The description provides enough context for typical usage: it states the purpose, the time window, and bulk capability. It does not specify output format or error handling, but these are absent from the schema as well. The relationship between project_id and project_ids is implicit but acceptable. Overall, it covers the essential aspects for a logs tool.

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

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

The description explains the 'service' parameter as a filter by service type and clarifies that 'project_ids' is for bulk execution. It does not explicitly describe 'project_id', but that is straightforward given the context. The schema already provides enum values for service, and the description adds practical meaning for the optional bulk parameter.

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

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

The description clearly states the tool's function: retrieving logs for a Supabase project by service type. It specifies the resource (logs), the primary parameter (service type), and the context (debugging). This is unambiguous and distinguishes it from sibling tools, none of which handle log retrieval.

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

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

The description explicitly recommends using this tool to debug application problems, giving a clear use case. It also mentions bulk support via project_ids, which guides usage for multiple projects. However, it does not directly compare to alternative tools or state when not to use it, leaving some room for interpretation.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is established. The description adds meaningful behavioral context by noting that subscription plan data is included and that batched execution is supported via the `ids` parameter.

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

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

The description is concise and front-loaded: the first sentence states the primary purpose, and the second adds bulk behavior without unnecessary fluff. Every sentence provides useful information.

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

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

With no output schema, the description communicates the most important aspects: tool purpose, subscription plan inclusion, and bulk capability. It does not list return fields or explain the valid combinations of `id` versus `ids`, but given the simplicity of the tool and strong annotations, this is a minor gap.

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

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

Schema description coverage is 0%, so the description must compensate. It does partially by explaining that `ids` enables 'batched execution,' but it does not clarify the relationship between `id` and `ids`, nor by example or semantics how the batched form should be used. The parameter names themselves are reasonably self-explanatory.

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

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

The description clearly states it 'Gets details for an organization' and adds a specific output characteristic: 'Includes subscription plan.' This distinguishes it from related tools like supabase_list_organizations (which lists organizations) and supabase_get_project (which targets projects).

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

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

Usage is implied: use this tool when details for a specific organization are needed, and the bulk support note indicates when to pass multiple ids. However, it does not explicitly contrast with sibling tools such as supabase_list_organizations or explain when one should prefer listing over fetching details.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. Description adds bulk execution behavior via ids, but doesn't disclose return format or error behavior. No contradiction.

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

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

Two short sentences with no fluff; front-loads the core purpose then adds bulk detail.

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

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

For a simple read-only get operation with two flat string/array parameters and no output schema, the description plus annotations provide sufficient context. Bulk support is the only extra behavior, and it is mentioned. Could specify response details but 'details' implies that.

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

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

Schema has 0% description coverage. Description clarifies that 'ids' enables bulk execution, adding meaning to the optional parameter, but doesn't elaborate on 'id' or value formats beyond schema's type constraints.

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

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

Description uses specific verb 'Gets' with resource 'details for a Supabase project', clearly differentiating from siblings like supabase_list_projects (list all) and supabase_get_project_url (specific URL). Bulk support note adds precision.

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

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

No explicit alternatives or exclusions, but the bulk support sentence implies usage for single or batched project detail retrieval. It doesn't state when to prefer this over list_projects or get_project_url, leaving usage context implied.

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

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

Annotations already declare readOnlyHint: true, idempotentHint: true, and destructiveHint: false, covering safety. The description adds the bulk support capability, which is behavioral context beyond the schema. However, it does not explain behavior in failure scenarios or return structure, but given the strong annotation coverage, this is acceptable.

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

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

The description is extremely concise, consisting of two short sentences. It front-loads the core purpose and adds only essential information about bulk support. No unnecessary words, perfectly aligned with minimalism.

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

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

The tool is simple with only two parameters, and the description covers the essential functionality. However, it lacks specification of the return value format or error behavior, which would be helpful given no output schema. While adequate for a read-only getter, it could be more complete.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions bulk support for project_ids, explaining that parameter's purpose. While project_id is not described, its meaning is evident from the name and context. The description adds partial semantic value, though it could be more explicit about parameter formats.

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

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

The description uses a specific verb 'Gets' and a clear resource 'API URL for a project', distinguishing it from sibling tools like supabase_get_project which likely retrieves full project details. The mention of bulk support further clarifies its scope, making the purpose unambiguous.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives. It mentions bulk support but no exclusions or alternative tool references. The usage context is implied by the purpose, but no explicit 'use this when' guidance is given.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds useful context about disabled keys and the distinction between key types, but does not introduce any additional behavioral caveats beyond what annotations convey.

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

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

The description is well-structured in two short paragraphs, providing necessary context about key types and disabled status without excessive verbosity. It is concise and focused, with no redundant or ambiguous phrasing.

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

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

Given there is no output schema, the description adequately describes the expected output (keys of both types, disabled indicator) and key selection criteria. It provides enough context for an agent to understand the tool's role and usage, though it could benefit from specifying the exact output structure.

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

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

The description explains the purpose of both parameters: 'project' implicitly maps to project_id, and project_ids is explicitly described as supporting batched execution. This adds value beyond the raw schema, which only lists types. It covers the parameters sufficiently for an agent to invoke correctly.

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

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

The description clearly states the tool's function: getting all publishable API keys for a project, and distinguishes between legacy anon and modern keys. It uses a specific verb 'Gets' and specifies the resource, making the purpose unambiguous.

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

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

The description lacks explicit guidance on when to use this tool versus alternative tools. It mentions that publishable keys are recommended but does not compare with other tools or specify conditions for selection, such as when to use list vs. get or other project-related tools.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, which covers safety. The description adds that it returns branch details including status, which gives insight into what the tool reveals. It does not mention side effects (none expected) or additional caveats, but given the annotations, the transparency is adequate.

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

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

The description is concise and well-structured: two sentences that cover the core action, the return value usefulness, and bulk support. There is no redundant information or vague phrasing, making it easy for an agent to parse.

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

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

The description covers the main purpose, the nature of the return (branch details with status), and the bulk capability. It also explains how the output can be used (for checking completion of operations). While it does not detail the exact output schema (which is not provided), the description is sufficiently complete for a list operation, given the annotations.

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

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

The input schema provides no descriptions for parameters. The description only explains that 'project_ids' is for bulk execution, but does not clarify 'project_id' beyond being a project identifier. This leaves project_id's purpose implicit, and the coverage of parameters is less than 50% (only one of two parameters is described). The description does not fully compensate for the lack of schema descriptions.

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

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

The description clearly states the tool's purpose: 'Lists all development branches of a Supabase project.' This is a specific verb (lists) and resource (development branches), and it distinguishes the action from sibling tools like create_branch or delete_branch.

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

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

The description provides a use case: 'This will return branch details including status which you can use to check when operations like merge/rebase/reset complete.' This implies when to use the tool (to monitor completion of other operations). It also mentions bulk support via project_ids, which guides usage. However, it does not explicitly contrast with alternatives, but the listing vs. modification distinction is clear from the verb.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds the bulk-execution behavior, but does not disclose any edge cases or limits. Given annotation coverage, a 3 is fair.

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

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

The description is extremely concise: one sentence for the core purposeasi, and a second sentence for the bulk capability. No filler words.

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

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

For a list operation with good annotationsley and no output schema, the description sufficiently covers the action, scope, and bulk behavior. It doesn't describe return format but that's often left to schema; since none is provided, a slight gap exists, but for a simple listing tool this is acceptable.

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

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

The input schema has two parameters with no descriptionsates. The description explicitly notes that project_ids is for bulk execution, which adds meaning beyond the schema. However, it does not describe project_id at all beyond the required markerches, but that is self-evident from the name. Baseline 3 is appropriate as the schema description coverage is near 100%.

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

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

The description clearly states the tool 'Lists all Edge Functions in a Supabase project', using a specific verb and resource, and distinguishes from sibling tool supabase_get_edge_function by indicating it lists all functions rather than retrieving a single one.

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

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

It mentions bulk support (accepts project_ids), but does not explicitly contrast with alternatives like supabase_get_edge_function or state when to choose this vs. other listing tools. Implicit context is present, but no explicit exclusions or alternative recommendations.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds no additional behavioral details (e.g., side effects, rate limits) but does not contradict annotations, so it meets the lowered bar.

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

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

Two sentences, direct and free of redundant information. Efficiently conveys the core functionality and an additional capability.

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

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

Given the absence of an output schema, the description adequately covers what the tool does. It could mention return format or error behavior, but for a simple list operation, it is reasonably complete.

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

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

Schema provides no parameter descriptions (coverage 0%). The description explains project_ids as for batch execution but leaves project_id undefined. Since schema coverage is low, the description should compensate more fully; it only partially does.

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

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

Clearly states it lists all extensions in the database, distinguishing it from other list operations (e.g., list_branches, list_tables). The mention of bulk support adds specificity.

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

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

Provides some guidance on bulk usage (project_ids for batched execution) but does not explicitly clarify when to use this tool over alternatives or when to choose single vs. batch mode. Lacks explicit exclusionary language.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds the bulk execution feature, which is not in the annotations, and does not contradict them. It does not describe side effects or permissions, but the annotations cover safety.

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

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

The description is extremely concise, consisting of two short sentences. It conveys the core functionality and the bulk feature without any unnecessary words or restating the name. Excellent structure.

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

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

For a simple listing tool with no output schema, the description adequately explains the purpose and the bulk option. It does not explain return structure, but that is not required given the lack of an output schema. The description is sufficient for an agent to understand what this tool does.

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

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

The schema provides no parameter descriptions (0% coverage). The description only mentions 'project_ids' for bulk execution, but does not clarify the required 'project_id' parameter or its relationship to 'project_ids'. This leaves significant ambiguity about how to use the parameters effectively.

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

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

The description clearly states it 'lists all migrations in the database,' which is a specific verb and resource. It distinguishes from sibling list tools (e.g., list_branches, list_edge_functions) by targeting migrations, and mentions bulk support for multiple projects.

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

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

The description provides some usage context by noting bulk support via project_ids, which implies it can be used for single or multiple projects. However, it does not explicitly say when to use this over other listing tools or provide exclusion criteria. Still, the bulk feature offers a hint of when to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description is consistent with these, and it adds clarity by specifying the scope ('that the user is a member of') which is not explicit in annotations. It does not describe return format or pagination, but for a simple list operation with strong annotations, this is acceptable. No contradiction with annotations.

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

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

The description is a single concise sentence that directly states the tool's purpose. Every word earns its place; there is no fluff, redundant phrasing, or extraneous details. It is appropriately front-loaded and efficient.

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

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

Given the tool's low complexity (no parameters, simple read operation, no output schema), the description is nearly complete. The main omission is that it doesn't specify the output structure (e.g., array of organization objects) or mention that it returns only organizations where the user is a member, but that is already stated. The description suffices for an agent to invoke and understand the tool.

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

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

The input schema has no parameters, and schema description coverage is 100% (vacuously). The description adds nothing beyond the schema, but the baseline for a zero-parameter tool is 4, as there are no parameters to document. The description unnecessarily restates the obvious, but it does not need to.

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

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

The description clearly states the tool lists all organizations the user belongs to ('Lists all organizations that the user is a member of.'). It explicitly scopes to the authenticated user's memberships, distinguishing it from sibling tools like supabase_get_organization (singular) and supabase_list_projects, though it does not explicitly contrast with them.

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

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

The description implies when to use the tool: when you need to enumerate organizations for the current user. However, it provides no explicit guidance on when not to use it or alternatives for broader organizational access or filtering. No exclusions or alternatives are mentioned.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-covered. The description adds the purpose of discovering project IDs but doesn't describe return format or pagination behavior. This is minimal value beyond annotations, so a 3 is appropriate.

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

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

The description is two sentences, front-loaded with the primary action and followed by a practical use case. No wasted words and effective structure.

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

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

For a zero-parameter list operation with strong annotations and no output schema, the description is complete. It states what it does, who it's for, and a clear use case. No additional details are needed.

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

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

With zero parameters and 100% schema coverage, the schema fully defines the input. The description adds purpose context ('helps discover project ID') that is not redundant with the schema, meeting the baseline of 4 for zero-param tools.

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

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

The description clearly states 'Lists all Supabase projects for the user' and provides a specific use case ('discover the project ID'), distinguishing it from sibling supabase_get_project. The verb and resource are explicit.

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

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

The description provides clear when-to-use guidance ('Use this to help discover the project ID'), which implicitly advises using this tool when the project ID is unknown. It doesn't explicitly contrast with alternatives, but the guidance is sufficient.

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

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

Given annotations already declare readOnlyHint and idempotentHint, the description adds value by specifying output behavior (compact summary vs. verbose) and bulk capability. It does not cover authentication or rate limits, but for a read/list operation with these annotations, the spirit of the description aligns and adds meaningful context beyond the structured fields.

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

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

The description is elegantly brief: two sentences. The first states the purpose and default behavior; the second covers optional parameters and bulk support. Minimal redundant text, front-loads the core action, and stays focused to essential information without bloat.

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

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

The tool has no output schema and only annotations; the description covers the main behaviors (default/verbose, bulk) and gives enough context to understand operation. It lacks a note on return format (e.g., whether it's a paginated list) and error scenarios, but for a list operation it is nearly complete. The absence of an output schema makes it slightly less complete than the high-calibration example.

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

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

Schema description coverage is 0%, so the description's job is important. It clarifies verbose toggling behavior, schemas scope, and project_ids for batching. It does not expand on project_id, but its purpose is obvious from the name and required status. Overall, it compensates for the absent schema descriptions with clear, actionable parameter semantics.

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

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

The description clearly states the tool lists tables across schemas, with a specific verb-resource pair and scope. It distinguishes itself from sibling list tools (e.g., supabase_list_projects, supabase_list_branches) by targeting tables in schemas. Confusion with siblings is unlikely.

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

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

The description provides usage context: by default a compact summary is returned, verbose includes column details, and a bulk mode uses project_ids for batching. It implies when to choose verbose (need detail) and when to use bulk (multiple projects), but it does not explicitly name alternatives or say when not to use this tool. Slight improvement would be an explicit exclusions line.

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

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

The description hints at a destructive action (merging to production) but annotations are minimal (destructiveHint: false) and don't fully cover the risk. It adds some context about bulk support, but doesn't disclose side effects like potential conflicts or irreversible changes, especially for production.

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

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

The description is concise, two sentences, and front-loads the core purpose. The bulk support note is extra but valuable, so no wasted content. It could be more structured but is efficient.

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

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

Given the tool's complexity (merging branches to production) and lack of output schema, the description provides basic context but not enough to fully understand implications, such as what happens on conflict or if there are any confirmation steps. It's adequate but leaves gaps.

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

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

With schema description coverage at 0%, the description must explain the parameters, but it only mentions branch_ids for bulk support without detailing what branch_id represents or how they are used. It doesn't differentiate between the two parameters or clarify if branch_id is required versus optional.

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

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

The description clearly identifies the action (merges) and the resource (migrations and edge functions) from a development branch to production. It distinguishes it from sibling tools like supabase_rebase_branch, which has a different operation, and mentions bulk support for batch execution.

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

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

The description implies usage in the context of promoting changes from development to production, but does not explicitly state when to use this tool versus others like supabase_apply_migration or supabase_deploy_edge_function. There's no mention of prerequisites or scenarios to avoid.

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

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

The description discloses extra behavior beyond annotations by noting bulk support via project_ids. It also indicates this is a state-changing operation by describing 'Pauses', which is consistent with readOnlyHint: false. However, it does not cover what happens to the project after pausing, whether it is reversible, or what the response contains.

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

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

The description is extremely concise: two short sentences with no filler. The main purpose is front-loaded, and the bulk execution detail is a separate, useful addition.

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

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

It covers the core operation and bulk execution, which is the main contextual need. But for a state-changing tool with no output schema and sparse annotations, it does not describe side effects, restoration path, or response behavior, leaving some ambiguity for an agent deciding whether invocation is safe and appropriate.

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

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

Schema description coverage is 0%, so the description must compensate. It does clarify that project_ids enables batched execution, which adds meaning beyond the raw schema. Still, it does not explain the relationship or optionality between project_id and project_ids, or the expected ID format.

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

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

The description uses a specific verb and resource: 'Pauses a Supabase project.' This directly states what the tool does and is not confused by any sibling tool, since no sibling is also named as a pause action.

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

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

The description implies when to use the tool: when a Supabase project should be paused. However, it does not explicitly mention when not to use it, nor does it point to related alternatives such as supabase_restore_project for resuming a paused project.

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

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

Despite annotations being present (readOnlyHint false, destructiveHint false), the description adds behavioral context by stating that it will 'run any newer migrations from production onto this branch' and mentions bulk support. These details go beyond the schema and annotations, clarifying the side effects of applying migrations. No contradiction with annotations; the description enhances transparency.

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

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

The description is concise, consisting of two sentences. It is front-loaded with the main action and purpose, followed by a note on bulk support. No wasted words, achieving high efficiency.

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

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

For a tool with 2 parameters and no output schema, the description is fairly complete. It explains the main action, the reason (migration drift), and the bulk capability. It could be more explicit about what happens to the branch after rebase or any side effects, but given the annotations and simplicity, it is adequate.

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

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

Schema description coverage is 0%, so the description must compensate. It explains branch_ids for batched execution but does not explicitly describe branch_id, though it is inferable from the tool name and context. The mention of 'Bulk support' adds meaning to the optional array parameter, but the primary parameter is under-documented. Overall, it provides partial semantic value.

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

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

The description clearly states what the tool does: 'Rebases a development branch on production.' It also explains the purpose ('to help handle migration drift') and distinguishes itself from siblings like supabase_merge_branch and supabase_reset_branch by specifying the rebase action and its migration-focused role.

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

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

The description provides context on when to use the tool: 'This will effectively run any newer migrations from production onto this branch to help handle migration drift.' It implies the use case (migration drift) but does not explicitly mention alternatives or when not to use it. Given the sibling tools, this is a clear context but lacks explicit exclusions.

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

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

The description warns that 'Any untracked data or schema changes will be lost,' which indicates a destructive operation, yet the annotations declare destructiveHint=false. This is a direct contradiction. According to the rules, a score of 1 is required when the description contradicts annotations. The description itself provides useful safety information, but the conflict with the structured annotation undermines trust.

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

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

The description is composed of two terse, effective sentences. The first states the core operation and its consequence, the second adds bulk support. No unnecessary words or repetition. It is front-loaded with the most critical information.

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

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

The description covers the basic operation and warns about data loss, but it fails to explain what 'reset' means precisely (e.g., does it roll back to a specific migration version? Does it remove all migration history?). It also ignores migration_version and provides no information about return values or side effects beyond the warning. Given the destructive nature and the annotation contradiction, more detail is needed for safe use.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies branch_id (development branch) and branch_ids (bulk support), but migration_version is entirely unmentioned. The meaning of migration_version is left unclear, and the description adds only partial value over the raw schema.

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

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

The description clearly states the action: 'Resets migrations of a development branch.' This is a specific verb-resource pair that distinguishes it from sibling tools like supabase_rebase_branch or supabase_delete_branch. The scope is limited to development branches, adding clarity.

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

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

The description implies usage for development branches and mentions bulk execution, but it does not explicitly state when to use this tool versus alternatives (e.g., rebase, merge, or delete). It lacks clear preconditions or exclusions, so it provides minimal guidance beyond the basic context.

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

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

All annotations are false, so the description carries full responsibility for disclosing behavior. It does not mention any side effects (e.g., overwriting existing data, potential downtime), required permissions, or whether the operation is reversible. The bulk support hint is about execution, not behavioral consequences.

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

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

The description is exceptionally concise: two sentences, no fluff, and the most important info (the action) is front-loaded. The bulk support note is a separate sentence, keeping structure clean.

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

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

The description is too sparse for a tool like restore. It lacks context about what 'restore' means (from backup? to a specific state?), whether it overrides current settings, or what happens to existing project data. With no output schema and no annotation support, this leaves the agent guessing about important operational details.

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

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

The description adds minimal meaning beyond the schema: it explicitly says 'project_ids' is for 'batched execution', which clarifies the optional array parameter. However, it does not explain that 'project_id' is the primary required parameter for a single restore, nor does it describe any format or constraints. Given 0% schema coverage, this is insufficient but not entirely absent.

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

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

The description clearly states the action ('Restores') and the resource ('a Supabase project'), making the tool's purpose immediately obvious. It distinguishes itself from sibling tools like create_project, delete_project, or pause_project by specifying a restore operation.

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

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

No guidance is given on when to use this tool versus alternatives. The description doesn't mention typical scenarios (e.g., restoring from a backup) or any prerequisites, nor does it explicitly exclude cases where restore shouldn't be used. The bulk support note is a feature hint, not usage guidance.

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

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

Annotations indicate read-only, idempotent, non-destructive behavior. The description adds that the tool is always up-to-date, implying fresh results. The GraphQL schema exposes return types, though prose doesn't explicitly state the output shape.

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

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

The prose is concise (two sentences), and the lengthy schema is necessary for usage clarity. The structure is logical, though somewhat dense due to the schema contents.

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

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

Provides enough information to understand the tool's purpose, input requirements, and the query capabilities via schema. Missing an explicit output description but the schema's types infer the returned data.

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

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

The sole parameter graphql_query is explained as requiring a valid GraphQL query. The embedded schema defines the query structure, providing sufficient detail beyond the basic string type.

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

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

The description clearly states 'Search the Supabase documentation using GraphQL' and requires a valid GraphQL query. This distinguishes it from other Supabase management tools like supabase_get_project or supabase_list_tables.

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

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

Explicitly instructs to default to calling this even if knowledge is assumed, because documentation updates. This provides a strong when-to-use directive, and the need for a valid GraphQL query is made clear.

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

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

The annotations already declare readOnly and idempotent behavior. The description adds value by detailing the specific content of the state (installed MCPs, connection status, accounts, catalog tool counts), which goes beyond the annotations without contradicting them.

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

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

The description is a single, concise sentence that efficiently conveys the tool's purpose without unnecessary detail. It is well-structured and front-loaded.

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

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

Given no parameters, no output schema, and the presence of annotations, the description is fully sufficient. It covers all necessary aspects of the tool's behavior and output, making it complete in context.

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

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

With zero parameters, the baseline is 4. The description does not need to explain parameters, and it correctly omits any mention, maintaining consistency.

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

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

The description clearly states the tool's action ('Returns') and resource ('current toolkit state'), with specific details about the output (installed MCPs, connection status, accounts, catalog tool counts). It differentiates from sibling tools by being a read-only status overview.

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

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

The description does not explicitly mention when to use this tool versus alternatives. It only describes what it does, without context on when a status check is preferred or how it differs from other tools in the toolkit.

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