Skip to main content
Glama

get_context_for_file

Retrieves project conventions from AI_README files to align code suggestions with existing codebase standards.

Instructions

ALWAYS CALL THIS FIRST - NO EXCEPTIONS. WHEN TO CALL (check these FIRST before responding):

  • User asks: optimize, improve, analyze, review, suggest, think, opinion.

  • User mentions: file name, component name, project, codebase, backend, frontend, infra, devops, CI/CD, docker, config.

  • User asks: "what can", "what should", "how to", "can you", "help me".

  • User wants to: create, build, add, implement, setup, configure, deploy, migrate, optimize, refactor, improve, analyze, review, suggest, think, opinion.

  • User selects an option that leads to code changes (e.g., choosing from a list of approaches).

  • User says: "next step", "next phase", "next section", "continue", "proceed", "go ahead", "start", "do it", "yes" (confirming action).

  • Before: Write, Edit, TodoWrite, Bash (for build/deploy), suggesting ANY code changes.

  • When executing a plan, todo, or multi-phase task: call BEFORE each file modification.

  • After user approves a plan or todo, call this BEFORE the each Write/Edit. IF ANY ABOVE = TRUE → CALL get_context_for_file IMMEDIATELY.

MANDATORY: Call this tool BEFORE every code-related response.

CALL EVERY TIME - EVERY response that involves code/suggestions MUST start with get_context_for_file. CALL EVERY TIME - even if you called it earlier in this conversation. CALL EVERY TIME - even if working on the same file. CALL EVERY TIME - even within the same section/phase - multiple calls are expected and correct. CALL EVERY TIME - context may have changed or sub-directories may have additional conventions. CALL EVERY TIME - when user confirms or selects an option that will result in code changes.

What this tool does: Gets AI_README context showing project conventions that MUST be followed. Why it matters:

  • Without: Wrong tech (suggest Tailwind when project uses CSS Modules).

  • With: Suggestions fit existing codebase perfectly.

  • During plan/todo/phase execution: Context may differ per directory; call before EACH file change. DETECT CONFLICTS: After reading context, if user wants X but AI_README says Y:

  • This is ARCHITECTURAL DECISION.

  • Workflow: get_context → update_ai_readme → get_context → Write/Edit.

RECORD DECISIONS: When you make architectural decisions during planning or implementation:

  • Design patterns, API structure, naming conventions, new abstractions.

  • Call update_ai_readme to record decisions that affect multiple files.

  • Future code (yours or others) will follow these recorded conventions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesThe path to get context for (relative to project root). Can be either a FILE path or a DIRECTORY path. Examples: "src/components/Button.tsx", "src/components", "README.md", "src/app". Use "." to get root-level context when no specific file is known. The tool will find all relevant AI_README files in the path's directory and parent directories.
includeRootNoWhether to include root-level AI_README (default: true)
projectRootYesThe root directory of the project. Use the current working directory (e.g., from environment or pwd). If unsure, pass the project root path.
excludePatternsNoGlob patterns to exclude when scanning
Behavior4/5

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

No annotations provided, so description carries full burden. It explains that context may differ per directory, multiple calls are expected, and that without it the agent may suggest wrong tech. However, it does not explicitly state that the tool is read-only or non-mutating, though implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a strong imperative, but it is overly verbose with repeated 'CALL EVERY TIME' sections and a long list of triggers. It could be trimmed significantly without losing clarity.

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 the complexity (4 params, no output schema), the description covers usage context thoroughly, including siblings workflow and conflict detection. However, it lacks any description of the return format, which would be important for an agent.

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 coverage is 100% with descriptions for all 4 parameters. The description adds some value for the 'path' parameter with examples and usage notes, but for others like 'includeRoot' and 'excludePatterns', it adds little beyond the schema. Since coverage is high, baseline 3 is appropriate.

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 'Gets AI_README context showing project conventions that MUST be followed.' It identifies the verb (get), resource (AI_README context), and scope (project/file-level). It distinguishes from sibling tools like update_ai_readme and validate_ai_readmes by focusing on retrieval.

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 an exhaustive list of when to call, including specific user intents and triggers. Explicitly states 'CALL EVERY TIME' before code changes. Includes a workflow: get_context → update_ai_readme → get_context → Write/Edit, clearly differentiating from siblings.

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/Draco-Cheng/ai-readme-mcp'

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