Skip to main content
Glama
jonasliesas

singlestore-mcp-server

by jonasliesas
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

security_change_apply

Destructive

Apply a previewed SingleStore security change to users, roles, grants, or resource pools after explicit confirmation; typed confirmation is required for destructive actions.

Instructions

Run one previewed change (users, roles, groups, grants, resource pools) on the cluster.

Refuses unless ``confirm`` is true: call it only after the user saw the plan (security_change_plan) and
explicitly confirmed. Where the plan asks for it (DROP, revoke all, the connected user or an admin user),
``typed_confirmation`` must be the name the user typed. The plan is rebuilt from fresh cluster state first,
and blockers (lock-out, last admin) refuse the change. ``password`` (create_user only) is sent as a bound
parameter and never returned, logged or stored.

Args:
    action: The same action object as for security_change_plan.
    confirm: Must be true: the user's explicit confirmation.
    typed_confirmation: The object name the user typed, when the plan requires it.
    password: The new user's password (create_user only).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYes
confirmNo
passwordNo
typed_confirmationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and non-idempotent, but the description goes well beyond them: it discloses the confirm gate, the typed_confirmation safety valve for DROP/revoke-all/admin targets, that the plan is rebuilt from fresh cluster state, that lock-out/last-admin blockers refuse the change, and that password is bound, never returned/logged/stored. This is far richer than the annotation hints.

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

Conciseness5/5

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

Front-loaded with what the tool does and its hard refusal gate, followed by behavioral caveats and a tight Args block. With 0% schema coverage the Args section carries real weight rather than repeating structured fields; no sentence is filler.

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

Completeness4/5

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

For a destructive, non-idempotent mutation with no output schema, the description covers permissions implied by confirm, blocker refusal behavior, and secret handling, which is what an agent needs to invoke it safely. It does not describe the success/return payload, a minor omission given no output schema exists.

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 description coverage is 0% and the nested action object is opaque, but the description supplies meaning for confirm (must be true), typed_confirmation (the exact name the user typed, only when the plan requires it), and password (create_user only, never persisted). The action object's internal shape is only deferred to security_change_plan, which is reasonable but leaves a small gap.

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

Purpose5/5

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

States a specific verb (run/apply) and resource (one previewed security change covering users, roles, groups, grants, resource pools) on the cluster. The sibling security_change_plan is named explicitly, so an agent can separate the preview step from the apply step without opening either schema.

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?

Gives an explicit precondition chain: call only after the user has seen the plan via security_change_plan and explicitly confirmed; refuses unless confirm is true; typed_confirmation required only when the plan asks for it. When-to-use and when-not-to-use are both stated, with the alternative sibling identified.

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