TempoGraph is an MCP server that builds a deep dependency graph of your codebase to provide AI agents with precise, context-aware file and symbol information for coding tasks.
Core Task Assistance
prepare_context – One-shot context for a coding task; selects relevant files, symbols, and hotspots within a token budget (proven +18.6% file prediction improvement)
diff_context – Impact analysis for changed files, with git auto-detection (unstaged, staged, commit, branch)
cochange_context – Uses git history to find files that frequently change together (logical coupling detection)
Codebase Understanding
overview – Project type, languages, biggest/most complex files, module dependencies, and circular import warnings
file_map – File tree with top symbols per file
architecture – High-level module-to-module dependency view
symbols – Full symbol index: every function, class, component, hook, and type with signatures and relationships
stats – File/symbol/edge/line counts and estimated token costs per mode
Dependency & Impact Analysis
focus – Task-scoped context around a query or symbol, including callers/callees and related files
blast_radius – What breaks if you change a given file or symbol (importers, callers, cross-language bridges)
dependencies – Detects circular imports and shows dependency layer structure
lookup – Natural language questions: "where is X defined?", "what calls X?", "what imports X?"
Risk & Quality
hotspots – Ranks riskiest symbols by coupling, complexity, and cross-file callers
dead_code – Exported symbols never referenced elsewhere — cleanup candidates
get_patterns – Coding conventions, naming patterns, and structural idioms
Search
search_semantic – Hybrid FTS5 keyword + vector similarity search to find symbols by meaning (requires embed_repo)
embed_repo – Generate local vector embeddings (BAAI/bge-small-en-v1.5) for semantic search
Automation & Workflows
run_kit – Composable multi-tool workflows (e.g., explore, deep_dive, change_prep, code_review, health)
suggest_next – Predicts the most useful next tool based on learned session patterns
learn_recommendation – Data-driven context strategy recommendations based on task type and usage history
Repository Management
index_repo – Build or rebuild the semantic graph index
watch_repo / unwatch_repo – Live incremental graph updates on file changes
Feedback
report_feedback – Log whether a tool's output was helpful to improve future recommendations
Supports deep extraction for Python, TypeScript, JavaScript, Rust, Go, Java, C#, and Ruby, plus generic support for 170+ additional languages. Warm queries run in ~21ms with content-hashed storage so only changed files are re-parsed.
Your AI agent finds the right files. Every time.
TempoGraph builds a dependency graph of your codebase and gives your AI coding agent exactly the files it needs before making changes. One tool call. No guessing.
AI coding agents guess which files to look at. They search by filename, grep for keywords, and hope for the best. In large codebases, they miss critical dependencies, break things downstream, and waste tokens reading irrelevant code.
Related MCP server: better-code-review-graph
pip install tempographAdd to your MCP config (Claude Code, Cursor, Windsurf, or any MCP client):
{
"mcpServers": {
"tempograph": {
"command": "tempograph-server",
"args": []
}
}
}Your agent calls prepare_context with a task description. TempoGraph returns the exact files that matter — based on real dependency analysis, not text matching.
Tested on real PRs from django, flask, httpx, fastapi, requests, and pydantic. Task: predict which files need to change.
Model | Without TempoGraph | With TempoGraph | Improvement |
GPT-4o | 21.7% F1 | 27.5% F1 | +27% |
GPT-4o-mini | 19.2% F1 | 24.5% F1 | +28% |
qwen2.5-coder:32b | — | — | +18.6% (p=0.049) |
Consistent improvement across every model. 2-3x more tasks helped than hurt. No other code context tool publishes retrieval benchmarks with statistical significance.
your repo ──→ tree-sitter parse ──→ symbols + edges ──→ SQLite graph
│
AI agent calls prepare_context ─────────┘
│
◄── KEY FILES + callers + callees + risk signalsParses your code with tree-sitter into a structural dependency graph
Content-hashed and stored in SQLite — only changed files get re-parsed
Warm queries in ~21ms. Branch switching doesn't trigger a rebuild
Knows when NOT to inject context (adaptive gating avoids harming diffuse commits)
Beyond prepare_context, TempoGraph exposes 24 MCP tools for deeper analysis when your agent needs it:
Tool | When to use it |
| "What breaks if I change this file?" |
| "Show me everything related to auth" |
| "Which files are riskiest to change?" |
| "What can I safely delete?" |
| "What's the impact of my current changes?" |
| "Orient me in this new codebase" |
Tool | What it does |
| One-shot context for a task — the primary tool |
| Repository orientation: size, languages, entry points |
| Connected subgraph around a symbol — callers, callees |
| What breaks if you change this file or symbol |
| Impact analysis of changed files |
| Ranked risk list — complexity x coupling x size |
| Unreferenced symbols — cleanup candidates |
| "Where is X?", "What calls X?" |
| Circular imports, dependency layers |
| Module-level dependency view |
| Full symbol inventory |
| File tree with top symbols per file |
| Hybrid keyword + vector + structural search |
| Files that historically change together |
| Predicts the next useful tool call |
| Composable multi-tool workflows |
| Token budget estimates |
| Codebase conventions and idioms |
| Log whether output was useful |
| Suggestions from feedback history |
| Build or rebuild the graph |
| Live incremental updates |
| Generate vector embeddings |
# Orient in a new repo
tempograph ./my-project --mode overview
# What's connected to auth?
tempograph ./my-project --mode focus --query "authentication"
# What breaks if I touch db.ts?
tempograph ./my-project --mode blast --file src/lib/db.ts
# Find dead code to clean up
tempograph ./my-project --mode deadfrom tempograph import build_graph
graph = build_graph("./my-project")
results = graph.search_symbols("handleLogin")
importers = graph.importers_of("src/lib/db.ts")
dead = graph.find_dead_code()Python, TypeScript, JavaScript, Rust, Go, Java, C#, and Ruby get deep extraction (custom tree-sitter handlers). 170+ additional languages are supported via generic handler. pip install tempograph[full] for everything.
If TempoGraph saves you time, consider sponsoring the project. Sponsors get early access to new features.
TempoGraph is AGPL-3.0 — free to use, modify, and distribute. If you use TempoGraph in a network service (SaaS, hosted IDE, AI coding platform), AGPL requires you to open-source your service code. If that doesn't work for you, commercial licenses are available.
Contact eali@needspec.com for commercial licensing terms.
AGPL-3.0 — free to use. Network service use requires source disclosure, or a commercial license.
High-level architecture view: modules, their roles, and inter-module dependencies. Groups files into top-level directories, shows import and call edges between modules. Use for understanding how the codebase is organized at a macro level.
exclude_dirs: comma-separated directory prefixes to skip
output_format: "text" (default) or "json" for structured response| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| exclude_dirs | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses that the tool groups files, shows import/call edges, and supports text or JSON output. It implies a read-only analysis, though it doesn't explicitly state non-destructive behavior or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief, well-structured with separate parameter explanations, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity and presence of output schema, the description is sufficient. It covers core functionality and parameters, though it could mention prerequisites or scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning for 'exclude_dirs' (comma-separated prefixes) and 'output_format' (text or JSON). 'repo_path' is not explained beyond default, but overall it compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it produces a high-level architecture view with modules, roles, and inter-module dependencies. It distinguishes from siblings like 'dependencies' and 'file_map' by focusing on macro-level organization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states 'Use for understanding how the codebase is organized at a macro level.' Does not provide when-not-to-use or explicit alternatives, but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What breaks if you change this file or symbol? Shows importers, external callers, component render chains, and cross-language bridges.
Parameter priority: if BOTH file_path and query are provided, query wins.
- file_path: whole-file blast radius, e.g. "src/lib/db.ts"
- query: symbol-level blast radius (more precise), e.g. "Sparkline.max"
For large monolith files, prefer query over file_path.
At least one of file_path or query must be provided.
output_format: "text" (default) or "json" for structured response| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| file_path | No | ||
| query | No | ||
| exclude_dirs | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations require full burden on description; it reveals parameter priority, required-parameter condition, and output options. However, it lacks details on authorization or rate limits, though these are less critical for a read-only analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses bullet points and parameter lists effectively, is free of fluff, and front-loads the core purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers purpose, usage scenarios, parameter dependencies, and output format. It could mention response size or async behavior, but existing output schema supplements return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description explains file_path and query well, and mentions output_format, but leaves repo_path and exclude_dirs unexplained. This is partial compensation for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'What breaks if you change this file or symbol?' and details specific impact types (importers, external callers, etc.), making the tool's purpose unambiguous and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use file_path vs query and prefers query for large files, but does not compare with sibling tools like 'dependencies' or 'cochange_context'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Files that historically co-change with a given file (logical coupling).
Uses git history to find files frequently changed in the same commits.
Useful for discovering hidden dependencies: if A and B co-change 80% of
the time, a change to A likely requires reviewing B.
file_path: path relative to repo root (e.g., "tempograph/render.py")
n_commits: how many recent commits to analyze (default 200)
output_format: "text" (default) or "json"
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| file_path | No | ||
| n_commits | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it uses git history, analyzes recent commits controlled by n_commits, and outputs results in text or JSON. It does not mention performance or mutation (it's read-only), but the behavior is adequately described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line purpose, a brief explanation, and a bullet-like list of parameter details. Every sentence adds value, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description appropriately avoids explaining return values. It covers the tool's concept and most parameters. It is complete enough for effective use, though the missing repo_path parameter reduces completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains file_path (with example), n_commits (default 200), and output_format (text/json). However, it completely omits the repo_path parameter, leaving that undocumented. This gap reduces the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds files that historically co-change with a given file (logical coupling). It uses a specific verb-resource pair ('co-change' and 'context') and distinguishes itself from siblings like 'dependencies' by focusing on historical co-change patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage advice: 'useful for discovering hidden dependencies' with an example condition. While it doesn't explicitly compare to sibling tools, the context is clear enough for an agent to infer when 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.
Find exported symbols never referenced by other files. Potential cleanup targets — unused exports, orphaned functions, dead interfaces. Respects Python all for precise export tracking.
max_tokens: cap output size (default 8000) to prevent context overflow
exclude_dirs: comma-separated directory prefixes to skip
output_format: "text" (default) or "json" for structured response
include_low: include low-confidence (likely false positive) symbols (default False,
saves ~47% tokens — ~1,300 tokens on a typical repo)| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| max_tokens | No | ||
| exclude_dirs | No | ||
| output_format | No | text | |
| include_low | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses token-saving behavior for include_low and clarifies parameter effects. However, it does not state that the tool is read-only or describe potential side effects (though likely none). The explanation of low-confidence symbols adds transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear lead sentence and bullet-point parameter explanations. It is concise but includes necessary detail. Minor redundancy in the parameter list could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values need not be documented. The description covers all parameters and provides usage details. It lacks mention of edge cases (e.g., empty repo, no dead code found) but is largely complete for a code analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates by explaining each parameter's purpose, default, format, and effect (e.g., max_tokens for context overflow, exclude_dirs for directory prefixes, output_format choices, include_low token savings). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Find exported symbols never referenced by other files.' It elaborates on cleanup targets (unused exports, orphaned functions, dead interfaces) and mentions Python __all__ support, making the purpose unambiguous and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like dependencies or blast_radius. The description focuses on parameter usage but does not provide context-specific recommendations or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dependency analysis: circular imports and layer structure. Shows import cycles and which files depend on which layers. Use before refactoring to understand the dependency graph.
exclude_dirs: comma-separated directory prefixes to skip
output_format: "text" (default) or "json" for structured response| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| exclude_dirs | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not state that tool is read-only or safe, nor any potential side effects or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short, front-loaded description with three sentences plus parameter explanations; no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose and two parameters; output schema exists but not shown. Missing repo_path explanation and behavioral transparency, but otherwise adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Explains exclude_dirs and output_format in description, but repo_path is left unexplained despite being a key parameter. Schema coverage is 0%, so description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states circular imports and layer structure analysis; distinguishes from siblings like architecture or blast_radius by focusing on dependency graph and refactoring use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use before refactoring to understand the dependency graph', but does not mention when not to use it or compare to alternatives like architecture or blast_radius.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Impact analysis for changed files. Pass comma-separated paths OR use scope to auto-detect from git.
changed_files: comma-separated file paths (overrides scope if provided)
scope: git detection mode — "unstaged" (default), "staged", "commit", "branch"
max_tokens: cap output length (default 6000)
output_format: "text" (default) or "json" for structured response
NOTE: When using scope (git auto-detect), the repo must be a git repository.
Returns a NOT_GIT_REPO error if it isn't. If changed_files is provided,
git is not required.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| changed_files | No | ||
| scope | No | unstaged | |
| max_tokens | No | ||
| exclude_dirs | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It mentions error conditions (NOT_GIT_REPO) and default values, but does not discuss authorization, rate limits, or whether the operation is read-only. This is adequate but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose first, then parameter explanations. It is front-loaded with the core concept. While slightly lengthy, every sentence adds value. A bit more conciseness could be achieved, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality and key parameters, but leaves out two parameters (repo_path, exclude_dirs). The presence of an output schema partially compensates for return value documentation. Given the tool's complexity (6 parameters, no annotations), the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains changed_files, scope, max_tokens, and output_format with clear semantics and defaults. However, it omits repo_path and exclude_dirs, two of six parameters. Since schema description coverage is 0%, the description should cover all parameters; the omission is a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Impact analysis for changed files' with two distinct input methods (comma-separated paths or git auto-detection). This differentiates it from sibling tools like dependencies or dead_code that focus on static analysis, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use changed_files vs scope, noting that changed_files overrides scope and scope requires a git repository. It also warns about the NOT_GIT_REPO error. However, it does not explicitly compare with sibling tools, which would elevate the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate embeddings for semantic search across all symbols in the codebase.
Run after index_repo to enable hybrid search (FTS5 + vector similarity).
Uses BAAI/bge-small-en-v1.5 (33MB, runs locally on CPU, no API keys).
Only embeds symbols without existing vectors — fast on subsequent runs.
Requires: pip install tempograph[semantic]
repo_path: absolute path to repository
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| exclude_dirs | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses local CPU execution, no API keys, incremental updates, and pip requirement. Adds significant behavioral context beyond default read/write assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: four short sentences covering purpose, prerequisite, model details, and behavior. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, sequence, and model behavior well, but fails to document two of three parameters (exclude_dirs, output_format). Output schema exists, so return info not required, but parameter gap reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. Only repo_path is mentioned (in a minimal way), while exclude_dirs and output_format are completely undocumented. Insufficient for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it generates embeddings for semantic search across symbols. Explicitly ties to index_repo and hybrid search, distinguishing it from sibling tools like index_repo and search_semantic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tells user to run after index_repo and mentions idempotent behavior (only missing vectors). Lacks explicit when-not or alternative tools, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
File tree with top symbols per file. Good for orientation and understanding project structure. Shows directory groupings, file sizes, and key symbols.
Use overview for a cheaper orientation, or focus for task-specific context.
max_symbols_per_file: how many symbols to show per file (default 8)
max_tokens: cap output (default 4000; 0 = use default)
exclude_dirs: comma-separated directory prefixes to skip
output_format: "text" (default) or "json" for structured response| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| max_symbols_per_file | No | ||
| max_tokens | No | ||
| exclude_dirs | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full burden. It describes the tool's output (file tree, symbols, sizes) but does not explicitly state it is read-only or safe, nor discuss error handling or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose lead, usage alternative hint, and parameter details. It is mostly concise, though parameter details could arguably be in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers the tool's purpose, usage, and key parameters. It mentions output content and format options, making it sufficient for a file mapping tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains max_symbols_per_file, max_tokens, exclude_dirs, and output_format in plain language, adding meaning beyond schema titles. Repo_path is not described, but is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it produces a file tree with top symbols per file for orientation and understanding project structure. It distinguishes from siblings by advising to use overview for cheaper orientation or focus for task-specific context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool vs alternatives, mentioning overview and focus. However, it does not include restrictions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get task-scoped context. Describe what you're working on and get back the relevant symbols, their callers/callees, complexity warnings, and related files — all within a token budget.
query: natural language description or symbol name
max_tokens: cap output length (default 4000)
exclude_dirs: comma-separated directory prefixes to skip
output_format: "text" (default) or "json" for structured response
Examples: "authentication middleware", "Canvas command palette",
"database migrations", "AI assistant toolbar"
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| query | No | ||
| max_tokens | No | ||
| exclude_dirs | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of disclosing behavior. It mentions token budgeting and output formats but does not explicitly state that the operation is read-only, or detail authorization needs or side effects. It partially describes output but lacks full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose, followed by a clear list of parameters with brief explanations, and useful examples. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and an existing output schema, the description covers the tool's purpose, parameters, and provides examples. It is nearly complete, though it could mention prerequisites (e.g., if the repo needs to be watched) and clarify the default repo_path.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description provides essential meaning for most parameters: query, max_tokens, exclude_dirs, output_format. The repo_path parameter is not explained, but it has a default. The description adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'get[s] task-scoped context' and lists the types of information returned (symbols, callers/callees, complexity warnings, related files). It distinguishes itself from siblings by its task-focused scope, though it doesn't explicitly differentiate from similar tools like 'diff_context' or 'prepare_context'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples (e.g., 'authentication middleware') and implies it should be used when working on a specific task. However, it does not mention when not to use it or alternatives among the sibling tools, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get coding patterns and conventions for this codebase.
Returns a catalog of naming conventions, structural patterns, module roles,
and repeated idioms. Use this before writing new code to ensure you follow
the project's existing conventions.
query: optional filter (e.g. "render", "plugin", "test", "handler")
max_tokens: cap output size (default 4000)
exclude_dirs: comma-separated directory prefixes to skip
output_format: "text" (default) or "json"
Examples:
- get_patterns(".") → full convention catalog
- get_patterns(".", query="plugin") → plugin-related patterns
- get_patterns(".", query="render") → rendering conventions
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| query | No | ||
| max_tokens | No | ||
| exclude_dirs | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies a read-only operation (no side effects mentioned), but does not explicitly state non-destructiveness, auth needs, or rate limits. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured with a clear opening, bullet-pointed parameters, and example calls. No redundant sentences; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations, the description covers purpose, when to use, parameter semantics, and examples. An output schema exists, so return values are handled. Complete for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining each parameter's purpose (query filter, max_tokens cap, exclude_dirs, output_format). Examples illustrate usage, adding value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'coding patterns and conventions' for the codebase, with a specific verb ('Get') and resource. It distinguishes itself from siblings like 'lookup' and 'symbols' by focusing on patterns and conventions rather than code search or symbols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use 'before writing new code to ensure you follow the project's existing conventions.' Examples show typical queries (plugin, render). Lacks explicit 'when not to use' or alternative sibling tool references, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the riskiest symbols: highest coupling, complexity, and cross-file callers. These are where bugs cluster and changes are most dangerous. Use before modifying unfamiliar code to know what to be careful around.
top_n: how many hotspots to return (default 15)
exclude_dirs: comma-separated directory prefixes to skip
output_format: "text" (default) or "json" for structured response| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| top_n | No | ||
| exclude_dirs | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not explicitly state that the tool is read-only or disclose any behavioral traits such as rate limits or side effects. The description focuses on what it finds but not on what it does behaviorally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose first, then usage guidance, then parameter details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no annotations, the description covers the main purpose, usage, and most parameters. The output format is mentioned, and the output schema exists so return values need not be detailed. Minor omission is the repo_path parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description explains three of four parameters (top_n, exclude_dirs, output_format) with useful details like defaults and formats. The repo_path parameter is not explained, which is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's purpose: 'Find the riskiest symbols: highest coupling, complexity, and cross-file callers.' This is a specific verb+resource combination that distinguishes it from siblings like 'dependencies' or 'dead_code'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: 'Use before modifying unfamiliar code to know what to be careful around.' While it doesn't explicitly mention alternatives or when not to use, the guidance is adequate for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build the semantic index and return a full orientation. Run this once at session start. Returns project type, stats, top files, complexity hotspots, and module dependency map. ~500-700 tokens — everything an agent needs to begin.
exclude_dirs: comma-separated directory prefixes to skip (e.g. "archive,vendor,dist").
Also reads from .tempo/config.json "exclude_dirs" array. Both sources are merged.
output_format: "text" (default) or "json" for structured response with
{status, data, tokens, duration_ms} fields.| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| exclude_dirs | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses the token range (~500-700) and explains merge behavior for exclude_dirs. Missing details on whether indexing is persistent, destructive, or requires permissions. Partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with purpose and quick overview. Parameters are explained in a bullet-style format. No redundant sentences; efficient use of space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return value and basic behavior but omits idempotency, cost (time/resources), and permission requirements. Given complexity (indexing tool) and lack of annotations, some gaps remain, but the token estimate and output format details help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, requiring description to compensate. Description adds meaning for 'exclude_dirs' (merge with config) and 'output_format' (text vs json response). 'repo_path' is left to schema (default /demo) with no additional context. Incomplete but helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Build the semantic index and return a full orientation.' It specifies what it does and gives a list of outputs (project type, stats, top files, etc.). It distinguishes itself as the initial session setup tool, but does not explicitly compare to siblings like 'embed_repo' or 'file_map'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Run this once at session start,' providing a clear when-to-use instruction. However, it does not mention when not to use it or suggest alternative tools (e.g., 'search_semantic' after indexing), limiting guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a data-driven context strategy recommendation from learned usage patterns.
Returns the best modes to use, expected token cost, and success rate for a given task type.
Known task types: debug, feature, refactor, code_navigation, orientation, cleanup,
architecture, dependency_audit, code_review, task_preparation, output_review,
learning, patterns.
Leave task_type empty to see all learned strategies for this repo.
NOTE: Requires the tempo package to be installed. Returns a LEARN_UNAVAILABLE
error if not installed — install with: pip install -e .
output_format: "text" (default) or "json" for structured response
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| task_type | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses dependency on tempo package and the error if missing, but omits details on permissions, side effects, or read-only nature. With no annotations, the description adds moderate behavioral context but is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded with the core purpose. Every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the tool's purpose, parameters, usage note, and output options. With an output schema present, it need not detail return values. Minor gaps include not explaining 'best modes' or linking to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description explains task_type (with list and empty case) and output_format (default and options). Repo_path is not explicitly explained but is self-explanatory from its name and default. Overall, it adds meaningful value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a data-driven context strategy recommendation, lists specific outputs (best modes, token cost, success rate), and enumerates known task types, making the purpose distinct and unambiguous from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions: leaving task_type empty shows all strategies, requires tempo package, and mentions output_format options. However, it lacks explicit differentiation from alternatives like 'suggest_next' or 'get_patterns'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answer a specific question about the codebase. Understands patterns like: - "where is X defined?" - "what calls X?" / "who uses X?" - "what does X call?" / "dependencies of X" - "what files import X?" - "what renders X?" (JSX/component tree) - "what implements X?" / "what extends X?"
Falls back to fuzzy symbol search if no pattern matches.
Typically ~100-500 tokens.
question: natural language question about the codebase
output_format: "text" (default) or "json" for structured response| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| question | No | ||
| exclude_dirs | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides adequate behavioral info: pattern matching, fallback, typical token length. However, it does not explicitly state read-only nature or side effects, though lookup is inherently read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with purpose. The list of patterns aids understanding, though it could be more structured (e.g., bullet points). No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (codebase lookup) and presence of an output schema, the description covers key behavior (patterns, fallback, token length). It lacks details on error cases or handling of no matches, but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description carries the burden. It explains 'question' (natural language question) and 'output_format' (text/json), but does not explain 'repo_path' or 'exclude_dirs'. This partial coverage meets baseline but does not fully compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Answer a specific question about the codebase.' It provides concrete examples of understand patterns (e.g., 'where is X defined?', 'what calls X?'), distinguishing it from sibling tools like `search_semantic` or `symbols`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool: for specific questions with known patterns. It mentions fallback to fuzzy symbol search, implying alternatives, but does not explicitly state when not to use it or list sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Repo orientation: project type, languages, biggest/most complex files, module dependencies, circular import warnings. ~500 tokens. Use this to understand the codebase structure. For coding tasks, call prepare_context(task="...") next — it selects the right context automatically.
repo_path: path to the repository (try "/demo" for a FastAPI demo)
exclude_dirs: comma-separated directory prefixes to skip (e.g. "archive,vendor")
output_format: "text" (default) or "json" for structured {status, data, tokens, duration_ms}.| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| exclude_dirs | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses output content (project type, languages, complex files, dependencies, circular import warnings), token estimate (~500), and format options. It implies read-only behavior without side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences for purpose, then parameter descriptions in a clean bullet-like format. No redundancies, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, output schema exists), the description covers all needed aspects: what it does, parameters, output hints, and next-step guidance. Nothing critical missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have meaningful descriptions: repo_path with example, exclude_dirs with format and example, output_format with default and option. Schema coverage is 0%, so description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool provides repo orientation (project type, languages, files, dependencies, warnings) and distinguishes from siblings like prepare_context by guiding the agent to use it for understanding structure and then call prepare_context for coding tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (understand codebase structure) and when not (for coding tasks, use prepare_context instead) with a clear alternative mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The recommended tool for coding tasks. Give it your task and get back a token-budgeted context with the right files, symbols, and hotspots — all in one call. Proven +18.6% file prediction improvement (p=0.049*, n=45). 95% helpful rate. Use this instead of calling index_repo → focus → blast_radius manually.
task: describe what you're working on. Two modes are auto-selected:
- PR/commit titles ("Merge pull request #123 from org/fix-auth-bug",
"fix: prevent null pointer in handler", "Fix teardown callbacks (#5928)")
→ keyword extraction from branch name → per-keyword symbol focus → KEY FILES list
→ proven +7% file prediction improvement on real PRs (canonical n=159, p=0.035*)
- General coding tasks ("add pagination to user list", "refactor database layer")
→ fuzzy symbol search → overview fallback if no match
task_type: optional hint — "changelocal" forces keyword-extraction path regardless
of task format; also accepts "debug", "feature", "refactor", "review"
max_tokens: total token budget for the response (default 6000)
exclude_dirs: comma-separated directory prefixes to skip
baseline_predicted_files: optional list of files already predicted by the model
(for adaptive injection). Two skip conditions:
1. If len(baseline) ≥ 3 → returns "" (model is highly confident with 3+ predictions;
any context disagrees more than it helps). Evidence: falcon bl=1.000, 3 correct preds
→ av2 without this guard injected anyway → F1 1.0→0.5 (commit 988960b/d4eb3c8).
2. If overlap(baseline ∩ KEY FILES) ≥ 50% → returns "" (model already knows the files).
Otherwise: returns full context (model needs the structural graph bridge).
Bench (canonical): python3 -m bench.changelocal.analyze --canonical --conditions baseline,tempograph_adaptive
Canonical result (n=159 Python+JS): +6.9% F1 (p=0.035*). Cost: 2× inference for ~37% of tasks.
precision_filter: if True, skip context when >4 key files are found (topic too broad).
Canonical bench: python3 -m bench.changelocal.analyze --canonical --conditions baseline,tempograph_precision
Canonical result (n=159 Python+JS): +3.7% F1 (p=0.21, ns). Default False (plain tempograph = +6.0%
outperforms precision_filter on canonical corpus). Enable only for high-baseline repos.
definition_first: if True, when a keyword produces too-broad focus (>10 files) and no path match,
fall back to the *defining file* of the top-ranked symbol (requires score≥10 and ≤2 defining files).
Handles "redirect" → flask/helpers.py instead of injecting nothing.
Default True (enabled).
output_format: "text" (default) or "json" for structured response
Returns: overview summary + focused context + KEY FILES + hotspot warnings,
all within the token budget. JSON format adds `key_files` (parsed list) and `injected` (bool).
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| task | No | ||
| task_type | No | ||
| max_tokens | No | ||
| exclude_dirs | No | ||
| baseline_predicted_files | No | ||
| precision_filter | No | ||
| definition_first | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description exhaustively covers behavior: token budgeting, mode selection, skip conditions for baseline predictions, precision filter effects, and fallback logic for definition_first.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but somewhat lengthy, though well-structured with clear sections and bullet points. It front-loads the main purpose, but benchmark details could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 params, no annotations), the description covers all relevant aspects: usage, parameter details, behavioral nuances, and return format (text vs JSON). The output schema exists, so return values are not missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description elaborates on every parameter except repo_path (which has a default). It explains task types, max_tokens, exclude_dirs, baseline_predicted_files with skip logic, precision_filter with benchmark data, definition_first behavior, and output_format options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for coding tasks, specifying it provides token-budgeted context with files, symbols, and hotspots. It distinguishes itself from manually calling multiple tools like index_repo, focus, and blast_radius.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this instead of calling index_repo → focus → blast_radius manually.' It also details two modes for different task types and conditions for baseline_predicted_files, precision_filter, etc.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report whether tempograph output was helpful for your current task. Call after using any tempograph tool. Helps improve the product.
mode: which tool you used (index_repo, overview, focus, hotspots, blast_radius, diff_context, dead_code, lookup, symbols, file_map, dependencies, architecture, stats, prepare_context, learn_recommendation)
helpful: true if the output helped, false if not
note: optional — what was missing or what worked well
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| mode | No | ||
| helpful | No | ||
| note | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether the tool is read-only, destructive, or any rate limits or permissions needed. It only briefly explains parameters, which is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and usage, followed by parameter explanations. It is relatively concise but has room for tighter integration of the parameter list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple feedback tool, the description adequately covers when and how to call it, and explains parameters. The existence of an output schema means return values are documented elsewhere, so the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must compensate. It adds meaning by listing and explaining three parameters (mode, helpful, note) with short descriptions. This provides useful semantics that the schema lacks, though it does not cover every detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Report whether tempograph output was helpful for your current task.' The verb 'report' and resource 'tempograph output' are specific. It distinguishes from sibling tools by noting it is called after using any tempograph tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call after using any tempograph tool,' providing clear usage context. However, it does not mention when not to use it or alternative tools, which would elevate the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a composable kit — a named multi-mode workflow that combines tempograph modes into a single token-budgeted response.
kit: name of the kit to run, or "list" to show all available kits.
Built-in kits:
explore — overview + hotspots (orient to a new codebase)
deep_dive — focus + blast (deep-dive into a symbol)
change_prep — diff + focus (prepare for a code change)
code_review — dead + hotspots + focus (code review workflow)
health — hotspots + dead (codebase health check)
Custom kits can be defined in .tempo/kits.json.
query: optional symbol or topic for focus/blast steps
max_tokens: total token budget across all kit steps (default 4000)
exclude_dirs: comma-separated directory prefixes to skip
output_format: "text" (default) or "json"
Examples:
- run_kit(".", "explore") → overview + hotspots
- run_kit(".", "deep_dive", query="render_focused") → focus + blast on symbol
- run_kit(".", "health") → hotspots + dead code
- run_kit(".", "list") → show all available kits
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| kit | No | ||
| query | No | ||
| max_tokens | No | ||
| exclude_dirs | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool combines modes with a token budget and supports output formats. It does not mention side effects, authentication requirements, or read-only nature. The token-budget detail adds value but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear opening sentence, bullet list of built-in kits, and examples. It is slightly verbose but front-loaded effectively. Every sentence adds value, though some redundancy exists in listing examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It covers parameter usage, built-in kits, and examples. Missing is guidance on error cases (e.g., invalid kit name) and how custom kits are defined, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'kit', 'query', 'max_tokens', 'exclude_dirs', and 'output_format' parameters with context and examples. However, 'repo_path' is only listed in the schema with a default and no explanation, leaving a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run a composable kit — a named multi-mode workflow'. It distinguishes from sibling tools by positioning it as a workflow combiner rather than a single mode. Built-in kits and examples reinforce specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (to run predefined workflows) and includes an option 'list' to discover kits. However, it does not explicitly state when not to use it or suggest alternatives like individual mode tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hybrid semantic + structural search across all symbols in a codebase.
Combines FTS5 keyword matching with vector similarity (if embeddings exist)
using Reciprocal Rank Fusion. Finds symbols by meaning, not just exact name match.
Example: search_semantic(repo, "handle user authentication") finds auth-related
functions even if they're named validate_token or check_credentials.
Run `python3 -m tempograph <repo> --embed` first to enable semantic vectors.
repo_path: absolute path to repository
query: natural language description of what you're looking for
limit: max results (default 10)
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| query | No | ||
| limit | No | ||
| exclude_dirs | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains the hybrid approach using FTS5, vector similarity, and RRF. It also notes the need for pre-computed embeddings. It does not disclose failure modes or fallback behavior if embeddings are missing, but overall provides good behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with paragraphs, an example, and a prerequisite note. It is efficient but could be slightly tighter. Every sentence adds value, though the two-line example could be integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists (unseen), so return values are covered. The description covers the core use case, method, and prerequisites. However, it lacks guidance on excluded directories and output formatting, and does not address edge cases like missing embeddings. Still, it is generally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It meaningfully describes three of five parameters (repo_path, query, limit) but omits exclude_dirs and output_format. The described parameters add clear semantic value beyond the schema, but the missing ones are a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs hybrid semantic + structural search across all symbols in a codebase. It distinguishes itself from exact name matching with a vivid example, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (to find symbols by meaning) and provides a prerequisite (run `python3 -m tempograph <repo> --embed` first). However, it does not contrast with sibling tools nor specify conditions where this tool is not suitable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quick repo statistics: file count, symbol count, edge count, line count, and estimated token costs for each mode. Use to plan your token budget.
exclude_dirs: comma-separated directory prefixes to skip
output_format: "text" (default) or "json" for structured response| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| exclude_dirs | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral aspects. It indicates read-only statistics collection but does not explicitly state non-destructive behavior or any prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with the tool's purpose, followed by a usage hint, then parameter details. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description covers input and purpose well. However, 'each mode' is ambiguous and could be clarified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for two of three parameters (exclude_dirs and output_format) beyond the schema. The repo_path parameter is left implicit but is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides counts (file, symbol, edge, line) and estimated token costs. This distinguishes it from some siblings, but not explicitly from similar tools like 'overview'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use to plan your token budget' implies a usage scenario, but there is no explicit when-not-to-use or comparison to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest the most useful next tool based on learned session patterns.
Analyzes historical usage events to predict what tool agents typically call next.
When prev_tool is provided, uses second-order Markov (prev→current→next) which is
significantly more accurate than first-order on repeated workflows.
Example: suggest_next(current_tool='focus', prev_tool='overview') returns
'hotspots (100%)' instead of the less certain 'hotspots (58%)' from first-order.
repo_path: absolute path to repository
current_tool: the tool you just called (e.g. 'focus', 'overview')
prev_tool: the tool called before current_tool (optional; enables second-order prediction)
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | ||
| current_tool | No | ||
| prev_tool | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the analytical process (Markov chains, first-order vs second-order) and example outputs, but since no annotations are provided, it does not disclose whether the tool is read-only or requires specific permissions, though it is implied to be 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear statement, technical details, example, and parameter explanations. It is appropriately sized, though slightly verbose in parts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the algorithm and usage well but lacks explicit description of the output format and prerequisites (e.g., indexed repo). Given the presence of an output schema, the description could still clarify the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for three of four parameters: repo_path as absolute path, current_tool as the tool just called, and prev_tool as optional for second-order prediction. Output_format is not described, but defaults cover it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool suggests the next most useful tool based on learned session patterns and distinguishes it from siblings by explaining second-order Markov accuracy, supported by an example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the prev_tool parameter for better accuracy and gives an example, but does not explicitly state when to avoid this tool or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full symbol index — every function, class, component, hook, type in the repo with signatures, locations, and relationships.
WARNING: Can be very large. Default max_tokens=8000 prevents context window overflow.
For scoped queries, use focus or lookup instead — they're much cheaper.
max_tokens: cap output (default 8000; 0 = use default)
exclude_dirs: comma-separated directory prefixes to skip
output_format: "text" (default) or "json" for structured response| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| max_tokens | No | ||
| exclude_dirs | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that output can be very large and that max_tokens caps output to prevent overflow. It clearly states the tool indexes all symbols in the repo. A score of 4 is appropriate; it could explicitly state read-only behavior, but it's implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise paragraphs: purpose first, then usage warning and alternatives, then parameter details. Front-loaded with key info, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (scans entire repo), presence of output schema (no need to explain returns), and sibling tools, the description is complete. It covers warnings, output format options, and parameter details adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains max_tokens ('cap output, default 8000'), exclude_dirs ('comma-separated directory prefixes to skip'), and output_format ('text or json'). repo_path is self-explanatory with default '/demo'. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Full symbol index — every function, class, component, hook, type in the repo with signatures, locations, and relationships.' This is a specific verb+resource combination and distinguishes from siblings 'focus' and 'lookup' mentioned as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'For scoped queries, use focus or lookup instead — they're much cheaper.' Also warns about large output and default max_tokens, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop watching a repository for file changes.
repo_path: absolute path to the repository root
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description only states the action; lacks disclosure of side effects, failure conditions (e.g., if not watched), or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with purpose, efficiently details the single parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple stop action but lacks guidance on return values (output schema exists) and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema by specifying 'absolute path to the repository root' for repo_path, but could offer more detail on format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Stop watching a repository for file changes,' with a specific verb and resource, and distinguishes from sibling tools like watch_repo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage to stop watching but provides no explicit guidance on prerequisites, when not to use, or alternatives (e.g., watch_repo).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start watching a repository for file changes. Incrementally updates the graph DB when files are added, modified, or deleted. Uses Rust-backed file watcher for performance.
repo_path: absolute path to the repository root
exclude_dirs: comma-separated directories to ignore (e.g. "node_modules,dist")
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | /demo | |
| exclude_dirs | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions Rust-backed performance and incremental DB updates, but lacks details on side effects, permissions, resource usage, long-running nature, or how to stop watching (requires 'unwatch_repo').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences for purpose and two lines for parameters, front-loaded with the main action, concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and parameters, but omits output format, error behavior, and whether the watch runs indefinitely or requires termination. Sibling 'unwatch_repo' suggests start/stop pattern, which is not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description adds value by explaining 'repo_path' and 'exclude_dirs' meanings, compensating for the schema's lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Start watching') and resource ('repository for file changes'), clearly distinguishes from siblings like 'unwatch_repo', and states the effect (incrementally updates graph DB).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for watching a repo for file changes, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it compare with alternatives like 'index_repo' or 'unwatch_repo'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.7.4architecture2 fields changedInput schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path"
-]blast_radius2 fields changedInput schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path"
-]cochange_context3 fields changedInput schema / properties / file_path / defaultAdded value: +""Input schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path",
- "file_path"
-]dead_code2 fields changedInput schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path"
-]dependencies2 fields changedInput schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path"
-]diff_context2 fields changedInput schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path"
-]embed_repo2 fields changedInput schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path"
-]file_map2 fields changedInput schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path"
-]focus3 fields changedInput schema / properties / query / defaultAdded value: +""Input schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path",
- "query"
-]get_patterns2 fields changedInput schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path"
-]hotspots2 fields changedInput schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path"
-]index_repo2 fields changedInput schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path"
-]learn_recommendation2 fields changedInput schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path"
-]lookup3 fields changedInput schema / properties / question / defaultAdded value: +""Input schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path",
- "question"
-]overview2 fields changedInput schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path"
-]prepare_context3 fields changedInput schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / properties / task / defaultAdded value: +""Input schema / requiredRemoved value: -[
- "repo_path",
- "task"
-]report_feedback4 fields changedInput schema / properties / helpful / defaultAdded value: +trueInput schema / properties / mode / defaultAdded value: +""Input schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path",
- "mode",
- "helpful"
-]run_kit3 fields changedInput schema / properties / kit / defaultAdded value: +""Input schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path",
- "kit"
-]search_semantic3 fields changedInput schema / properties / query / defaultAdded value: +""Input schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path",
- "query"
-]stats2 fields changedInput schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path"
-]symbols2 fields changedInput schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path"
-]watch_repo2 fields changedInput schema / properties / repo_path / defaultAdded value: +"/demo"Input schema / requiredRemoved value: -[
- "repo_path"
-]v0.1.0architectureblast_radiuscochange_contextdead_codedependenciesdiff_contextembed_repofile_mapfocusget_patternshotspotsindex_repolearn_recommendationlookupoverviewprepare_contextreport_feedbackrun_kitsearch_semanticstatssuggest_nextsymbolsunwatch_repowatch_repoEach tool has a clearly distinct purpose with detailed descriptions. Even related tools like overview, focus, and prepare_context target different scopes (high-level, task-specific, recommended for coding). Potential overlaps are minimal and well-explained.
Tool names follow a lowercase_underscore pattern but mix verb_noun (index_repo, watch_repo) with noun phrases (architecture, hotspots, dead_code). Inconsistent but still readable and meaningful.
24 tools is on the higher end but appropriate given the breadth of analysis features (orientation, risk, dependencies, search, etc.). Each tool addresses a specific need without feeling redundant.
The tool set covers most aspects of codebase analysis: orientation, search, risk, dependencies, patterns, change impact, and workflow recommendations. Missing only rare edge cases, but core workflows are well-supported.
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Ground-truth code graph for your codebase: exact callers, callees, symbols & dependencies.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Elmoaid/TempoGraph'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
