Skip to main content
Glama

get_decisions_for_context

Retrieve curated engineering decisions for a file or task. Use before writing code to adopt team conventions, preferred patterns, and avoid rejected approaches.

Instructions

Fetch the team's canonical engineering decisions for a file/area and task.

    Call this FIRST, before writing or editing code in an area — and again when you
    move to a new file or module. It surfaces the conventions, preferred patterns,
    rejected approaches, and known gotchas the team has already curated for that part
    of the codebase, so you write code that matches their standards on the first try
    instead of rediscovering them. Read the returned decisions and comply with them.

    Behavior: only human-approved (canonical) decisions are returned, ranked by how
    well their scope matches `file_path_or_area` and by how helpful past agents
    rated them. Each call also records a usage event so your later `submit_feedback`
    can be tied back to this exact result set.

    Returns a plain-text block. The first line is a header carrying the query token
    and server revision; then each decision is numbered for rating by index, e.g.:

        metatron:query 7f3a... · rev 0.2.1 (reference the query id in submit_feedback)
        [1] [high] Use internal.http for outbound calls, not the requests library
          scope: src/services/**
          why: flaky network caused phantom 5xx errors; the internal client retries

    Keep the query token: pass it to `submit_feedback` after the task to rate the
    decisions by their `[index]`. If nothing is registered for the area, the body is
    exactly "No matching decisions." — proceed normally.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
file_path_or_areaYesThe file path, directory, or architectural area you are about to work in (e.g. "src/routes/api/users.py" or "billing").
task_descriptionYesA short description of what you are about to do there (e.g. "add error handling to the billing webhook").

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

No annotations provided, so description fully carries the burden. It discloses that only human-approved decisions are returned, ranked by scope match and past ratings, that each call records a usage event for feedback linkage, and details the exact return format including the query token and the case of no matches.

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?

The description is moderately long but well-structured: opening purpose, usage guidance, behavioral details, return format, and reminder. It is front-loaded with critical information, and every sentence adds value. Could be slightly more concise but overall effective.

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?

The description fully explains the tool's behavior, return format (including header, numbered decisions, and no-match case), and how to use the output with siblings. Despite the presence of an output schema (not shown here), the description covers all necessary context for correct invocation.

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 description coverage is 100%, so baseline is 3. The description adds value by giving concrete examples for 'file_path_or_area' ('src/routes/api/users.py' or 'billing') and for 'task_description', and by explaining how these parameters fit into the workflow (e.g., 'surfaces ... conventions for that part of the codebase').

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 the tool fetches 'team's canonical engineering decisions' for a file/area and task, using a specific verb 'fetch' and resource. It distinguishes from sibling tools 'submit_candidate_decision' and 'submit_feedback' by focusing on retrieval, not submission or feedback.

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?

Explicitly instructs to 'Call this FIRST, before writing or editing code in an area — and again when you move to a new file or module.' It also tells agents to use 'submit_feedback' afterward, providing clear context and alternatives.

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/kerbelp/metatron'

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