Skip to main content
Glama

activate_intent

Switch your current focus to an existing intent by its ID, restoring its context and prior decisions for completion or resumption.

Instructions

Activate an existing intent by ID — sets it as THIS session's current focus.

Use this to:

  • Switch your current focus to a different intent found via list_team_intents or get_relevant_context

  • Re-activate an intent that was deactivated (e.g., to complete it)

  • Resume work on a previously created intent

  • Resume an "abandoned" intent (see below)

Accepts both cloud IDs (from get_relevant_context / API) and local UUIDs (from list_team_intents).

Multi-active model: activating an intent only moves YOUR session's current pointer. Many intents can be active on a repo at once (one current per session/teammate), so this never blocks on or displaces another session's active intent — there is no lock to take over.

Resuming abandoned intents:

  • Abandoned intents have their decisions soft-deleted (invisible to recall and get_relevant_context). Activating one transparently restores them — single-intent decisions for this intent get their soft-delete cleared so the prior reasoning becomes visible again. Multi-intent decisions stay visible throughout (they were never soft-deleted).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
intentIdYesThe cloud ID (preferred) or local UUID of the existing intent to activate.
repoPathYesLocal path to the repository root
forkAuthorNoFork attribution; usually resolved by Muninn automatically — pass only for override / testing.
repoOriginNoGit remote origin URL. Auto-detected from repoPath via git if not provided.
workspaceIdNoWorkspace identifier; usually resolved by Muninn automatically — pass only for override / testing.
Behavior5/5

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

No annotations provided, so description carries full burden. It discloses key behaviors: accepts cloud IDs and local UUIDs, multi-active model (no blocking), and transparent restoration of soft-deleted decisions for abandoned intents. This exceeds typical description detail and prevents misuse.

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?

Description is well-structured with section headers (Use this to, Accepts both, Multi-active, Resuming abandoned) and front-loaded main sentence. While slightly long, each section adds essential information without redundancy. Could be slightly more concise, but structure compensates.

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?

Given 5 parameters (2 required, nested objects) and no output schema, the description adequately covers activation behavior, multi-active semantics, and abandoned intent handling. It does not describe the return value, but for a mutation tool this is acceptable. The explanation of edge cases (abandoned intents) adds completeness.

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 100%, but description adds value beyond schema by explaining the dual ID acceptance and auto-resolution behavior for forkAuthor and workspaceId ('usually resolved by Muninn automatically'). This context helps agents decide when to provide overrides.

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?

Description clearly states 'Activate an existing intent by ID — sets it as THIS session's current focus.' It specifies the verb (activate), resource (intent), and scope (existing, by ID, session-specific). It distinguishes from siblings like create_and_activate_intent and check_active_intent, making the purpose unambiguous.

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?

Provides explicit use cases: switch focus, re-activate deactivated, resume work, resume abandoned. Also explains the multi-active model (no locks, only session pointer moves) and when to use alternative tools (e.g., list_team_intents to find intents). This gives clear when-to and when-not-to guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kawacode-ai/kawa.mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server