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

singlestore-mcp-server

by jonasliesas
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

security_change_plan

Read-only

Preview a SingleStore security change before executing it: see exact statements, warnings, blockers, confirmation requirements, and privilege availability without running anything.

Instructions

Read-only preview of one change: the exact statements (any password masked), warnings, blockers (lock-out, last admin, missing objects) and whether the user must type the object's name to confirm. Runs nothing. Works without the change privileges (allowed says whether the connected user may run it).

Args:
    action: {"action": one of create_user, drop_user, grant, revoke, revoke_all, create_role, drop_role,
        create_group, drop_group, grant_role, revoke_role, grant_group, revoke_group, create_pool, alter_pool,
        drop_pool, set_default_pool, grant_pool, revoke_pool, change_password, lock_user, unlock_user,
        set_login_policy, set_require, grant_view, plus its fields: user, host, role, group,
        grantee_type ("user"/"role"), privileges, database, table, with_grant_option, grant_option, pool,
        settings, default_pool, failed_login_attempts, password_lock_time (seconds; both 0 = off),
        require ("SSL"/"NONE"), columns and view (grant_view: a view with these columns of database.table,
        SELECT granted on it – 9.0 has no column-level grants)}. Never a password.
    pending: The changes already in the script basket (same shape), for a change that needs objects they
        create (the plan then says ``needs_script``).

Input Schema

NameRequiredDescriptionDefault
actionYes
pendingNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.1

TDQS

A4.7/5.0
Behavior5/5

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

Beyond `readOnlyHint: true`, the description discloses the exact output content: statements with passwords masked, warnings, blockers such as lock-out/last admin/missing objects, and whether name confirmation is required. It also explains that nothing runs, that it works without change privileges, and that `allowed` reports whether the connected user may run the underlying change.

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?

The core purpose and behavior are front-loaded, and the length is justified by the large undocumented `action` object. The inline action/field enumeration is dense and could be easier to scan, but there is little wasted prose.

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?

Although there is no output schema and the input schema has 0% description coverage, the description explains return contents, blockers, confirmation behavior, privilege requirements, and parameter shape in enough detail to call the tool correctly. It is complete for a complex preview tool with only a `readOnlyHint` annotation.

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

Parameters5/5

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

Schema description coverage is 0% and `action` is an unconstrained nested object, so the description carries the full parameter burden. It enumerates the supported action types and the associated fields, and it adds crucial semantics such as password masking, `0` disabling login-policy settings, `require` values, and the `grant_view` column/view behavior. It also explains that `pending` has the same shape and can cause the plan to report `needs_script`.

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?

The description opens with a specific verb and resource: "Read-only preview of one change," and immediately states what it returns and that it "Runs nothing." That contrasts clearly with the sibling apply/script tools without requiring the agent to open another schema.

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

Usage Guidelines4/5

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

It gives a clear usage context: preview a single change, see blockers/warnings, and use `pending` when the change depends on objects already in the script basket. It also states that no change privileges are required. It stops short of explicitly naming `security_change_apply` or `security_change_script` as alternatives, so the routing guidance is strong but not maximal.

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