Skip to main content
Glama

get_relevant_context

Finds past intents and decisions relevant to your current request, using the prompt and active files to narrow results.

Instructions

Find past intents and decisions relevant to the current user request.

When to use:

  • After you have done a quick initial exploration of the user's request and know which files are involved. Calling earlier with only a vague prompt gives weak results.

  • To pull task-specific context instead of dumping all recent activity — preferred for large projects.

Inputs of note:

  • prompt: the user request, in their words or your paraphrase.

  • activeFiles (recommended): files you have identified as relevant to the request. Significantly improves relevance.

  • maxIntents, maxDecisions, minRelevance: result-shaping caps and threshold.

Returns:

  • relevantIntents: past work units (intents) related to the task, scored by relevance.

  • relevantDecisions: prior decisions related to the task — both intent-scoped and repo-scoped. Summary-only (no inline rationale, to keep context lean); call get_decision_detail(decisionId) for the full rationale/context/consequences of any decision you want to open.

Recommended sequence:

  1. check_active_intent at session start to resume any existing work.

  2. Briefly explore the user's request to identify involved files.

  3. get_relevant_context with the prompt and activeFiles to inform the approach.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
promptYesThe user request to find relevant context for
repoPathYesLocal path to the repository root
forkAuthorNoFork attribution; usually resolved by Muninn automatically — pass only for override / testing.
maxIntentsNoMaximum number of intents to return
repoOriginNoGit remote origin URL. Auto-detected from repoPath via git if not provided.
activeFilesNoFiles currently being discussed or recently opened
workspaceIdNoWorkspace identifier; usually resolved by Muninn automatically — pass only for override / testing.
maxDecisionsNoMaximum number of decisions to return
minRelevanceNoMinimum relevance score (0-1)
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses return types (relevantIntents, relevantDecisions), notes that decisions are summary-only, and suggests get_decision_detail for full rationale. It does not mention auth or read-only nature, but the tool is clearly non-destructive.

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?

The description is well-structured with sections: main purpose, when to use, inputs of note, returns, recommended sequence. It is front-loaded with the core purpose, and every sentence adds value without redundancy.

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 9 parameters, 100% schema coverage, no output schema, the description explains return values and usage sequence. It provides enough context for an agent to decide when and how to use the tool, including prerequisites and follow-up steps.

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%, baseline 3. The description adds value by explaining the purpose of key parameters: prompt (paraphrase allowed), activeFiles (improves relevance), maxIntents/maxDecisions/minRelevance (result-shaping), and forkAuthor/workspaceId (auto-resolved). This helps the agent use parameters correctly.

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?

The description clearly states 'Find past intents and decisions relevant to the current user request.' It uses specific verb-resource, and distinguishes from sibling tools like get_intents_for_file by returning both intents and decisions, and by being task-specific.

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?

The description explicitly provides 'When to use' conditions, advising against vague prompts and recommending use after initial exploration. It also gives a preferred use case for large projects. However, it does not explicitly name sibling tools as alternatives or state when not to use this tool.

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