Skip to main content
Glama

get_my_active_work

Retrieve all active claims you hold across every plan—tasks, findings, and attempts in review—to recover work after a session restart.

Instructions

Every active claim the calling actor currently holds across every plan: tasks, findings, and attempts in review. Use this on session start to recover claims after a Claude restart.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
as_agentNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. 'Get' and 'active claims ... currently holds' imply a safe read scoped to the caller, which is meaningful context, but it discloses nothing about return shape, ordering, or how claims in different states are reported.

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, both earning their place, with the resource scope front-loaded before the usage cue. No filler or restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-required-param read tool with no output schema, purpose and trigger are adequately covered. However, the unexplained as_agent parameter — which the 'calling actor' phrasing muddles rather than clarifies — leaves an agent unsure whether this tool can be pointed at someone else's claims.

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

Parameters2/5

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

The single parameter as_agent has 0% schema description coverage, so the description must compensate and does not — it never explains what as_agent does. Worse, saying it returns claims 'the calling actor currently holds' arguably conflicts with the existence of an as_agent parameter that would let the caller query another actor's claims.

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+resource: it returns every active claim held by the calling actor, and it enumerates the exact claim types (tasks, findings, attempts in review) and scope (across every plan). That distinguishes it cleanly from siblings like get_stuck_work and get_plan_dashboard without needing 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 an explicit when: 'Use this on session start to recover claims after a Claude restart.' It does not name a when-not condition or an alternative sibling, so it stops short of full routing guidance, but the trigger context is clear and actionable.

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