Skip to main content
Glama
Sign In

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.

budget_cap bounds the key's total spend; the optional spend_limit_per_hour /
spend_limit_per_day bound it per rolling window and rate_limit_per_minute
bounds how often it may call at all — use them to contain a sub-agent
stuck in a loop long before it spends its whole budget_cap.

Input 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.
spend_limit_per_dayNoSafety limit: most units this key may spend in any rolling 24 hours (same error as the hourly one). Unset = no limit.
spend_limit_per_hourNoSafety limit: most units this key may spend in any rolling hour. Over it, charged calls get 402 INSUFFICIENT_KEY_WINDOW_BUDGET until the window frees up. Unset = no limit.
rate_limit_per_minuteNoSafety limit: most requests (of any kind, free ones included) this key may make per rolling minute; over it, 429 with Retry-After. Unset = no limit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / rate_limit_per_minute
      Added value: +{
+  "anyOf": [
+    {
+      "exclusiveMinimum": 0,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Safety limit: most requests (of any kind, free ones included) this key may make per rolling minute; over it, 429 with Retry-After. Unset = no limit.",
+  "title": "Rate Limit Per Minute"
+}
    • addedInput schema / properties / spend_limit_per_day
      Added value: +{
+  "anyOf": [
+    {
+      "exclusiveMinimum": 0,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Safety limit: most units this key may spend in any rolling 24 hours (same error as the hourly one). Unset = no limit.",
+  "title": "Spend Limit Per Day"
+}
    • addedInput schema / properties / spend_limit_per_hour
      Added value: +{
+  "anyOf": [
+    {
+      "exclusiveMinimum": 0,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Safety limit: most units this key may spend in any rolling hour. Over it, charged calls get 402 INSUFFICIENT_KEY_WINDOW_BUDGET until the window frees up. Unset = no limit.",
+  "title": "Spend Limit Per Hour"
+}
  2. 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."
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the owner-only auth requirement, the one-time reveal of the secret key, and the safety semantics of each limit. It does not cover failure modes for the mint call itself (e.g. invalid owner_key, duplicate label), leaving a small gap for a mutation tool.

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?

Three short paragraphs, front-loaded with purpose, then return/auth caveats, then limit rationale. Every sentence adds something, though the swarm/revocation sentence is slightly expansive for a tool 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?

Despite having no output schema, the description documents the return shape ({subkey_id, key}) and the crucial one-time-reveal property, plus the auth constraint and limit semantics. An agent has everything needed to call it correctly and reason about the result.

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 already 100%, so baseline is 3. The description adds genuine rationale beyond the schema by explaining why budget_cap and the per-window limits exist ('contain a sub-agent stuck in a loop long before it spends its whole budget_cap'), which helps an agent choose sensible values rather than merely understand the fields.

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 ('Issue a new scoped credential for one sub-agent') and immediately frames it as the standard onboarding path. It distinguishes itself from siblings by naming aanet_revoke_subkey and aanet_get_activity as the tools whose behavior this key structure enables.

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?

Explicitly says when to use it (bringing a sub-agent into an existing workspace), states a hard precondition (requires the owner_key; a sub-key cannot mint another sub-key), and gives a directive on the correct pattern (one key per sub-agent rather than sharing). The alternative pattern is also explained via the attribution/revocation rationale.

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
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources