Skip to main content
Glama

Network Describe Network Rule

network_describe_network_rule
Read-onlyIdempotent

Inspect a Snowflake network rule's mode, type, and value list to verify its INGRESS, INTERNAL_STAGE, or EGRESS configuration.

Instructions

Describe mode (INGRESS, INTERNAL_STAGE, EGRESS), type (IPV4, AWSVPCEID, HOST_PORT), and value list of a network rule.

Input Schema

NameRequiredDescriptionDefault
databaseNoQuote names that aren't all uppercase, exactly as list tools return them.
rule_nameYesQuote names that aren't all uppercase, exactly as list tools return them.
schema_nameNoQuote names that aren't all uppercase, exactly as list tools return them.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv3.0.0
    • addedInput schema / properties / database / description
      Added value: +"Quote names that aren't all uppercase, exactly as list tools return them."
    • addedInput schema / properties / rule_name / description
      Added value: +"Quote names that aren't all uppercase, exactly as list tools return them."
    • addedInput schema / properties / schema_name / description
      Added value: +"Quote names that aren't all uppercase, exactly as list tools return them."
  2. Addedv2.0.4

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully structured. The description contributes the returned attribute shape but doesn't mention output structure formatting, name-resolution caveats, or errors for missing rules.

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

Conciseness4/5

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

A single efficient sentence that front-loads the verb and immediately names the returned fields. It is tight, though perhaps over-terse for a describe tool that could have used one more sentence on scope.

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

Completeness4/5

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

With an output schema present and full schema coverage on all three parameters, plus rich annotations, the description covers the essential purpose and return shape. Only minor gaps remain, such as qualification of the rule by database/schema and behavior on an unknown rule name.

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

Parameters3/5

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

Schema description coverage is 100%, with each of the three parameters documented (database, schema_name, rule_name, all with quoting guidance). The description adds no parameter-level detail (e.g., how the optional database/schema qualify rule_name), so the baseline of 3 applies.

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

Purpose4/5

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

The description states a specific verb ("Describe") and resource ("a network rule") and enumerates the returned attributes: mode, type, and value list. It implicitly distinguishes itself from list-style siblings such as network_list_network_rules because it targets a single named rule, but it never names that 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 explicit guidance about when to call this instead of network_list_network_rules or the sibling network_describe_network_policy, nor any prerequisites or scope notes. Usage is only inferable from the verb "Describe" and the required rule_name.

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