mcp-codebase-oracle

by iamseyhmus7

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
All 24 tools have clearly distinct purposes. Each targets a specific aspect of code analysis (e.g., scanning, searching, impact analysis, visualization) with no overlapping functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case, such as analyze_impact, detect_architecture, scan_project. The naming is predictable and uniform.
Tool Count5/5
With 24 tools, the server covers a comprehensive range of codebase analysis operations without being overwhelming. The count is well-suited for the server's purpose.
Completeness4/5
The tool set covers core code analysis workflows: scanning, searching, explanation, dependency analysis, impact analysis, and visualization. Minor gaps exist, such as lack of diff or metric reporting tools, but the surface is largely complete.
Average 3.5/5 across 24 of 24 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as whether the tool reads the file, requires a scanned project, or any side effects. The explanation is minimal and assumes the user knows what 'explains' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, only 5 lines, with clear structure (purpose line then parameter list). No unnecessary words. However, the parameter descriptions are cramped into a docstring format, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and an output schema, the description is incomplete. It does not explain what the output contains, any preconditions, or the tool's role among 23 sibling tools. For a file explanation tool, more context about the explanation style or limitations is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides one-line explanations for each parameter: 'path' as project root, 'file_path' as file to analyze, and 'detail_level' with options (brief, detailed, comprehensive). This adds meaning beyond the schema titles, though definitions are basic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'explains a file in human-understandable way', which is clear and specific. However, it does not differentiate from sibling tools like 'explain_function', which could also explain a file's function. The verb 'explains' and resource 'file' are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks context on prerequisites, when not to use it, or which sibling tools are more appropriate for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks behavioral details such as side effects, prerequisites (e.g., requires project scan), or performance implications. It only mentions generation without further context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and structured with an Args section. However, it mixes languages (Turkish and English), which may reduce clarity. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of annotations, the description is incomplete—it doesn't mention prerequisites, output details (though output schema exists), or integration with other tools like scan_project. More context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% but description adds meaning: 'path' is project root directory, 'style' has options listed. However, it doesn't explain differences between style options or any constraints, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it generates project architecture diagram in Mermaid format, which is a specific verb and resource. It distinguishes from siblings like detect_architecture or generate_dependency_matrix by focusing on diagram generation, but could be more explicit about the output format's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like detect_architecture or generate_dependency_matrix. The description only states what it does, not when or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It does not explain that this is a read-only operation (generating a map based on git history), nor does it mention any prerequisites like git availability or project state. The description lacks details on side effects or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. The parameters are listed in a structured format (Args section), making it easy to read. However, the Turkish-only description may be a barrier for some users, but it remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which explains return values), the description does not mention important context such as that it requires git history, that it is a read-only operation, or how the hotspot map is computed. The complexity is moderate, and a more complete description would include these details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description compensates by listing the two parameters with brief explanations: 'Proje kök dizini' for path and 'Gösterilecek hotspot sayısı' for top_n. This adds meaning beyond the raw schema, but the explanations are minimal and do not describe data types or allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a code change heat map based on git blame, using a specific verb and resource. The name 'generate_hotspot_map' aligns well with this purpose, and it distinguishes itself from sibling analysis tools like 'generate_architecture_diagram' by focusing on code changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or when not to use it. The description only explains what the tool does, without any context about its appropriate application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden for behavioral disclosure. It implies a read operation but does not explicitly state idempotency, safety, or side effects. Additional context like rate limits or destructive potential is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured, with a purpose sentence followed by argument and return lists. Every sentence is useful and no extra fluff. However, it could benefit from a brief usage note or context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers basic function and parameters, it misses contextual completeness: no mention of prerequisites, edge cases, or when to prefer this over sibling tools like 'get_call_graph' or 'explain_function'. Given the output schema exists, return details may be redundant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It provides brief explanations: 'project root directory' for path, 'file path (project-relative)' for file, and 'symbol name' for name. This adds basic meaning but lacks format constraints or clarity on symbol naming conventions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns detailed information of a symbol, listing specific fields like signature, callers, callees, and complexity. This distinguishes it from some siblings, but lacks explicit differentiation from tools like 'explain_function' or 'get_call_graph' which may overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, such as the need for the project to be scanned first, nor does it exclude cases where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must bear full burden. It only mentions returning matching files and lines, but omits critical behavior like recursion scope, case sensitivity, ignore patterns, performance characteristics, or any side effects. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. However, the use of Turkish and the informal example format could be streamlined. It effectively conveys the core information without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no enums, output schema exists), the description covers basic functionality but lacks details on return format, error handling, or expected input validation. Sibling tools are not addressed, reducing completeness for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the tool's description compensates by explaining each parameter's purpose and providing examples (e.g., 'ör: "*.py"'). This adds meaningful context beyond the schema's bare names and types, though it could include constraints or defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for text/regex in project files, with parameter examples. However, it does not differentiate from sibling tools like 'find_symbol' or 'explain_file', which could cause confusion. The Turkish language description may also hinder understanding for English-speaking agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context or when-to-use versus alternatives is provided. The description only explains what the tool does, not when to choose it over other search-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral aspects such as whether the tool is read-only, destructive, requires permissions, or any side effects. For a static analysis tool, this is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes structured Args and Returns sections. It is efficient and front-loaded with the core purpose in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and parameters, but lacks context on what constitutes 'dead code', scanning behavior, or how results are structured. Given the output schema exists, the description doesn't need to detail returns, but more context on usage would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description partially compensates by explaining 'path' as project root directory and 'file' as a specific file or None for whole project. However, it lacks details on expected formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects unused (dead) code, using a specific verb and resource. It distinguishes from sibling tools like detect_code_smells or analyze_impact, which address different concerns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. Does not mention prerequisites, limitations, or situations where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Only states it generates a matrix as a table, but does not disclose read-only nature, performance implications, or what exactly the matrix captures. Output schema may help but is not referenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with two short sentences. Front-loaded with the main purpose; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, return structure is covered. However, description lacks context about matrix scope (direct vs transitive dependencies), file format, and whether prior scan is needed. Adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description compensates by explaining 'path' as 'Proje kök dizini' (project root directory), adding semantic meaning beyond the schema's bare title 'Path'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it generates a dependency matrix as a table, which is a clear verb and resource. However, it does not explicitly differentiate from sibling tools like get_dependency_graph or find_circular_dependencies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_dependency_graph or analyze_impact. No context on prerequisites (e.g., whether a project must be scanned first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that the tool returns a report with pattern, confidence score, evidence, layer map, and diagram. However, it does not specify side effects, required permissions, or limitations (e.g., supported project types).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but mixes Turkish and English, which may reduce clarity for some agents. The structure is standard (Args/Returns), but the initial Turkish sentence could be more universally accessible. No wasted words, but could be streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one parameter and an existing output schema, the description adds value by listing return fields. It is mostly complete for a detection tool, though it omits usage context and any dependencies on prior scans.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description's Args section clarifies the 'path' parameter as 'Proje kök dizini' (project root directory), adding meaningful context beyond the bare schema type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects the architectural pattern of a project. The verb 'detects' and resource 'architecture' are specific. It does not explicitly differentiate from siblings like 'generate_architecture_diagram', but the purpose is distinct and clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, limitations, or context of use. It lacks any 'when to use' or 'when not to use' information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states that the tool generates a guide but does not mention side effects, permissions, read/write nature, or output details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: one for purpose and one for the parameter. It is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not explain what the guide contains, its format, or what the tool actually does beyond generation. The agent lacks context to decide when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that the 'path' parameter is the project root directory, adding meaning beyond the schema's title and type. This is valuable given the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an onboarding guide for new developers explaining the project's general working logic. The verb 'generate' and resource 'onboarding guide' are specific, and this tool is distinct from its sibling analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use, or which sibling tools might be substitutes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses the output structure (node list, edge list, Mermaid diagram) and implies a read-only operation. However, it lacks details like performance implications of depth, potential size limits, or any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (~50 words) with a clear structure: purpose sentence followed by labelled Args and Returns. Every sentence adds value, though the Returns section could be slightly more specific.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, with a known output schema) and many sibling tools, the description provides basic functionality but lacks comparative context to help agents choose among related tools like get_call_graph or detect_architecture. Output schema existence is noted but not described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by briefly explaining each parameter: 'path: project root', 'root_file: start file (None = all project)', 'depth: max depth'. This adds meaningful context beyond the schema's types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns a module dependency graph, using a specific verb ('return') and resource ('module dependency graph'). It implicitly differentiates from siblings like 'get_call_graph' and 'get_class_hierarchy' by focusing on module-level dependencies, but does not explicitly distinguish them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., analyze_impact, find_circular_dependencies). There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool is an analyzer (likely read-only) and describes the output (impact report with affected files, risk level, Mermaid diagram). However, it does not explicitly state that no modifications are made, nor does it disclose any side effects, permissions, or rate limits. Without annotations, more behavioral detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear one-line purpose and structured Args/Returns sections. The hyperbolic phrase 'PROJENİN KALBİ' does not add functional value but does not detract significantly. Every element serves a purpose, and it is well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description's mention of report contents is appropriate. All parameters are explained, and the tool's core function is clear. However, it lacks context about dependencies on other tools (e.g., whether the project must be scanned first) or how the output schema complements the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description's Args section provides meaningful explanations for all four parameters, including an enumeration of change_type values. This significantly compensates for the schema's lack of descriptions, though some details (e.g., path format) are absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes the impact of a change, specifying what resources are involved (path, file, symbol). However, it does not distinguish itself from similar sibling tools like what_if_delete and what_if_rename, which could be alternatives for specific change types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any conditions or prerequisites. The description only explains what it does, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially compensates by mentioning that side effects are explained. However, it does not disclose whether the tool is read-only, what the output format is (though output schema exists), or any permission needs. The description adds some behavioral context but not comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence defining the tool's purpose followed by a parameter list. It is front-loaded with the core action. A slightly more structured format (e.g., bullet points) could improve readability, but it is efficient and without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's function and parameter details, and the output schema exists, so return values are covered. It lacks mention of prerequisites like project scanning (given siblings include scan_project), but for a straightforward tool with three required params, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description provides meaningful summaries for all three parameters: 'path' as project root directory, 'file_path' as the file containing the function, and 'function_name' as the function to explain. This adds significant value beyond the schema names, making parameter semantics clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool explains a function's behavior, parameters, and side effects, using specific verb and resource. It differentiates from sibling tools like explain_file (for entire files) and get_symbol_detail (for any symbol) due to its function-specific focus, though it could be more explicit about the context (e.g., within a project).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as explain_file or get_symbol_detail. There are no examples, prerequisites, or when-not-to-use conditions, leaving the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It fails to mention side effects, permissions, performance implications, or the format of the return value beyond a vague 'list and suggestions'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but includes separate sections for Args and Returns. It is front-loaded with the purpose. Slightly more structure would improve readability but it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema, the description provides minimal context. It does not explain what circular dependencies are, how results are structured, or any edge cases. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the single parameter 'path' by explaining it is the project root directory. This compensates for the lack of schema property descriptions (0% coverage).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects circular dependencies, which is a specific verb+resource. It distinguishes from sibling tools like detect_code_smells or find_dead_code by focusing solely on circular dependencies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like detect_architecture or get_dependency_graph. The description does not mention prerequisites, appropriate contexts, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. It does not state whether the tool is read-only, destructive, or requires any permissions. The 'what_if' prefix implies no side effects, but this is not explicitly confirmed, leaving ambiguity about actual impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single line stating the purpose, followed by clearly structured Args and Returns sections. Every sentence is necessary and no words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no schema descriptions, and an output schema (not detailed), the description provides basic context but lacks depth. It mentions the return type ('dosya ve satır listesi') but does not describe the output schema structure or any edge cases. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage). The description compensates by explaining each parameter: 'path: Proje kök dizini' (project root), 'target: Yeniden adlandırılacak sembol adı' (symbol to rename), 'new_name: Yeni isim' (new name). This adds meaningful context beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Bu sembolü yeniden adlandırsam nereleri değiştirmem gerekir?' which means 'If I rename this symbol, where do I need to change?'. It specifies a specific verb ('rename') and resource ('symbol'), and distinguishes itself from sibling tools like 'what_if_delete' by focusing on renaming rather than deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'analyze_impact' or 'what_if_delete'. The description simply states what it does without explaining when it is appropriate or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes output structure but does not explicitly state it is read-only or mention any side effects. Without annotations, disclosure of behavioral traits is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and to the point, with separate sections for Args and Returns. Could be slightly more front-loaded with the main purpose, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, and returned structure. Missing usage prerequisites, error cases, or performance notes, but adequate given the tool's simplicity and presence of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds clear semantics for both parameters: 'path' as project root directory and 'file' as project-relative path, compensating well for the lacking schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states verb 'extract' and resource 'structural overview of a file', listing specific output elements (imports, classes, functions, exports). This clearly distinguishes from sibling tools like 'explain_file' or 'get_call_graph'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'explain_file' or 'get_symbol_detail'. Lacks any when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the search behavior (partial match, kind filter) and the return structure (file, line, signature). However, it does not address performance, scope limitations, or side effects. Since no annotations are provided, the description carries the full burden but could be more thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. The Args/Returns section is efficiently structured, adding necessary detail without superfluous text. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's three parameters and required inputs, the description covers the essential behavior and return format. It is complete for a basic search tool, though it could hint at usage with sibling tools for advanced cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to all three parameters (path, name, kind) beyond the input schema, which lacks descriptions. It clarifies that name supports partial matching and kind offers specific filters, compensating for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool searches for functions, classes, or variables in a project, specifying the action and resource. It also mentions partial matching and kind filtering, which distinguishes it from sibling tools like get_symbol_detail or search_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as search_code or get_symbol_detail. There is no mention of preferred use cases or when to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description is straightforward and transparent about returning a call graph with Mermaid diagram and details. However, it does not disclose any potential side effects, permissions needed, or limitations beyond parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise; uses a clear Args/Returns structure. Every sentence is necessary and front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and an output schema, the description covers the essential behavior. Could be improved by noting any dependencies (e.g., project must be scanned). Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description adds meaning to parameters: explains direction options and the return format. Provides more context than the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a function call graph, with a specific verb and resource. It is distinct from sibling tools like get_dependency_graph or get_class_hierarchy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternatives. No mention of prerequisites, when-not-to-use, or comparison with similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the output format (Mermaid class diagram) but does not mention whether the tool is read-only or has side effects. Since annotations are absent, the description should explicitly state safety traits (e.g., no-modification).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with Args and Returns sections, but is written in Turkish. For an English-based AI, this may reduce clarity slightly. However, it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input parameters and output format (Mermaid diagram). Since an output schema exists, the description need not detail return structure. Missing are usage context and side-effect disclosure, but overall it is adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides clear explanations for both parameters: path (project root) and class_name (specific class or all), including default behavior. This adds significant meaning beyond the schema, which lacks descriptions (schema_description_coverage 0%).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the class inheritance hierarchy using a specific verb ('returns') and resource ('class inheritance hierarchy'). This distinguishes it from sibling tools like get_call_graph or generate_architecture_diagram.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for obtaining class hierarchy but does not explicitly state when to use it over alternatives or provide exclusions. Sibling tools exist but are not mentioned, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Calculates' implies a read-only operation, but no explicit statement about side effects, required permissions, or data access. The description is adequate but lacks behavioral details such as whether it modifies state or requires prior analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with zero wasted words. It uses a clear structure with Args and Returns sections, making it easy to scan. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers purpose, parameters, and return values. However, it omits any note about prerequisites like scanning the project first (suggested by sibling tools). The output schema exists, so explaining return values is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains both parameters: 'path' as project root directory and 'module' as module/file path. This adds meaning beyond the bare schema, though no constraints or formats are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates coupling metrics of a module, specifying afferent, efferent, and instability metrics. It uses a specific verb ('hesaplar' / calculates) and resource ('coupling metrics of a module'), distinguishing it from sibling tools like detect_code_smells or get_dependency_graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Siblings include many analysis tools, but the description does not provide context on prerequisites (e.g., project must be scanned) or conditions where coupling metrics are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses behavioral aspects such as parsing, extracting symbols/relationships, and caching results. However, it does not mention whether this is a read-only operation, required permissions, or other 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear main purpose followed by bullet points for parameters and returns. However, it is somewhat verbose and could be more concise. The front-loading is adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, but an output schema (mentioned), the description provides a reasonable overview of behavior, parameters, and return value. It could be improved by mentioning prerequisites or potential side effects beyond caching.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by explaining that 'path' is the project root directory (absolute or relative), 'exclude_patterns' are extra exclusion patterns in gitignore format, and 'max_depth' is the maximum directory depth with a default of 50. This compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans and indexes a project, finds source files, parses them, and extracts symbols/relationships. It differentiates from siblings like rescan_project (which likely rescans) and get_project_summary (which likely returns a summary without scanning).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool (e.g., scanning a project root directory) but does not explicitly mention when not to use it or point to alternative tools. It lacks guidance on distinguishing from siblings like rescan_project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of disclosure. It explains that the tool returns a 'deletion scenario' including broken imports and calls, and asks whether it is safe. This clearly signals a read-only analysis with no side effects, which is adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-line question as title, followed by a bullet-style list of arguments and return description. Every sentence adds value, and the structure front-loads the core purpose, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple scope (a what-if impact analysis) and the existence of an output schema (not shown but signaled), the description provides sufficient context. It covers the main inputs and output, though it could optionally mention whether the analysis is recursive or project-wide. Overall, it is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema lacks descriptions (coverage 0%), but the description fully explains each parameter: 'path' is the project root, 'target' is the file path or symbol name, and 'target_type' specifies whether the target is a file, function, or class. This adds essential semantic meaning beyond the schema's raw property names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: to simulate the impact of deleting a file, function, or class. The verb 'silersem ne olur?' (what if I delete) and the return explanation 'broken imports, calls, safe?' make the tool's function explicit. It also distinguishes itself from sibling tools like 'what_if_rename' by focusing specifically on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives like 'analyze_impact' or 'find_dead_code'. It only explains the tool's own behavior, leaving the agent to infer usage context from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not mention any behavioral traits such as read-only nature, permissions, side effects, or rate limits. The description only states the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: purpose stated first, then usage instruction, then parameter and return info. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (indicated by context), the description covers the prerequisite, parameter, and return structure adequately. However, lacks behavioral context which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter 'path'. The description adds 'Proje kök dizini' (project root directory), providing meaningful semantics beyond the schema's title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'returns' and resource 'general summary of the scanned project'. It distinguishes from sibling tools like scan_project (prerequisite) and other analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to first use scan_project before this tool, providing a clear usage sequence and prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that scanning is limited to Python files, and if file=None, scans the entire project. Return format is specified (category, severity, file, suggestion). Missing details on side effects (none expected) or resource usage, but sufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus bullet-style Args and Returns. Every part adds value. Front-loaded with purpose. No wasted words. Structure aids quick scanning by AI.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists (not shown), description needn't detail return format, but it does. It covers main aspects: scope, inputs, output structure. Missing technical details like detection method (AST/regex) or dependencies, but overall complete for a moderately complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It does: path is 'project root directory', file is 'specific file (None means entire project, only Python)'. This fully explains both parameters beyond the raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'detects code smells', a specific verb+resource. It distinguishes from siblings like find_dead_code and find_circular_dependencies by being a general smell detector. The scope (only Python, entire project if file=None) further clarifies purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage via Args: path and file parameters are explained. However, no explicit guidance on when to use this tool versus siblings (e.g., find_dead_code for dead code). The description lacks when-not-to-use or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool updates the project incrementally and returns a change report. This gives basic behavioral insight but lacks details on side effects, authorization needs, or idempotency. The description is not misleading but could be more thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a purpose statement, an incremental update explanation, and clearly labeled Args and Returns sections. Every sentence is essential, and the structure is logical. The mixed languages (Turkish and English) are minimal and do not detract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, output schema exists) and the clear description of its incremental behavior and return value, the description is nearly complete. It lacks mention of whether the operation is synchronous or requires specific permissions, but overall it provides sufficient context for an agent to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides the parameter name 'path' with type string and no description. The description adds a clear explanation: 'path: Proje kök dizini' (project root directory), which completely defines the parameter's meaning. With 0% schema description coverage, this is excellent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a previously scanned project incrementally, only re-parsing changed files. The verb 'rescan' and the explicit 'incremental' nature distinguish it from an initial full scan, which is implied by the sibling tool 'scan_project'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that the tool is for updating a previously scanned project, providing clear context for when to use it. However, it does not explicitly state when not to use it or mention alternatives like 'scan_project' for initial scans, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-codebase-oracle MCP server](https://glama.ai/mcp/servers/iamseyhmus7/mcp-codebase-oracle/badges/card.svg)](https://glama.ai/mcp/servers/iamseyhmus7/mcp-codebase-oracle)

Score Badge

Copy to your README.md:

[![mcp-codebase-oracle MCP server](https://glama.ai/mcp/servers/iamseyhmus7/mcp-codebase-oracle/badges/score.svg)](https://glama.ai/mcp/servers/iamseyhmus7/mcp-codebase-oracle)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/iamseyhmus7/mcp-codebase-oracle'

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