Skip to main content
Glama

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

TableJSON 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.
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

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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."
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and delivers: it discloses read-only semantics, owner-level authorization, the output field set including statuses, and the important trust property that the log cannot be faked or skipped. This goes well beyond the minimal 'get activity' phrasing.

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 short, front-loaded paragraphs with no filler. The first sentence states purpose and trust value, the second paragraph covers output fields and recommended use cases, and every sentence earns its place.

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?

Given six parameters, no annotations, and an output schema present, the description supplies what an agent needs to select and invoke the tool correctly: purpose, authorization requirement, use cases, and output shape. The schema covers filtering parameters, so nothing critical is missing.

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 the baseline is 3 even without extra parameter explanation. The description adds useful context about owner_key and the audit-log entry fields, but it does not elaborate on limit/since/operation/subkey_id beyond what the schema already documents.

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 ('Read') and resource ('server-side audit log of every attempt in this workspace'), making the tool's scope immediately clear. It also distinguishes itself as the authoritative source versus sub-agents' self-reports, which separates it from sibling data-read tools like aanet_get_messages.

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?

Provides explicit use cases: reconstructing what happened after the fact and checking spend pattern before adjusting budget_cap via aanet_update_subkey. It also flags the owner_key requirement, though it does not explicitly name alternatives or exclusion conditions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources