Skip to main content
Glama
Sign In
singlestore-mcp-server

singlestore-mcp-server

by jonasliesas
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

security_change_apply

Destructive

Apply a previewed SingleStore security change—users, roles, grants, or resource pools—only after explicit confirmation, with typed confirmation and blocker checks when required.

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, change_password) 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) or the new password (change_password).
    update_connection: Changing your own password: after it succeeded, also save the new password for the
        active saved connection in the OS credential store.

Input Schema

NameRequiredDescriptionDefault
actionYes
confirmNo
passwordNo
update_connectionNo
typed_confirmationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.11.0
    • addedInput schema / properties / update_connection
      Added value: +{
+  "default": false,
+  "title": "Update Connection",
+  "type": "boolean"
+}
  2. Addedv0.10.1

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and non-idempotent, and the description adds substantial context beyond them: the hard refusal unless confirm is true, the fresh-state plan rebuild, and the lock-out/last-admin blockers that abort the change. The secret-handling note (password sent as a bound parameter, never returned, logged or stored) is behavior found nowhere in the schema or annotations.

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?

Front-loads the refund/refusal constraint and prerequisites before the Args block, and every sentence carries information. The middle paragraph is somewhat dense and run-on, but nothing is padding.

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, nested-object mutation tool this is close to complete: safety gate, confirmation protocol, validation order, and secret handling are all covered, and no output schema exists so return values needn't be explained. A brief note on what a successful apply yields (or how partial failures are reported) is the only real omission.

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%, so the description carries the full burden and mostly delivers — confirm, typed_confirmation, password and update_connection each get purpose plus triggering conditions (including the OS credential store side effect for update_connection). The gap is the required `action` object, whose internal structure is only deferred as 'the same action object as for security_change_plan' rather than characterized, leaving the one required parameter the thinnest documented.

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?

Opens with a specific verb and resource ('Run one previewed change') and enumerates the object classes it covers (users, roles, groups, grants, resource pools) on the cluster. The word 'previewed' plus the explicit reference to security_change_plan cleanly separates it from the plan and script siblings.

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?

States the precondition explicitly: call only after the user saw the plan via security_change_plan and explicitly confirmed. It also names the conditional requirement (typed_confirmation) and the circumstances that trigger it ('DROP, revoke all, the connected user or an admin user'), which is exactly the when-to-use/when-not guidance an agent needs.

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