Skip to main content
Glama
Sign In

AANet

by space.aanet
OverviewDiscussionsAdmin

aanet_get_activity

Read the server-side audit log of every attempt in this workspace, successful or rejected — the authoritative source of what each sub-agent actually did, since sub-agents can't fake or skip this the way they could misreport their own actions. Owner_key required.

Each entry has subkey_id, operation, path, cost_charged, status (e.g.
OK, INSUFFICIENT_BALANCE, SCOPE_DENIED, CONFLICT), and a free-text
detail. Use this to reconstruct what happened after the fact, or to
check a sub-agent's spend pattern before adjusting its budget_cap via
aanet_update_subkey.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum entries to return, newest first, up to 500.
sinceNoISO timestamp — only return entries at or after this time.
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.
since_idNoEntry id cursor: only entries with id > since_id (strictly exclusive). The recommended way to poll — pass the highest id you've already seen. Results are newest first.
operationNoFilter to one operation type, e.g. "PUT_FILE", "LOCK_ACQUIRE", "SEND_MESSAGE", "WEBHOOK_DELIVERY". Omit for all operation types.
subkey_idNoFilter to attempts by this sub-key only. Omit for all.
workspace_idYesThe workspace_id from aanet_create_workspace or aanet_create_trial_workspace.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / since_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Entry id cursor: only entries with id > since_id (strictly exclusive). The recommended way to poll — pass the highest id you've already seen. Results are newest first.",
+  "title": "Since Id"
+}
  2. Changed8 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."
    • addedInput schema / properties / limit / description
      Added value: +"Maximum entries to return, newest first, up to 500."
    • addedInput schema / properties / limit / exclusiveMinimum
      Added value: +0
    • addedInput schema / properties / limit / maximum
      Added value: +500
    • addedInput schema / properties / operation / description
      Added value: +"Filter to one operation type, e.g. \"PUT_FILE\", \"LOCK_ACQUIRE\", \"SEND_MESSAGE\", \"WEBHOOK_DELIVERY\". Omit for all operation types."
    • addedInput schema / properties / since / description
      Added value: +"ISO timestamp — only return entries at or after this time."
    • addedInput schema / properties / subkey_id / description
      Added value: +"Filter to attempts by this sub-key only. Omit for all."
    • 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.1/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 meaningful work: it discloses the audit log includes both successful and rejected attempts, that the record is server-side and tamper-resistant ('sub-agents can't fake or skip this'), the owner_key requirement, and the status vocabulary (OK, INSUFFICIENT_BALANCE, SCOPE_DENIED, CONFLICT). It does not discuss volume, rate limits, or retention, which keeps it short of a 5 for a read tool with zero annotation coverage.

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?

Purpose is front-loaded in the first clause, followed by entry contents and then usage. Three sentences are tight and each carries information, though the aside about sub-agents misreporting their own actions is more rhetorical than operative.

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?

An output schema exists so return values need not be explained, and the schema fully documents all 7 parameters. The description covers purpose, auth prerequisite, and workflow context, leaving only pagination and result-volume expectations unaddressed — a minor gap for a straightforward read tool.

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?

Schema description coverage is 100%, so every parameter including limit, since, since_id, operation and subkey_id is already documented in the schema, setting the baseline at 3. The description confirms the shape of returned entries but adds no filter syntax, cursor mechanics, or defaults beyond what the schema states.

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: 'Read the server-side audit log of every attempt in this workspace, successful or rejected.' The 'every attempt, including rejected ones' framing plus the enumeration of raw entry fields (subkey_id, operation, status) effectively separates it from the summary-style sibling without the agent needing to open either 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?

Gives two concrete use cases ('reconstruct what happened after the fact', 'check a sub-agent's spend pattern before adjusting its budget_cap via aanet_update_subkey') and states the owner_key prerequisite. It stops short of naming the competing alternative (aanet_get_activity_summary) or saying when NOT to use this tool, so it is clear context without explicit exclusions.

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