Skip to main content
Glama

Ankra

by ai.ankra
OverviewDiscussionsAdmin

create_storage_class

Destructive

Create a new StorageClass on the cluster. Typed on purpose: the AI assistant may not write a StorageClass through patch_resource or delete_resource, and apply_manifest accepts one only under the same check. provisioner must be a CSI driver installed on the cluster (a CSIDriver of that name, or the provisioner an existing class already uses); the call is refused for an uninstalled provisioner, listing the installed ones. The name must be new: an existing class is never edited or replaced (Kubernetes does not let a class's provisioner, parameters or reclaim policy change in place). The new class is never made the cluster default and this tool cannot move the default. Before the confirmation card the cluster's StorageClasses, CSI drivers, volumes and claims are read live; if they cannot be read the call is refused with a 'Not checked' line, never passed. reclaim_policy Delete (the default) deletes a claim's volume and data with the claim; Retain keeps the volume until someone deletes it. Changing the default class, editing an existing class, or deleting a volume a claim uses stays with a person: the Ankra UI, ankra cluster apply (a manifest in the cluster's stack YAML), ankra cluster patch storageclass ... or ankra cluster delete ..., none of which the AI policy limits. Requires kubernetes.write.

Input Schema

NameRequiredDescriptionDefault
nameYesName of the new StorageClass, a Kubernetes name (lowercase letters, digits, '-' and '.'). Must not exist yet.
cluster_idYesAnkra cluster id (UUID) the call targets. Discover ids with list_clusters.
parametersNoDriver-specific parameters, string keys to string values (e.g. {"type": "ssd", "fsType": "ext4"}). Numbers are written as strings.
provisionerYesThe CSI driver that provisions the class's volumes, exactly as the cluster names it (e.g. csi.hetzner.cloud, driver.longhorn.io, rancher.io/local-path).
reclaim_policyNoWhat happens to a volume when its claim is deleted. Defaults to Delete.
volume_binding_modeNoWhen a volume is provisioned: at claim time (Immediate, the default) or when the first pod using the claim is scheduled (WaitForFirstConsumer, preferred for zonal disks).
allow_volume_expansionNoWhether claims of this class may be resized larger later. Only set it when the CSI driver supports expansion.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: the call is refused for uninstalled provisioners (listing installed ones), existing classes are never edited, the new class never becomes default, live pre-check of StorageClasses/CSI drivers/volumes/claims with a 'Not checked' refusal path, and the kubernetes.write requirement. This goes well past the destructive/readOnly/idempotent hints.

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?

Dense and front-loaded with the core action first, then constraints and semantics. A few clauses are wordier than necessary (the repeated CLI enumeration, the 'none of which the AI policy limits' aside), costing a bit of tightness.

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

Completeness5/5

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

For a 7-param mutation with nested objects and no output schema, the description covers provisioning prerequisites, refusal behavior, default-class immutability, reclaim-policy consequences, and auth requirements. An agent has what it needs to call it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: provisioner must be an installed CSI driver, the name must not exist, and reclaim_policy Delete destroys the volume and data with the claim. Marginal extra beyond what the schema documents, so a 4 rather than 5.

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

Purpose5/5

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

States a specific verb and resource ('Create a new StorageClass on the cluster') and explicitly delineates it from apply_manifest, patch_resource, delete_resource, and (by implication) delete_storage_class. An agent can identify the right tool without reading schemas.

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

Usage Guidelines5/5

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

Explicitly says the AI may not write a StorageClass via patch_resource or delete_resource, that apply_manifest works only under the same check, and lists the human-only paths (UI, ankra cluster apply/patch/delete) for editing the default, editing existing classes, and deleting volumes. When-to-use and when-not-to-use are both spelled out.

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

All Ankra toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources