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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description usefully adds that the window is fixed at the past 7 days and that this is a pre-composed aggregate rather than a raw query, but it says nothing about credit units, latency, or data freshness.

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

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

A single front-loaded sentence with no filler. The scope constraint (7 days) appears immediately after the resources.

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

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

With an output schema present and no parameters, the description needs only to convey purpose and scope, which it does. The remaining gap is routing guidance relative to the many overlapping sibling tools.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; a 4 baseline applies. The description correctly implies a fixed 7-day window with no configurable inputs.

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

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

States a clear verb (summarize) and specific resources (warehouse compute credits, storage consumption) with a bounded scope (past 7 days), which distinguishes it from query-history and load-history siblings. The 'composite recipe' framing is slightly opaque about what exactly is composed or returned, but the core purpose is legible.

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

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

The description gives no when-to-use guidance and never mentions alternatives such as snowflake_get_warehouse_load_history or snowflake_profile_table, which overlap in the cost/usage domain. Usage is only inferable from the topic.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds the useful scoping fact that the transaction binds to the active session, but omits what happens on error, whether autocommit is suspended, and behavior when a transaction is already open.

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

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

A single front-loaded sentence with zero filler; the verb and scope appear immediately. Nothing in the sentence is redundant with the title or annotations.

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

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

An output schema exists, so return values need not be explained, and annotations carry the safety profile. What is missing is transactional lifecycle context (pairing with commit/rollback, session scoping implications, nesting/error behavior) that an agent needs to use this correctly in a sequence of DML calls.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. Schema coverage is nominally 100% and the empty schema matches the description's lack of arguments.

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

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

States a specific verb (begin) and resource (an explicit transaction) scoped to the active session, which is unambiguous. It does not, however, name its natural lifecycle partners snowflake_commit_transaction / snowflake_rollback_transaction, so the transactional grouping must be inferred from sibling names.

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

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

Usage is only implied: an agent can guess this precedes a multi-statement unit of work, but the description never says when to start a transaction versus issuing individual statements, nor that it must be closed with commit or rollback. No explicit when/when-not guidance.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the agent knows this is a mutating operation. The description's only added behavioral fact is that the target must be actively running, but it omits permission requirements, idempotence, and what happens if the query already completed.

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

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

A single front-loaded sentence with no wasted words. Brevity is achieved at the cost of some precision, but nothing is redundant.

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

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

An output schema exists, so return values need not be explained. However, for a destructive, open-world operation the description leaves gaps: how to discover the Query ID, required privileges, and behavior on a non-running query.

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

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

Schema description coverage is 0%, so the description carries the burden. It identifies the single parameter's meaning (Query ID) and that it selects the query to cancel, but gives no format, case, or source for the identifier.

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

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

States a specific verb (Cancel) and resource (Snowflake query), plus the scoping qualifier 'active running' and the identifying key (Query ID). No sibling in the list performs cancellation, so differentiation is implicit rather than explicitly named.

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

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

There is no guidance on when to reach for this tool versus letting a query run, nor on where to obtain a Query ID (e.g., from snowflake_get_query_history). The 'active running' qualifier hints at a precondition but is not framed as usage guidance.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description does add real Snowflake-specific value with 'zero-copy', signaling metadata-only clone semantics with shared underlying storage rather than a data copy. It still omits whether the operation requires ownership/privileges, whether a pre-existing target conflicts, and whether the clone is independent or storage-linked afterwards.

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

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

A single short sentence that is front-loaded with the key verb and the distinguishing 'zero-copy' trait. There is no waste, but the brevity leaves obvious gaps that a second sentence could have filled without bloat.

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

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

An output schema exists, so return values need not be explained. However, for a state-changing object-creation tool, the description supplies no prerequisites, no conflict behavior for an existing target, and no routing against the sibling clone/create-database tools. It is minimally viable rather than complete.

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

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

Schema description coverage is 0% for both required parameters, so the schema provides no semantics at all and the description must compensate. It never mentions source_database or target_database, what naming/qualification rules apply, or what happens if target_database already exists. Parameter names are fairly self-evident, which keeps this above a 1, but the description adds nothing.

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

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

States a specific verb and resource: 'Create a zero-copy clone of a database'. This is clear and distinguishable from non-clone DDL siblings like snowflake_create_database. However, it does not distinguish itself from the closely related snowflake_clone_schema or snowflake_clone_table, which use the same clone concept at different object levels.

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

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

No guidance on when to use a clone versus creating an empty database, no prerequisites (e.g. source database must exist, required privileges), and no mention of alternatives such as snowflake_create_database or snowflake_clone_schema. The agent must infer all usage context.

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

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

Annotations already disclose readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds the meaningful 'zero-copy' semantics (metadata reference rather than physical data duplication), which annotations do not convey. It omits, however, whether the target must be empty/nonexistent or what privileges are required.

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

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

A single front-loaded sentence with zero waste. It is appropriately terse for a name that already conveys much of the action, though the brevity edges toward under-specification given the undocumented parameters.

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

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

An output schema exists, so return values need not be described, but this is a mutating, open-world tool with 0% parameter documentation and no usage guidance. For a clone operation that creates a new schema object, the description does not supply enough context to invoke it confidently.

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

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

Schema description coverage is 0% and the three parameters (database, source_schema, target_schema) are named but entirely undocumented in the schema. The description adds no meaning for any of them, so the agent cannot tell whether 'database' scopes the source, the target, or both.

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

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

States a specific verb+resource ('Create ... clone of a schema') and adds the distinguishing 'zero-copy' qualifier, which separates it from snowflake_create_schema (which creates an empty schema). However, it does not explicitly contrast itself with the sibling create/clone tools, so the differentiation must be inferred.

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

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

There is no when-to-use guidance, no mention of alternatives such as snowflake_create_schema vs clone_schema, and no prerequisites (e.g., target schema must not already exist). The agent is left to infer when cloning is appropriate.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the read/write nature is already conveyed. The description adds genuinely useful Snowflake-specific context via 'zero-copy' (instant, metadata-only, no data duplication), but omits prerequisites such as required privileges or whether an existing target will fail.

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

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

A single front-loaded sentence with zero filler and no redundancy against the schema or annotations. It is efficient, though arguably terse for a mutating operation that carries prerequisites.

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

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

The output schema exists so return values need not be described, and the tool has only two params. However, for a mutation with 0% parameter documentation and no stated prerequisites or name-resolution rules, the description is too thin for an agent to invoke it confidently.

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

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

Schema coverage is 0%, so both parameters are undocumented in the schema and the description does not compensate. It never names or explains source_table or target_table, leaving the agent to guess whether values are qualified names or plain identifiers.

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

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

States a specific verb (create clone) and resource (table) with the defining Snowflake trait 'zero-copy'. It separates the resource target from siblings like snowflake_clone_schema and snowflake_clone_database, but does not distinguish itself from snowflake_clone_table_recipe or explain how it differs from snowflake_create_table.

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

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

No when-to-use, prerequisites, or alternative guidance. It never mentions when a clone is preferable to create_table or clone_table_recipe, and gives no indication that the target must not already exist. The agent must infer all of the routing itself.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false, so the safety profile is largely covered. The description adds that this is a composite recipe executed in one call, but it omits permissions, target-table behavior, and what happens if the target already exists.

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

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

