Skip to main content
Glama

AANet

by space.aanet
OverviewDiscussionsAdmin

aanet_mint_subkey

Issue a new scoped credential for one sub-agent — the standard way to bring a sub-agent into an existing workspace. Requires the owner_key; a sub-key cannot mint another sub-key.

Returns {subkey_id, key} where key is shown exactly once, the same as
owner_key at workspace creation. Give each sub-agent its own sub-key
rather than sharing one across several — that's what makes
aanet_get_activity attributable per sub-agent and what lets you revoke
exactly one misbehaving sub-agent (aanet_revoke_subkey) without taking
down the rest of the swarm.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
labelYesDisplay name for this sub-key, e.g. the sub-agent's role or id.
api_keyYesBearer credential for this workspace: either the owner_key returned once by aanet_create_workspace/aanet_create_trial_workspace, or a sub-key returned by aanet_mint_subkey. Sent under the hood as `Authorization: Bearer <api_key>`. Owner-only tools reject a sub-key with a 403.
budget_capNoCap this sub-key's own cumulative spend, in the same integer units as the workspace balance ($0.00001 each), even if the workspace has more left. Leave unset for no per-key cap beyond the shared workspace balance.
workspace_idYesThe workspace_id from aanet_create_workspace or aanet_create_trial_workspace.
path_scope_prefixNoRestrict this sub-key to file paths and lock names under this prefix only (least-privilege). Leave unset for unrestricted access to the whole workspace.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / api_key / description
      Added value: +"Bearer credential for this workspace: either the owner_key returned once by aanet_create_workspace/aanet_create_trial_workspace, or a sub-key returned by aanet_mint_subkey. Sent under the hood as `Authorization: Bearer <api_key>`. Owner-only tools reject a sub-key with a 403."
    • changedInput schema / properties / budget_cap / anyOf
      Previous value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "exclusiveMinimum": 0,
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / budget_cap / description
      Added value: +"Cap this sub-key's own cumulative spend, in the same integer units as the workspace balance ($0.00001 each), even if the workspace has more left. Leave unset for no per-key cap beyond the shared workspace balance."
    • addedInput schema / properties / label / description
      Added value: +"Display name for this sub-key, e.g. the sub-agent's role or id."
    • addedInput schema / properties / path_scope_prefix / description
      Added value: +"Restrict this sub-key to file paths and lock names under this prefix only (least-privilege). Leave unset for unrestricted access to the whole workspace."
    • addedInput schema / properties / workspace_id / description
      Added value: +"The workspace_id from aanet_create_workspace or aanet_create_trial_workspace."
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, so the description must carry behavioral disclosure, and it does: key is only displayed once, minting requires the owner key, and a sub-key cannot mint further sub-keys. It could also mention the full create-key lifecycle or rate limits, but the operational essentials are transparent.

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?

The definition is front-loaded with the single-sentence purpose, then adds constraints and usage best practices in a compact, readable sequence. Every sentence contributes meaning, and there is no redundant filler.

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?

For a five-parameter minting tool, the description covers input constraints, return behavior, security-relevant display limitation, and recommended usage pattern. It gives an agent enough context to invoke the tool correctly without ambiguous follow-ups.

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

Parameters3/5

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

The schema already describes label, api_key, budget_cap, and path_scope in detail, so the description adds little per-parameter semantics beyond the owner_key restriction and return caveat. Baseline 3 is appropriate given the high schema coverage.

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 starts with a specific verb and resource: 'Issue a new scoped credential for one sub-agent' and positions it as 'the standard way to bring a sub-agent into a workspace.' This clearly differentiates it from workspace creation and sub-key revocation.

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?

The description explicitly declares the prerequisite ('Requires the owner_key; a sub-key cannot mint another sub-key') and provides direct usage guidance: give each sub-agent its own sub-key rather than sharing one. It also names the sibling revoke tool (aanet_revoke_subkey) and explains why this pattern enables per-agent attribution and revocation.

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

All AANet toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources