snowflake-mcp-server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools are cleanly separated by resource type and action, so choosing a list/describe/create/drop tool is usually straightforward. However, the composite recipe tools create real overlap with underlying tools (e.g., inspect_table_with_sample vs. profile_table vs. sample_table, and clone_table_recipe vs. clone_table), though the 'composite recipe' descriptions mitigate some ambiguity.
Naming Consistency4/5
Tool names follow a consistent snowflake_<verb>_<noun> structure for the majority, with list/create/describe/drop/resume/suspend used predictably. Deviations include get_ vs. describe_ for metadata operations, read_stream_changes, and recipe-style names such as warehouse_scale_and_execute and account_usage_summary.
Tool Count2/5
At 127 tools, the surface is far beyond the general well-scoped range and will make tool selection harder for an agent. The count is inflated by many read-only list/describe tools plus overlapping composite recipes, so a tighter tool set would be more coherent.
Completeness3/5
The server covers a huge portion of Snowflake's object types, including databases, tables, warehouses, tasks, streams, pipes, alerts, roles, users, and Cortex AI. However, lifecycle support is uneven: many object types only have list/describe, and there are notable gaps like no create/drop view, no alter operations, and no grant/revoke tools.
Average 2.9/5 across 127 of 127 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on August 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the 'zero-copy' property, which is a useful behavioral trait for Snowflake cloning. However, it does not describe any side effects (e.g., whether the source remains fully accessible), permissions required, or reversibility. For a schema-level creation operation, this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, which is concise, but it is under-specified rather than efficiently complete. It omits essential context that should be included for a tool with multiple parameters and no other documentation. Simplicity is not an asset when key information is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, 0% schema coverage, no annotations, and an output schema that is not referenced in the description, the description is far from complete. It does not address parameter usage, expected return, or any operational details an agent would need to call it correctly. This is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description says nothing about the parameters. It does not explain what 'source_schema' vs 'target_schema' mean, nor how the optional 'database' parameter interacts. An agent must guess the semantics from parameter names alone, which is insufficient for a multi-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Create') and object ('clone of a schema'), and adds 'zero-copy' as a characteristic. However, it does not differentiate from sibling clone tools (e.g., snowflake_clone_table, snowflake_clone_database) beyond the word 'schema', which is already in the tool name. It essentially restates the name with minor elaboration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like snowflake_clone_table and snowflake_clone_database present, an agent has no textual clues to decide which clone tool is appropriate for a given task. There is no mention of context, exclusions, or alternative routes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'Requires confirmation', which hints at a safety gate, but does not disclose the irreversible nature of dropping a task, potential side effects on dependent objects, or permission requirements. This is minimal behavioral transparency for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences), which is concise, but it is under-specified rather than appropriately concise. It front-loads the purpose but omits critical details needed for correct invocation. The brevity comes at the cost of completeness, so a 2 is warranted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive drop operation with 4 parameters and an output schema, the description is severely incomplete. It does not explain the confirm requirement, the optional database/schema context, or any prerequisites (e.g., task must be suspended). The agent lacks sufficient context to call the tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 by explaining parameters. It does not mention 'confirm', 'database', 'task_name', or 'schema_name' at all, leaving the agent without any semantic guidance beyond the schema's bare types and defaults. The description adds no parameter-level value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Drop' and the resource 'task in Snowflake', making the action unambiguous. It does not explicitly differentiate from sibling drop tools, but the resource type is sufficiently specific to avoid confusion. A 4 is given because purpose is clear but lacks any context about what 'task' means in Snowflake.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any conditions or exclusions. The only additional clause 'Requires confirmation' is a prerequisite, not usage guidance. There is no mention of when to prefer this over other drop tools or how to verify the task exists before dropping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('Suspend an active alert') without revealing consequences, reversibility, required permissions, or side effects. For a state-changing operation, this is a significant gap—an agent cannot anticipate what happens to the alert or whether suspended alerts are permanently disabled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal (one short sentence), but it is under-specified rather than concisely informative. It lacks any structure that would make it easy to parse for key information, and it does not earn its place because it adds no value beyond the tool name. A well-structured description would front-load the core action and then provide contextual details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters (one required) and no annotation coverage, the description is severely incomplete. It does not explain how to identify an alert, what database/schema context is needed, what the output will look like, or any prerequisites. Even though an output schema exists, the description should still cover invocation essentials, which it entirely omits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the three parameters (database, alert_name, schema_name). The description provides no additional meaning beyond the raw schema, leaving the agent to guess what 'alert_name' refers to or how database and schema scope the operation. The description utterly fails to compensate for the lack of schema-level documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Suspend an active alert' clearly identifies the specific verb (suspend) and resource (alert). It is unambiguous about the tool's primary action, though it does not explicitly distinguish it from sibling alert operations like resume_alert or drop_alert. The name itself already conveys the purpose, so the description adds minimal extra clarity but is not misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that alerts must be in an active state, that suspended alerts can be resumed later, or any prerequisites such as requiring appropriate permissions. An agent would have to infer usage entirely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It does not mention any side effects, error conditions, idempotency behavior (e.g., how if_not_exists affects execution), required privileges, or what happens on success. The description merely repeats the tool's name without adding behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single, clear sentence that is efficient, but it is so brief that it under-specifies the tool. It lacks essential details about parameters and behavior, making it more under-specified than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and a non-trivial if_not_exists option, the description is grossly incomplete. It does not explain parameter semantics, failure modes, or the output, so an agent cannot call it correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters. It only hints at 'specified database' but gives no meaning for 'name', 'comment', or 'if_not_exists'. The description adds no value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create a new schema' and specifies the context 'inside a specified database', which distinguishes it from other schema operations like drop or clone. It is specific about the resource type and target database, though it doesn't explicitly reference sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like snowflake_create_database or snowflake_clone_schema. The description only states what it does, not under what conditions to choose it, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal that the clone is 'zero-copy', implying a metadata-only operation, but says nothing about failure conditions (e.g., target already exists), required privileges, reversibility, or any side effects. For a data-definition operation, this is a minimal disclosure that leaves critical behavior untold.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words, and it includes the useful qualifier 'zero-copy'. However, it is not structured (e.g., no bullet points or sections) and is overly brief, missing substantial content. The conciseness is appropriate for what is included, but the trade-off is under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low parameter complexity (2 flat strings) and existence of an output schema, the description does not need to explain return values. However, it fails to provide essential operational context such as naming conventions (whether the target must be new), the relationship to other clone tools, or any constraints on source/target usage. An agent calling this tool would have significant knowledge gaps about correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining the parameters. It does not mention that source_table and target_table likely require fully qualified names, nor any format expectations. The parameter names are self-explanatory, but the description adds no additional semantic meaning beyond what the schema already provides, so it fails to bridge the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a zero-copy clone of an existing table'), which is specific and unambiguous. It distinguishes itself from sibling clone tools (database, schema) by explicitly mentioning 'table', though it does not contrast with them. The description is clear enough for an agent to understand the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like snowflake_clone_database or snowflake_clone_schema, nor any prerequisite conditions (e.g., target table must not exist, source must exist). No context about suitable scenarios or exclusions is provided, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It only states the action 'create', implying a mutation but not disclosing any other behavior: what happens if the table exists, whether it validates SQL, if it uses default settings, or how it interacts with the 'if_not_exists' flag. There is no mention of side effects, permissions, or reversibility. For a DDL operation, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is under-specified to the point of being unhelpful. It appears more like a label than a guideline. While it is front-loaded with the core verb, it omits any elaboration that would make the sentence useful, so it does not 'earn its place' effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and zero schema coverage, the description is far too sparse. It does not explain the expected return value (even though an output schema exists, the description doesn't reference it), the behavior of defaults, or the interaction between parameters. An agent would have no confidence in constructing a correct invocation without external knowledge of Snowflake DDL.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters, but it does not mention any of the five parameters. 'specified column definitions SQL' hints at columns_sql but doesn't clarify its format (e.g., a fragment like 'col1 INT, col2 VARCHAR' or full CREATE TABLE subclause). Database, schema_name, table_name, and if_not_exists are entirely unexplained, leaving the agent to guess required context and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), a resource ('a table in Snowflake'), and the general mechanism ('specified column definitions SQL'). It is clear enough to distinguish from 'clone_table' and other DDL operations. However, it lacks any refinement about table ownership, schema, or database context, which is slightly vague but still specific overall.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, such as 'snowflake_clone_table' or 'snowflake_create_schema'. No context about prerequisites (e.g., database/schema must exist) or conditions where this is inappropriate is given. The intended usage is only implied by the name and description, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Resume a suspended alert' and omits any side effects, permission requirements, idempotency, or what happens if the alert is not in a suspended state. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, but it conveys minimal information beyond the name. While it is not verbose, it does not 'earn its place' because it adds little value. It is appropriately short but lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of three parameters and no annotations, the description is incomplete. It does not explain when to invoke the tool, what inputs are needed, or any expectations about the result (despite an output schema being present but not described). An agent would struggle to use this tool correctly without further guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for its three parameters (database, alert_name, schema_name). The description adds no explanation of what these parameters mean, how they relate, or whether database and schema_name are optional. It fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Resume a suspended alert' clearly states the verb (resume) and the resource (alert), making the primary purpose unambiguous. It aligns with the tool name and distinguishes it from suspend_alert, though it does not explicitly mention any differentiating nuances beyond the action itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention preconditions (e.g., the alert must be suspended), suggest related tools, or explain context such as requiring the alert to exist. Users must infer usage solely from the tool name and the existence of snowflake_suspend_alert.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('set or assign') without revealing side effects (e.g., whether existing tag values are overwritten), permission requirements, idempotency, or failure behavior. For a mutation tool this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is under-specified rather than efficiently structured. It front-loads the action but omits all operational detail, so it fails to earn its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no parameter descriptions, and no usage guidance, the description is inadequate for a mutation tool that requires three parameters and has a defaulted fourth. The presence of an output schema is not enough to compensate for the missing behavioral and semantic context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — the description does not mention any of the four parameters (tag_name, tag_value, object_name, object_domain). The agent gets no help understanding parameter formats, defaults, or relationships beyond what the schema's basic types provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Set or assign a tag value') and a resource ('on a Snowflake object'), and lists example object types (TABLE, SCHEMA, DATABASE). This clearly distinguishes it from sibling tools like snowflake_list_tags or snowflake_describe_tag, which read rather than mutate tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context (e.g., that the tag must exist, or that setting a tag is distinct from listing or describing tags). The description is purely definitional and lacks routing information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does without mentioning side effects, cost implications, permission requirements, or any special behavior (e.g., whether it reads from warehouse context, rate limits). For a generative tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it under-specifies rather than being efficiently informative. It does not front-load the most critical behavioral or usage data. It is short but not necessarily 'good conciseness' because it omits essential guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is an output schema, the return format need not be described, but the tool has 4 parameters and is one of many analogous Cortex tools. The description is too sparse: it lacks any note on the difference from other Cortex tools, parameter nuances (e.g., temperature range), or typical usage scenarios. An agent is left without enough context to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters. The schema has 4 parameters (model, prompt, max_tokens, temperature) but schema coverage is 0%, and the description does not compensate. It does not even mention that 'prompt' is required or that 'model' has a default. The agent must infer everything from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run LLM completion') and the resource (Snowflake Cortex AI), with concrete model examples. It distinguishes itself from specialized cortex tools (like summarize, sentiment) by indicating it is a general completion tool, though it does not explicitly name a sibling as an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus other Cortex AI tools or other Snowflake tools. It does not mention that it is for general text generation and not for summarization, translation, or other specialized tasks. The examples give a hint but no explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the core action and engine, omitting details like language code formats, output structure, authentication requirements, rate limits, or whether the operation is synchronous. This is a significant gap for an AI agent selecting the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the essential action without fluff. It is appropriately sized and front-loaded, though its brevity contributes to the lack of behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not explain return values, but it lacks critical operational details such as language format specifications and any limitations. For a simple translation tool, the description is thin, leaving the agent to guess at ambiguous parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no additional meaning to the parameters 'text', 'source_language', and 'target_language'. It does not clarify accepted language formats (e.g., ISO codes vs. names) or any constraints, leaving the agent to infer from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (translate), the resource (text), and the two key parameters (source and target languages). It distinguishes from other Cortex tools by explicitly naming the translation operation, making it unambiguous even without naming a specific alternative sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when translation is needed, but provides no explicit guidance on when to choose this over other Cortex tools (e.g., snowflake_cortex_summarize) or any conditions for use. There is no mention of when not to use it or prerequisite context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits, but it only states the action without any details about side effects, required permissions, idempotency, or what happens if the pipe already exists. It does not even mention the auto_ingest option or that a COPY statement must be provided, leaving the agent without essential 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise as a single sentence, which is front-loaded, but it is under-specified to the point of being unhelpful. Conciseness should not come at the expense of necessary information; here it is too sparse, so while structure is clean, it fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, including a required copy_statement and optional flags like auto_ingest and if_not_exists, the description is severely incomplete. Without explaining what a copy statement is, how database and schema are used, or the effect of the booleans, an agent cannot reliably construct a valid call. Even though an output schema exists, the input side is entirely unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema only has parameter titles but no explanatory text. The description does not elaborate on any of the six parameters (pipe_name, copy_statement, database, schema_name, auto_ingest, if_not_exists), leaving the agent to guess their meanings and formatting, which is critical for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (Snowpipe) with a purpose ('for continuous ingestion'), making it unambiguous and distinguishing it from query tools or other creation tools like create_table or create_stage. The specific resource name alone differentiates it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, no prerequisites (e.g., needing a stage), and no mention of when not to use it. The description is a bare one-liner with no contextual direction for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Create a new role,' which implies a mutating operation, but gives no details about failure modes (e.g., if the role already exists), the effect of the if_not_exists parameter, or required permissions. This is minimal and leaves critical behavior undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence, which scores well on brevity. However, it lacks structure—it is under-specified and does not front-load any scoping, options, or guidance beyond the action itself. It is not verbose, but it is also not appropriately sized given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and an output schema (though not shown), the description is incomplete. It does not mention command behavior on existing roles, return values, error conditions, or any side effects. An agent has no way to anticipate outcomes or handle edge cases from this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 by explaining the parameters. It does not mention role_name, comment, or if_not_exists at all, providing no additional meaning beyond the schema's bare field names. This is a complete failure to aid parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'a new role in Snowflake,' making the primary purpose unambiguous. It does not differentiate from sibling create tools (e.g., create_database), but the role-specific naming removes most ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives like snowflake_describe_role or snowflake_drop_role, nor does it state any prerequisites (e.g., required privileges) or conditions under which creation should be attempted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'Create', implying a mutation, but does not mention required permissions, side effects, idempotency (despite the if_not_exists parameter), or any other operational details. The minimal wording leaves significant behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is so terse that it borders on under-specification, though for the purpose of clarity it is concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters (1 required), no annotations, 0% parameter coverage, and no usage context, the description is grossly incomplete. It does not explain what a stage is used for, when to call this tool, or what the output signifies. An agent cannot confidently decide to invoke this tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. The schema lists stage_name, comment, database, schema_name, and if_not_exists, but their roles and relationships are not described. The description offers no clue about what values are expected or how they affect the operation, so the agent is left guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (create) and the resource (an internal named stage in Snowflake). It is specific enough to distinguish from other create tools like snowflake_create_database or snowflake_create_schema, though it does not explicitly reference them. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of scenarios where creating a stage is appropriate, nor any reference to related tools like list_stages or describe_stage. The description simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are entirely absent, so the description must carry the full burden of behavioral disclosure. It states what information is returned (condition SQL, action SQL, etc.) but does not disclose whether the operation is read-only, what side effects might occur, permission requirements, or error behavior (e.g., what happens if the alert does not exist). This is a significant gap for a tool that may be used in varied contexts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words, which is efficient. However, it is so terse that it borders on under-specification rather than concise clarity. It conveys the core purpose but omits details that would be valuable for correct usage, making it acceptable but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, zero schema description coverage, and no annotations, the description is incomplete. It does not explain parameter semantics, usage conditions, or behavioral aspects. While an output schema exists, the description does not reference it, and the agent is left without sufficient guidance to ensure correct invocation, especially for a describe operation that may require precise specification of the alert.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description adds no value to the parameters. It does not explain the role of alert_name, database, or schema_name, nor how they relate to identifying the alert. The only hint is that the tool describes an alert, but the description does not clarify how to specify which alert. This leaves an agent with little understanding of the required inputs beyond the schema's structural constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Describe alert...' and lists specific components (condition SQL, action SQL, schedule, warehouse). This is distinct from sibling describe tools (e.g., describe_table, describe_warehouse) because it explicitly targets alerts and their configuration aspects, though it does not mention the alert name as a parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or why you would choose this over something like snowflake_list_alerts or snowflake_describe_task. The intended usage is only implicit from the name and the resource type, so an agent lacks explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the output ('definition and COPY statement') but does not clarify that this is a read-only operation, any required permissions, or whether side effects are absent. It is not misleading, but it lacks substantive 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, which is economical, but it is under-specified. The sentence earns its place but does not carry enough information to be effective. It is short rather than appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and there are only three parameters, the description is incomplete. It does not explain the output structure beyond 'definition and COPY statement', how database/schema defaults work, or how the pipe name is qualified. An agent would need to inspect the schema or make assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 by explaining parameter meaning. It does not mention any of the three parameters (database, pipe_name, schema_name) or their roles, leaving the agent to infer usage from names alone. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Describe') and resource ('pipe'), and clarifies that it returns the definition and COPY statement. This is clear and distinguishable from other describe tools based on the resource type, though it does not explicitly differentiate from siblings like snowflake_get_pipe_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as snowflake_list_pipes or snowflake_get_pipe_status. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions 'Requires confirmation,' which hints at a safety mechanism but does not disclose that the operation is destructive and irreversible, or that the 'confirm' parameter must be set to true for the drop to execute. It fails to explain what happens if confirm is false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only two sentences and is front-loaded with the core action. However, it is under-specified to the point of omitting critical behavioral and parameter details; it sacrifices necessary information for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with a confirmation flag, the description is notably incomplete. It does not describe the confirmation flow, the effect of the 'confirm' parameter's default, the nature of the output (success/failure), or any side effects. The existence of an output schema is not leveraged to reduce the need for explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 for the lack of parameter documentation. The description does not explain that 'role_name' is the identifier of the role to drop, nor that 'confirm' must be true to complete the operation (with a default of false). It adds essentially no meaning beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Drop a role') and the target resource ('role in Snowflake'), distinguishing it from create/list/describe role tools. However, it does not explicitly mention that dropping is irreversible, which leaves some ambiguity about the operation's severity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., ownership privileges), and no indication of cases where the user might want to avoid dropping a role. The description provides no usage context beyond the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It only states that it executes a data modification statement, which implies mutation but adds no context about transactionality, side effects, permission requirements, or whether the operation is idempotent. The inclusion of CREATE also introduces ambiguity about the actual behavior (DDL vs DML). This is insufficient for a potentially destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the core verb and resource. However, it is terse to the point of being under-specified, which is not ideal, but the conciseness itself is good. The structure is clear and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutational nature and the large set of sibling tools that specialize in specific DDL/DML operations, the description is incomplete. It lacks guidance on when to use this generic tool, what to do about transactions, and how it relates to similar tools. The output schema exists, so return values are covered, but the description itself leaves critical decision-making to the agent without sufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the 'statement' parameter (0% coverage), so the description must compensate. It fails to do so meaningfully – it does not explain what format the statement should take, whether it accepts a full SQL string, any syntax requirements, or examples. The description merely implies that the parameter is the SQL statement, adding little beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb and resource clearly: 'Execute a data modification SQL statement' and lists specific SQL types. However, including 'CREATE' blurs the line between DML and DDL, which conflicts with the 'data modification' framing and may misdirect an agent that should use dedicated DDL tools like snowflake_create_table or snowflake_create_database. The purpose is identifiable but not sharply delimited from those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not say when to use this generic DML tool versus the many specialized sibling tools (e.g., snowflake_query for read-only, snowflake_create_table for DDL). An agent is left to infer that this tool is for ad-hoc DML, but there is no explicit recommendation or warning about overlaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'trigger immediate one-time execution' but doesn't explain whether the call returns immediately, waits for completion, produces side effects, or requires the task to be in a specific state (e.g., suspended). For an execution tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is good for front-loading the core purpose. However, it is under-specified given the tool's complexity and the missing parameter details; conciseness without substance is not appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a task execution tool, the description omits critical context such as return value (even though output schema exists), side effects, and usage scenarios. It fails to inform the agent about the task's execution behavior or how it relates to other task-management tools in the sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters (database, task_name, schema_name). It does not mention any of them, leaving the agent to guess that task_name is the task identifier and that database/schema may be required for context. No additional meaning is provided beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (trigger execution) and resource (a task), and the qualifier 'immediate one-time' distinguishes it from scheduled execution (resume_task). However, it doesn't explicitly name the sibling it differs from, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like snowflake_resume_task or snowflake_execute_dml. It does not mention prerequisites (e.g., task must be enabled) or exclusions (e.g., not for scheduled runs), leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'list' implies a read-only operation, but it does not explicitly state that it is safe, non-mutating, or free of side effects. Unlike the get_calls example, it adds no behavioral context beyond the operation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded with the core purpose. However, it is under-specified rather than appropriately concise. It earns a 3 because it has no unnecessary words and states the primary action, but it omits essential details that would make it more useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema, the absence of usage guidelines and parameter explanations makes it incomplete. The description covers the basic action but fails to provide enough context for an agent to confidently invoke it correctly, especially with three optional parameters and no hints about common patterns or alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 by explaining parameter usage, but it does not. The three parameters (pattern, database, schema_name) are not mentioned at all. While their names are somewhat self-explanatory, the description provides zero guidance on how they affect the query or their formats, leaving the agent to infer from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List OCI image repositories in Snowflake' clearly states the action (list) and target resource (OCI image repositories). It is specific enough to distinguish from most sibling list tools, though it does not explicitly name an alternative like get_calls did, so it loses a point for lacking sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any conditions, prerequisites, or exclusions. An agent cannot tell when this tool is preferable to other listing tools such as list_iceberg_tables or list_tables without additional context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It only states that it lists integrations; it does not disclose whether it requires permissions, the effect of the pattern parameter, or the exact scope of the listing. This is insufficient for a safe and correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, but it is under-specified rather than efficiently complete. It front-loads the resource but omits crucial details, so the brevity compromises usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the sparse description, no annotation coverage, and undocumented parameters, the definition is severely incomplete. Even though an output schema exists, the missing operational context (filtering, permissions, scope) makes it inadequate for reliable tool selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain the parameters. It does not mention 'pattern' at all and only vaguely references integration types via the categories. This fails to clarify how to use integration_type or pattern to filter results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists external integrations and enumerates categories (API, Storage, Notification, Security). This distinguishes it from other list tools that target different resources (tables, schemas, etc.), 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention conditions such as needing to inspect integrations or when a pattern filter is appropriate, leaving the agent without direction on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action without disclosing any behavioral traits such as read-only nature, output format, pagination, or the effect of the pattern parameter. There is no mention of side effects, prerequisites, or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the purpose. It is not verbose and is appropriately brief for a simple listing tool. However, it lacks any additional structural elements that could enhance clarity, earning a high but not perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for an agent to use correctly. It does not explain the pattern parameter, and there is no mention of any filtering behavior or output expectations. While an output schema exists, the description still omits essential context about how the list is produced and how to use the parameter effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the single 'pattern' parameter. The schema shows an optional string with a null default, but there is no description of what pattern filters on (e.g., name pattern). With 0% schema coverage, the description must compensate but fails to do so, leaving the agent to guess the parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'network policies' within the account scope. It is distinct from sibling list_* tools by resource type, though it does not explicitly differentiate from describe_network_policy or list_network_rules. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention describe_network_policy for details or list_network_rules for related resources. The only implied usage is that it lists network policies, with no exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and scope, omitting any details about side effects (e.g., read-only nature), required permissions, output format, or pagination. Listing is likely non-destructive, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, a single sentence without fluff, but it may be overly terse given the missing parameter explanations. It's well-structured but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters with no schema descriptions and no annotations, the description is inadequate. An agent knows the purpose but lacks guidance on how to specify pattern, database, or schema_name, and what the output schema contains. The description does not compensate for the missing structured context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It mentions 'database or schema' which relates to database and schema_name, but pattern is completely unexplained. The description adds minimal semantic value beyond what the schema already provides (which is nothing).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('auto-increment sequences') with a clear scope ('in a database or schema'). It distinguishes itself from sibling list tools like list_tables and list_views by the resource type, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There's no mention of conditions, prerequisites, or exclusions. An agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the operation is to 'list files' (implying read-only), but does not explicitly mention side effects, permissions, pagination, or the nature of the output. The example implies a scoped location but adds no safety or constraint details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste, but it's telegraphic to the point of under-specification. It front-loads the main purpose but omits essential details, making it more an outline than a complete description. It's short but not effectively structured for agent use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters (one undocumented in description), an output schema exists but no behavioral annotations, the description is incomplete. It doesn't explain the optional pattern parameter, constraints on stage_location format, or what the result looks like. For a simple list operation, more context is needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 by explaining parameters. It only provides an example for stage_location and completely ignores the 'pattern' parameter. The description adds no meaning beyond the schema's field names, which is insufficient for the agent to know how to use pattern or understand the expected format of stage_location.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List files') and the resource ('inside a Snowflake stage location'), with an example format. It is specific enough to distinguish from siblings like list_stages (which lists stages) or describe_stage (which describes a stage), though it doesn't explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used to list files in a stage, but provides no explicit guidance on when to use it versus related tools (e.g., list_stages, describe_stage) or any prerequisites. There's no mention of when not to use it or what alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without disclosing the mutation effect, potential permissions required, or the state change from suspended to running. It adds no information beyond the basic operation, leaving the agent unaware of side effects or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no fluff, which is efficient in length. However, it is under-specified to the point of being unhelpful; a concise description should still pack essential information, which it does not. The front-loading is fine but the content is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists so return values need not be explained, the description fails to cover even the basic operational context. With three parameters and zero schema coverage, the description should at least clarify the purpose and naming of these parameters, but it does not. This leaves the tool underspecified for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for parameters, and the description mentions none of them. The required 'task_name' and optional 'database'/'schema_name' are undocumented, forcing the agent to guess their semantics. The description provides no value in clarifying parameter meaning or defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Resume') and resource ('task'), and specifies the target state ('suspended'). It is specific enough to distinguish this from other resume tools (e.g., resume_warehouse, resume_dynamic_table) that target different resource types. However, it is very close to a restatement of the tool name, adding only the word 'suspended'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, any prerequisites, or alternatives. The description does not mention that a task must be suspended before resuming, nor does it reference sibling tools like suspend_task or execute_task. An agent is left without context on the appropriate conditions for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full responsibility for behavioral disclosure. It only states the operation without explaining side effects, reversibility, required permissions, or impact on future task runs. For a mutating operation on a scheduler, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence), which is positive, but it is so minimal that it omits essential context. It is not bloated, but it also does not front-load any useful details beyond the core verb-resource pair. It is appropriately sized but under-informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple state-changing operation, the description is incomplete. It lacks any mention of expected behavior, error conditions, or what the output represents. Even though an output schema exists, the description does not explain the return value or any side effects. The tool's low complexity does not excuse the lack of context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain any of the three parameters (database, task_name, schema_name), nor does it indicate that task_name is required. The description adds no semantic value beyond the schema field names, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Suspend') and the resource ('active scheduled task'). It distinguishes itself from sibling tools like snowflake_resume_task and snowflake_execute_task, though it doesn't explicitly contrast them. It is unambiguous and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites (e.g., the task must exist and be in a resumable state). No mention of context where suspension is appropriate or when to prefer other task-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only states 'Create a new virtual warehouse', which is essentially a restatement of the tool name. It does not mention side effects (permanent creation), required privileges, or failure conditions (e.g., existence conflicts), leaving the agent with no behavioral context beyond the obvious mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It is appropriately concise, but its brevity contributes to incompleteness, which is penalized in other dimensions. For pure conciseness, it earns a high score because every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a create operation with 6 parameters, no annotations, no output schema explanation, and 0% schema parameter coverage, the description is drastically incomplete. An agent would have no idea how to correctly set values like warehouse_size (valid options), what auto_resume/auto_suspend do, or what the if_not_exists flag means. The description fails to provide essential context for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description adds no parameter meaning. The agent is left to infer semantics solely from parameter names (warehouse_name, warehouse_size, auto_resume, etc.) with no explanation of valid values, constraints, or relationships. The description does nothing to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create' and the resource 'virtual warehouse' and specifies the platform 'Snowflake'. It distinguishes itself from sibling tools like list/describe/drop/resume/suspend/resize warehouse through the explicit verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. There is no mention of required permissions, how it differs from other warehouse operations, or when to prefer one of the many sibling warehouse tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only says 'ask a question', implying a query operation, but doesn't state it's read-only, what happens on execution, whether it requires special permissions, or any limitations. This is insufficient for a tool that likely runs analytical queries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficient and to the point. However, it's perhaps too terse, omitting necessary detail, but the wording itself is clear and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose and the presence of an output schema, the description is still incomplete. It doesn't mention prerequisites like needing a semantic model, how to specify it, or any context about the type of questions. An agent would have limited information to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should explain the parameters. It does not describe what 'question' should look like or what 'semantic_model_path' refers to beyond the implicit 'using semantic models'. The description adds almost no parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: ask a natural language analytical question, and specifies the resource: Cortex Analyst semantic models. It differentiates from raw SQL query tools like snowflake_query and general tools like snowflake_cortex_complete by the use of semantic models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention snowflake_query or any other tool, nor does it specify conditions like having a semantic model. An agent would have to infer usage context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects, idempotency (via if_not_exists), persistence, or any permission requirements. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no fluff. It is appropriately brief for a straightforward create operation, though the brevity borders on under-specification rather than effective concision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters with zero schema descriptions, no annotations, and no behavioral notes, the description is incomplete. While an output schema exists, the description does not aid in parameter usage or side-effect expectations, leaving the agent under-equipped.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter information. The agent cannot infer what 'name' constraints exist, how 'data_retention_time_in_days' behaves, or the effect of 'if_not_exists' from the tool's text. The description fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action (create) and resource (database), and the 'in Snowflake' scope confirms the domain. It distinguishes from related tools like clone_database and drop_database by focusing on creation, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as prerequisites (e.g., required privileges) or conditions like using if_not_exists. The agent has no context to decide between this and similar create tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it says nothing about side effects, whether tasks are created suspended by default, idempotency (note the if_not_exists parameter), required permissions, or how the 'scheduled or serverless' distinction affects behavior. The agent cannot anticipate what happens after creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no fluff. It front-loads the core action. However, it is so short that it borders on under-specification; it earns its place but does not leverage the available space to add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that creates a complex object (a Snowflake task) with 7 parameters and an output schema, this description is insufficient. It omits usage context, parameter semantics, and behavioral nuances. While the output schema might cover return values, the description does not help the agent decide whether this is the right tool or how to construct valid arguments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 7 parameters, and the description does not compensate by explaining any of them. It fails to clarify the meaning of task_name, sql_statement, schedule, warehouse, database, schema_name, or if_not_exists. The agent must rely entirely on parameter names, which are ambiguous (e.g., 'schedule' could be a cron string or interval).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the resource (a scheduled or serverless task in Snowflake), which is specific and distinct from task-related siblings like drop, resume, or suspend. It could be more explicit about how it differs from other create tools (e.g., create_table), but the verb+resource combination is clear enough for an agent to understand the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as snowflake_create_alert, snowflake_create_pipe, or even snowflake_execute_task. The description does not state prerequisites (e.g., required privileges), nor does it mention when not to use it. An agent would have to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'describe' implies read-only, but there is no explicit statement about permissions, side effects, or reversibility. It also doesn't mention what the output contains, though an output schema exists. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clean sentence that efficiently states the purpose. It is front-loaded and free of fluff. While it could include more detail, it is appropriately concise for a simple describe operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no schema descriptions, the description is incomplete. It does not explain how database and schema_name affect the lookup, nor does it provide any usage context. The output schema exists, so return values are covered, but parameter usage remains unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain the parameters. It does not state that tag_name is required or how database and schema_name qualify the tag. The description adds no meaning beyond the schema's titles, which is insufficient for proper invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool describes tag properties, allowed values, and comment. It identifies the resource (tag) and action (describe) unambiguously. While it doesn't explicitly differentiate from other describe tools, the tag resource is distinct among siblings, making the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no conditions, and no exclusions. It offers no context about scenarios where a tag description is needed or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavior. It does mention that confirmation is required, which hints at a safety mechanism, but it omits critical implications: whether the drop is permanent, whether it fails without confirmation, whether dependent objects are affected, or what the output/return value indicates. This is minimal beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and to the point, with no fluff. However, conciseness is undermined by under-specification; the two phrases are relevant but omit essential operational details. It is efficiently written but not fully 'earning its place' because critical context is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 4 parameters, zero schema descriptions, no annotations, and no output schema details, the description is grossly insufficient. It fails to mention that the operation is destructive and potentially irreversible, does not explain the confirmation requirement clearly, and leaves the agent ignorant about how to specify the pipe, database, and schema. An agent cannot safely or correctly invoke this tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameter descriptions, so the description must compensate, but it only mentions 'confirmation' without explicitly linking to the 'confirm' parameter or explaining the roles of pipe_name, database, and schema_name. It doesn't clarify that pipe_name is required, nor what database/schema defaults mean. Effectively no parameter semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action 'Drop' and the resource 'Snowpipe', which clearly distinguishes it from siblings like snowflake_create_pipe, snowflake_list_pipes, and snowflake_describe_pipe. The verb-resource pairing is unambiguous and matches the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites (like needing to stop ingestion first), and no exclusions. The only hint is 'Requires confirmation', which is a usage condition rather than a comparative guideline. It doesn't mention any conditions under which dropping a pipe might be inappropriate or what to check beforehand.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get', which implies a read, but it doesn't mention whether an empty result is returned if no tags exist, whether object_domain accepts values beyond TABLE, or what the return structure looks like (though an output schema exists). The description adds no behavioral context beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff or redundancy. It is front-loaded with the verb. However, it is under-specified, which is a completeness issue rather than a conciseness issue; the wording itself is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a required parameter and a parameter with a default, but the description does not explain the domain of object_domain or the expected format of object_name. While an output schema exists (which may document return values), the description still leaves critical input semantics undocumented. For a simple two-parameter tool, this is incomplete but not severely lacking; a 2 reflects the absence of essential parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 for the lack of parameter docs. It does not mention object_name format (e.g., fully qualified name) or object_domain allowed values (e.g., TABLE, VIEW, DATABASE). The description adds zero value beyond the raw property names in the schema, leaving the agent with no semantic guidance for either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and specific resource ('tag key/value assignments') scoped to 'a specific database object'. This distinguishes it from list_tags (which lists all tags) and set_object_tag (which writes), though it doesn't explicitly name those siblings. The purpose is unambiguous and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like snowflake_list_tags or snowflake_set_object_tag. It doesn't mention the required object_name or the object_domain parameter's valid values, nor does it explain any exclusions or preconditions. An agent must infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates the tool returns schema, row count, column types, and sample rows, which implies read-only behavior, but it never explicitly states this or any caveats (e.g., potential cost, limits on sample rows, or behavior for missing tables). The phrase 'in 1 call' adds a performance hint but does not address side effects or operational characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the composite nature and lists the outputs. There is no fluff or redundancy. It earns a high score for conciseness, though it could have included more detail without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which reduces the need to describe return values), the tool has 4 parameters with zero explanation. The description does not address how database and schema_name interact with the current session context, nor does it mention any limitations on sample_rows or error conditions. Given the availability of an output schema, the description should at least cover parameter usage, which it entirely omits. The tool is relatively simple but still incomplete for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It does not mention database, schema_name, table_name, or sample_rows at all. The description adds no value for parameter understanding; an agent cannot infer the meaning or default behavior of these fields (e.g., that database and schema_name default to null, implying current context).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Describe table schema, row count, column types, and preview sample rows in 1 call.' It identifies a specific composite operation with a verb ('describe/preview') and a resource ('table'). However, it does not name or distinguish from sibling tools like snowflake_describe_table or snowflake_sample_table, so it lacks explicit differentiation despite the 'composite recipe' tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention that this combines describe_table and sample_table, nor does it suggest circumstances (e.g., need both schema and sample data) that would favor this composite over separate calls. It is entirely silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only says 'List' which implies read-only, but does not explain any details such as whether the result is fully materialized, if there is pagination, or if the pattern parameter filters results. No side effects or permissions are mentioned. The description is too sparse to be behaviorally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy. It is front-loaded with the action and resource, and there is no waste. However, it is arguably too terse, which hurts other dimensions, but structurally it is appropriately concise for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three optional parameters and zero schema coverage, the description should compensate by explaining how to use them. It does not. While an output schema exists (so return values are covered), the description is incomplete for a tool with this complexity. An agent would need to guess at parameter behavior, making the description insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no information about the parameters (pattern, database, schema_name). The description does not hint at how these parameters influence the listing, their formats, or defaults. Since the schema offers no descriptions and the description adds none, an agent has no clue about parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'network rules' with a scope of 'database or schema.' It is unambiguous about what the tool does. However, it does not differentiate from sibling tools like snowflake_list_network_policies or snowflake_describe_network_rule, which could lead to confusion, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention any prerequisites, context, or exclusions. The description gives no hint that snowflake_describe_network_rule might be better for inspecting a single rule, or that snowflake_list_network_policies is for a different object type. An agent is left to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the scope ('account or database') but does not state what the tool returns (though output schema exists), whether it lists all policies or only those visible to the current role, or any effects of the optional parameters. The description adds minimal behavioral context beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded with the action and resource. It is concise with no fluff, though it sacrifices substance for brevity. Structure is acceptable, but the lack of detail prevents a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description is incomplete. It does not explain the purpose of the optional parameters or how to use them for filtering, nor does it clarify the meaning of 'account or database' (e.g., whether database requires schema). While an output schema exists so return format is not needed, the absence of parameter explanations and usage context leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the three parameters (pattern, database, schema_name). The agent receives no explanation of what these parameters do, how they interact, or what formats are expected. The description fails entirely to compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List'), resource ('password security policies'), and scope ('in the account or database'). It distinguishes from the sibling 'snowflake_describe_password_policy' by the list-versus-describe orientation, but it does not explicitly name the alternative. It is not a tautology and gives a clear action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus snowflake_describe_password_policy or other list tools. It does not mention that 'pattern' filters by name or that database/schema scope the listing. There is no mention of exclusions or alternatives, leaving the agent to infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It only states the action (list) and does not explain result ordering, pagination, required permissions, or how the optional filters affect output. This is a significant gap for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. It contains no filler and is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits parameter semantics and any usage context. For a tool with three optional filtering parameters and zero schema documentation in the description, an agent is left to guess how to scope the listing, making it incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters (pattern, database, schema_name) to compensate. It fails to do so—no hints about what 'pattern' means (e.g., LIKE syntax) or how database/schema scoping works. An agent cannot construct meaningful arguments without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource 'Snowpipes' with scope 'in a database or schema', making the tool's purpose unambiguous. It distinguishes from describe_pipe by indicating enumeration, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus related tools like snowflake_describe_pipe or snowflake_get_pipe_status, nor does it mention prerequisites or typical use cases. An agent gets no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states that it lists secrets, which implies a read-only operation, but it doesn't disclose whether results are scoped by the current database/schema, whether the pattern parameter filters by name, or whether any sensitive data is masked. It also doesn't mention authentication requirements or potential side effects. The lack of any behavioral details beyond the basic listing leaves the agent underinformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly states the tool's purpose. It is front-loaded with the action and resource. While it omits important parameter context, that is a completeness issue rather than a conciseness/structure issue. The sentence is efficient and easy to parse, with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three optional parameters with zero schema descriptions and no annotations, the description is far from complete. It doesn't explain what the pattern parameter does, how to scope with database/schema_name, or what the output (though an output schema exists, it's not visible here) contains. For a listing tool with filtering capabilities, the lack of parameter guidance and usage context makes it inadequate for an agent to call it correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three optional parameters (pattern, database, schema_name) with no descriptions, and schema description coverage is 0%. The description does not mention any of these parameters or their intended meaning. An agent has no idea what 'pattern' refers to (e.g., a regex for secret names?), or how database and schema_name affect the scope of listing. The description fails completely to clarify parameter semantics, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and the resource (security secrets stored in Snowflake), with examples of what counts as secrets (API keys, OAuth credentials). It is distinct from sibling tools like snowflake_describe_secret (which targets a single secret) and other list tools. It does not explicitly name alternatives, but the purpose is unambiguous and specific enough for an agent to know what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, such as snowflake_describe_secret for retrieving a specific secret or snowflake_list_integrations for integration objects. It doesn't mention prerequisites like requiring appropriate privileges or that it might list only secrets in the current context unless database/schema are specified. The agent is left to infer the usage context without any explicit conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List views' implies a read-only operation, but nothing is said about whether it returns metadata, paginates, requires privileges, or how errors are handled. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It gets straight to the point. It could add more detail without becoming verbose, but as it stands, it is appropriately concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema that documents the return structure, the description is too thin for a tool with three optional parameters and no annotations. It doesn't explain how to use database/schema to scope the listing or what pattern does. A simple list tool still benefits from clarifying parameter semantics, so this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — the description adds no meaning to the three parameters (pattern, database, schema_name). It mentions 'database schema' generically but doesn't explain that these optional parameters narrow the scope or that pattern filters by view name. Since the description fails to compensate for the schema's lack of documentation, it scores very low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('views') and specifies the context ('in a database schema'), clearly distinguishing it from siblings that list other objects like tables or schemas. However, it is terse and doesn't mention the optional pattern filtering, so it's not fully explicit about scope. It earns a 4 because the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives (e.g., list_tables, describe_view). It doesn't clarify whether it's for exploration, introspection, or filtering, and doesn't state any prerequisites like needing a specific database/schema context. The description provides no direction for an agent to decide between this and sibling listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It only states the action 'restore... using Time Travel' but omits critical behaviors like the requirement that the database be recently dropped, the reliance on Time Travel retention, potential side effects (e.g., overriding an existing database with the same name? not mentioned), or any permission requirements. This is markedly insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the verb and resource. It is a single sentence with no redundancies. While it is extremely brief, it does not waste words. However, it could include essential prerequisite context while still being concise, so it loses a point for overly sparse structure that sacrifices necessary information for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with one parameter, but the description is incomplete for safe and correct usage. It does not mention the critical condition that the database must have been dropped within the Time Travel retention period, nor does it clarify whether the operation overwrites an existing database or is reversible. Although an output schema exists, the lack of usage context makes the description insufficient for an agent to determine when and how to invoke this tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains a single parameter 'name' with zero description coverage (0%). The tool description does not mention this parameter or explain its meaning, format, or constraints. According to the rubric, when schema coverage is low, the description must compensate, but it does not. Thus, the description adds no value beyond the bare schema, leaving the parameter semantics entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'restore' and the resource 'database', which immediately communicates that this tool undrops a database. It distinguishes from siblings like undrop_schema and undrop_table by explicitly mentioning 'database'. However, it could more explicitly differentiate from drop_database or indicate that it is the counterpart operation; still, the single-sentence purpose is clear without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites such as the database being within Time Travel retention, nor does it exclude cases where the database cannot be restored. There is no explicit 'when to use' or 'when not to use' context, so an agent is left without direction on selection or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals the tool uses time travel (timestamp/statement ID), but omits critical traits: whether it overwrites an existing target, whether it is destructive, what happens if the target exists, required privileges (e.g., AT/BEFORE clause support), and what the composite recipe actually does step-by-step. This is insufficient for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, efficient and front-loaded with the core functionality. However, it is almost too terse: the term 'Composite recipe' is jargon, and the sentence does not structure information in a way that clearly separates the purpose from usage notes. Still, no fluff and good brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is labeled a 'composite recipe' (likely a multi-step operation), the description lacks crucial context: what the recipe entails (e.g., cloning plus a lookup or DDL generation), any prerequisites, and limitations. The output schema exists, so return values are covered, but the absence of behavioral and usage context makes this incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameter semantics. It only hints that at_or_before accepts a timestamp or statement ID, but does not detail formats, defaults, or the relationship between source_table and target_table. Names are self-explanatory but no additional meaning is added, leaving agents to guess about the parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool clones a table with Time Travel support (timestamp or statement ID), which is a specific verb+resource. It implicitly differentiates from snowflake_clone_table by mentioning time travel, but the term 'Composite recipe' is vague and could confuse agents about what the recipe entails. Still, the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus the sibling snowflake_clone_table. It does not mention that this should be used when time travel is needed, nor does it describe any exclusions or alternatives. The phrase 'Composite recipe' implies a convenience wrapper but does not explain the selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of disclosing behavior. It only states it is a 'query' which implies a read operation, but does not explicitly confirm read-only behavior, mention any side effects, auth requirements, rate limits, or error conditions. Minimal disclosure leaves the agent uncertain about side effects or restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is efficiently structured and front-loaded with the core action. However, it is under-specified given the tool's complexity, but for conciseness, it gets a high score because it wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, zero schema description coverage, no annotations, and an existing output schema (which covers return values), the description is grossly inadequate. It fails to explain what a Cortex Search Service index is, how to construct a query, what columns refers to, or what limit does. The agent would be unable to correctly invoke this tool without additional external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 by explaining parameters. It provides no information about service_name, query, limit, or columns, leaving the agent unaware of what values are expected or how they affect the search. The description adds no value beyond the raw schema, which is entirely absent of semantic help.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Query') and resource ('Snowflake Cortex Search Service index'), and adds the scope 'over unstructured text' which differentiates it from other cortex tools like snowflake_cortex_summarize or snowflake_query. It is a concise, unambiguous statement of what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as snowflake_query or other cortex functions. There is no mention of scenarios, prerequisites, or cases where a sibling tool would be more appropriate. The description merely states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it creates a user but does not disclose side effects (e.g., whether existing users are modified, permission requirements), idempotency behavior (the schema shows if_not_exists defaults to true, but this is not mentioned), or what happens if the user already exists. It also omits password requirements and whether a password is optional or needed for authentication setup. This is a significant gap for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded with the action and resource. It is concise and wastes no words. However, its brevity is a symptom of under-specification rather than efficient summarization, but the dimension measures conciseness and structure, and it scores well on those grounds.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no annotations and an output schema (which is not visible to the agent), the description is incomplete. It does not mention prerequisites (e.g., the role and warehouse must exist), default behavior (if_not_exists), or error conditions. It also does not indicate what the returned output represents. Given the complexity of user creation (passwords, roles, warehouses), the description is insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters, but it only mentions 'default role and warehouse' by name, which maps to default_role and default_warehouse. It does not explain comment, password, or if_not_exists semantics. For a create operation, password and if_not_exists are critical for correct invocation. The description adds almost no value beyond the parameter names already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'a new Snowflake user', and mentions the key attributes default role and warehouse. This distinguishes it from list/describe user tools and other create tools (e.g., create_database) by resource type. However, it does not differentiate from create_role or other create operations that also involve users indirectly, nor does it mention the 'if_not_exists' default behavior, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that this is for creating a user specifically, nor does it contrast with list_users, describe_user, or create_role. The description implies usage only by stating what it does, but it provides no context for selection or exclusions. An agent could mistake it for a general user management tool or overlook prerequisite checks (e.g., role/warehouse must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It implies a read-only operation by using 'Describe', and lists the output aspects. However, it doesn't explicitly state that it's read-only, nor does it mention any permissions, side effects, or prerequisites. The description adds some value by specifying the returned fields, but is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and lists the key output attributes. It is not verbose, and every part contributes to conveying what the tool does. It could be slightly more detailed, but it is appropriately sized for the simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 3 parameters and no annotations, the description is incomplete. It does not explain the parameters, nor does it provide usage guidance or behavioral context. The existence of an output schema covers the return values, but the input and selection criteria are missing. For a tool with such low schema coverage, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It does not mention database, table_name, or schema_name at all. The required parameter table_name is not described, and the optional parameters are not discussed. The description focuses on output, not input, providing no help for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Describe' and the resource 'dynamic table', and specifies four specific attributes (definition, target lag, warehouse, query text) that will be returned. This distinguishes it from generic describe_table and list_dynamic_tables, though it doesn't explicitly name a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like describe_table or list_dynamic_tables. The name implies it's for dynamic tables, but the description doesn't state that this is the right tool for describing dynamic tables specifically, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what information is returned (mode, type, value list) but does not mention error conditions, required privileges, or whether the operation is read-only. For a describe operation, this is minimal but insufficiently rich—it does not warn about potential failures or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that lists the returned attributes. It is front-loaded with the verb and resource, and every word adds information. No fluff or redundancy, though it could be slightly more structured with parameter hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (which relieves the description of explaining return values), the description lacks critical context for calling the tool correctly: how to specify the network rule (parameters), any requirements, and when to use this over sibling tools. For a tool with no annotations and 0% schema coverage, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameters. It says 'of a network rule' but does not indicate that rule_name, database, or schema_name are needed to identify the rule. The agent must infer from the schema structure alone, which is a gap given that the description could clarify the parameter roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Describe') and resource ('network rule'), and enumerates the attributes returned (mode, type, value list). This distinguishes it from other describe_* tools by naming the exact object type. However, it does not explicitly differentiate from closely related tools like describe_network_policy, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or cases where a different describe tool (e.g., describe_network_policy) would be more appropriate. Usage context is entirely absent, relying on the agent to infer from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It reveals the output fields but does not mention side effects, read-only status, or required permissions, which is a notable gap for a describe operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the purpose and key outputs. It is efficient with no redundant words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, the description lacks critical context such as when to use it, parameter formatting, and safety implications. For a simple describe tool, it should at least mention the relationship to describe_function or provide usage hints, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the parameters. The required procedure_signature is not explained in terms of format or constraints, and database and schema_name are left entirely ambiguous. The description fails to compensate for the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (procedure) and the specific information returned (signature, return type, language, definition body). It is not a tautology and distinguishes from similar tools like describe_function by explicitly stating 'procedure'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as describe_function, list_procedures, or how to construct the required procedure_signature. The description only states what it does without any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of disclosing behavioral traits. It states the tool drops a stream, implying a destructive action, but does not clarify permanence, reversibility (e.g., absence of undrop_stream), side effects on dependent objects, or that confirm=false results in no action. 'Requires confirmation' is vague—it does not explicitly say the drop is skipped unless confirm is set to true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise—two short sentences with no filler. It front-loads the action and the key requirement (confirmation). While terse, every word serves a purpose, and it avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with a confirmation flag and optional scoping parameters, the description is inadequate. It does not explain the behavior of confirm (whether false means no-op), the role of database and schema_name, or any consequences. An output schema exists but the tool's side effects and failure modes remain unclear. The description leaves too much to inference for an agent to invoke it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It only addresses confirm implicitly via 'Requires confirmation.' The database and schema_name parameters are optional and default to null, but the description provides no guidance on their purpose or how they scope the drop. The stream_name is obvious but not explicitly described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Drop a stream.' This clearly indicates the tool's purpose. While there are many drop_* siblings, 'stream' uniquely identifies the target resource, so an agent can distinguish it from drop_table or drop_database without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions 'Requires confirmation' which hints at the confirm parameter but provides no context on when to use this tool versus alternatives, prerequisites, or typical scenarios. It lacks explicit guidance on when this tool is appropriate, and does not mention that confirmation is mandatory for the drop to execute.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Requires confirmation,' which hints at a confirm parameter but does not explain the exact behavior (e.g., when confirm is false, the drop is not executed). It omits important traits like whether the action is destructive and irreversible, what permissions might be needed, or any side effects. For a destructive operation, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with two short sentences and no redundant words. The core action is front-loaded. However, its brevity omits critical operational details, which reduces its effectiveness, but it is still efficiently written and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, parameter descriptions, and an unclear confirmation mechanism, the description is grossly incomplete. It does not explain how to properly set the confirm parameter, the consequences of dropping a warehouse, or any safety caveats. An agent would struggle to call this tool correctly and safely. The presence of an output schema does not remedy the missing usage and safety information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 by explaining the parameters. However, it fails to explain warehouse_name (which is required) or confirm (which controls execution). The description adds no meaning beyond the schema's field titles, leaving the agent to guess the role of the confirm flag and the format of warehouse_name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Drop a virtual warehouse' clearly states the specific action (drop) and resource (virtual warehouse), distinguishing it from other drop tools for different resources (e.g., drop_database, drop_table). The added 'Requires confirmation' hints at a required confirm step, further clarifying the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus other drop tools, nor any context about prerequisites or alternatives. The description does not mention when it is appropriate to drop a warehouse, what conditions must be met, or that undrop might be available (though no undrop_warehouse exists in siblings). This leaves usage entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It indicates a write operation (creating files in a stage) but omits side effects such as overwrite behavior, idempotency, warehouse requirements, or whether the stage must already exist. The 'composite recipe' label suggests additional internal steps but doesn't describe what happens behind the scenes, leaving behavioral traits ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is not bloated, but it is under-specified. It does not prioritize critical usage information (such as parameters or prerequisites), and the opening 'Composite recipe' is somewhat vague. It's an acceptable length but lacks structure that would make the key details stand out.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which presumably covers return values), the description fails to address the tool's complexity: it has four parameters, two required, yet none are explained. It also lacks context about the composite workflow, what happens to existing files, or how the query is executed. This leaves an agent under-informed for a tool that appears to combine multiple steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It mentions none of them: neither the query content nor the stage_location format, nor the header/file_format options. The agent is left without any semantic guidance beyond the parameter names themselves, which is inadequate for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: unload query results to a stage, and specifies the output formats (Parquet or CSV). This distinguishes it from siblings like snowflake_query (which executes queries but doesn't export) and snowflake_execute_dml (which modifies data). The verb 'unload' and resource 'query results to a stage' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., an existing stage, warehouse availability), when to prefer it over snowflake_query or stage-management tools, or any context for choosing between Parquet and CSV. The phrase 'composite recipe' hints at a multi-step process but never explains the steps or the conditions that warrant its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It mentions 'exact' DDL, implying a read operation, but does not disclose anything about error conditions, permissions, or the format of the returned DDL. This is minimal coverage for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one succinct sentence with no filler. It is appropriately front-loaded with the core action and resource, though it lacks depth for a read-only tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present), the description still misses key context: usage differentiation, parameter format, and behavioral expectations. It is not complete enough for an agent to call correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameter usage. It does not mention 'database_name' at all, leaving the agent to guess whether it expects a plain name or a fully qualified identifier. The description adds no value beyond the schema's bare field name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Retrieve') and resource ('CREATE DATABASE DDL definition'), making the tool's purpose unambiguous. While it doesn't explicitly differentiate from sibling tools like 'get_table_ddl', the resource scope is distinct enough that an agent can infer it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'describe_database' or 'get_table_ddl'. The description only states what it does, not when to choose it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the full burden. It discloses only the scope (account/user) but says nothing about default behavior, the meaning of 'recent', maximum lookback, or whether any permissions are needed. This is minimal behavioral disclosure for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the verb and resource. There is no fluff or redundancy; every word contributes to the core message.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description omits crucial operational details: the meaning and effect of 'limit', the recency window, and any constraints like warehouse requirements. It is too sparse for an agent to invoke confidently without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the single 'limit' parameter at all. The agent must guess its meaning from the parameter name alone, which is particularly risky given the default value of 20 is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (retrieve) and the resource (recent query execution history), with a specific scope (current account/user). It is not a tautology and is distinct enough from general query tools, though it doesn't explicitly contrast with related siblings like snowflake_get_query_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many query-related siblings (e.g., snowflake_get_query_plan, snowflake_get_warehouse_load_history), the agent is left to infer the appropriate context from the vague phrase 'recent query execution history'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states a listing action, which implies read-only, but it does not explicitly confirm no side effects, nor does it mention any permissions, rate limits, or output details. The description adds no behavioral context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It is appropriately front-loaded with the core purpose and is as concise as possible while remaining informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no required parameters, no nested objects, and has an output schema), but the description gives minimal context. It omits any guidance on filtering (e.g., pattern semantics, database/schema scoping) or the nature of the returned data. While the output schema covers return format, the lack of parameter explanation leaves the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no information about the parameters (pattern, database, schema_name). It does not explain their purpose, format, or relationships. Since the description must compensate for low coverage, this is a major gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('container services') with a specific scope ('running on SPCS compute pools'). This unambiguously distinguishes it from sibling list tools (e.g., snowflake_list_tables, snowflake_list_compute_pools) without needing further context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or when another listing tool would be preferred. The purpose is implied but no usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'List', implying read-only, but does not disclose any additional behavior such as pagination, filtering semantics, or return format. This is insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently states the core purpose. It is front-loaded and free of redundancy. However, it is so terse that it sacrifices critical information, but for conciseness itself it earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the presence of an output schema and lack of annotations, the description is too sparse. It does not explain the parameters, usage context, or any behavioral traits. An agent would not know how to correctly call this tool beyond inferring it lists streams.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'in a database or schema', which hints at the database and schema_name parameters, but does not explain the pattern parameter at all. With 0% schema description coverage, the description fails to adequately compensate for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List') and resource ('table/view streams') within a scope ('in a database or schema'), giving a clear purpose. However, it does not differentiate from sibling list tools like snowflake_list_tables or snowflake_list_views, so it loses a point for lack of sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of when it is more appropriate than other list tools, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It states that scheduling and lag monitoring are resumed, but it does not explain side effects (e.g., whether it starts data refresh automatically), prerequisites (e.g., required permissions), or what happens if the table is already running. For a mutation operation, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. It front-loads the core action and resource. Every word contributes to the meaning, and it is appropriately sized for the task.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with three parameters, no annotation coverage, and minimal description, it is not complete. It lacks guidance on when to call it, what state the table must be in, and what happens after execution. The existence of an output schema reduces the need to describe return values, but the absence of usage context and side effects leaves the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description provides no information about the three parameters (database, table_name, schema_name). An agent cannot determine from the description which parameters are required, how they are used, or how they relate to the target dynamic table. The description entirely fails to compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Resume scheduling and lag monitoring') on a specific resource ('a dynamic table'). It distinguishes itself from siblings like snowflake_suspend_dynamic_table (which suspends) and snowflake_refresh_dynamic_table (which refreshes data). It could be slightly more explicit about the object being resumed, but the verb+resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not state that it should be used after a suspension, nor does it mention any prerequisites or conditions. Usage context is only implied by the word 'resume' – an agent must infer that the table is currently suspended. No alternative or exclusionary guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits itself. It only states the bare action, missing important context like whether the operation is idempotent, what happens if the warehouse is already running, or any permission requirements. This is a state-changing operation with minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no waste. However, it lacks structure that would help an agent, such as any mention of prerequisites or outcomes. It is not verbose but is minimal to the point of being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one parameter, no nested objects), a short description might suffice, but this one lacks essential context like return behavior or failure conditions. The presence of an output schema partially compensates, but the description still feels incomplete for a state-changing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter warehouse_name, and the description adds no meaning beyond the parameter's name. The description neither explains expected format, examples, or constraints, leaving the agent with only the field name as guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Resume' on the resource 'virtual warehouse', which is specific and unambiguous. It distinguishes itself from siblings like snowflake_suspend_warehouse or snowflake_resize_warehouse by naming the exact operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use it, or any conditions that would make this tool the correct choice. An agent is left to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a mutation (creation) but does not disclose whether it is idempotent, what happens if an alert with the same name exists, whether specific permissions are required, or any side effects. This is a significant gap for a create operation with multiple parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with every word adding value. The verb and resource are front-loaded, and it highlights the core components. There is no filler, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters (5 required), no annotations, and no parameter descriptions, a one-line summary is inadequate. The agent lacks details on how to formulate condition SQL and action SQL, what schedule syntax is expected, and how the database/schema context is used. The output schema exists, so return format is not a gap, but the input requirements for successful invocation are underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It names three parameters (schedule, condition_sql, action_sql) but provides no syntax, format, or examples. It entirely ignores alert_name, warehouse_name, and the optional comment/database/schema_name. The agent gets only a vague notion that these exist, with no guidance on how to construct them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb 'Create' and resource 'alert', and lists the key components (schedule, condition SQL, action SQL). This distinguishes it from other alert operations like resume/suspend/drop, and also from other resource creation tools. However, it doesn't explicitly differentiate from other create tools (e.g., create_database) beyond the resource name, and it omits mention of alert_name and warehouse_name, which are also core to the tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a warehouse), when not to use it, or how it relates to sibling tools like list_alerts, describe_alert, or resume_alert. The agent is left to infer that this is for creating a new alert, but there is no explicit context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It states 'Describe' which implies a read-only operation, but does not explicitly state that no modifications occur, that it may require special privileges, or how it handles nonexistent policies. This leaves behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose. It is not verbose and contains no filler, though it could be slightly expanded to cover parameters without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 0% schema coverage and no annotations, the description is incomplete. It does not explain how to specify the policy (parameter semantics), when to use the tool, or any behavioral caveats. An agent would struggle to call it correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does not mention database, schema_name, or policy_name at all—what they mean, how they are used, or that policy_name is required. The agent gets no semantic help beyond the raw parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Describe' and the specific resource 'password policy constraints' with examples (min length, lockout time, history, age). This clearly distinguishes it from sibling tools like list_password_policies, which lists policies rather than describing a single one's constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that it requires a specific policy_name, nor does it suggest using list_password_policies to first discover policies. The agent is left to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It implies a read-only operation ('Describe') but doesn't state permissions required, side effects (likely none), or any other behavioral traits. It adds little beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with zero filler. It is front-loaded with the verb and resource, making it highly concise. However, brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values need not be explained, but the description is still insufficient for an agent to determine correct usage, parameter roles, or when to invoke this tool among many siblings. It lacks essential usage context and parameter elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions what is described (definition, schedule, etc.) but does not clarify the meaning of database, schema_name, or task_name beyond what the schema names imply. There is no added semantic value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action 'Describe' on task-related details (definition, schedule, warehouse, definition SQL), making the purpose clear. It does not explicitly differentiate from sibling describe tools (e.g., describe_warehouse), but the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other describe tools or alternatives. The description gives no context about typical scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It does mention 'Requires confirmation,' which signals that the operation is destructive and needs an explicit confirm flag. However, it does not describe other important behaviors: what happens to the stage, whether the action is reversible, whether it checks for existing objects, or error handling. The confirmation note is a positive addition, but the description is too sparse to fully convey the destructive nature and operational nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two sentences) and front-loaded with the core action. It has no filler. However, it is so terse that it omits essential details. While every sentence earns its place, the overall brevity results in under-specification. It is appropriately concise but not sufficiently informative, so a neutral score of 3 is warranted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with four parameters and no schema descriptions, the description is incomplete. It does not explain the confirmation flow (e.g., that confirm must be set to true, or what happens if it is false), the role of the optional database and schema_name, or any prerequisites. Even though an output schema exists, the description fails to provide enough context for an agent to invoke the tool correctly. The presence of a confirm parameter is hinted but not clarified, and the parameter semantics are largely missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no meaning for any parameter. The description only mentions 'Requires confirmation,' which maps to the confirm boolean, but it does not explain the roles of stage_name, database, or schema_name. The description does not compensate for the missing schema documentation. An agent would struggle to know how to populate the optional database and schema_name fields or how the confirm flag interacts with the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action specifically: 'Drop a stage in Snowflake.' It identifies the verb (drop) and the resource (stage) with platform context. The second sentence 'Requires confirmation' hints at the confirm parameter, adding operational detail. It does not explicitly differentiate from sibling drop tools (e.g., drop_table, drop_database), but the resource descriptor makes it clear enough. Slightly below a 5 because it lacks any details that distinguish it from closely related siblings beyond the object type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., stage existence, permissions), scenarios where it should be avoided, or comparison to other drop tools. The only usage hint is 'Requires confirmation,' which is more about the parameter than about when to invoke the tool. The description fails to help an agent decide when to choose this over other snowflake_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the operation and gives no details about read-only nature, error conditions, prerequisites (e.g., valid database/schema), or any effects. This is minimal, though not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action and resource. There is no wasted wording, and it is appropriately short for a simple listing operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (which may cover return format), the description lacks essential usage context: it does not specify parameter optionality, how to list all tags versus filtered subsets, or how this tool relates to other tag operations. For an agent to use it correctly, significant inference is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for explaining parameters. It vaguely references 'database or schema' but does not clarify that these are optional filters, nor does it explain the 'pattern' parameter at all. The description fails to provide sufficient semantic meaning for any of the three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (List), a resource (object tags), and a scope (in a database or schema). It distinguishes from related tag tools (describe_tag, set_object_tag) by the 'list' verb, though it does not explicitly name alternatives. The purpose is unambiguous and easy to understand.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like snowflake_describe_tag or snowflake_set_object_tag. The description does not mention any conditions, prerequisites, or scenarios where this tool is appropriate, leaving the agent to infer usage solely from the verb 'list'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It says 'composite recipe' implying multiple operations, but doesn't mention read-only nature, potential cost, or side effects. Minimal behavioral info beyond the outcome.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no fluff, front-loaded with 'Composite recipe'. Concise but somewhat terse, lacking necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a composite profiling tool with no annotations and 0% schema coverage, the description is too sparse. It doesn't explain parameter optionality, any prerequisites, or return value expectations, leaving agent uncertain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description provides no parameter context. It doesn't explain database, schema_name, or table_name beyond their names, offering no added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it profiles table metadata, row count, and column inventory, which is a specific composite verb+resource. It differentiates from siblings like describe_table by mentioning row count and column inventory, but doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives. The 'composite recipe' hints it's a bundle, but it doesn't state when to prefer it over describe_table or sample_table. Usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation and states the default row count, but reveals nothing about sampling method (random vs. ordered), whether rows are deterministic, row limits, or what the returned shape looks like. For an unannotated tool this is a thin disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the core action and default behavior are stated first. It borders on under-specification rather than genuine conciseness, but the prose is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, which helps with return values. However, with 0% parameter schema coverage and no annotations, the description should explain table_name qualification and sampling semantics. It is minimally adequate for a straightforward preview tool but leaves the key parameter undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only reaffirms the sample_size default of 10. It does not clarify what table_name should be (e.g., fully qualified vs. schema-qualified) or any bounds/behavior for sample_size. The description adds almost nothing beyond what the schema already exposes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Preview') with a clear resource ('sample rows from a table') and states the default of 10 rows. It conveys the read-only intent and differentiates from data-definition siblings, though it doesn't explicitly distinguish itself from similar read tools like snowflake_query or snowflake_inspect_table_with_sample.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like snowflake_query or snowflake_inspect_table_with_sample. There are no exclusions, no recommended context, and no hints about when sampling is preferable to a full query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states the action (generate embeddings) but doesn't disclose whether this is read-only, any side effects, authentication needs, or rate limits. It also doesn't mention the response format or any potential failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and direct, with the key purpose front-loaded. No unnecessary words or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown), so return values are covered. However, the description doesn't provide essential context like input constraints, model options, or limitations. For a 2-parameter tool, more guidance is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It mentions 'for text' which maps to the text parameter, but gives no information about the model parameter, its default, or options. The description adds only marginal meaning beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates 768-dimensional dense vector embeddings for text using Snowflake Cortex AI. This distinguishes it from sibling cortex functions like completion or summarization, and from other snowflake tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like other Cortex functions or other embedding tools. It doesn't mention any use cases or conditions that would make this tool the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the high-level action ('extract direct answer') without explaining what happens if no answer is found, whether the output is a single sentence or a span, or any limitations. There is no mention of output format, error behavior, or how the tool handles ambiguous questions. This is a significant gap for a tool with no structured behavioral hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler words. However, it is almost too terse, omitting crucial details that a slightly longer description could include without sacrificing brevity. While it is efficient, the lack of substantive content makes it merely adequate rather than exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the existence of many sibling Cortex tools, the description is incomplete. It doesn't provide usage guidance, parameter explanations, or behavioral expectations. Although an output schema exists (which may clarify return structure), the description alone doesn't equip an agent to correctly distinguish this tool from snowflake_cortex_search or snowflake_cortex_summarize, and it fails to address how the answer is extracted or formatted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It implicitly references the two inputs: 'source document/text' (source_text) and 'question' (question), but does not explicitly map them or explain their roles or expected formats. For example, it doesn't clarify that source_text can be a long passage or that question should be a well-formed natural language query. This is only a partial hint and not sufficient for a tool with undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Extract direct answer to a question from unstructured source document/text.' This clearly identifies the tool as extractive question-answering, distinct from the sibling Cortex tools (summarize, sentiment, translate) by its focus on returning a direct answer rather than a transformation. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention 'use this when you need a direct answer rather than a summary' or compare with siblings like snowflake_cortex_summarize or snowflake_cortex_search. The context is implied but not stated, leaving an agent to infer the appropriate use case from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the creation action but does not disclose side effects, required permissions, idempotency (though if_not_exists default may hint), or the nature of a CDC stream. There is no mention of storage impact or that the stream captures changes. This is minimal and insufficient given the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, front-loading the core action. It is appropriately concise for a simple create operation, though it under-specifies details. There is no wasted text, and the structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, and an output schema, the description is incomplete. It does not explain the append_only option, the if_not_exists behavior, or the requirement for an existing table/view. It also fails to describe what a CDC stream is or what happens after creation, leaving an agent without sufficient context to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain any parameters; it only mentions the action and target. While parameter names like stream_name and on_table are somewhat self-explanatory, the meaning of append_only and if_not_exists (which have defaults but no descriptions) is not clarified. The description adds no value beyond the schema's structural information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: 'Create a CDC stream on a table or view.' It uses a specific verb (create) and resource (CDC stream) with a target (table or view), distinguishing it from other create tools like create_table or create_database. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as snowflake_list_streams, snowflake_describe_stream, or snowflake_drop_stream. It does not mention prerequisites (e.g., existing table or view) or contexts where creating a stream is appropriate. The description simply states the action without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. The verb 'describe' implies a read-only operation, and the listed aspects (schema, catalog integration, external volume) indicate inspection, not mutation. However, it does not explicitly state that it is non-destructive or mention any prerequisites like permissions. Given that 'describe' is inherently safe, a score of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that lists exactly what the tool reports. It is front-loaded with the key verb and resource, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, only one of which is required, the description is under-specified. It does not explain how database and schema_name are used or whether they default to the current context. While the output schema exists, the input semantics are unclear, making successful invocation uncertain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the parameters (database, schema_name, table_name). The agent is left to infer that database and schema_name are optional and that table_name is required, but no guidance is given on how these combine to identify the table (e.g., fully qualified name resolution). This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'describe' with a clear resource 'Iceberg table' and lists the aspects covered (schema, catalog integration, external volume). This distinguishes it from generic table operations like snowflake_describe_table, though it doesn't explicitly state 'use only for Iceberg tables'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for Iceberg tables specifically or when to choose it over snowflake_describe_table. No exclusions or context for selection are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the tool describes user properties, but does not mention whether it is read-only, idempotent, requires specific privileges, or how it behaves for non-existent users. The read-only nature is implied by 'describe' but not explicitly disclosed, and there is no information about error handling or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. It avoids verbosity and includes the key properties. There is no wasted text, though it lacks structured formatting like bullet points or context sections. Overall, it is efficient and appropriately sized for a simple describe tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are defined, partially relieving the description. The description lists key properties covered, which is helpful. However, it does not mention error conditions, required privileges, or any behavioral caveats. For a tool with no annotations and a single input, this is a minimal but acceptable level of completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for the undocumented 'user_name' parameter. It does not mention the parameter at all, nor does it explain how the parameter is used, its format, or any constraints. The only information comes from the schema's 'User Name' title, which provides minimal meaning. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('describe') and resource ('user'), and lists the exact properties covered (email, disabled status, default warehouse/role). This clearly distinguishes it from sibling tools like snowflake_list_users (which lists users) and snowflake_describe_role (which describes a role). The purpose is unambiguous and immediately understood.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or scenarios where another tool (like snowflake_list_grants_to_user or snowflake_describe_role) would be more appropriate. Usage is only implied by the tool's name and typical describe semantics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does mention 'Requires confirmation,' which alerts the agent that confirmation input is needed, but it does not elaborate on the destructive and potentially irreversible nature of the operation, authorization requirements, or side effects. The statement is minimal and leaves significant behavioral context unstated for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the core purpose in the first sentence. It is concise with no filler or redundancy, which is ideal for a simple tool. However, conciseness is achieved at the expense of necessary detail, but dimension 5 rewards conciseness and structure separately from completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, 0% schema description coverage, and no annotations, the description is far from sufficient for an agent to invoke correctly. It does not explain how to construct a valid call, what the confirmation flag does precisely, or whether database/schema_name are optional scope qualifiers. The output schema exists, but the description still leaves critical usage information missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate by explaining parameters. It does not describe what 'confirm' does (beyond a vague 'Requires confirmation'), nor does it explain the role of 'database' and 'schema_name' in qualifying the alert. The description adds no meaning beyond the raw schema; an agent cannot infer correct usage for the optional parameters or the exact confirmation logic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action and resource: 'Drop an alert in Snowflake.' This is a distinct operation from other drop tools in the sibling list (e.g., drop_table, drop_database) because it names the alert resource explicitly. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as suspend_alert, resume_alert, or create_alert. It does not mention conditions for using it, nor any exclusions. The only hint is 'Requires confirmation,' which is more behavioral than usage guidance. No explicit 'when to use' or 'when not to use' context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the disclosure burden. It notes the confirmation requirement, which is useful behavioral context, but doesn't mention that the operation is irreversible, its permission needs, or what happens on failure. Since 'drop' implies permanent deletion, some of this is inferable, but the description leaves destructive consequences undisclosed to the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence that front-loads the action and resource. No filler words, though the brevity comes at the cost of behavioral and parameter detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with zero annotation coverage and a bool guard parameter, this definition is thin. It lacks the confirmation semantics, irreversibility warning, and prerequisites that an agent needs to call it safely and correctly. The presence of an output schema doesn't offset the missing guidance around the confirm flag.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only loosely references the confirm parameter ('confirmation flag') without naming how to satisfy it (setting confirm=true) or explaining the table_name format (e.g., database.schema.table). The agent gets almost no added meaning beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb+resource ('Drop a table in Snowflake') that distinguishes it from sibling drop operations on databases, schemas, streams, and stages. It's unambiguous which object type is dropped, though it doesn't explicitly contrast with the related destructive truncate_table sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions that a confirmation flag is required, but gives no guidance on when to use this tool versus the destructive siblings (truncate_table, undrop_table) or any prerequisites. No exclusions or conditions are provided for an irreversible operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions what is returned but does not state that the operation is read-only, whether special permissions are needed, or how errors are handled. It does not disclose side effects or constraints beyond the basic status retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It front-loads the purpose and the key returned data, making it immediately scannable. This is appropriately concise for a status-check tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of a status-check operation and the presence of an output schema, the description is adequate for basic usage. However, it lacks edge-case handling (e.g., pipe not found), required permissions, and any linkage to related pipe-management tools. It does not cover usage context beyond the bare query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, but it mentions none of the parameters (pipe_name, database, schema_name) or their meaning. It does not explain how these parameters are used or how they affect the query. The description adds no value beyond the schema field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('Snowpipe'), and the type of information returned ('pending file count, last ingested timestamp'). It clearly distinguishes from sibling tools like 'snowflake_describe_pipe' (likely metadata) and 'snowflake_list_pipes' (listing), though it doesn't explicitly name them for contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as snowflake_describe_pipe or snowflake_list_pipes. The description implies a specific use case but does not provide explicit conditions, exclusions, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It does mention the scope ('active database or schema') but lacks details on read-only nature, permissions, pagination, or any side effects. The description is minimal and does not contradict annotations (since none exist), but it under-discloses important traits for safe and correct usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the action and resource. It avoids unnecessary verbosity and is easy to parse. While it could slightly expand on parameters without losing conciseness, its brevity is a strength and earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three optional parameters and context-dependent scope, the description is incomplete. It doesn't explain how to override the active database/schema, what pattern filters, or any prerequisites (like an active context). The existence of an output schema doesn't compensate for missing input semantics. An agent would struggle to call this tool correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It hints at database and schema_name via 'active database or schema' but does not clarify that these override the context. The pattern parameter is entirely unexplained. With three optional parameters and zero schema coverage, the description fails to compensate, leaving agents without critical semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the specific resource ('internal and external stages'), scoped to the active database or schema. It unambiguously differentiates from siblings like snowflake_list_stage_files (files within a stage) and snowflake_describe_stage (specific stage details), leaving no doubt about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as snowflake_list_stage_files or snowflake_describe_stage. It also omits how to override the active database/schema via the database and schema_name parameters, and what the pattern parameter is for. Agents are left to infer usage from the name and context, which is inadequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It only says it lists Streamlit applications, but does not disclose whether the operation is read-only, whether it errors if filters are misapplied, whether it uses the current session context, or what the response format is. For a list operation, the behavior is predictable, but crucial scoping details (e.g., does it list all Streamlits account-wide or must database/schema be provided?) are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It delivers the core purpose in eight words. This is appropriately concise and well-structured for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of three optional parameters and zero schema coverage, the description is not complete enough for an agent to call the tool correctly. It does not explain how to filter, whether the parameters are globally applicable, or what the typical use case is. While the output schema may define return structure, the input semantics remain opaque, leaving a significant gap in the agent's ability to construct a valid call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides only parameter names (pattern, database, schema_name) without any explanatory text. The description does not mention these parameters or their meanings, so the agent has no way to know what 'pattern' filters on, whether database/schema are required, or what values are expected. The description completely fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('Streamlit applications') with the context 'hosted in Snowflake'. It clearly distinguishes the tool from siblings like snowflake_list_tables or snowflake_list_sequences, and pairs with snowflake_describe_streamlit as the listing counterpart. The purpose is unambiguous and cannot be mistaken for a different tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that snowflake_describe_streamlit could be used for details, nor does it explain when to supply the optional database/schema_name parameters or whether the tool can list across all scopes. The agent is left to infer usage from the name alone, which is insufficient for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the output includes login status and default roles, but does not clarify whether the optional pattern filters results, what permissions are required, or any potential side effects. Since this is a read operation, the lack of explicit safety indication is acceptable, but the pattern behavior is undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that conveys the core purpose with no filler. It is appropriately sized for a simple list operation and front-loads the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (so return format is covered), the description leaves the sole parameter 'pattern' completely unexplained. For a tool with one optional parameter, this is a significant gap. The agent cannot determine how to filter or whether the parameter is a LIKE pattern, exact name, etc.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'pattern' with no description (0% coverage), and the description does not mention it at all. An agent has no idea what format or semantics to use for the filter. The description fails to compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('users in the Snowflake account') and adds output details ('with login status and default roles'). It clearly distinguishes this from sibling tools like snowflake_describe_user (single user) and snowflake_list_roles (roles), making the intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention that this lists all users in the account, nor does it contrast with snowflake_describe_user for individual lookups. An agent would have to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but omits any consequences: whether the refresh blocks execution, requires specific privileges, affects ongoing operations, or incurs costs. For a mutating operation, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action directly with no filler. It is efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, the description is too thin. It does not mention prerequisites, potential failure modes, or the meaning of the output schema (which exists but is not described). An agent calling this tool would lack critical context about what constitutes a successful refresh or what side effects to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It does not: table_name is required, database and schema_name are optional with null defaults, but their purpose in locating the dynamic table is unmentioned. The description adds zero value over the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Trigger an immediate manual refresh') and the target resource ('a dynamic table'). It is specific and distinguishable from sibling tools like snowflake_resume_dynamic_table or snowflake_suspend_dynamic_table, which handle lifecycle states rather than refresh operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios such as preferring refresh on schedule, conditions under which refresh is unnecessary, or contrast with resume/suspend operations. An agent has to infer when 'immediate manual refresh' is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'change' implying a mutation, but it does not disclose side effects (e.g., impact on running queries, cost implications, whether the operation is synchronous), prerequisites, or reversibility. This is a significant gap for a mutation tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It directly states the action and the relevant value domain. It is appropriately sized for the minimal information it provides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which covers return format), the description is too sparse. It lacks any mention of prerequisites (e.g., warehouse existence), side effects, or failure conditions. For a tool with two required parameters and no annotations, an agent would need more context to invoke it correctly and understand consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning to the 'size' parameter by listing valid values (XSMALL, SMALL, MEDIUM, etc.), but it says nothing about 'warehouse_name' (e.g., that it must refer to an existing warehouse). This partial compensation warrants a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'change' and the resource 'warehouse compute size', and even lists valid size options. It is not a tautology. However, it does not differentiate from the sibling tool 'snowflake_warehouse_scale_and_execute' or other warehouse management tools, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention any context such as when resizing is appropriate, any prerequisites (e.g., warehouse must exist), or exclusions. The description is purely descriptive with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action 'Resume' which implies a state mutation, but gives no information about side effects, costs, idempotency, what happens if the pool is already running, or the success/failure response. The agent has limited insight into the operation's behavior beyond the simple verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded with the key verb and object. It is highly efficient with no wasted words or filler. However, it may be too terse, sacrificing necessary detail for brevity, but as a standalone statement it is admirably concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing operation with no annotations and minimal description, the context is incomplete. The agent lacks guidance on state prerequisites, post-condition expectations, or handling of edge cases. While an output schema exists, the description itself does not explain what a successful resume entails or any caveats, making it insufficient for confident invocation without additional investigation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for the single required parameter 'pool_name'. The description does not elaborate on the parameter's meaning, format, or constraints beyond the term 'pool' which mirrors the resource name. Since the schema provides no documentation, the description should compensate, but it fails to add any semantic value beyond what the parameter name itself offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Resume') and the target resource ('SPCS compute pool'), with the condition 'idle or suspended' adding specificity. It distinguishes from related siblings like suspend, describe, and list compute pools, though it doesn't explicitly call out alternatives. A clear, direct statement of what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a pool is idle or suspended, giving some context. However, it provides no explicit guidance on when not to use it (e.g., already running), no mention of prerequisites such as checking state, and no naming of alternatives or error conditions. The usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the effect (suspending refresh and lag evaluation) but does not mention side effects, reversibility, permissions, or impact on data. For a mutation tool, this is incomplete and leaves significant behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that front-loads the core action. There is no waste, and the description is efficiently structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and the existence of an output schema, the description should provide more context about prerequisites, what happens after suspension, and how to reverse the operation. It only covers the basic action, leaving gaps that could lead to incorrect usage for a mutation tool. The input schema is simple but the description does not address any surrounding context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description provides no explanation of the parameters (database, schema_name, table_name). The schema itself only offers names and defaults, not semantics. The description fails to compensate for the lack of parameter documentation, leaving agents to guess the meaning and required format of each argument.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Suspend' and the specific resource and action: 'automated refresh and lag evaluation for a dynamic table.' This distinguishes it from sibling tools like resume_dynamic_table and refresh_dynamic_table, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as resume_dynamic_table or refresh_dynamic_table. While the name implies usage context, there is no direct guidance on conditions, prerequisites, or alternatives, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states that it suspends an 'active' warehouse, implying a state change, and mentions the cost-saving effect. However, it does not disclose side effects such as impact on running queries, whether it is idempotent, required permissions, or error conditions. This is a significant gap for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. It front-loads the action and purpose. While it is under-specified, it earns its place without redundancy. The structure is efficient, though it lacks any additional useful details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a state-changing operation with no annotations and a single parameter, the description is incomplete. It does not mention prerequisites (e.g., the warehouse must exist), consequences for running queries, error handling, or what happens if the warehouse is already suspended. The output schema exists but is not shown; regardless, the description omits essential operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameter. It only implies that `warehouse_name` is the name of the warehouse to suspend, but gives no details about format, uniqueness, or validation. The description does not compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'suspend' and the resource 'active virtual warehouse', and states the purpose of saving compute costs. It is distinct from siblings like resume or resize, though it does not explicitly reference them. The phrase 'active' adds a condition, making the action scope clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose 'to save compute costs' implies when to use this tool, but there is no explicit guidance on when not to use it (e.g., vs. dropping a warehouse) or any alternatives mentioned. The context is implied rather than stated, so it meets the 'implied usage' bar but lacks exclusions or directional advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It mentions 'Safely scale up' and 'optionally restore previous size', but does not explain what 'safely' entails (e.g., rollback on failure), the side effects on warehouse size, or what happens if the query fails. The behavior is only described at a high level without specifics an agent would need to understand consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence. It front-loads the primary action (scale and execute) and mentions the optional restore in a natural way. There is no filler or redundancy, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a composite tool with four parameters and no schema descriptions, the description is skeletal. It omits critical operational details such as what happens when restore_previous_size is false, whether the warehouse remains scaled if the query fails, or any prerequisites (e.g., warehouse must exist). The presence of an output schema is unknown, but the description does not prepare the agent for expected results or error conditions. This is insufficient for reliable autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema descriptions, the tool description must compensate for parameter meaning. It implicitly maps warehouse_name and target_size to 'scale up a warehouse', query to 'run a heavy query', and restore_previous_size to 'optionally restore previous size'. This provides some semantic linkage, but it lacks details such as valid target_size formats, query constraints, or the exact effect of restore_previous_size on failure. It is enough for a superficial understanding but insufficient for precise invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's composite purpose: scale a warehouse, run a query, and optionally restore size. It uses specific verbs and resources, and the 'Composite recipe' label distinguishes it from single-action sibling tools like snowflake_resize_warehouse or snowflake_query. However, it does not explicitly contrast itself with these alternatives, so it stops short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus sequentially calling separate tools like resize and query. It does not mention any conditions, prerequisites, or alternative scenarios. The only implicit hint is 'Safely', but no explicit when-to-use or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'describe' appropriately implies a read-only operation, which is fitting. However, the description adds no detail on required permissions, error behavior, or the expected function_signature input format — minimal value beyond what the verb itself conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with no filler. The purpose is front-loaded and every word earns its place, though it packs minimal information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and covers return values, which relieves some burden. The tool is simple (3 params, 1 required), but the critical required parameter's format is unexplained and no routing guidance is given. Adequate but with a notable gap around the function_signature input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, but it explains none of the three parameters. Most importantly, the required function_signature parameter follows non-obvious Snowflake signature syntax that is left undocumented, leaving the agent without the format needed to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Describe) and resource (UDF function) and lists exactly what is returned: signature, return type, language, and body. The 'UDF' qualifier implicitly separates it from the sibling snowflake_describe_procedure, though that distinction is not made explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs related siblings such as snowflake_list_functions or snowflake_describe_procedure. No prerequisites, exclusions, or context are provided — the agent must infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states it drops a schema (destructive) and requires confirmation, but does not elaborate on consequences, reversibility (though undrop_schema exists), permissions, or failure conditions. The confirmation flag is already visible in the schema, so the description adds no new behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that state the action and the key requirement. It is front-loaded, free of filler, and appropriately sized for the information it conveys. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and three parameters, the description is incomplete. It lacks usage context (when to use vs. alternatives), parameter explanations, and behavioral details beyond the confirmation flag. Even though an output schema exists, that does not cover pre-call context. An agent cannot fully understand the tool's risks and prerequisites from this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It only mentions the confirmation flag (already evident from the schema's default false), and does not explain the 'name' or 'database' parameters. This is insufficient for an agent to correctly provide inputs without additional knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Drop a schema in Snowflake', providing a specific verb and resource, and distinguishes from siblings like snowflake_drop_database and snowflake_drop_table by naming the resource type. The mention of a confirmation flag adds specificity, but it does not explicitly contrast with undrop_schema, which would enhance differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a critical usage guideline: the confirmation flag is required, implying the confirm parameter must be true for the drop to execute. However, it lacks guidance on when to use this tool versus alternatives like undrop_schema, and does not mention prerequisites such as ownership or dependency checks. It offers minimal but non-trivial direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It says 'List' which implies a read-only operation, but it does not explicitly state read-only behavior, permission requirements, or any side effects. It also does not mention whether the results are limited by the user's access or if it queries system views. Minimal disclosure leaves the agent guessing about safety and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the core action and resource. However, it is too brief to convey necessary details, which slightly reduces its structural effectiveness, but it is appropriately concise for the scope it covers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three optional parameters and no annotations, the description is inadequate. It does not explain how to use the filters, what happens if no parameters are provided, or the scope of alerts returned. The existence of an output schema helps with return values, but the input semantics are severely lacking, making the tool difficult to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 and explain the parameters. It does not mention 'pattern', 'database', or 'schema_name' at all, leaving their purpose and how they filter the results entirely unclear. The agent cannot correctly use these optional filters without additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('List'), the resource ('configured alerts'), and adds specific content ('condition queries, schedules, and state'). It distinguishes from sibling list tools like snowflake_list_tasks and snowflake_list_streams by the alert focus, and from describe_alert by the list vs. detail distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing alerts but provides no explicit alternative guidance. It does not mention when to use this versus snowflake_describe_alert for a single alert, nor does it address exclusions or prerequisites. The context is clear from the name, but the description adds no routing information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states a read-only action ('List') which implies no side effects, but it does not explicitly confirm the operation is non-destructive, or mention any permissions or session context requirements. For a simple listing operation, this is adequate, but it omits details like whether the result includes system schemas or respects visibility filters. The description provides baseline transparency but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource. There is no superfluous text or redundant information. It is appropriately concise for a tool of this simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has an output schema (so return format is covered) and a simple purpose, the description leaves the pattern parameter unexplained and does not clarify the behavior of 'current active database' beyond a passing mention. Given the low schema coverage, the description is insufficient for an agent to safely invoke the tool with the pattern parameter or to understand potential edge cases (e.g., what happens if no database is active).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It only hints at the database parameter ('a specific database or the current active database') but completely omits the pattern parameter, leaving its purpose and format unknown. The database parameter is partially clarified (optional, defaults to active database), but the pattern parameter—likely a filter—is entirely undocumented. This is a significant gap for an agent trying to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), the resource (schemas), and the scope (a specific database or the current active database). This distinguishes it from other listing tools like snowflake_list_tables or snowflake_list_views, though it does not explicitly name alternatives. The verb 'List' and resource 'schemas' make the purpose unambiguous, but it could be slightly more precise about the pattern parameter's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'a specific database or the current active database', which tells the agent the database parameter can be used to target a database or fall back to the session's active one. However, it provides no guidance on when to prefer this tool over similar listing tools (e.g., snowflake_list_tables, snowflake_list_databases), nor does it specify any exclusions or alternatives. The lack of such routing leaves the agent without clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. The description calls the operation 'Query', which implies read-only, but in Snowflake, reading stream changes advances the stream offset and consumes the records. The description mentions 'unconsumed' but does not explicitly warn that calling this tool will mark those changes as consumed. This is a critical side effect that an agent must know to avoid accidentally losing data. The description also does not mention any other side effects or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action and includes the default limit. There is no redundancy or filler; every word contributes to meaning. It is appropriately concise for a tool with only two parameters and a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool reads CDC changes, which involves nuanced semantics around consumption and offset advancement, yet the description does not explain these. It also does not mention what the output contains (though an output schema exists), nor any conditions like stream availability or required privileges. Given the complexity of stream reading and the lack of annotations, this description is insufficient for an agent to reliably invoke the tool without making assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of documentation on parameters. It addresses `limit` by stating the default of 10 rows, but it does not elaborate on `stream_name`—for example, whether a fully qualified name is required, what format is expected, or any constraints. The schema only provides types and titles, so the description adds only marginal value for one of the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Query), a specific resource (unconsumed CDC changes recorded in a stream), and mentions the default row limit. This clearly distinguishes it from sibling tools like snowflake_list_streams (which lists streams) and snowflake_describe_stream (which describes stream metadata). It is unambiguous about its function, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended use case (querying CDC changes) but provides no explicit guidance on when to prefer this tool over others, nor any exclusions or prerequisites (e.g., that the stream must exist, or that querying consumes the changes). The 'unconsumed' phrasing hints at the consumption semantics but does not state them clearly. This leaves selection and invocation partially to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It does disclose that confirmation is required, which is a genuine behavioral trait beyond the schema, and the action is implicitly destructive. However, it does not clarify the confirmation mechanism (e.g., that confirm must be set to true to proceed, or safety implications of the default false). Partial disclosure only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no wasted words, and the primary purpose is front-loaded in the first sentence. Efficient and readable, though the brevity comes at the cost of omitting needed behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not required. The main gap is the confirmation workflow: the description never links 'Requires confirmation' to the confirm parameter or tells the agent whether confirm=true is mandatory. For a destructive two-parameter tool this is a notable but not overwhelming omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it explains neither parameter. The confirm boolean's meaning is ambiguous — the description mentions confirmation generally but never ties it to the confirm parameter or explains what default false implies. stage_file_path is self-explanatory by name only. The description adds essentially no semantic value beyond the schema field titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Remove a file from a stage location'), making the core purpose clear. It implicitly distinguishes from siblings like snowflake_drop_stage (removing the whole stage) and snowflake_list_stage_files (listing), though it doesn't name these. The phrase 'Requires confirmation' adds a meaningful qualifier to the intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not explain that listing stage files first (snowflake_list_stage_files) is a natural prerequisite, nor does it contrast removing a single file with dropping an entire stage. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'zero-copy' but does not explain what that implies (e.g., no data duplication, instant creation). It also fails to disclose behaviors like whether the target database must not exist, what happens on conflicts, permission requirements, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that conveys the core intent without any redundancy. It is appropriately sized and front-loaded, placing the key action and resource immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal for a database mutation operation. It does not cover important context such as prerequisite conditions (source existence, permissions), the behavior if the target already exists, or the implications of zero-copy (e.g., storage efficiency, dependency on source). The presence of an output schema does not compensate for these missing operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must clarify the parameters. It does not mention source_database or target_database at all. While the parameter names are somewhat self-explanatory, the description adds no meaning about their roles, required formats, or any constraints beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the resource (a zero-copy clone of a database), using the exact phrase 'zero-copy' to convey the specific cloning mode. The name 'snowflake_clone_database' and the mention of 'database' distinguish it from siblings like snowflake_clone_table and snowflake_clone_schema, which target different object types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its alternatives, such as snowflake_clone_table or snowflake_clone_schema. It doesn't mention any conditions for database cloning versus other clone types, nor does it indicate when it would be inappropriate to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. The verb 'Describe' implies a read-only operation, but it does not explicitly state that it is non-destructive or that it may error on nonexistent databases. It lists output fields, which gives some context, but lacks explicit expectations about permissions or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the operation and its key output aspects. There is no fluff, and the core purpose is immediately visible. It is appropriately sized for the simple one-parameter describe operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. However, the description lacks situational guidance (when to use vs alternatives) and any preconditions. For a simple describe tool, the information is largely sufficient, but missing usage context and parameter details leave it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single parameter with 0% description coverage, so the description must compensate. It does not mention the database_name parameter at all, nor does it explain format, case sensitivity, or fully qualified name handling. The parameter name is self-explanatory, but the description fails to provide any additional clarity beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Describe' and the resource 'database', and lists the specific properties returned (owner, retention time, comment). This distinguishes it from list_database which lists all databases, and from describe_table/schema/warehouse tools, though it does not explicitly name those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like snowflake_list_databases or snowflake_get_database_ddl. It does not mention conditions such as whether the database must exist, nor does it suggest situations where a describe operation is preferred over a list or DDL retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It implicitly indicates a read-only introspection operation by using 'Describe', but it does not mention any access requirements, side effects, or limitations. It names the output aspects but not the return structure or potential errors. This is the minimum viable disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's function without any filler. Every word carries meaning, and the structure is front-loaded with the primary action and resource. No unnecessary information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description need not explain return values, but it still lacks parameter clarification and usage context. For an agent to correctly invoke it, the description does not help with parameter selection or disambiguation from similar describes (e.g., snowflake_describe_table). Overall, it is incomplete for practical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — the description does not reference any of the three parameters (database, schema_name, stage_name). It fails to clarify which parameter is required or how they relate to the stage location. Since the schema already provides names but no descriptions, the tool needs this compensation and does not provide it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Describe') and resource ('stage'), and names the exact aspects covered: location URL, storage integration, and file format properties. This clearly distinguishes it from siblings like snowflake_list_stages (which lists stages) and snowflake_create_stage (which creates them).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or contrasting scenarios with siblings such as list_stages or list_stage_files. An agent is left to infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Describe' implies a read-only operation, but the description does not explicitly state that it has no side effects, makes no modifications, or requires specific permissions. It adds no insight beyond what the tool name already conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It front-loads the core purpose and is appropriately sized for a simple describe operation. Every word adds value and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters with zero schema coverage and no annotations, the description fails to provide essential context. It does not explain parameter semantics, usage prerequisites, or behavioral guarantees. While an output schema exists, the input parameters remain completely undocumented, leaving an agent without enough information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the JSON schema provides no descriptions for the parameters. The description does not explain any of the parameters (database, schema_name, streamlit_name) or how they relate to the output. It only mentions output attributes, providing zero value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Describe' and the resource 'Streamlit application', and specifies the exact attributes it returns: root location, stage, and query warehouse. This distinguishes it from sibling tools like snowflake_list_streamlits (listing vs describing) and other describe tools for different resources (e.g., snowflake_describe_stage).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: if you need details about a Streamlit application, use this tool. However, it does not explicitly state when to use this versus alternatives (e.g., snowflake_list_streamlits for listing) or any exclusions. The context is clear but not explicitly framed as a routing instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It only states what it returns but does not mention whether it is read-only, potential performance implications of a 'composite recipe', schema existence requirements, or how it handles missing database/schema parameters. The 'composite recipe' label hints at multiple steps but offers no further detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, achieving clarity without verbosity. It front-loads the action ('Discover') and the composite nature is noted upfront. However, its brevity leaves out important usage and parameter details, so it is not perfect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's composite nature and the existence of an output schema, the description provides a minimal understanding of what it returns. However, it lacks context on parameters, error conditions, and how the composite recipe operates. The name implies lineage but the description does not address that, leaving ambiguity about the output's scope. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the parameters at all. It mentions 'a schema' but does not map database and schema_name to the inputs, nor how the parameters interact. Without compensation for the missing schema descriptions, agents cannot infer parameter meaning from the tool description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Discover') and resource ('all tables and views in a schema along with their column definitions'). It clearly differentiates from siblings like list_tables or describe_table by indicating a composite result that includes both table/view lists and column details. The name suggests lineage, but the description's explicit scope still gives a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that it replaces multiple calls (e.g., list_tables + describe_table) or when to prefer it over simpler tools. No exclusions or conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It says 'Drop a database' and 'Requires confirmation flag,' but does not reveal that this is a destructive operation that permanently removes the database and its contents, nor does it mention whether recovery (undrop) is possible or the impact on dependent objects. The confirmation requirement is disclosed, but the severity and side effects are not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, declarative sentences with no filler. It front-loads the purpose and then states the key requirement. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with two parameters, no annotations, and no parameter descriptions in the schema, the description is severely incomplete. It does not cover the destructive nature, the exact role of the confirm flag (e.g., must be true to proceed), what happens if confirm is false, recovery options, or any output. An agent would not have enough information to safely invoke this tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain the parameters. It only references the confirmation flag, implicitly indicating that `confirm` must be true to execute, but provides no explanation of `name` (what it is, format, or constraints). The description adds minimal value over the raw schema, leaving the agent to guess the meaning of `name`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the precise action ('Drop a database in Snowflake') with a clear verb and resource, and the name naturally differentiates it from siblings like create, clone, undrop, and describe. Even without explicitly naming alternatives, the action is unambiguous and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to choose this tool over alternatives such as truncate, drop_schema, or undrop. It only mentions that a confirmation flag is required, which is a precondition rather than usage context. No guidance on safety, prerequisites, or when it is appropriate to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool lists compute pools, implying a read-only operation, but does not explicitly confirm it, nor does it mention any side effects, permissions, or output structure. There is no contradiction, but the behavioral context is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero wasted words. It is front-loaded with the action and resource, and the SPCS clarification adds value without verbosity. Structure is excellent for its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and minimal description, the context is incomplete. It does not explain the purpose of the 'pattern' parameter, whether the operation is read-only (important for an agent's safety), or what the output schema contains. Though an output schema exists (per signals), the description still leaves the agent guessing about filtering and defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional 'pattern' parameter with no description (0% schema coverage). The tool description does not mention it, so an agent has no idea what 'pattern' means—likely a filter, but it could be any pattern. The description adds nothing to clarify parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a specific resource ('Snowpark Container Services (SPCS) compute pools'), clearly distinguishing it from other list tools for different resources (e.g., snowflake_list_sequences) and from describe/action tools for compute pools (snowflake_describe_compute_pool, snowflake_resume_compute_pool). The resource is named precisely with the SPCS abbreviation, making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention that it is a listing operation for compute pools, nor does it contrast with describe_compute_pool for details, or with suspend/resume for lifecycle management. An agent would need to infer usage from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It states the core action but does not mention that this is a read-only operation, any potential performance implications, or what the pattern parameter does. It also does not clarify whether it returns a list, a count, or any other format. This is a significant gap for a tool that appears to be a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It front-loads the core action and scope, achieving efficiency without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits any mention of the 'pattern' parameter, which is a key aspect of its functionality. It also does not provide any context about the return format, pagination, or required prerequisites (e.g., role permissions). While an output schema exists, the description is incomplete for a tool that accepts a filtering parameter, leaving the agent under-informed about how to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter 'pattern' with zero description coverage, yet the description does not explain the meaning or usage of this parameter. The description entirely ignores the pattern, leaving the agent to guess what filtering capabilities are available. Since the schema provides no descriptions, the description must compensate but fails to do so, earning a low score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action (List), a specific resource (databases), and a scoping condition (accessible to the current role). It distinguishes this tool from siblings like snowflake_list_schemas or snowflake_list_tables by explicitly naming the resource type, making it unambiguous which list tool to select.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent needs to enumerate databases accessible to the current role, but it provides no explicit guidance about when not to use it or alternatives. It does not mention that other list tools exist or when to prefer those, so the guidance is minimal and left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. Listing implies a read operation, but the description does not confirm safety (e.g., read-only, non-destructive), nor disclose pagination, limits, ordering, or what 'last refresh status' conveys. For an unannotated tool, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with no filler; the resource and key return fields are front-loaded. Minor deduction only because it ends abruptly without any usage framing, but as a concise statement it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return structure is covered externally. The description identifies the resource and return fields adequately for a basic listing tool, and all parameters are optional. However, given the huge sibling family and zero annotations, the lack of usage guidance and filtering semantics leaves the description somewhat incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the three parameters (pattern, database, schema_name). The parameter names and optional defaults are somewhat self-explanatory, but with zero coverage the description should compensate by explaining how filtering/scoping works, and it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and a specific resource ('dynamic tables'), and enumerates the distinguishing fields returned (lag targets, refresh mode, last refresh status). Among a large family of list_* siblings (list_tables, list_views, list_iceberg_tables), naming 'dynamic tables' clearly identifies the target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus the many sibling listing tools (list_tables, list_views, list_iceberg_tables) or describe_dynamic_table. The only disambiguation comes from the resource name itself, which is inferable; there is no explicit when-to-use / when-not-to-use or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It merely states 'List stored procedures', implying a read-only operation but without explicit confirmation or details about side effects, pagination, or authorization requirements. The description adds no behavioral context beyond the operation name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero unnecessary words. It delivers the core purpose efficiently and is appropriately concise for a simple listing operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no annotation support, the description is inadequate. It omits details on how to use the parameters, what the output looks like, and any edge cases. While an output schema exists, the description still fails to provide essential operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the three parameters (pattern, database, schema_name). It only hints at database/schema scoping but does not explain the 'pattern' parameter or how filtering works. This is insufficient given the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'stored procedures', scoped to 'a database or schema'. This distinguishes it from sibling listing tools like snowflake_list_tables and snowflake_list_functions, and no ambiguity exists about what it returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as snowflake_list_functions or snowflake_describe_procedure. The description offers no context about scenarios where listing procedures is appropriate, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full transparency burden. It only says 'List roles' with no mention of permissions, read-only nature, or any limitations. It also fails to explain what 'available' means (e.g., roles visible to the current user vs all roles). The singular sentence provides minimal behavioral insight beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb and resource. It contains zero wasted words and is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one undocumented parameter and no annotations, the description is incomplete. It does not explain the behavior of the pattern parameter, nor does it specify any constraints or prerequisites. While an output schema exists (so return values are covered), the missing parameter semantics and lack of behavioral context make it insufficient for an agent to confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the 'pattern' parameter is completely undocumented in both the schema and the description. The description does not explain what the pattern does (likely filters role names by a pattern). This is a critical gap for a parameter that is optional but may significantly alter results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), resource ('roles'), and scope ('in the Snowflake account'). This clearly distinguishes it from sibling tools like snowflake_list_users or snowflake_list_grants_to_role, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is clear about the action but provides no explicit guidance on when to use this tool versus alternatives. Since there are many list_* siblings, some routing hint would help, but the simplicity of the operation (listing roles) makes the usage implicit. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full responsibility for behavioral disclosure. It does not state that the operation is read-only, safe to run, or that it requires an existing database/schema. It also does not mention potential errors, performance implications, or whether it returns a paginated result. The description only states what is listed, not how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that packs the core action, scope, and output details without any waste. Every word adds value: the verb, the object, the scope, and the specific fields returned. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three optional parameters, no schema descriptions, and no annotations, the description is minimal. It omits how pattern works, whether database and schema_name are required together or individually, and any examples or edge cases. While an output schema exists (so return values are covered), the description does not explain how to correctly invoke the tool with the given parameters. An agent would struggle to craft a proper call without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It hints that tasks are listed 'in a database or schema', which maps to the database and schema_name parameters, but it does not explain the pattern parameter (likely a LIKE filter). No parameter is described explicitly, leaving the agent to guess what 'pattern' means and how the scoping works. This is insufficient given the lack of schema-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists tasks, scoped to a database or schema, and specifies the included fields (schedule, state, predecessor). This verb+resource+scope pattern distinguishes it from other list_* siblings, all of which target different object types. The description leaves no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided beyond the basic action. There is no guidance on when to use this tool versus alternatives like snowflake_describe_task, snowflake_list_sequences, or other list operations. No mention of prerequisites, typical use cases, or exclusions. The description implies it lists tasks but does not help the agent decide when to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It discloses that the tool is read-only and returns structured rows with metadata, but it omits other important behavioral details such as timeout behavior, result truncation (beyond the schema default), permission requirements, or what happens with unusually large queries. The lack of annotations leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. It states the action, the scope, and the result efficiently, making it easy to parse at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a query tool in a large family of Snowflake operations, the description lacks crucial context: it does not mention that it supports only single statements, does not clarify if it uses the current warehouse, and does not reference any limitations or the presence of an output schema that could inform the agent. Given the abundance of sibling tools and the absence of annotations, this is insufficient for an agent to call it effectively in many scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no additional meaning for the 'query' or 'max_rows' parameters. It does not explain the expected format of the query string, constraints on max_rows (e.g., limits), or the meaning of the default. The description adds zero value beyond the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Execute' with a specific resource 'SQL SELECT or read-only query' and the result 'structured rows with metadata'. It distinguishes the tool from DML-focused siblings like snowflake_execute_dml by emphasizing the read-only nature, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for read-only queries versus mutation tools like snowflake_execute_dml, but it does not explicitly state when to use this tool over other read-related tools (e.g., snowflake_get_query_history) or provide exclusions. The guidance is inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It only states the action and cost motivation, but does not disclose whether the suspension is reversible, impacts running services, requires special permissions, or what happens if the pool is already suspended. No side effects or state changes are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with zero fluff. The action and purpose are front-loaded, and every word adds value. No unnecessary details or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple suspend operation with one parameter, the description covers the primary intent, but lacks information on edge cases (idempotency, error conditions, return value) and does not clarify what constitutes an 'active' pool. Given an output schema exists, the response format may be documented there, but the description alone is only minimally complete for an agent to act reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'pool_name' is self-explanatory from its name and the tool context, but the schema provides no description (0% coverage) and the description does not elaborate on the expected format (e.g., full name vs. simple name, case sensitivity). The parameter's purpose is implicitly clear, so a mid score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Suspend') on a specific resource ('SPCS compute pool') with an explicit goal ('to stop node provisioning costs'). It is distinct from sibling tools like resume_compute_pool, but doesn't explicitly name the alternative or differentiate beyond the verb. Still, the purpose is clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool vs alternatives. No mention of preconditions (e.g., pool must be running) or exclusions. The description only implies usage to cut costs, but does not state when not to use it or when a different operation (e.g., drop, resize) would be appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It states the destructive nature ('truncate all data rows') and signals a confirmation requirement, but it fails to mention irreversibility, permission requirements, effects on constraints or identity counters, or any transactional behavior. It is only minimal information and does not prepare the agent for side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It front-loads the primary action and then adds a crucial safety note. Every word contributes value, and the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool performs a destructive operation but lacks essential context: what happens to table data, whether it is recoverable, what the return output shows, and any constraints on use. Given no annotations and an output schema that we don't see, the description leaves significant gaps for an agent to call it safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does not describe table_name format or scope, and only hints at 'confirmation' without explicitly stating that the confirm boolean must be set to true to execute. This is insufficient for an agent to know how to correctly provide the required inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (truncate), the target resource (table), and the key distinction from drop operations ('preserving schema'). This distinguishes it from sibling tools like drop_table and allows an agent to understand its purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions 'Requires confirmation' as a usage note but provides no guidance on when to use this tool versus alternatives like drop_table, delete, or export. There is no mention of prerequisites, scenarios where truncation is appropriate, or when to avoid it. The agent is left to infer from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the primary action (restore a dropped schema) but does not mention side effects, permissions required, failure modes (e.g., if the schema name is already in use), or the time travel window limitation. The phrase 'recently dropped' implies a constraint but doesn't specify details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence with no filler. It immediately states the purpose and mechanism, making it highly scannable. There is no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is incomplete for an agent to call the tool correctly. It does not clarify the roles of the two parameters, lacks any mention of the Time Travel retention period or error conditions, and offers no guidance on the database context. For a relatively simple tool, more explanation is needed given no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any parameter information. It does not explain that 'name' refers to the schema name or how 'database' is used. An agent would have to infer the parameter semantics from the tool name alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Restore') and resource ('schema') and clarifies the mechanism ('using Time Travel'). It clearly distinguishes from sibling tools like snowflake_undrop_database and snowflake_undrop_table via both the tool name and the explicit 'schema' reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a schema has been recently dropped), but provides no explicit guidance on when not to use it or how it compares to alternatives like undrop_database or undrop_table. It does not mention prerequisites such as being within the Time Travel retention period.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure. It mentions the action (restore) and the mechanism (Time Travel), implying mutability and time limitations, but it omits critical details such as required permissions, whether the restored table overwrites an existing one, or the exact conditions for success (e.g., table not purged). This is insufficient for a recovery operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately leads with the action. There is no redundant or filler content; every word contributes to the core meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutating nature, the lack of detail is a significant gap. The description does not mention operational constraints like time travel retention limits, whether the table must be in the same schema, or what the output contains (even though an output schema exists, the description could still warn about side effects or failure conditions). For a recovery operation, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for table_name, and the description does not elaborate on it. While the parameter name is self-explanatory, the description adds no value beyond the schema – it does not clarify naming conventions (e.g., fully qualified vs. unqualified), case sensitivity, or any constraints. The agent must guess the expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (restore), the object (a dropped table), and the mechanism (Time Travel). It is distinct from siblings like snowflake_drop_table and snowflake_clone_table, and from undrop operations on other objects (schema, database).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. It does not state prerequisites (e.g., the table must be within the time travel retention period) or mention when NOT to use it (e.g., if the table dropped long ago, or if you need a point-in-time copy rather than the most recent state). No alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is a 'composite recipe' but does not explain what that entails—whether it executes multiple queries, what side effects occur, or whether it is read-only. The 7-day window and metrics are disclosed, but the operational behavior is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose and the time window. It contains no filler and every word adds value. Ideal structure for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are presumably covered elsewhere. However, the description leaves the meaning of 'composite recipe' unexplained, and it does not clarify the operational scope (e.g., whether it spans multiple accounts or warehouses). For a no-parameter tool, this is adequate but could be stronger about what the summary actually reflects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. The description does not need to add parameter meaning because there are none. Per the rubric, the baseline for 0 parameters is 4, and there is no deficiency to penalize.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool produces a summary of warehouse compute credits and storage consumption over the past 7 days. This is a specific verb-resource pairing that distinguishes it from the mostly CRUD-oriented sibling tools. It does not explicitly name an alternative, but no sibling serves the same purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus others, nor any exclusions or prerequisites. The mention of 'composite recipe' hints it might combine multiple operations, but it does not explain when an agent should select it over, say, querying usage views directly or using the health check tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the output but does not mention that the operation is read-only, the need for any specific privileges, error behavior (e.g., failure if the table does not exist), or how missing schema/database parameters are resolved. For a describe operation, these are important expectations that are left unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundant information. It front-loads the core action and expected output. Every word contributes to clarity, making it an exemplary model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return format is covered. However, the description lacks guidance on when to choose this over similar describe tools (e.g., iceberg) and does not clarify parameter dependencies. Given the tool's simplicity, it is adequate but not fully complete for an agent that must pick between many sibling describe functions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate by explaining parameter usage. It only hints that table_name refers to a table or view, but does not elaborate on how database and schema_name parameters interact, whether table_name should be fully qualified, or the effect of leaving database/schema null. The description provides minimal added value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Describe') and the resource ('a table or view'), and specifies exactly what information is returned: column definitions, data types, nullability, and primary keys. This distinguishes it from sibling describe tools like snowflake_describe_iceberg_table (for iceberg tables) and snowflake_describe_database/schema (for different object types). The specificity is high and leaves no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention, for example, using snowflake_get_table_ddl for DDL statements or snowflake_describe_iceberg_table for iceberg tables. The context for selection is implied but never explicit, so an agent may not know which describe tool fits a given situation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It implies a read operation ('get') but does not explicitly state whether it is read-only, whether any permissions are required, or what time range the history covers. The description is minimal and does not convey additional traits beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence containing no redundant words. It communicates the core function efficiently without any fluff or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the return structure is covered elsewhere, so that omission is acceptable. However, the description lacks contextual details such as whether the history is per-warehouse, what time window is considered, or any prerequisites. For a simple get operation, it is minimally adequate but could be more complete with a note about the scope or usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter (warehouse_name) with no description, and the tool description does not mention it at all. Since schema_description_coverage is 0%, the description should have compensated by explaining the parameter's meaning or format, but it offers no additional value. The agent is left to infer that warehouse_name is a string identifier, which is not fully explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves load, queuing, and provisioning history for a specific warehouse. The verb 'Get' and resource 'warehouse load history' are specific, and it naturally distinguishes from siblings like get_query_history by focusing on warehouse-level metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_query_history or describe_warehouse. The description only states what it does, with no mention of conditions, exclusions, or when a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It only states the purpose and does not mention read-only nature, filtering behavior, pagination, permissions, or what happens when database/schema are omitted. It adds little beyond the tool name and does not contradict anything, but it is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the core purpose. No fluff or redundancy, but it could have included a brief mention of the pattern parameter without becoming verbose. It is appropriately concise, so a high score is warranted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits critical context: the meaning of pattern, behavior when scope is unspecified, and how this differs from list_procedures or describe_function. The tool's complexity (3 optional params) and lack of schema coverage demand a more thorough explanation. The description is incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not compensate. It alludes to 'database or schema' but does not explain the pattern parameter, how database/schema_name interact, or any syntax expectations. The agent is left to guess parameter semantics from names alone, which is risky for a 3-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'user-defined functions (UDFs)', and the scope 'in a database or schema'. It effectively distinguishes this tool from sibling list tools like snowflake_list_tables or snowflake_list_views by specifying UDFs, and from describe_function by indicating a list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to list UDFs), but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or conditions. Without naming siblings like snowflake_list_procedures or describe_function, it leaves the selection to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'List', implying read-only, but does not mention potential effects, return format, pagination, or any limitations. It adds very little beyond the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that front-loads the core action and resource. There is no redundant wording, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with an output schema provided, the description is minimally adequate. However, it lacks nuance about what privileges are included (e.g., object-level vs account-level) and does not differentiate from the very similar grants_to_user tool beyond the role parameter. It covers the basics but leaves some context implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not mention the role_name parameter at all. Though the parameter is self-explanatory (a role name string), the description fails to add any additional meaning or clarify expectations, leaving the agent to rely on the name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List privileges granted') on a specific resource ('a specific role'), clearly distinguishing it from the sibling 'snowflake_list_grants_to_user' which targets users. It is unambiguous and directly names the resource being queried.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool over alternatives like snowflake_list_grants_to_user or snowflake_list_roles. There is no mention of prerequisites, context, or conditions where this tool is preferred, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It notes the query must be 'active running' but fails to mention side effects (e.g., cancellation is irreversible), error behavior for invalid IDs, or success/failure response semantics. The description is a bare action statement without operational detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the verb and object. There is zero waste; every word is necessary. It achieves maximum conciseness without sacrificing core clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and presence of an output schema, the description captures the essential action. However, it omits any error handling details, prerequisites (e.g., must have a valid running query ID), or indication of where to obtain the ID from other tools. The output schema may cover return values, but the description leaves operational context vague.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must clarify the parameter. It does identify query_id as the identifier for the query to cancel, which adds meaning beyond the schema's bare type/title. However, it doesn't provide additional details like the format or source of the ID, so it only partially compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Cancel') and resource ('active running Snowflake query') and specifies the key parameter (Query ID). It clearly distinguishes from all siblings, none of which perform cancellation. This is an unambiguous statement of the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no contextual guidance on when to use this tool versus alternatives or exclusions. It doesn't mention that the query must be running, how to obtain the query ID, or that other query-related tools exist. The only implicit guidance is that cancellation is the purpose, but it offers no 'when not to use' or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses what information is returned (metadata, source table, stale status), which gives some behavioral context. However, it does not explicitly state that the operation is read-only (though 'describe' implies it), nor does it mention any side effects or permissions needed. It adds value beyond the schema but could be richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose. It has no fluff and earns its place. However, it is slightly terse; adding a note about the required parameter or typical usage would improve it without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since an output schema exists, the return format is covered elsewhere, so the description doesn't need to explain it. Yet the lack of usage guidance or parameter clarification leaves gaps. For a simple describe tool this is adequate, but it doesn't fully address the context in which an agent might pick this over siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain any of the three parameters (database, schema_name, stream_name). While the parameter names are self-explanatory, the description fails to compensate for the lack of schema documentation, leaving the agent to infer that these are locators for the stream. No additional meaning is provided beyond the schema's bare property definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Describe stream metadata, source table, and stale status' clearly states a specific verb (describe) and resource (stream), and specifies the exact information returned (metadata, source table, stale status). It distinguishes from siblings like snowflake_list_streams (which lists) and snowflake_create_stream/drop_stream (which modify) by focusing on inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, such as snowflake_list_streams or snowflake_read_stream_changes. It does not mention prerequisites (e.g., needing the stream to exist), nor does it advise against use in certain contexts. The agent is left to infer that 'describe' implies inspection, but no explicit routing is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description clearly implies a read-only operation (listing tables) and specifies that it returns row counts and bytes, which indicates a non-destructive behavior. However, it does not explicitly state that no modifications occur, nor does it disclose potential performance implications of listing many tables or whether there are any limitations. The basic behavior is transparent, but it lacks depth beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that is front-loaded with the verb and resource. Every word contributes to the core message. There is no filler or repetition. This is an excellent example of concise, focused tool documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three optional parameters and no annotations, the description is too sparse. It does not clarify parameter semantics, default behavior when parameters are omitted, or how the 'pattern' interacts with the other fields. Since the output schema is not described within the description, the agent cannot rely on the description for return structure beyond 'row counts and bytes.' Given the simplicity of the tool, some gaps are acceptable, but the ambiguous 'pattern' and lack of usage context make the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. The description only mentions 'database schema' but does not explain the three parameters: pattern, database, and schema_name. While database and schema_name are reasonably self-explanatory, 'pattern' is ambiguous and could mean a LIKE pattern, a regex, or something else. The description provides no additional meaning for these parameters, leaving the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a resource ('tables'), and a clear scope ('in a database schema'), and adds what is returned ('row counts and bytes'). This distinguishes it from sibling tools like snowflake_list_views or snowflake_list_sequences. The purpose is unambiguous and immediately actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as snowflake_list_views, snowflake_describe_table, or snowflake_get_table_ddl. The description does not mention any exclusions, prerequisites, or context for choosing this tool over others. An agent would have to infer usage from the name and schema, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the bare action; it does not disclose that the session state changes, that subsequent operations become part of this transaction, or that a commit or rollback is required. For a transaction operation, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero wasted words. It is appropriately concise for a parameterless tool, though more context could have been added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and no parameters, the description is too thin for a transaction control operation. It omits essential context like the need to pair with commit or rollback, the session-scoped nature, and the effect on subsequent queries. An agent cannot fully infer correct usage from this definition alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema documents none, so the baseline of 4 is appropriate. The description adds nothing about parameters, which is fine since none exist. No compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('begin') and target (explicit transaction on active session), and is distinct from sibling tools like commit_transaction. It leaves no ambiguity about what operation is performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives or what precedes/follows it. It does not mention that it should be used before executing multiple statements or that it requires a subsequent commit/rollback, nor does it point to any sibling tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states the output range and does not mention safety, side effects, limits (e.g., input length, language support), or error conditions. For a read-only analysis tool, this is minimal; it does not reveal potential pitfalls or operational characteristics an agent might need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that states the action and the output. There is zero redundancy, and the essential information is front-loaded. It is appropriately sized for a tool with a single parameter and a well-defined return.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (though its contents are not shown here) and the tool is simple, the description is adequate for a basic call. However, it lacks context on any prerequisites, input limits, or whether the tool handles non-English text. It is not incomplete enough to make the tool unusable, but it leaves some operational questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'text' with no description (0% coverage). The tool description says 'Analyze sentiment of text', which adds no information beyond the parameter name itself—it does not clarify expected format, length constraints, or encoding. Since the schema provides nothing, the description should compensate but fails to add meaningful detail about the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Analyze', the resource 'text', and the output as a sentiment score ranging from -1.0 to 1.0. It is specific and distinct from all sibling tools, which focus on data management, queries, or other Cortex capabilities. The output range precisely defines what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says what the tool does but provides no explicit guidance on when to use it versus alternatives like snowflake_cortex_summarize or snowflake_cortex_extract_answer. An agent can infer it is for sentiment analysis, but there is no mention of when it is appropriate or any exclusions. It is straightforward but leaves usage context to the agent's discretion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states what the tool describes, not that it is a read-only operation, what happens if the policy does not exist, or any required permissions. 'Describe' implies non-destructive but is not explicit, and no other behaviors are disclosed, leaving the agent with minimal insight beyond the literal action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It immediately states the purpose and the content details, front-loading the key information. There is no wasted text, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with one parameter and an output schema exists (which covers return values). However, the description lacks guidance on parameter usage and any context about prerequisites or error scenarios. It is adequate for a basic describe operation but misses parameter semantics and usage distinctions from similar tools, leaving a few gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, and the tool description does not mention the 'policy_name' parameter at all. It fails to explain what the parameter represents, any format requirements, or how it relates to the output. With no added meaning beyond the schema field name, the description is insufficient for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool describes a network policy, specifying the exact content returned (allowed IP lists, blocked IP lists, and comments). This identifies the verb 'describe' and the resource 'network policy', distinguishing it from sibling tools like snowflake_list_network_policies (which lists policies) and snowflake_describe_network_rule (which targets a different object).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys that this is for retrieving detailed information about a specific network policy, but it does not explicitly mention when to use it over alternatives like snowflake_list_network_policies or snowflake_describe_network_rule. There is clear context (describing a policy) but no exclusions or comparisons, so a slight deduction is applied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It states the tool returns role properties and assigned grants, which conveys a read-only, descriptive nature. However, it does not mention any prerequisites (e.g., role existence), error conditions, or response complexity. The description is adequate but minimal, adding no detail beyond the basic returning of information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the core functionality without any filler. It is front-loaded and every word earns its place, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple describe operation with a single parameter and an existing output schema, the description is adequate but not rich. It does not elaborate on what specific properties or grant details are included, nor does it mention pagination or limits. The existence of an output schema mitigates the need to explain return values, but the description still lacks some operational context (e.g., whether it returns grants for the role only or also inherited grants).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the schema provides only a title 'Role Name' with no description. The tool description does not explicitly explain that role_name identifies the specific role to describe, nor does it add any context about name format, case sensitivity, or required privileges. Since the description fails to compensate for the missing schema documentation, it adds minimal semantic value beyond the field name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Describe') applied to the resource ('role') and names the two aspects covered: properties and assigned grants. This clearly distinguishes it from sibling tools like snowflake_list_roles (which lists available roles) and snowflake_list_grants_to_role (which lists grants separately). The purpose is unambiguous and differentiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention snowflake_list_roles for discovering roles, nor snowflake_list_grants_to_role for grant details separately, nor any conditions that would select one over the other. The intended usage is only implied (describe a specific role), with no exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are entirely absent, so the description must carry the full burden of disclosing side effects, permissions, and return characteristics. The description only lists what is checked ('connection, active session, warehouse state, and credit consumption') but does not state whether the operation is read-only, whether it can trigger actions (like resuming a warehouse), or what the output structure is. Critical behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists the health-check targets. It is front-loaded with 'Composite recipe' to signal aggregation. However, it could use slightly more structure to clarify the output or usage context without becoming verbose. It's concise but not maximally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's composite nature and the existence of an output schema, the description should explain what the returned health report contains or at least note common usage. It does not address potential prerequisites, cost implications, or the meaning of 'health check' beyond the list. Since it's a zero-parameter read-only-style tool, it is partially adequate, but the lack of behavioral transparency and usage guidance lowers completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter information because none is needed. It correctly avoids redundant content, and the schema already fully covers the (empty) parameter list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Run health check') and enumerates four distinct resources (connection, active session, warehouse state, credit consumption). This clearly delineates the tool's scope from the many sibling tools that operate on individual objects like tables or warehouses. It's unambiguous and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It is described as a 'composite recipe' but does not specify contexts (e.g., initial troubleshooting, pre-upgrade checks) or contrast with dedicated tools like snowflake_get_current_context or snowflake_describe_warehouse. The agent is left to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that it lists tables but does not mention read-only nature, side effects, error conditions, or how scope filtering behaves (e.g., whether database and schema are mutually exclusive or hierarchical). The agent is left guessing about the operational semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that front-loads the action and scope. No filler words, objective and directly to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with all-optional parameters and an output schema (which may describe return format), the description is minimally adequate but omits critical details like pattern usage, scope precedence, and expected output structure. It gives a high-level idea but not enough for confident invocation without additional probing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the three parameters. The description hints at 'database or schema' as scope but does not explain the 'pattern' parameter at all, nor does it clarify how the parameters interact (e.g., whether pattern is a filter or a name pattern). With 0% coverage, the description needed to compensate but only partially did.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('Apache Iceberg tables'), with an explicit scope ('account, database, or schema'). This distinguishes it from sibling listing tools like snowflake_list_tables (regular tables) and snowflake_list_views, which are clearly different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for Iceberg tables specifically, which hints at when to use it. However, it does not explicitly mention alternatives or conditions for when not to use it (e.g., 'for non-Iceberg tables, use snowflake_list_tables'). No guidance on scope selection or parameter precedence is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the basic function without mentioning any side effects, permissions, rate limits, or what happens with edge cases (e.g., non-English text, long inputs). The lack of behavioral detail leaves the agent relying on assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero waste. It front-loads the action and clearly states the input and tool, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is adequate for a basic call. However, it lacks guidance on when to prefer this over other Cortex tools and does not mention any constraints or expected behavior, leaving some gaps for more complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The single parameter 'text' is indirectly explained by 'Summarize English text', which adds the language constraint. However, it does not clarify length limits or formatting expectations beyond what the schema shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Summarize' and the resource 'English text using Snowflake Cortex AI'. It is distinct from sibling Cortex tools like sentiment, translate, and extract_answer, and the function's purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when summarization is needed), but it does not explicitly mention alternatives or conditions for when not to use it. The sibling names are self-explanatory, so an agent can infer, but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only operation via 'Retrieve' but does not explicitly state that it is non-destructive or mention any prerequisites (e.g., query must be in history, required permissions). It also does not describe the return payload, though an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single declarative sentence with no filler. It front-loads the verb and object, then adds the constraint. Every word earns its place, and the description is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, so return values are covered. However, it lacks any usage guidance about when to prefer this over related query-inspection tools, and it does not mention potential limitations or prerequisites beyond 'past Query ID'. This is a functional but incomplete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, query_id, has zero schema description coverage. The description adds essential semantics by stating it must be a 'past Query ID', which is crucial for correct invocation. However, it does not elaborate on the format or source of the ID beyond that, leaving room for ambiguity in how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (retrieve), the object (operator-level execution statistics and profiling data), and the context (for a past Query ID). This distinguishes it from sibling tools like snowflake_get_query_plan and snowflake_get_query_history, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as snowflake_get_query_plan or snowflake_get_query_history. There is no mention of when it is appropriate or when it is not, leaving the agent to infer based solely on the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It states the tool retrieves schema properties, owner, and retention settings. The name 'describe' implies a read-only operation, which is standard across the suite. It does not explicitly say it is non-destructive, but the described action is clearly a query-like operation, which is transparent enough for this context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core purpose and key output aspects (properties, owner, retention). There is zero wasted text and it reads clearly. It is appropriately terse for a describe tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is covered. However, the parameter semantics gap (especially the optional 'database' field) is not addressed, and there is no differentiation from sibling describe tools. The description is functional for a simple describe operation but leaves the agent guessing about parameter usage. It meets the minimum viable threshold but lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (the input schema provides no descriptions). The description does not mention the 'schema_name' required parameter or the optional 'database' parameter, nor does it explain how 'database' qualifies the schema lookup. The agent receives no guidance on parameter semantics from either schema or description, making this a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Describe' and the resource 'schema', and specifies the exact aspects covered: properties, owner, and retention settings. This distinguishes it from sibling describe tools like describe_database and describe_table, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for schema metadata retrieval, but it does not explicitly state when to use this tool over alternatives (e.g., list_schemas for enumeration, or describe_database for database-level detail). No exclusions or context-linking guidance is provided, leaving the agent to infer from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the operation is read-only (describes metadata) and explicitly notes it does not expose the secret value, which is a critical behavioral trait. It also mentions the type enumeration (GENERIC_STRING, OAUTH2), giving insight into the output. While it does not discuss privileges or error behavior, the description is notably transparent about its scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the main purpose and includes important constraints. Every word earns its place; no filler or redundancy. It efficiently conveys the core function and the critical exclusion of the secret value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple describe operation, the description conveys its main purpose and what it returns. However, the lack of parameter explanation is a gap given 0% schema coverage. The presence of an output schema reduces the need to describe return values, but the optional database and schema parameters remain unaddressed, leaving some ambiguity in how to scope the describe call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain any of the parameters. The required secret_name is only implicitly understood from the resource name, while database and schema_name are entirely unexplained. Without schema descriptions or elaboration in the description, an agent may not know how to locate the secret or what these optional parameters signify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb (describe) and resource (secret), specifies the contents of the metadata (type, owner), and explicitly notes it avoids exposing the secret value. This distinguishes it from list_secrets or any value-returning operation, making its purpose unmistakable even among many sibling describe tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives, nor any mention of exclusions or sibling tools. The phrase 'without exposing secret value' implies that this is for metadata only, but it does not state when one should instead retrieve the value or use other secret-related tools. The context is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It implies a read-only operation ('Retrieve') but does not mention permission requirements, potential errors for nonexistent objects, or whether it affects state. Given the absence of annotations, more explicit behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that delivers the essential purpose without any redundancy or unnecessary detail. It is front-loaded and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists to cover return format, the description does not elaborate on usage context such as required permissions or whether the object must be fully qualified. For a simple retrieval tool, the description is adequate but could be enhanced with a brief note on object naming conventions. The brevity leaves some gaps for an agent to handle correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate by explaining parameter meanings, but it does not. It mentions TABLE/VIEW but does not clarify that object_type can be set to VIEW or that object_name likely requires a fully qualified name. The schema only provides types and defaults, leaving the agent to guess parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Retrieve' and the exact resource ('CREATE OR REPLACE TABLE/VIEW DDL definition'), making it distinct from sibling tools like snowflake_get_database_ddl or snowflake_describe_table. No ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives such as snowflake_describe_table or snowflake_get_database_ddl. Situational context is implied by the purpose, but there is no direct guidance on selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only list operation and scopes to 'in the account', but does not explicitly state read-only nature, mention pagination or filtering behavior, or note any permission requirements. It is not misleading, but it adds little beyond the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the core action and resource. There is no redundant phrasing or unnecessary detail; it wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, return fields are covered externally. However, the description fails to document the 'pattern' parameter and offers no usage guidance relative to sibling tools. For a tool with one optional parameter and a clear list purpose, this is adequate but leaves the parameter semantics and selection context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'pattern' is not described in the schema (only its type and default are given), and the description does not mention it at all. With 0% schema coverage, the description should compensate by explaining what the parameter filters (e.g., a name pattern), but it does not. The agent is left to guess its meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List') and a specific resource ('virtual warehouses in the account'), and it names distinguishing attributes (size, state, auto-suspend configurations). This separates it from other listing tools like snowflake_list_tables or snowflake_list_schemas, and from single-warehouse tools like snowflake_describe_warehouse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. The tool's purpose implies it is for enumerating warehouses, but it does not mention alternatives such as snowflake_describe_warehouse for a single warehouse or snowflake_get_warehouse_load_history for load metrics. The context is inferred but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral effects. It only states the action without mentioning side effects (e.g., making changes permanent), error conditions (e.g., failure if no active transaction), or whether it is reversible. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the action. It is front-loaded, contains no filler, and delivers the core purpose concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal for a transaction operation. It does not explain prerequisites (e.g., an active transaction from snowflake_begin_transaction) nor what happens if no transaction exists. However, given the simplicity and presence of an output schema, it provides a baseline level of completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain any. The schema coverage is trivially 100%, and the absence of parameters is correctly implied by the description. The baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Commit') and the resource ('the current active transaction on the session'). It distinguishes from the sibling 'snowflake_begin_transaction' by focusing on the commit operation, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's usage is implied but not explicit. It does not mention that it should follow snowflake_begin_transaction or when not to use it (e.g., if no transaction is active). No alternatives are suggested, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses what the tool returns (instance family, min/max nodes, active nodes, state) but does not explicitly state it is read-only, has no side effects, or requires prior existence of the pool. While 'describe' implies a read operation, the description does not make these behavioral traits explicit, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste. It states the action and the key output fields directly, information is immediately actionable, and there is no redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, one-parameter tool with an output schema, the description covers the main return values and is nearly complete. Minor omissions like explicit read-only status or error behavior are present, but the existence of an output schema mitigates the need to describe return formats. Overall, an agent can call this tool correctly with the available information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the pool_name parameter. Although the parameter name and tool purpose make its meaning inferable, the description fails to add any explicit semantic detail (e.g., format, case-sensitivity, or that it must be an existing pool). Low coverage requires the description to compensate, and it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Describe') and resource ('compute pool'), and enumerates the exact attributes returned (instance family, min/max nodes, active nodes, state). This clearly distinguishes it from sibling tools like list_compute_pools (which enumerates pools) or resume/suspend_compute_pool (which modify state), so an agent knows exactly what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the standard 'describe' pattern: when you need details of a specific pool, use this tool rather than listing all pools. However, the description does not explicitly mention alternatives or when not to use it. There is no direct comparison to list_compute_pools or other describe tools, so an agent must infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It explicitly states that the query is not executed, which is the most important safety property. However, it doesn't mention other behaviors such as whether it requires a running warehouse, whether it reads only, or any limitations on query types. More context would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs in the action, resource, and the critical non-execution qualifier. Every word carries meaning, and the most important information (that it doesn't execute) is front-loaded. There is zero redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one simple string parameter and an output schema (which presumably describes the returned plan structure), the description is adequate but minimal. It tells the agent what it does and that it doesn't execute, but doesn't provide any workflow context, such as typical use cases (e.g., query optimization, debugging) or any prerequisites. The output schema likely covers the return format, so this gap is acceptable, but more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single 'query' parameter, so the description must compensate. It does not elaborate on the parameter at all—no format, examples, or constraints. The name 'query' is self-explanatory because the tool is about SQL queries, but the description adds no additional meaning beyond what the parameter name implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (generate), the resource (EXPLAIN execution plan), and the key qualifier ('without executing it'). This distinguishes it from the sibling snowflake_query tool that actually executes queries, so an agent can immediately understand what this tool does and how it differs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without executing it' implies when to use this tool (when you want to inspect a plan without running the query), but it does not explicitly mention alternatives or when not to use it. No comparison with snowflake_query is made, and there are no clear conditions or exclusions beyond the non-execution aspect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the tool 'Describes' details and running state, implying a read-only operation, but does not explicitly say it is non-mutating, whether the warehouse must exist, or what error handling looks like. It adds no additional behavioral context beyond what the name and verb imply, so it is adequate but not rich. A 3 reflects that it is clear but under-discloses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the verb and resource, and the additional detail about 'running state' is useful without being verbose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple introspection tool with one parameter and an output schema (which we assume exists given the tool definition), the description covers the essential function. It does not explain the output format, but that is handled by the output schema. The description is sufficient for an agent to select and invoke the tool correctly, and the sibling context makes the purpose unambiguous. A 4 is given because it could mention prerequisites (e.g., warehouse existence) but that is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The phrase 'a specific virtual warehouse' maps directly to the warehouse_name parameter, giving it contextual meaning (as opposed to listing all warehouses). However, it does not elaborate on the parameter's format, constraints, or default behavior, and the schema provides only the type. The description adds some value but not enough to warrant a higher score; a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Describe') and resource ('a specific virtual warehouse'), and explicitly mentions 'running state' which adds precision. It clearly differentiates from siblings like list_warehouses (which enumerates), create/drop/resume/suspend/resize (which modify), and get_warehouse_load_history (which focuses on historical load). An agent can immediately understand this is the introspection tool for a single warehouse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting a single warehouse's configuration and state, which is distinct from listing all warehouses. It does not explicitly state when NOT to use it (e.g., when you need load history), but the context is clear. No exclusions are mentioned, so this is a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'list' implies a read-only operation, but the description does not explicitly state that it is non-destructive, does not require special permissions, or mention any other behavioral traits like pagination or result limits. For a simple list operation, this is minimally adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It is front-loaded with the action verb and directly states what is returned, making it highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter scope and that an output schema exists (which presumably details return values), the description is complete for an agent to call the tool correctly. It could mention that it returns only roles (not all grants) or any prerequisites, but the current text is adequate for the operation's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines user_name as a string with no description (0% coverage). The description's phrase 'to a specific user' clarifies that the parameter is the user whose roles are listed, adding meaning beyond the schema. For a single obvious string parameter, this is sufficient context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List roles granted to a specific user' uses a specific verb (list) and resource (roles granted to a user), clearly distinguishing it from siblings like snowflake_list_grants_to_role (roles granted to a role) and snowflake_list_roles (all roles). The meaning is unambiguous and directly tied to the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need the roles for a specific user), but it does not explicitly mention alternatives or exclusions. There is no guidance on when not to use it or how it differs from similar tools, so it relies on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly indicates a read operation ('Retrieve') and lists the returned context fields. It does not disclose edge cases like missing sessions or errors, but for a zero-parameter read, this is largely sufficient. Slight deduction for not explicitly stating read-only behavior or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and the specific context items. Every word adds value, with no repetition or filler. It is appropriately sized for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return formats. For a zero-parameter read that lists the exact fields it retrieves, the description is fully complete. Nothing an agent needs to know to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline per the rubric is 4. The description does not need to explain parameters, and the schema already confirms an empty properties object. No additional parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' with a clear resource 'current active session context' and enumerates the exact fields (user, role, warehouse, database, schema, account). This unambiguously distinguishes it from the many sibling tools, which target other Snowflake objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it (when session context is needed) but does not explicitly state alternatives or exclusions. It is a unique retrieval tool among siblings, so the context is understandable, yet no explicit guidance about when not to use it is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/christianclaudio/mcp-server-snowflake'

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