Skip to main content
Glama

Snowflake Describe Task

snowflake_describe_task
Read-only

Retrieve task definition, schedule, warehouse, and SQL to inspect a Snowflake task's configuration.

Instructions

Describe task definition, schedule, warehouse, and definition SQL.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
databaseNo
task_nameYes
schema_nameNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.2.0
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / database / title
      Removed value: -"Database"
    • removedInput schema / properties / schema_name / title
      Removed value: -"Schema Name"
    • removedInput schema / properties / task_name / title
      Removed value: -"Task Name"
    • removedInput schema / title
      Removed value: -"snowflake_describe_taskArguments"
    • removedOutput schema / title
      Removed value: -"snowflake_describe_taskDictOutput"
  2. First observedv0.1.0

TDQS

B3/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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

An output schema exists, so return values need not be 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.

Parameters2/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

Deploy Server

Other Tools