The description is a single front-loaded sentence with no wasted words. It communicates the essential action and the distinguishing Time Travel option immediately.

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

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

Output schema exists, so return values need not be explained. However, for a composite clone tool in a large sibling set, the description leaves out the distinction from snowflake_clone_table and does not fully cover the optional Time Travel parameter semantics.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that at_or_before accepts a Time Travel timestamp or statement ID, which is useful, but source_table and target_table are only self-documenting names and no format details are provided.

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

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

The description gives a specific verb and resource ('Clone table') plus the Time Travel capability, so the core purpose is clear. It does not explicitly distinguish itself from the sibling tool snowflake_clone_table, which weakens sibling differentiation.

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

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

The phrase 'with Time Travel timestamp or statement ID' implies the tool is for cloning a table at a historical point, but there is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The implied context is somewhat useful but far from complete.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the session scoping of the transaction, but says nothing about behavior when no transaction is active, error handling, or that pending DML becomes durable — useful context that is missing.

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

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

A single front-loaded sentence with no filler; the scope qualifier 'current active ... on the session' is placed where it is immediately useful.

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

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

An output schema exists, so return values need not be explained, and there are no parameters to document. Still, for a transaction-control tool the description omits the prerequisite (a transaction must be open) and post-commit state, which is the main thing an agent needs to call it correctly.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate beyond the fact that the target transaction is implicit (the session's current one).

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

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

States a specific verb (Commit) and resource (the current active transaction on the session), so the action is unambiguous. However, it does not distinguish itself from the adjacent lifecycle siblings snowflake_begin_transaction and snowflake_rollback_transaction, which an agent must choose between.

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

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

Usage is only implied: an agent can infer this follows snowflake_begin_transaction and is the alternative to snowflake_rollback_transaction, but neither the prerequisite nor the commit-vs-rollback condition is stated. No when-not guidance is given.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that the operation is natural-language and uses semantic models, but does not disclose latency, cost, or authentication requirements.

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

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

A single sentence with no filler, front-loading the core purpose. Every word earns its place, and there is no redundancy.

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

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

Despite having an output schema and annotations, the description is incomplete for a tool with two parameters and 0% schema coverage. It does not explain the optional semantic_model_path parameter, nor does it give usage context relative to siblings like snowflake_query.

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

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

Schema description coverage is 0%, so the description must compensate for two undocumented parameters. It hints at the 'question' parameter via 'natural language analytical question' and vaguely references semantic models, but never explains the optional semantic_model_path parameter, its format, or what happens when it is omitted.

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

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

The description states a clear verb ('Ask') and resource ('natural language analytical question using Cortex Analyst semantic models'), which distinguishes it from generic SQL query and other Cortex text tools. However, it does not explicitly name alternatives or scope boundaries.

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

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

No when-to-use guidance or alternatives are provided. The description implies it is for analytical questions, but does not say when to choose it over snowflake_query or other Cortex functions.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context such as latency, cost, rate limits, or output format, which are relevant for an LLM completion tool that may involve external model calls.

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

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

The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's action and provides useful model examples without padding.

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

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

With four parameters and 0% schema coverage, the description is insufficient for an agent to call the tool correctly. It omits explanations for required and optional parameters, does not mention output format or how to handle responses, and lacks any usage context despite the tool's complexity.

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

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

Schema description coverage is 0%, so the schema provides no clarifications for any parameter. The description only lists model name examples but does not explain the roles of prompt, max_tokens, temperature, or their defaults. It fails to compensate for the complete lack of schema documentation.

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

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

States a specific verb (Run LLM completion) and clearly identifies the resource (Snowflake Cortex AI). The parenthetical examples of model names ('llama3.3-70b', 'mistral-large2', 'snowflake-arctic') distinguish it from siblings like snowflake_cortex_summarize or snowflake_cortex_sentiment, which are task-specific rather than general completion.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not explain when to choose this over snowflake_cortex_summarize, snowflake_cortex_sentiment, snowflake_cortex_translate, or snowflake_cortex_extract_answer, nor does it mention any prerequisites or constraints.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds useful output context by specifying dense 768-dimensional vectors and the Cortex AI service, but it does not disclose cost, rate limits, model behavior, or other operational traits beyond what annotations provide.

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

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

A single front-loaded sentence with no filler. The action, output, input, and service are all communicated efficiently.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. However, the description is still incomplete for a two-parameter tool because it omits model parameter semantics and gives no usage guidance.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only implies a text input via 'for text' and completely omits the 'model' parameter, including its default and possible model choices.

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

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

States a specific verb ('Generate'), resource ('768-dimensional dense vector embeddings'), and input domain ('text') using Snowflake Cortex AI. This clearly distinguishes it from sibling Cortex tools like complete, summarize, sentiment, and translate.

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

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

The description gives no explicit when-to-use guidance, prerequisites, or alternatives. It implies embedding generation for text but does not say when to choose this over cortex_search, cortex_complete, or other Cortex tools.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the agent knows it's a read-only external-call operation. The description adds nothing beyond this – no model behavior, latency, token limits, or whether the answer is grounded or hallucination-prone. For a Cortex LLM 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.

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

A single front-loaded sentence with no waste. It is concise, though very minimal for the complexity of an LLM extraction tool.

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

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

Given this is an LLM-based extraction tool with openWorldHint, the description is too sparse. It omits usage boundaries vs. sibling Cortex tools, input format expectations, and any behavioral caveats. Output schema exists, so return values needn't be described, but much else is missing.

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

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

Schema description coverage is 0% and the description doesn't clarify what 'source_text' and 'question' mean beyond the names. For example, it doesn't say whether source_text must be a single document or can be concatenated, or question phrasing constraints. With an output schema present, return semantics are handled, but parameter semantics are weak.

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

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

States a specific verb+resource: extract a direct answer to a question from unstructured source text. An agent can distinguish it from siblings like cortex_complete and cortex_summarize. However, it does not explicitly contrast itself with the sibling cortex_summarize or other Cortex text tools.

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

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

No guidance on when to use this over cortex_summarize, cortex_complete, or cortex_search. It implies a question-answering use case but doesn't state exclusions, prerequisites, or alternative selection criteria.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only that this is a semantic search over unstructured text, with no mention of index prerequisites, latency, or how limit/columns affect results. Adequate but thin against a lower annotation-covered bar.

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

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

One front-loaded sentence with no filler or redundancy. It is efficient, though its brevity borders on under-specification for a four-parameter tool.

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

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

An output schema exists, so return values need not be explained. However, with four undocumented parameters, no usage guidance, and no behavioral detail beyond the safety hints, the description leaves the agent without enough to invoke the tool confidently.

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

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

Schema description coverage is 0% for all four parameters, so the schema alone gives no meaning for service_name, query, limit, or columns. The description mentions 'query' and 'index' only implicitly and never explains that service_name identifies the target search service or that limit/columns control result shaping.

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

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

States a clear verb (Query) and resource (Snowflake Cortex Search Service index), and the phrase 'over unstructured text' distinguishes it from SQL-oriented siblings like snowflake_query and from the other cortex_* text tools. It stops short of explicitly naming which sibling it replaces, so it lands at 4 rather than 5.

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

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

No when-to-use guidance is given. With siblings such as snowflake_cortex_complete, snowflake_cortex_extract_answer, and snowflake_query, the agent gets no signal on when semantic index search is the right choice versus an LLM completion or a plain SQL query.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds genuinely useful behavioral detail beyond the annotations: the output is a score on a -1.0 to 1.0 scale. It does not mention cost, latency, language support, or text length limits.

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

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

A single front-loaded sentence with zero filler; the operation comes first and the output range follows. Nothing needs trimming.

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

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

An output schema exists, so return structure need not be explained, and a one-parameter read-only tool is intrinsically simple. The description is nearly sufficient; only input constraints (length, language) are missing to be fully complete.

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

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

Schema description coverage is 0% and there is one parameter, so the description must carry the semantics. 'sentiment of text' implicitly names the input, but adds no detail on format, size limits, language coverage, or whether it accepts one string or a batch. Barely compensates for the coverage gap.

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

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

States a specific verb (analyze sentiment) and resource (text), and even specifies the numeric output range, so an agent knows exactly what operation it performs. It does not explicitly differentiate itself from siblings like snowflake_cortex_complete or snowflake_cortex_summarize, but the purpose is unambiguous on its own.

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

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

Usage is only implied: an agent can infer this is the tool for sentiment scoring of a piece of text. There is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives in the Cortex family (summarize, translate, complete) for cases where the goal is not sentiment.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the useful constraint that only English text is supported, but says nothing about cost, model/feature enablement, input length limits, or latency.

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

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

A single, front-loaded sentence with no filler — everything stated earns its place. It is arguably too terse for the gaps left in parameters and usage, but by structure and size it is efficient.

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

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

An output schema exists, so return values need not be explained. However, for a tool with zero schema description coverage and several closely related Cortex siblings, the description leaves an agent without the constraints needed to call it confidently.

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

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

Schema description coverage is 0% for the single 'text' parameter, so the description carries the burden. It only hints that the input must be English, offering no guidance on length, format, or whether it accepts a single string vs. multiple passages.

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

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

States a specific verb ('Summarize') and resource ('English text') plus the engine ('Snowflake Cortex AI'), so the operation is unambiguous. It does not distinguish itself from siblings like snowflake_cortex_complete, which can also produce summaries, so it stops 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.

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

There is no explicit guidance on when to choose this over snowflake_cortex_complete, snowflake_cortex_extract_answer, or snowflake_cortex_sentiment. Usage is only inferable from the verb, and no prerequisites (e.g., Cortex availability, region, cost) are mentioned.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description restates only that it uses Snowflake Cortex AI, adding no behavioral detail such as latency, token/size limits, cost implications, or whether results are cached.

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

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

A single front-loaded sentence with no filler; the operation is stated immediately. It is efficient, though arguably too terse given the gaps in parameter and behavioral coverage.

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

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

The presence of an output schema means return values need not be explained, but with three fully required parameters at 0% schema coverage and no annotation gaps being filled, the definition leaves key invocation details (language code format, text constraints) unspecified.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning and it does not. It never indicates the expected language format (ISO code vs. full name), whether auto-detect is supported for source_language, or any length limits on text.

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

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

The description gives a specific verb (translate) and resource (text) plus directionality (source to target), so an agent knows exactly what operation this performs versus siblings like cortex_summarize or cortex_sentiment. It does not explicitly name a sibling to differentiate against, but the Cortex-family names already do that work.

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

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

The description says what the tool does but never says when to choose it over alternatives such as cortex_complete (which could also translate) or when it is inappropriate (e.g., long documents). No prerequisites, no exclusions, no routing guidance at all.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds a genuine behavioral rule beyond the schema: confirm=True is required for destructive actions, which is valuable safety context the annotations do not convey. There is mild tension with destructiveHint=false (the tool's action SQL can destroy data), but calling this a full contradiction would be harsh since the confirm guard exists precisely for that case.

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

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

Two tight sentences, front-loaded with the purpose before the safety rule, with no filler. It is efficient, though the brevity is partly under-specification rather than economy.

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

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

An output schema exists, so return values need no explanation, but for a 9-parameter write tool with a required warehouse, no defaults documented, and no context fallback described, the definition is thin. Notably missing: Snowflake creates alerts suspended (requiring resume_alert), and behavior when the alert already exists.

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

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

Schema description coverage is 0% across 9 parameters, so the description carries the full burden — and it only names four of them (schedule, condition_sql, action_sql, confirm). alert_name, warehouse_name, database, schema_name and comment are left completely unexplained, including whether database/schema fall back to the session context.

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

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

States a specific verb and resource ('Create an alert') and names the three defining parameters (schedule, condition SQL, action SQL) that distinguish the operation. However, it does not distinguish itself from siblings like snowflake_create_task or snowflake_create_pipe, which have near-identical shapes, so an agent gets no explicit routing help.

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

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

The only usage guidance is 'Destructive actions require confirm=True', which hints at a prerequisite but never says when to prefer this tool over snowflake_create_task, nor what environmental conditions (warehouse, database/schema context) must hold first. No alternatives, no when-not-to-use.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the write nature is covered. The description adds nothing beyond that—it does not mention required privileges, the fact that the default if_not_exists=true silently no-ops on an existing database, or that creation is effectively permanent.

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

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

A single front-loaded sentence with no padding, which is structurally sound. However, 'in Snowflake' is redundant given the tool name, and the sentence is so minimal that brevity comes at the cost of omitted essential detail.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. Even so, a mutation tool with four undocumented parameters—including one whose default silently suppresses errors—needs more description than a bare one-liner to be called correctly.

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

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

Schema description coverage is 0% for four parameters. The description names the resource, which weakly implies the required 'name' argument, but says nothing about 'comment', 'data_retention_time_in_days', or the significant behavior of 'if_not_exists' (default true). It fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('Create a new database'), which tells an agent exactly what the tool does. It does not differentiate itself from siblings like snowflake_clone_database or snowflake_create_schema, but the verb+resource combination is unambiguous on its own.

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

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

There is no guidance on when to use this versus alternatives such as snowflake_clone_database or snowflake_create_schema, nor any statement of prerequisites (privileges, active role, warehouse context). The description is purely declarative.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds only the ingestion-purpose hint and says nothing about how auto_ingest changes behavior, what if_not_exists defaults to, permission requirements, or idempotency—context that would genuinely help for a create operation.

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

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

A single front-loaded sentence with no waste—but it is under-specified rather than concise, carrying no routing or behavioral detail. Brevity alone isn't a strength when the content is this thin.

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

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

An output schema exists so return values need not be described, but for a mutating 6-parameter create tool with 0% schema coverage the description is materially incomplete: no parameter meaning, no safety/permission notes, and no usage context.

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

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

Schema description coverage is 0% across 6 parameters, so the schema documents nothing. The description compensates for none of it: pipe_name, copy_statement, auto_ingest, if_not_exists, database, and schema_name are all unexplained, including which two are required.

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

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

States a specific verb and resource ('Create a Snowpipe') plus its domain ('continuous ingestion'), which separates it from sibling verbs like drop_pipe, list_pipes, and get_pipe_status. It's clear but does not explicitly name or contrast with those siblings.

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

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

The phrase 'for continuous ingestion' gives a hint of context, but there is no guidance on when to create a pipe versus alternatives, no prerequisites, and no exclusions. The agent must infer the entire usage situation from the name.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds no behavioral context beyond that - nothing about required privileges, whether the operation is idempotent given if_not_exists defaults to true, or what happens on conflict or failure. It carries no information the annotations do not already provide.

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

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

A single front-loaded sentence with no filler or redundant clauses. It is efficient, though the brevity here reflects under-specification rather than tight editing.

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

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

For a mutating creation tool with an output schema (so return values need not be explained), the description still omits the essentials: required privileges, the meaning of if_not_exists, and any placement relative to sibling role/object-creation tools. An agent cannot call this confidently from the description alone.

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

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

Schema description coverage is 0% across three parameters (role_name, comment, if_not_exists), and the description supplies no meaning for any of them. In particular, if_not_exists defaulting to true and the optional comment field are completely undocumented, so the description fails to compensate for the coverage gap.

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

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

The description states a specific verb and resource (create a role in Snowflake), so the operation itself is unambiguous. However, it is essentially a restatement of the tool name/title and offers no differentiation from related siblings like snowflake_drop_role, snowflake_describe_role, or snowflake_create_user. It is clear but adds almost nothing beyond what the name already tells the agent.

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

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

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites such as the required privilege to create roles, and no note on when if_not_exists behavior is relevant. 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.

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the mutation/safety profile is partly covered. The description adds no behavioral context such as required privileges, what happens if the schema already exists (relevant given if_not_exists defaults to true), or the effect of omitting 'database'.

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

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

A single short sentence with the object and scope front-loaded; there is no filler or redundancy. It is efficient but sparse rather than deliberately structured around what the caller needs to know.

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

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

An output schema exists, so return values need no explanation, but this is a DDL mutation tool with 4 parameters at 0% schema coverage and no usage or prerequisite context. The default-true if_not_exists (idempotency) and the unnamed database fallback are material omissions.

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

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

Schema description coverage is 0% and the description must therefore carry the full burden, but it only obliquely gestures at the 'database' parameter via 'specified database'. The required 'name', the optional 'comment', and the 'if_not_exists' default of true are entirely unexplained, including whether the call is idempotent.

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

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

States a specific verb+resource ('Create a new schema') and a scope ('inside a specified database'), which is enough to distinguish it from read-oriented siblings like snowflake_list_schemas or snowflake_describe_schema. It doesn't explicitly differentiate from snowflake_clone_schema or snowflake_create_database, so it stops 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.

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

The description gives no when-to-use or when-not-to-use guidance and names no alternatives. Nothing tells the agent whether this is preferred over clone_schema or what prerequisites (existing database, active role) are needed.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the agent knows this is a non-destructive creation operation. The description adds the 'internal' qualifier but omits key behavioral details such as idempotency (if_not_exists default true), required privileges, or what happens on conflicts. This is below the bar for a creation tool with five parameters.

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

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

One short sentence, front-loaded, no filler. However, the brevity leaves the definition under-specified for the operation's complexity.

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

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

With an output schema present, return values need not be explained, but the definition still leaves the agent guessing about optional parameters, default behavior (if_not_exists defaults true), and scoping (database/schema). For a creation tool with five parameters and zero schema descriptions, this is inadequate.

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

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

Schema description coverage is 0%, so the description must compensate. It only implies a stage name and says 'internal', leaving database, schema_name, comment, and if_not_exists completely unexplained. No parameter meaning is added beyond what the schema names already suggest.

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

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

The description states a specific verb and resource ('Create an internal named stage') and the object type is clear against siblings like snowflake_drop_stage or snowflake_list_stages. It does not differentiate itself from other create tools beyond resource name, but the combination is unambiguous.

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

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

There is no guidance on when to use this tool, prerequisites, or alternatives. The word 'internal' hints at a distinction from external stages, but no such alternative is named or excluded.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so safety is partly covered. The description adds no behavioral context: it does not explain CDC staleness, that if_not_exists defaults to true, what append_only changes, or what happens on failure.

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

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

A single front-loaded sentence with no wasted words. It is structurally fine but so terse that it omits needed information, which is under-specification rather than true conciseness.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a six-parameter creation tool with zero schema coverage, the description omits parameter meaning, defaults, and prerequisites, leaving the agent under-informed.

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

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

Six parameters with 0% schema description coverage, and the description mentions none of them. The meaning of append_only, if_not_exists, and the optional database/schema_name qualifiers is undocumented in both schema and description, so the description does not compensate for the coverage gap.

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

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

States a specific verb ('Create') plus resource ('CDC stream') and names the supported target objects ('table or view'). It is distinguishable from siblings like snowflake_drop_stream and snowflake_read_stream_changes, though it does not explicitly contrast itself with them.

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

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

No when-to-use guidance, no prerequisites (e.g., required privileges or that a stream must be refreshed/consumed), and no mention of alternatives such as drop_stream or read_stream_changes. The agent must infer all usage context.

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

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

Annotations already disclose that this is a non-read-only, non-destructive, open-world write operation. The description adds no further behavioral context such as required privileges, default if_not_exists behavior, or whether the operation is transactional. It only restates the purpose without enriching the safety or execution profile.

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

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

The definition is a single front-loaded sentence with no filler. It is appropriately concise, though the phrasing 'column definitions SQL' is slightly awkward. The brevity is efficient but leaves the sentence carrying little structure.

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

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

With five parameters, 0% schema description coverage, and a large sibling set, the description is incomplete. It does not clarify optional database/schema scoping, the default behavior of if_not_exists, or the expected SQL syntax. The presence of an output schema and annotations helps, but the input contract remains under-explained.

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

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

Schema description coverage is 0%, so the description must explain the five parameters, but it only vaguely references column definitions. It does not explain database, schema_name, table_name, or if_not_exists. The single phrase 'specified column definitions SQL' adds minimal meaning beyond the parameter name columns_sql.

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

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

The description states a specific verb and resource: "Create a table in Snowflake." It distinguishes this from sibling operations like create_schema or create_database by naming the object type. It does not, however, differentiate from related table operations such as clone_table or undrop_table.

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

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

The description gives no when-to-use guidance or alternatives. It does not mention clone_table, undrop_table, or when to prefer creating over cloning. An agent receives only the implied use from the verb 'Create'.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only the 'scheduled or serverless' nuance and says nothing about required privileges, what if_not_exists=true does when the task exists, or side effects of creating a scheduled task.

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

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

A single front-loaded sentence with no filler. It is appropriately short, though it borders on under-specification rather than true conciseness.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. But with 7 undocumented parameters at 0% coverage, a mutation tool, and a complex scheduling domain, the description is far too thin to let an agent invoke it correctly.

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

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

Schema description coverage is 0% across 7 parameters, so the schema supplies names only. The description mentions scheduling and serverless concepts but never maps them to the schedule, warehouse, database/schema_name, or if_not_exists parameters, leaving the burden unmet.

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

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

The description states a clear verb+resource ('Create ... task') and the 'scheduled or serverless' qualifier narrows the kind of task. It does not, however, explicitly distinguish this from siblings like snowflake_create_alert or snowflake_execute_task, 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.

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

There is no when-to-use guidance, no prerequisites, and no routing to alternatives such as snowflake_execute_task or snowflake_create_alert. The agent is left to infer the usage context entirely.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond this, such as authentication requirements, handling of existing users, password behavior, or whether if_not_exists affects errors.

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

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

A single front-loaded sentence with no wasted words. It is appropriately compact, though the trailing clause about default role and warehouse can read as if those are always set rather than optional defaults.

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

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

For a mutation tool with 6 parameters at 0% schema description coverage and only 1 required parameter, this one-sentence description is too thin. An output schema exists, so return values need not be explained, but prerequisites and parameter meaning are missing.

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

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

Schema description coverage is 0% across 6 parameters, so the description must compensate. It only alludes to default role and warehouse, leaving user_name, password, comment, and if_not_exists undocumented in both schema and description.

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

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

States a specific verb and resource ('Create a new Snowflake user') and adds scope ('with default role and warehouse'). Clear enough to distinguish from siblings like snowflake_list_users and snowflake_describe_user, but it does not explicitly name or contrast with alternatives.

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

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

Provides no guidance on when to use this tool versus alternatives, no prerequisites, and no conditions such as required privileges or whether the user must not already exist. The agent gets only the bare purpose.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the write nature is covered. The description adds nothing beyond that: no mention of IF NOT EXISTS behavior, cost implications of auto-suspend/auto-resume, size constraints, or required privileges for a warehouse-creation operation.

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

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

One front-loaded sentence with zero waste, but the brevity borders on under-specification rather than disciplined conciseness. It is efficiently structured but does almost no work.

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

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

An output schema exists so return values need no explanation, but for a six-parameter, 0%-documented mutation tool the description is far too thin. It omits parameter meaning, privilege requirements, and cost/behavioral context that an agent needs before creating a warehouse.

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

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

Schema description coverage is 0% across six parameters, and the description names none of them. warehouse_size, auto_suspend, auto_resume, if_not_exists, and comment are left entirely unexplained, so an agent gets no help on what values are valid or what defaults mean.

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

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

The description states a specific verb (Create) and resource (virtual warehouse) in Snowflake, which puts it clearly in the create-family alongside create_database/create_schema. It does not explicitly differentiate itself from those siblings, but the resource noun makes selection unambiguous in practice.

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

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

There is no guidance on when to create a warehouse versus resizing an existing one (snowflake_resize_warehouse) or how it relates to siblings like snowflake_create_schema. Usage is only implied by the tool name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety and reach of the operation are covered. The description adds that the operation surfaces condition SQL, action SQL, schedule and warehouse — useful inspection context — but says nothing about permission requirements or error behavior when the alert does not exist.

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

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

A single economical sentence with the verb and resource front-loaded and no filler. It is appropriately sized for the task, though the enumerated return fields read more like an output summary than guidance on invoking the tool.

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

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

An output schema exists, so the description need not explain return values, and annotations carry the safety profile. The remaining gap is the optional database/schema_name qualifiers, whose role in resolving the alert_name is left unexplained — a moderate shortfall for a 3-param lookup tool.

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

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

Schema description coverage is 0%, so the description must compensate for three undocumented parameters (database, alert_name, schema_name) and does not. The word 'warehouse' in the description refers to a returned attribute, not the optional database/schema_name qualifiers, so it adds no parameter meaning — particularly unclear whether database/schema_name are needed to disambiguate the alert name.

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

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

States a specific verb (describe) and resource (alert) and enumerates the attributes returned — condition SQL, action SQL, schedule, warehouse. This lets an agent distinguish it from siblings like snowflake_list_alerts (enumeration) and snowflake_create_alert/drop_alert (mutation). It does not explicitly name those siblings, 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.

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

There is no when-to-use guidance, no mention of prerequisites, and no routing to alternatives. An agent can infer it inspects an existing alert, but nothing states when this is preferable to snowflake_list_alerts or how it relates to the other alert tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond that — no statement about permissions required, whether the pool must exist, or failure behavior — and its field list is return-value information already carried by the output schema.

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

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

A single front-loaded sentence that names the action and the returned attributes with no filler. Nothing in it is wasted.

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

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

An output schema exists, so return values need not be explained (and the description's field list is partly redundant with it), and annotations cover the read-only nature. The remaining gap is routing: nothing tells the agent to resolve pool_name via snowflake_list_compute_pools first, so the definition is adequate but not complete.

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

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

Schema description coverage is 0% for the single required parameter pool_name. The description does not explain the identifier's format, qualification, or case sensitivity, so it only marginally compensates; the parameter name itself is largely self-explanatory, keeping this at the baseline.

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

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

States a clear verb (describe) plus resource (compute pool) and enumerates the attributes returned (instance family, min/max nodes, active nodes, state). This separates it from sibling mutators like snowflake_resume_compute_pool and snowflake_suspend_compute_pool, though it does not explicitly contrast itself with snowflake_list_compute_pools.

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

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

No when-to-use guidance is given. There is no indication of when to prefer this over snowflake_list_compute_pools (which would find the pool name first) or when a describe is warranted versus a direct resume/suspend call. Usage is only inferable from the verb 'describe'.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds which attributes are returned, but says nothing about privilege requirements (Snowflake metadata visibility depends on role grants), missing-database errors, or whether it requires the database to be the active context.

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

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

One front-loaded sentence with zero filler, and the key payload (what fields come back) leads. It is arguably under-specified for a metadata tool, but nothing in the sentence is wasted.

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

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

An output schema exists, so return values need not be explained, and annotations carry the safety profile. For a low-complexity single-parameter describe call, the remaining omission (privilege/visibility caveats) is minor.

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

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

The single parameter database_name has 0% schema description coverage, and the description never mentions the argument at all — no format, qualification, or case-sensitivity guidance to compensate. With one undocumented parameter, the schema does none of the work and the description does none either.

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

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

States a specific verb ('Describe') plus the target resource ('a database') and enumerates what is surfaced: properties, owner, retention time, comment. That is enough to distinguish it from snowflake_list_databases or snowflake_get_database_ddl, though it never names those siblings explicitly.

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

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

There is no when-to-use, when-not-to-use, or alternative-tool guidance. An agent must infer from the name alone that this is the metadata-inspection call rather than list_databases, get_database_ddl, or describe_schema.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the list of attributes returned (lag, warehouse, query text), which is mild context but overlaps with the output schema. No mention of permissions, cross-database resolution, or error behavior.

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

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

A single front-loaded sentence with no filler; the key resource and returned attributes come first. It is efficient, though slightly terse given the unaddressed parameters.

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

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

An output schema exists, so return-value explanation is not strictly required, and annotations cover the read-only nature. However, with zero parameter documentation and no usage context for a three-parameter tool, the description is only minimally complete.

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

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

Schema description coverage is 0% across three parameters (database, table_name, schema_name). The description mentions no parameter names, no defaulting behavior, and no guidance on whether database/schema must be qualified when table_name is ambiguous. The description does not compensate for the coverage gap.

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

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

States a specific verb (Describe) and a specific resource (dynamic table), plus the attributes it surfaces: definition, target lag, warehouse, query text. This implicitly separates it from snowflake_describe_table, but it never names or contrasts with that sibling explicitly.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as snowflake_describe_table, snowflake_get_table_ddl, or snowflake_list_dynamic_tables. The agent must infer that this is the right tool for dynamic tables only.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only a list of returned attributes, which the output schema already conveys; it does not mention prerequisites or permission needs. With annotations carrying the load, a 3 is appropriate.

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

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

A single tight sentence with zero filler and the resource front-loaded. It is efficient, though its brevity is part of why parameter and usage gaps exist.

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

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

Output schema exists, so return values need not be re-explained, and annotations cover safety. However, for a 3-parameter tool with 0% schema coverage and no usage routing, the definition is only minimally adequate for correct invocation.

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

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

Schema description coverage is 0% across 3 parameters, so the description must compensate and does not. It says nothing about function_signature format (e.g., name(arg_types)) nor about how database/schema_name scope the lookup, leaving required overloading semantics undocumented.

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

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

States a specific verb+resource (describe UDF function) and enumerates what is returned: signature, return type, language, body. The 'UDF/function' framing implicitly separates it from snowflake_describe_procedure, though it never names that sibling or snowflake_list_functions explicitly.

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

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

No when-to-use guidance, no conditions, and no mention of the obvious alternatives (snowflake_list_functions to enumerate, snowflake_describe_procedure for stored procedures). 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.

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

Annotations already mark it read-only, non-destructive, and open-world. The description adds that it inspects Iceberg-specific metadata (catalog integration, external volume), which is modest scope context, but no permissions, limits, or edge behavior are disclosed.

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

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

One front-loaded sentence with no filler; it immediately states the action and scope.

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

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

Output schema and annotations cover return shape and safety, so the description need not repeat those. However, with zero schema parameter descriptions and no routing guidance versus sibling describe tools, the definition is minimally complete rather than fully self-sufficient.

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

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

Schema description coverage is 0% for three parameters, and the description does not name or explain table_name, database, or schema_name. It only implies a table is required, leaving all parameter semantics to the bare schema.

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

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

Names the verb (describe) and the exact resource (Iceberg table), and scopes the inspected metadata to schema, catalog integration, and external volume. It does not explicitly contrast with snowflake_describe_table or snowflake_list_iceberg_tables, so it is clear but 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.

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

No when-to-use or when-not-to-use guidance. It does not mention alternatives such as snowflake_describe_table for standard tables or snowflake_get_table_ddl for DDL, and no prerequisites are stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the agent knows this is a safe read against a live account. The description adds only the return contents, which the output schema already covers, and says nothing about permissions needed or how unqualified names resolve.

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

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

A single front-loaded sentence that states the action and its outputs with zero filler. Nothing to trim and nothing buried.

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

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

For a read-only describe tool with an output schema and a simple qualified-name parameter set, the description is just adequate. It omits how the optional database/schema qualifiers default when policy_name is unqualified, which is a real ambiguity given the sibling context tools.

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

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

Schema description coverage is 0%, so the description carries the full burden for the three parameters, yet it mentions none of them. It does not explain that database and schema_name are optional qualifiers defaulting to the current context, which is the one piece of semantics an agent actually needs.

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

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

The description names a specific verb (describe) and resource (masking policy) and even enumerates what is returned: signature, return type, and body. That distinguishes it from snowflake_list_masking_policies, but it never explicitly routes the agent away from that sibling, so it stops short of the top band.

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

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

There is no statement of when to use this tool versus snowflake_list_masking_policies or snowflake_describe_row_access_policy, and no prerequisites (e.g., required privileges) are mentioned. Usage is only implied by the word 'describe.'

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful content context by naming what is returned, but says nothing about permissions needed or behavior for a nonexistent policy.

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

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

A single tight sentence that front-loads the tool's purpose with zero filler. It is efficient, though it spends most of its length on fields that an output schema likely already covers.

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

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

An output schema exists, so the return shape does not need to be spelled out here, and this is a simple read-only tool with one parameter. The only real gap is the unexplained argument format, which is minor for such a straightforward operation.

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

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

Schema description coverage is 0% – policy_name carries only a type with no documentation. The description does not compensate by explaining the expected identifier form (e.g., whether it is a bare name or a fully qualified/account-level reference), leaving the single required parameter underspecified.

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

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

States a specific verb (describe) plus resource (network policy) and even enumerates the returned fields (allowed IP lists, blocked IP lists, comments). It implicitly separates itself from snowflake_list_network_policies, but never names the sibling to sharpen the boundary.

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

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

Usage is only implied by the verb 'describe' – an agent can infer this is for inspecting a single policy's configuration. There is no explicit when-to-use, no mention of the list sibling, and no prerequisites such as required role or policy-name format.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered externally. The description adds only that it returns mode/type/value-list, which is largely restated by the output schema; it says nothing about qualification requirements or empty-result behavior.

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

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

A single economical sentence with no filler. It is front-loaded with the verb, though the parenthetical enum lists make it read more like a return-value spec than an instruction.

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

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

An output schema exists, so return values need not be re-explained, and the description roughly matches that scope. However, for a tool with two undocumented optional qualifiers it should at least indicate how the rule is resolved, which it does not.

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

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

Schema description coverage is 0% for three parameters (rule_name, database, schema_name), so the description carries the full burden of explaining them. Instead it never mentions the parameters or how the optional database/schema_name qualify the rule name, leaving the agent to guess at scoping.

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

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

States a specific verb (Describe) and resource (network rule), and enumerates the attributes returned (mode, type, value list), which distinguishes it from the sibling snowflake_list_network_rules. It is clear what the tool acts on, though it is framed around the returned fields rather than 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.

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

No when-to-use context is given, and no alternative is named. The agent must infer that this is the per-object counterpart to snowflake_list_network_rules; nothing in the text routes it there or states prerequisites.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds some context by listing the constraint categories it returns, but does not disclose authentication needs, identifier qualification behavior, or other operational traits. This is a modest but not rich addition beyond the structured metadata.

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

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

The description is a single front-loaded sentence with no filler. It immediately states the action and the relevant constraint categories, and every word earns its place.

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

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

Although an output schema and read-only annotations exist, the description is incomplete for an object-description tool with three parameters and 0% schema description coverage. It does not explain how to identify the target policy or how database and schema_name affect resolution, leaving important invocation details missing.

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

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

Schema description coverage is 0%, and the description does not explain any of the three parameters. It never mentions policy_name, database, or schema_name, nor does it clarify that policy_name is required or how database/schema qualify the lookup. With three undocumented parameters, the description fails to compensate for the schema gap.

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

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

The description states a specific verb and resource: describe a Snowflake password policy. It also enumerates the kinds of constraints returned (min length, lockout time, history, age), which helps distinguish it from list_password_policies. It stops short of explicitly naming that sibling, so it is clear but not maximally differentiated.

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

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

There is no guidance on when to use this tool versus list_password_policies or other policy-description tools. The implied usage is merely to inspect an existing policy, with no prerequisites, exclusions, or alternative paths mentioned.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only that the result includes the pipe definition and COPY statement, with no mention of permissions or behavior when the pipe doesn't exist.

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

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

A single front-loaded sentence with no filler. It is efficient, though the brevity reflects under-specification rather than tight writing.

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

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

An output schema exists, so return values needn't be detailed, but with 0% parameter coverage and no usage context or scoping rules, the description leaves too much for the agent to infer about a three-parameter tool.

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

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

Schema description coverage is 0%, so the description carries the full burden for three parameters. It says nothing about pipe_name being the required target or that database/schema_name are optional qualifiers, leaving all three parameters undocumented.

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

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

States a specific verb (describe) and resource (pipe), and even names what the output covers (pipe definition and COPY statement). This differentiates it from siblings like snowflake_list_pipes, snowflake_create_pipe, and snowflake_get_pipe_status, though it doesn't explicitly call them out.

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

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

There is no guidance on when to use this versus snowflake_list_pipes (enumerate pipes) or snowflake_get_pipe_status (runtime state). The agent must infer the difference 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.

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

The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds useful content about what metadata is retrieved (signature, return type, language, definition body), but does not disclose privilege requirements or other operational context.

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

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

The definition is a single front-loaded sentence with zero wasted words. It efficiently enumerates the exact metadata fields returned without unnecessary elaboration.

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

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

An output schema exists, so return values need not be explained in detail, and annotations cover safety. However, the description omits critical parameter semantics and any usage guidance for a tool whose required procedure_signature input is otherwise undocumented.

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

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

Schema description coverage is 0% for three parameters, and the description provides no meaningful parameter guidance. It does not explain the required procedure_signature format or the optional database and schema_name qualifiers, leaving the agent without necessary invocation details.

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

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

States a specific verb ('Describe') and a precise resource ('procedure signature, return type, language, and definition body'). An agent can distinguish it from sibling tools like snowflake_list_procedures, which lists procedures rather than retrieving detailed metadata.

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

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

The description gives no explicit when-to-use guidance, prerequisites, or alternatives. It leaves the agent to infer that this tool is used when detailed procedure metadata is needed, but does not mention sibling list_procedures or any conditions for choosing between them.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered without description help. The description adds only that grants are included in the response, which is closer to output content than behavioral disclosure; it does not mention permissions needed, latency, or pagination.

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

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

A single clean sentence with no filler and the key noun (role) front-loaded. It is arguably terse for a tool whose schema is undocumented, but there is no wasted language to cut.

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

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

Output schema exists, so return values need not be explained, and annotations cover safety for this read-only describe tool. The remaining gap is the absence of any routing signal against the many sibling describe/list role and grant tools.

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

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

Schema description coverage is 0% for the single role_name parameter, so the schema adds nothing. The description implies a role is the target but gives no naming convention, qualification (e.g. DB.ROLE vs ROLE), or case-sensitivity guidance; the parameter name is self-evident enough to keep this at a baseline 3.

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

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

States a specific verb+resource ("Describe role") and names what the result contains (properties and assigned grants), which is more informative than a tautology. It does not, however, distinguish itself from close siblings such as snowflake_list_roles or snowflake_list_grants_to_role, which cover overlapping ground.

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

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

There is no guidance on when to call this versus snowflake_list_roles, snowflake_list_grants_to_role, or snowflake_describe_user. The agent must infer usage purely from the name, and no prerequisites or exclusions are stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful context by naming the returned components (signature, filter expression, comment), but says nothing about permissions needed or how database/schema resolution behaves, so it is only modestly additive.

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

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

A single front-loaded sentence that states the action and the returned fields with zero filler. Nothing is padded or redundant.

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

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

An output schema exists, so the description needn't explain return formatting, and it does list the returned fields. However, with 0% parameter documentation and no note on identifier resolution or permissions, an agent is left guessing about a non-trivial part of the call.

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

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

Schema description coverage is 0% and all three parameters (database, policy_name, schema_name) are undocumented. The description mentions 'a row access policy' but never explains the required policy_name or how the nullable database/schema qualifiers resolve (current database/schema vs fully-qualified), so it fails to compensate for the coverage gap.

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

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

The description states a specific verb (Describe) and resource (row access policy) and even enumerates what is returned: signature, filter expression, and comment. That distinguishes it from snowflake_list_row_access_policies, though it never names the sibling explicitly, 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.

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as snowflake_list_row_access_policies or snowflake_describe_masking_policy. Usage must be inferred entirely 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.

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the returned field categories, but omits any auth/permission requirements, the effect of the optional database parameter, or behavior when the schema does not exist.

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

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

A single front-loaded sentence with no wasted words. It is efficient, though its terseness leaves semantic gaps rather than being over-long.

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

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

An output schema exists so return values need not be described, and the read-only annotations cover safety. The remaining gap is undocumented parameter semantics at 0% coverage, leaving the definition only minimally adequate.

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

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

Schema description coverage is 0% for two parameters, and the description never explains the meaning of schema_name or the optional database fallback. The mentioned fields (owner, retention settings) are return values, not parameters, so the description does not compensate for the coverage gap.

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

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

States a clear verb+resource (describe schema) and enumerates the returned aspects (properties, owner, retention settings), which distinguishes it from snowflake_list_schemas. However, it does not explicitly contrast against siblings like snowflake_describe_database, so sibling differentiation is only implied.

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

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

There is no when-to-use guidance, no mention of prerequisites (e.g., needing the database context), and no reference to alternatives such as snowflake_list_schemas. The agent must infer the usage context entirely.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful non-annotation context: the operation deliberately does not expose the secret value, which matters for a security-sensitive object. It stops short of noting permission requirements or error behavior when the secret does not exist.

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

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

A single front-loaded sentence with no filler; every clause (metadata, type values, owner, no value exposure) contributes distinct information.

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

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

An output schema exists, so return-value detail is not required, and for a simple describe tool the description covers purpose, scope, and the key security caveat. The only real gap is parameter guidance, which is partly mitigated by self-evident parameter names.

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

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

Schema description coverage is 0% across three parameters (database, schema_name, secret_name), so the description is expected to compensate and does not: it never mentions any parameter, its optional/default-null status, or the fully-qualified-name conventions. The names are largely self-explanatory, which keeps this above a 1, but no added meaning is provided.

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

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

States a specific verb (Describe) and resource (secret) and enumerates the returned metadata: type with its allowed values (GENERIC_STRING, OAUTH2) and owner. The added 'without exposing secret value' clause cleanly separates it from snowflake_list_secrets and from any tool that would retrieve the secret's contents.

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

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

Usage is implied rather than stated: an agent can infer it inspects a single secret and that snowflake_list_secrets finds the name first, but there is no explicit when-to-use versus alternatives, no prerequisite about needing database/schema context, and no note on when describing is preferable to listing.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, so safety is covered by structured data. The description adds no behavioral context beyond annotations: no note on permissions, no result format, no failure modes when the stage is missing. With annotations carrying the safety burden the bar is lower, but this adds almost nothing extra.

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

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

One efficient sentence with no filler and the primary resource front-loaded. Its brevity is appropriate, though it borders on under-specification for a describing tool.

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

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

An output schema exists so return values needn't be explained, but the description is otherwise thin: no usage guidance, no parameter semantics, no prerequisites. For a describe tool with 0% param coverage, this leaves meaningful gaps.

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

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

Schema description coverage is 0% for three parameters. The description mentions the stage object but does not explain database/schema_name qualification semantics, nor whether omitting them falls back to the current context. It fails to compensate for the coverage gap.

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

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

States a clear verb+resource ('Describe stage') and enumerates what is returned (URL, storage integration, file format properties). This distinguishes it from write siblings like snowflake_create_stage or snowflake_drop_stage, though it doesn't explicitly contrast with snowflake_list_stages or snowflake_list_stage_files.

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

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

No when-to-use context, no prerequisites, and no routing to alternatives such as snowflake_list_stages (enumeration) or snowflake_list_stage_files (contents). The agent is left 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.

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that output includes stale status and source table, which is useful content context, but says nothing about how staleness is determined or what auth is needed.

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

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

A single front-loaded sentence with zero filler; every clause adds a distinct piece of information about what is returned.

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

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

An output schema exists, so return values need not be explained. However, with 0% parameter coverage and no usage guidance, the definition leaves the caller without enough context to know how to qualify the stream name in multi-database environments.

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

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

Schema description coverage is 0% and none of the three parameters (database, schema_name, stream_name) are documented. The description does not explain the optional database/schema_name nullability or default behavior, so it fails to compensate for the schema gap.

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

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

The description states a specific verb (describe) and resource (stream) and even lists what is returned: metadata, source table, and stale status. This distinguishes it from snowflake_list_streams and snowflake_read_stream_changes, though it never names those siblings explicitly.

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

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

There is no guidance on when to use this tool versus siblings like list_streams (bulk listing) or read_stream_changes (consume changes). Usage is only implied by the word 'describe'; no prerequisites or alternatives are stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds value by naming the three attributes it surfaces (root location, stage, warehouse), but says nothing about permissions or behavior when the named Streamlit does not exist.

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

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

A single front-loaded sentence with no filler. It is efficient, though the terse fragment form leaves room to state scope or qualification without bloat.

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

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

An output schema exists, so return-value explanation is not required, and annotations carry the safety profile. However, with 0% parameter coverage the definition leaves the qualification semantics (database/schema) unexplained, which is a real gap for an object-resolution tool.

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

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

Schema description coverage is 0% across 3 parameters, so the description must compensate and does not. It never mentions streamlit_name, nor the optional database/schema_name qualifiers that determine where the Streamlit app is resolved.

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

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

States a specific verb+resource ('Describe Streamlit application') and enumerates what is returned: root location, stage, and query warehouse. An agent can distinguish it from snowflake_list_streamlits, though the description never names that sibling.

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

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

No when-to-use guidance, no exclusions, and no mention of the alternative snowflake_list_streamlits (or the fact that this describes a single app rather than enumerating them). The agent must infer the usage context entirely.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds which attributes are returned, which is useful, but says nothing about error behavior when the object does not exist or how unqualified names are resolved, and an output schema already exists for return shape.

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

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

A single front-loaded sentence with no filler; every element (columns, types, nullability, primary keys) is informative and nothing is repeated from the schema or annotations.

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

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

The existence of an output schema means return values need no further explanation, and the scope ('table or view') is stated. However, for a three-parameter tool with zero schema description coverage, the omission of name-resolution semantics leaves a real gap.

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

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

Schema description coverage is 0% for all three parameters (database, table_name, schema_name), so the description must compensate and does not. It never explains how the optional database/schema_name interact with table_name or whether the current session context is used as a default.

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

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

States a specific verb (describe) and resource (table or view) plus the exact metadata returned: column definitions, data types, nullability, primary keys. That distinguishes it implicitly from list_tables and get_table_ddl, but no sibling is named and the view/table overlap with siblings like describe_iceberg_table is left for the agent to infer.

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

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

There is no when-to-use guidance and no routing to alternatives such as get_table_ddl (full DDL), sample_table, or profile_table, which an agent could easily confuse with this tool. Usage is only implied by the word 'describe'.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. However, the description adds no behavioral context beyond that – no mention of permissions, response format, or openWorldHint implications. With no output schema details in the description (though output schema exists), 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.

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

A single short sentence, front-loaded and waste-free. It communicates the core action without extraneous detail.

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

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

Given a 3-parameter tool with 0% schema coverage and no output schema details in the description, it is missing necessary context for correct invocation – especially the role of database and schema_name in resolving the tag. The description is too sparse to be complete.

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

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

Schema description coverage is 0%, so the description must compensate for three parameters. It mentions 'tag properties' but does not explain database, schema_name, or tag_name format or defaults. The description offers almost no semantic clarification for any parameter.

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

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

States a specific verb (Describe) and resource (tag) plus the properties returned (allowed values, comment). Clear purpose, though it does not explicitly differentiate from siblings like snowflake_list_tags or snowflake_describe_masking_policy.

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

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

No guidance on when to use this tool versus alternatives such as snowflake_list_tags or snowflake_get_object_tag_references. The description is purely a functional statement.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds which attributes are retrieved (schedule, warehouse, SQL), which is useful content, but says nothing about behavior on a missing task, permissions needed, or output shape beyond the field list.

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

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

A single compact sentence with the key retrieval targets front-loaded. No filler, though the term 'definition' and 'definition SQL' are somewhat redundant.

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

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

An output schema exists, so return values need not be explained, and the read-only annotations cover the safety side. However, the 0% parameter coverage and total absence of usage context leave gaps an agent would need to fill from schema guesswork.

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

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

Schema description coverage is 0% across 3 parameters, so the description carries the burden. It lists return fields rather than parameters and never explains that database/schema_name are optional qualifiers for resolving task_name, leaving the parameter semantics undocumented.

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

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

The description pairs a specific verb ('Describe') with a specific resource ('task') and enumerates the salient fields returned (definition, schedule, warehouse, definition SQL). This distinguishes it from siblings like snowflake_list_tasks and snowflake_create_task, though it does not explicitly name an alternative.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no routing to or from sibling tools. The agent must infer that this is the metadata-inspection counterpart to snowflake_list_tasks, which is not stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered and the description doesn't need to restate it. The description adds no behavioral context such as required privileges to inspect another user or what happens if the user does not exist, so it is adequate but thin for a metadata-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.

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

A single front-loaded sentence with no filler; the resource and returned fields come first. It is efficiently sized, though it is arguably too terse given the undocumented parameter.

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

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

An output schema exists, so the description need not explain return values. However, with the only parameter undocumented in the schema and no usage guidance against a large set of describe/list siblings, the definition is minimally complete rather than fully self-sufficient.

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

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

Schema description coverage is 0% and the sole required parameter user_name has no description anywhere. The description does not clarify whether user_name is a login name, an identifier requiring quoting, or case-sensitive, so it fails to compensate for the schema gap.

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

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

The description gives a specific verb (Describe) and resource (user) and enumerates the returned attributes (email, disabled status, default warehouse/role), so the agent knows exactly what it retrieves. It does not explicitly contrast itself with the sibling snowflake_list_users, so it stops short of full sibling differentiation.

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

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

The description states no condition for when to use this over snowflake_list_users (bulk listing) or snowflake_list_grants_to_user. There are no prerequisites, exclusions, or alternative-routing guidance of any kind.

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