Skip to main content
Glama
dnotitia

akb

by dnotitia
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

akb_grant

Grant vault access to a user with a specified role. Use source_key and revision for rule-driven grants, enabling later withdrawal of your own reason without affecting other grants.

Instructions

Grant vault access to a user. You must be owner or admin of the vault. A rule-driven grantor should name its own source_key so it can later withdraw its own reason without deleting anybody else's.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roleYesRole to grant
userYesTarget username
vaultYesVault name
revisionNoMonotonic per (vault, user, source). A retry carrying a revision no newer than the stored one is a no-op rather than an overwrite.
source_keyNoThe basis on which the role is held, as '<namespace>:<id>'. Omit it and the grant is 'direct', which is what every grant was before bases could coexist.
_vault_skill_ackNoOpaque acknowledgement returned as vault_skill.ack_token. After applying that guide, retry the unchanged operation with this value. The bundled proxy supplies it automatically.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.0.14
    • addedInput schema / properties / _vault_skill_ack
      Added value: +{
+  "description": "Opaque acknowledgement returned as vault_skill.ack_token. After applying that guide, retry the unchanged operation with this value. The bundled proxy supplies it automatically.",
+  "maxLength": 128,
+  "type": "string"
+}
    • addedInput schema / properties / revision
      Added value: +{
+  "description": "Monotonic per (vault, user, source). A retry carrying a revision no newer than the stored one is a no-op rather than an overwrite.",
+  "type": "integer"
+}
    • addedInput schema / properties / source_key
      Added value: +{
+  "description": "The basis on which the role is held, as '<namespace>:<id>'. Omit it and the grant is 'direct', which is what every grant was before bases could coexist.",
+  "type": "string"
+}
  2. Addedv2.0.4
  3. Removedv2.0.1
  4. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does disclose a key behavioral trait: only owner/admin can grant, and rule-driven grants should carry a source_key to allow future self-withdrawal without affecting others. It does not describe overwrite semantics, but the schema's revision field covers retry behavior.

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?

Two sentences are used efficiently: the action, the permission gate, and the one nuanced parameter guidance are all front-loaded. No filler or repetition of schema content.

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?

Given the six-parameter schema with full descriptions, the tool is adequately specified for selection and invocation: purpose, permission requirement, and source_key rationale are present. No annotations or output schema exist, but the description plus rich schema covers the essential operation-level context.

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 the baseline is 3. The description adds meaningful semantics for source_key beyond the schema: "so it can later withdraw its own reason without deleting anybody else's." It does not describe revision/_vault_skill_ack behavior, but those are already documented in the schema.

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: "Grant vault access to a user," which clearly identifies the operation and target. The owner/admin prerequisite further sharpens the intended context, and the name/role make sibling confusion unlikely.

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 explicit context by requiring owner/admin status and by advising rule-driven grantors to set source_key. It does not explicitly enumerate alternatives such as akb_revoke, but for a straightforward grant operation the use case is clear.

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