Skip to main content
Glama

The Bridge

by dev.thebridge
OverviewDiscussionsAdmin

Delete Privilege

delete_privilege
Destructive

Permanently delete a privilege, addressed by its key (or id) from list_privileges. THIS IS IRREVERSIBLE — the privilege is removed from every role that grants it, so people holding those roles lose it at their next sign-in, and flag rules and app code that check its key stop matching anyone. The AUTHENTICATED privilege cannot be deleted. Requires confirmation: pass confirm set to the exact privilege key, and only after the user has explicitly asked for the deletion — do not supply it on your own initiative. To take a privilege away from one role only, use update_role instead. dryRun: true previews it first — the privilege and the roles that grant it — without deleting anything or needing confirm. Fails with PRIVILEGE_NOT_FOUND when nothing matches. Same as bridge privilege delete. What a role can do is only the app's default setup until you have read it here. Control access with a flag rule on a privilege (preferred) or on the role key, never with a hard-coded role check in app code. A privilege rule matches the whole key: privileges contains "REPORTS_VIEW" does not match REPORTS_VIEW_ALL. Before writing app code that consumes this, call get_integration_guide with topic=team and the framework the app uses.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoPrivilege id from list_privileges, instead of key.
appNoId of the Bridge app to act on for this call (see list_apps). Omit to use the current app.
keyNoPrivilege KEY from list_privileges, e.g. "REPORTS_VIEW". Pass this or id, not both.
dryRunNotrue previews what the deletion would affect and deletes nothing — no confirm needed. Do this first and show the user the result. Needs the same privilege as the deletion itself.
confirmNoRepeat the exact key of the resource being deleted, as confirmation. Required to delete; not needed with dryRun. This is a deliberate safety step — do NOT guess it or copy it from a fuzzy match. If you are not certain, list the resources first and ask the user which one they mean.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description goes well beyond them: it explains what is destroyed (the privilege removed from every role, holders lose it at next sign-in, flag rules and app code stop matching), the hard constraint (AUTHENTICATED cannot be deleted), the confirm/idempotency safety contract, and the PRIVILEGE_NOT_FOUND failure mode.

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

Conciseness3/5

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

The core action, irreversibility, and confirm contract are front-loaded well, but the tail drifts into tangential platform guidance about flag rules, hard-coded role checks, and privilege-rule key matching ('REPORTS_VIEW' does not match REPORTS_VIEW_ALL). That material is relevant to the auth model but not to invoking this delete tool, so it dilutes an otherwise tight definition.

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?

With no output schema, the description still covers effects, permissions needed, error conditions, the reversible preview path, and sibling routing — everything an agent needs to call this destructive tool safely.

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 100%, so baseline is 3; the description adds meaning by clarifying that confirm must be the exact resource key and must not be guessed or copied from a fuzzy match, and that dryRun needs no confirm. It stops short of documenting the app parameter's scoping behavior in prose, so it exceeds but does not maximize the dimension.

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 ('Permanently delete a privilege') plus the addressing mode (its key, or id, from list_privileges). An agent can immediately distinguish this from create_privilege, update_privilege, and delete_role without opening any 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?

Explicit when-not guidance and an alternative: 'To take a privilege away from one role only, use update_role instead.' It also prescribes the ordering (dryRun first, then confirm only after explicit user request) and the correct remediation path (get_integration_guide with topic=team) for consuming code, leaving little to inference.

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

All The Bridge toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources