Magector

by krejcif

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v2.16.16
Disambiguation5/5
Each tool has a clearly distinct purpose, with descriptions that cross-reference related tools, minimizing ambiguity. Even overlapping functions like semantic search vs. grep are well-delineated.
Naming Consistency4/5
All tools follow the 'magento_<verb>_<noun>' pattern with snake_case, though a few (e.g., magento_module_structure, magento_complexity) deviate slightly. Overall, naming is predictable and consistent.
Tool Count3/5
47 tools is on the high end, covering a broad domain. While each tool is justified, the large number may overwhelm agents, requiring careful selection.
Completeness5/5
The tool set covers virtually every aspect of Magento codebase analysis: search, discovery, tracing, debugging, performance, and batch operations. No significant gaps are apparent.
Average 4.1/5 across 47 of 47 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on April 8, 2026
- 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It describes the analytical steps (trace, find, list, resolve) and implies a read-only analysis, but it does not explicitly state it is non-destructive, list permissions needed, or describe any side effects. It lacks explicit behavioral traits like 'does not modify state'.
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: two sentences with no fluff. The first sentence is action-oriented and front-loaded with the primary action 'Trace complete event flow chain'. Every phrase earns its place.
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 explains the tool's purpose and steps adequately. However, since no output schema is provided, it would benefit from specifying the output format (e.g., list, JSON, file paths). The phrase 'Shows the full dispatch → observer → handler chain' is somewhat vague. Slightly more detail on output 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?
The input schema already provides a description and examples for the single required parameter (eventName). The description does not add any new semantics beyond what the schema states, so it meets the baseline of 3 given 100% 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 the tool's purpose: 'Trace complete event flow chain' with specific actions (find, list, resolve). It names the resource (event flow, observers, handlers) and distinguishes from siblings like magento_find_event_dispatchers or magento_find_observer by combining multiple steps into a full chain.
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 any guidance on when to use this tool versus its siblings. No explicit 'when to use' or 'when not to use' instructions, and no alternatives are mentioned. The user must 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 are provided, so the description must fully disclose behavioral traits. It does not mention whether the tool is read-only, has side effects, requires permissions, or any error conditions. The sole description of 'Find' implies reading, but the agent has no assurance about safety 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences with no wasted words. The first sentence delivers the core purpose, and the second efficiently references sibling tools. It is front-loaded and easily scanable.
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?
There is no output schema, and the description does not explain what the tool returns (e.g., file paths, code snippets, or structured data). For a search/find tool, this omission leaves the agent without critical information on how to use the results, making it incomplete.
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 100%, so both parameters are already well-described in the schema. The description adds a list of examples for the 'query' parameter and describes the 'schemaType' enum values, but this only marginally extends the schema information. A baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds GraphQL schema definitions (.graphqls), types, queries, mutations, and resolver PHP classes. It provides a specific verb and resource, and the 'See also' note differentiates it from sibling tools like magento_find_class and magento_find_method.
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 gives explicit guidance by pointing to alternative tools (magento_find_class, magento_find_method) for resolver implementation details. This helps an agent decide when to use this tool for GraphQL definitions versus when to use others for PHP code.
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 must carry behavioral disclosure. It states the tool parses errors and provides file paths/fix suggestions, implying read-only behavior. However, it does not clarify what happens with unrecognized error patterns or any side effects, leaving some ambiguity.
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 three sentences: purpose, list of recognized patterns, and output summary. No superfluous content, but the structure could front-load the most critical info (the purpose) more aggressively.
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 single-parameter input and no output schema, the description adequately explains what the tool does and what it returns (file paths, fix suggestions). It could be more explicit about the output format, but it is sufficiently complete for an agent to understand its 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?
The single 'error' parameter is fully described in the input schema (100% coverage). The tool description adds no additional semantic value beyond restating what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a parser for Magento error messages and stack traces, mapping them to source files and root causes. It lists specific error patterns it handles, distinguishing it from sibling tools that search or find components.
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 use when encountering Magento errors, but does not explicitly state when to prefer this over alternatives like magento_search or magento_grep. No exclusion criteria or prerequisites mentioned.
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, so the description carries the full burden of behavioral disclosure. It only states the purpose and basic role of blocks, but does not mention any behavioral traits like query limitations, rate limits, authentication needs, or side effects. This is inadequate for a tool with no annotation coverage.
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 only three sentences, each adding value. It opens with the primary purpose, then adds context, and finally lists related tools. 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 one parameter and no output schema, the description should cover what the tool returns or how results are presented. It does not explain the output format or any pagination/ordering. The 'see also' helps contextualize but does not substitute for missing return value 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 input schema has 100% description coverage for the single parameter 'query', including examples. The tool description adds no additional semantic value beyond what the schema already provides. Baseline of 3 is appropriate since schema does the work.
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 finds Magento Block classes used in view rendering, with a specific verb ('Find') and resource ('Magento Block classes'). It distinguishes from siblings by explicitly mentioning related tools (magento_find_template, magento_find_config) in the 'see also' clause.
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 provides context about when to use the tool ('Blocks bridge controllers and templates') and references alternatives (magento_find_template, magento_find_config). However, it does not explicitly state when not to use it or provide exclusion criteria, leaving room for more precise guidance.
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 disclose behaviors. It mentions searching in PHP and XML files but omits whether the tool is read-only, any codebase scope limits, or performance considerations. This leaves significant gaps for an AI agent.
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?
Two sentences, no wasted words. The first sentence states the core action, the second provides context and patterns. Highly 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?
The tool is complex (cross-codebase search), but the description does not explain output format (e.g., list of files with line numbers). Given no output schema, this omission reduces completeness. Parameter documentation is good, but behavioral context is lacking.
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 covers both parameters, and the description adds value by clarifying that className narrows results and providing examples for methodName. It also explains the search patterns (->method(), ::method()), which is beyond the 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 finds all call sites of a PHP method, specifying patterns for PHP and XML. This distinctly sets it apart from siblings that find definitions or other artifacts.
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 says to use it to understand where a method is used and trace data flow, but does not provide explicit when-not-to-use guidance or mention alternatives like magento_trace_call_chain. The guidance is implied but not comprehensive.
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, so the description carries full burden for behavioral details. It does not disclose whether the operation is read-only, any access restrictions, rate limits, or side effects. The description lacks behavioral context beyond the basic function.
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 front-loaded, stating the purpose immediately. It includes examples and sibling references efficiently. However, it could be structured with bullet points for improved readability.
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 complexity (2 parameters, no output schema), the description covers key aspects: the types of classes found, example queries, and related tools. It does not explain return format or pagination, but this is acceptable for a search tool with high schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds example values for className and notes namespace as optional, but does not provide additional semantic meaning beyond what the schema already offers (e.g., no details on partial matching behavior or case sensitivity).
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 explicitly states the tool finds PHP classes, interfaces, abstract classes, or traits by name, and lists concrete examples like repositories, models, and controllers. It also distinguishes from siblings by referencing magento_find_plugin, magento_find_preference, and magento_find_method.
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 provides clear sibling references with brief explanations of their purposes, guiding when to use alternatives. However, it does not mention when not to use this tool or cover all sibling alternatives (e.g., magento_find_config, magento_find_block).
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, so the description carries the full burden. It does not disclose behavioral traits such as read-only nature, error handling (e.g., what happens if route not found), or any side effects. For a tool that is likely read-only, this omission is notable.
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 only two sentences and a see-also reference. It is front-loaded with the main purpose and contains no redundant or extraneous information.
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 no output schema, the description should mention what the tool returns (e.g., a list of controller classes or paths). It also lacks behavioral details. However, for a simple lookup tool with well-documented parameters, it is minimally adequate but not fully complete.
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 100%, so the schema already documents both parameters. The description adds context by explaining the mapping to action classes and providing examples, which is helpful but does not significantly surpass the schema's own 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 that the tool finds MVC controllers by route path and maps them to action classes. It distinguishes itself from siblings by mentioning a related tool (magento_find_config) with a specific use case.
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 provides clear context for when to use this tool (finding controllers by frontend/admin route) and references an alternative (magento_find_config) for config routes. However, it lacks explicit when-not or other exclusions.
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?
Without annotations, the description reveals the tool shows copied fields per aspect, implying read-only behavior. However, it does not disclose details like permission requirements, case sensitivity, or output format, leaving some behavioral ambiguity.
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 two sentences, front-loaded with the core action ('Find fieldset.xml definitions') and includes immediate context. Every sentence adds value without redundancy.
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 tool has no output schema and is relatively simple, but the description only states it 'shows which fields are copied' without detailing the return structure. Some users may need more clarity on what the tool produces.
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 input schema covers both parameters with descriptions and examples (aspect, fieldset). The tool description adds no extra meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds fieldset.xml definitions for data copying between Magento entities, with specific examples like order→quote. It distinguishes from sibling tools by targeting a specific Magento component.
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 usage for understanding data conversion flows (reorder, checkout), but does not explicitly state when to use it versus alternatives or when not to use it. Context is clear but lacks comparative guidance.
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, so the description carries the full burden. It describes what it finds but does not disclose behavioral traits like side effects, performance, or output format. As a read-only lookup tool, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two sentences with front-loaded action. No wasted words, efficient and clear.
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?
With a single required parameter and no output schema, the description covers purpose and sibling hint. However, it does not hint at the output format (e.g., list of classes), which would improve completeness for a simple tool.
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 100% with examples. The description adds no additional parameter semantics beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds event observers and locates Observer classes and events.xml declarations. It distinguishes from sibling magento_find_config by mentioning an alternative use case.
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?
Provides a 'See also' reference to magento_find_config for raw XML, offering guidance on when to use an alternative. Does not explicitly state when not to use this tool, but sufficient for a single-purpose tool.
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, so the description must disclose behavioral traits. It only states the basic purpose (find plugins) without describing what the output looks like, whether it returns detailed info, or any side effects. This 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (2 sentences) with no wasted words. It front-loads the purpose and packs in relevant cross-references, though a sentence on output could be added without bloating.
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?
For a find tool with 2 optional parameters and no output schema, the description adequately explains what it does and guides to related tools. It lacks details on return format or limitations, but is generally complete for the use case.
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 100%, so the schema already documents both parameters. The description adds examples but no additional meaning beyond the schema, meeting the baseline for high 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 finds Magento plugins (interceptors) that modify class behavior via before/after/around methods, and locates Plugin classes and di.xml declarations. It effectively distinguishes from sibling tools by referencing related tools.
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 provides explicit links to alternative tools (magento_find_class, magento_find_method, magento_find_config) with usage hints, but does not explicitly state when not to use this tool or describe prerequisites.
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, so the description must cover behavioral traits. It only states the tool finds templates without mentioning side effects, performance, or result format. This is a gap for a read-like 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?
The description is two sentences plus a 'See also' reference, with the main action front-loaded. Every sentence contributes value, 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?
The description provides examples and areas but does not explain return values or response structure. With no output schema, this is a gap. However, given the tool's simplicity and the schema coverage, it is minimally adequate.
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 100%, so baseline is 3. The description does not add meaning beyond the schema; it lists example queries but those are also in the schema's description. No extra semantic clarification.
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 finds PHTML template files in Magento for frontend or admin rendering, with specific examples (product pages, checkout, etc.). It distinguishes from sibling magento_find_block by noting the block class rendering the template.
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 provides a 'See also' reference to magento_find_block, suggesting a related tool, but lacks explicit when-to-use or when-not-to-use instructions. The context is clear enough for an experienced Magento developer but could be more specific.
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, so the description must fully disclose behavioral traits. The description lacks any mention of whether the tool modifies data, requires authentication, or has rate limits. It only describes what information it retrieves, without addressing side effects or prerequisites beyond the export requirement.
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 4 sentences, with the purpose front-loaded in the first sentence. Every sentence adds value: purpose, usage context, input clarifications, and an important note. No redundant 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?
The tool has no output schema, and the description does not explain the structure or format of the output beyond listing what it finds. The IMPORTANT note hints at possible missing data, but for a comprehensive understanding, more detail about the output would be beneficial. It is adequate but not complete.
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 input schema has 100% description coverage, so the baseline is 3. The description adds the context that the tool accepts either an exact path or keyword, but this is already stated in the schema parameter descriptions. No additional semantic meaning is provided beyond the 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 traces a Magento config path end-to-end, specifying exactly what it finds: system.xml definition, PHP classes, and DB values. The verb 'trace' and resource 'config path' are specific, and it differentiates from sibling tools like magento_find_config by emphasizing the end-to-end tracing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: 'when investigating config-driven behavior' with examples. It also includes an IMPORTANT note guiding the agent on what to do if exports are missing. It does not explicitly mention when not to use or alternatives, but the guidance is clear enough.
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 correctly identifies the tool as reading definitions and implementations (non-destructive), but does not elaborate on authorization, rate limits, or output behavior. Acceptable but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a see-also line, entirely front-loaded with the primary purpose. Every sentence serves a purpose with no redundancy or filler.
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?
With no output schema, the description should clarify what the tool returns (e.g., list of endpoints, struct). It only mentions 'find definitions and implementations' but omits any indication of output format or results count, leaving a significant gap for a tool with simple parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have descriptive text. The description adds little beyond examples in the query parameter; the schema already conveys the necessary semantics. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and resource 'REST and SOAP API endpoint definitions in webapi.xml and their service class implementations', distinguishing it from siblings like magento_find_config and magento_find_class via explicit cross-references.
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 provides 'See also' pointers to two specific sibling tools (magento_find_config, magento_find_class), giving context on alternatives. It lacks explicit when-not-to-use statements but the see-also effectively guides appropriate tool choice.
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 explains search methods (Test/ directories, @covers, mocks, class names) but does not disclose whether the tool is read-only, requires authentication, or has rate limits. The behavior is implied to be safe and non-destructive, but not explicitly stated.
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?
Three sentences: purpose, method, benefit. No extraneous words, front-loaded with the primary action. Highly concise and well-structured.
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?
For a simple two-parameter tool, the description covers purpose, search method, and use case. No output schema exists, but return format (test file paths) is implicit. Adequate for typical usage, though could mention result structure.
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?
Input schema coverage is 100%, with each parameter description including examples. The tool description adds no additional parameter semantics beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds PHPUnit test files for a given PHP class or method, specifying verb, resource, and context. It distinguishes from sibling tools (e.g., magento_find_class, magento_find_method) by focusing specifically on test identification.
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 usage during refactoring ('helps identify test coverage') but does not provide explicit guidance on when to use versus alternatives, nor does it mention when not to use. Sibling tools are listed but not referenced for exclusion.
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 must carry the full burden. It lists what the tool returns (component types) but does not disclose behavioral traits like whether it requires a working Magento installation, performance considerations, or any side effects. The description is adequate but not comprehensive.
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 two sentences with front-loaded action verb 'Get'. Every sentence adds value with no wasted words. Information is presented efficiently.
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 lack of output schema, the description lists many component types, providing a good overview. It could be more explicit about the output format (e.g., list vs. hierarchy) but is sufficiently complete for a structural overview tool among many specific siblings.
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 100% with clear examples for the parameter. The tool description adds no additional meaning beyond what the schema already provides, achieving the baseline score of 3.
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 gets the complete structure of a Magento module and enumerates component types (controllers, models, etc.). This specific verb+resource distinguishes it from sibling tools that focus on individual components.
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 usage for obtaining an overall module architecture overview but does not explicitly state when to use this tool versus alternatives like magento_find_controller. No when-not or exclusion criteria are provided.
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, so description must carry full burden. It describes output behavior (risk scoring, change classification) but does not explicitly state it is read-only or non-destructive, nor cover authentication or rate limits. Lack of annotations makes the description partially adequate but not fully transparent.
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?
Two concise sentences with no filler. Every clause adds value, clearly conveying purpose and usage.
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?
No output schema, so description should clarify return format. It mentions outputs (risk scoring, classification, impact) but lacks detail on how results are presented (e.g., JSON, report). Given the tool's complexity, more completeness would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description restates 'staged changes or specific commits' which maps directly to the parameters but adds no extra meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes git diffs for risk scoring, change classification, and per-file impact analysis, and specifies it works on commits or staged changes. This distinguishes it well from sibling tools like magento_search or magento_describe.
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 mentions 'Useful for code review,' providing context but no explicit when-not-to-use or alternatives. It gives a clear usage scenario without differentiating from siblings like magento_impact_analysis.
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, so the description must fully disclose behavioral traits. It only says 'Find XML configuration files and nodes' but does not mention output format, side effects, permissions, or safety. This lack of transparency for an unannotated tool is a significant gap.
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 a single sentence with a short 'See also' line. It is front-loaded with the core purpose and every part serves a function without unnecessary 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?
With no output schema, the description should hint at what the tool returns, but it does not. However, given the low complexity (2 simple params) and the presence of sibling tools for more specific tasks, the description is minimally acceptable but missing return value information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description's examples for the query parameter add some context, but the parameter descriptions in the schema are already detailed. The description does not significantly add new meaning beyond the 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 finds XML configuration files and nodes in Magento, listing specific config types (di.xml, events.xml, etc.). It also distinguishes itself by referencing sibling tools like magento_find_observer for events.xml, showing it is not the only option for those specific tasks.
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?
The description includes 'See also: magento_find_observer, magento_find_preference, magento_find_api' which provides explicit guidance on when to use alternative tools for specific config types. This helps an agent choose the correct tool.
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 disclose any behavioral traits (e.g., permissions, side effects, or destructive potential). It only describes what the tool finds.
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?
Two concise sentences with no redundancy; the description is front-loaded with the main action and immediately provides a useful cross-reference.
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 explains the input and general purpose but does not specify output format or behavior (e.g., how results are structured or whether there are pagination/limitations). With no output schema, this is a gap.
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 examples for the jobName parameter (e.g., 'catalog_product', 'indexer'), which helps clarify expected input beyond the schema's brief description.
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 it finds scheduled cron jobs defined in crontab.xml and their handler classes, distinguishing from magento_find_config.
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?
Provides a 'See also' reference to an alternative tool for raw XML, giving context for when to use which tool.
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 full burden. It discloses that it searches method names, function definitions, and class method lists, but does not mention behavior on empty results, performance, or output format. Adequate but not comprehensive.
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?
Three brief sentences, each serving a purpose: what it does, what it searches, and cross-references. Front-loaded and 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?
The description covers the core function but omits return value details and error scenarios. Given no output schema and no annotations, the description is somewhat lacking but still functional for a search tool with clear semantics.
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 100%, so baseline is 3. The tool description does not add additional parameter semantics beyond what the schema already provides (e.g., examples and descriptions are in schema). No extra value added.
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 explicitly states 'Find implementations of a PHP method or function', clearly specifying the verb 'find' and the resource 'implementations'. It distinguishes from siblings by referencing related tools like magento_find_class and magento_find_plugin.
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 provides 'See also' references to sibling tools for related use cases, but does not explicitly state when to avoid using this tool or describe prerequisites. The context is clear enough for an agent to decide appropriately.
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 carries full burden. It discloses the types of code searched and the output format (dependency map). It does not mention whether the tool is read-only or any destructive side effects, but the description implies a read-only analysis. The lack of explicit read-only statement prevents a score of 5.
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, using two sentences plus parameter description. It front-loads the purpose and lists specific code types efficiently. It could be slightly tighter, but there is no excessive verbosity.
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 complexity (scanning multiple Magento code artifacts), the description covers the input (table name) and output (dependency map) well. No output schema exists, but the description hints at the return format. Without annotations, this is reasonably complete, though it could mention prerequisites like having a Magento codebase indexed.
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 input schema provides a description for the single parameter tableName, achieving 100% schema coverage. The tool description adds example values (e.g., 'salesrule_ordered'), which are helpful but not essential. Since schema already covers the parameter meaning, the description adds marginal value, warranting a baseline score of 3.
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: 'Find all code that references a database table' and specifies the exact types of code scanned (db_schema.xml, Setup scripts, raw SQL, etc.). It also explains the outcome: 'Builds a cross-module dependency map showing who reads/writes/creates a given table.' This distinguishes it from sibling tools like magento_find_db_schema, which focuses on schema definitions.
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 says 'Essential for impact analysis of schema changes,' which implies usage context but does not explicitly say when to use this tool versus alternatives such as magento_find_db_schema or magento_trace_dependency. No exclusion criteria or when-not-to-use guidance is provided.
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, so description must cover behavioral traits. It describes what the tool traces but does not disclose rate limits, side effects, or read-only nature. Adequate but not comprehensive.
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?
Two sentences, front-loaded with actionable information. No redundancy, every word serves purpose.
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?
No output schema, but description does not explain return format (e.g., list of steps, code). For a tracing tool, more detail on output would be beneficial. Adequate given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description and examples for 'carrier'. Description does not add meaning beyond schema, scoring baseline 3.
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 starts with specific verb 'Trace' and enumerates the chain components (carrier classes, plugins, modifier pool, collectors, fieldset mappings), clearly differentiating from sibling tracing tools.
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?
Explicitly states use cases: 'understand how shipping prices are calculated, modified, and propagated during checkout, reorder, or order edit.' Does not mention when not to use or compare to siblings, 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.
Behavior4/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 explains the tool's behavior (detecting setX(null) calls) and the underlying anti-pattern. It does not contradict any annotations since none exist, and it adds useful context about the data array behavior.
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 slightly verbose but well-structured, front-loading the core purpose. Every sentence adds value, though some technical detail could be condensed. It remains efficient for agent comprehension.
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 complexity (2 parameters, no output schema), the description explains the anti-pattern and usage but does not describe the output format (e.g., list of matches, code snippets). This leaves a minor gap in what the agent can expect as a result.
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 100%, so the schema already documents both parameters (path and maxResults) adequately. The description does not add significant meaning beyond what is in the schema, which is acceptable given baseline 3.
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 detects DataObject::setX(null) anti-pattern calls in Magento, explaining the problem and why it matters. It distinguishes itself from sibling tools by focusing on this specific anti-pattern.
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 provides clear usage context: during field-lifecycle audits or debugging 'value persists but shouldn't' bugs. It also mentions an alternative sibling tool (magento_batch) for multi-query workflows, though it doesn't explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It explains the scope (two sources) but does not disclose behavioral traits such as read-only nature, permission requirements, or return format. It adds some value but lacks depth.
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 two sentences that front-load the essential purpose and scope, with no extraneous information. Every sentence is useful, and it is appropriately concise.
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 low parameter count and no output schema, the description covers the key aspects: what is found and from which sources. It could hint at output format, but the level of detail is adequate for a simple lookup tool.
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 input schema has 100% coverage with a clear description and examples for the single parameter. The description does not add additional semantic meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds database table definitions, columns, indexes, and constraints from both modern declarative schema and legacy setup scripts, with a specific verb and resource. It distinguishes from siblings by mentioning magento_find_trigger and magento_find_table_usage.
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 provides clear context (covers both declarative and legacy schema) and mentions related tools in a 'See also' section. However, it does not explicitly state when not to use this tool or list prerequisites.
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 describes what the tool does (parses layout XML files) but does not disclose potential behavioral traits like read-only nature, performance impact, or side effects. It adequately implies a read/search operation but lacks explicit safety or scope details.
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 at two sentences, with no redundant information. The key action and purpose are front-loaded, making it efficient for an AI 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 tool's complexity (simple search, no output schema, no annotations), the description provides sufficient context: it covers what files are parsed and the purpose. It could briefly mention the output format or confirm it's read-only, but overall it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add extra meaning beyond what the schema provides. The schema already includes examples for both parameters ('query' and 'handle'). The description simply restates the purpose without parameter-specific elaboration.
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 'find' and the specific resources: layout XML files, handles, blocks, containers, and reference declarations. It distinguishes from sibling tools that focus on other Magento components like classes, methods, or config.
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 provides a clear usage context: 'Use to understand page structure and block assignments.' However, it does not explicitly state when not to use this tool or compare it to alternatives among the many sibling tools, which would improve guidance.
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 must bear full responsibility. It states the tool indexes/re-indexes and lists file types, but lacks disclosure of potential performance impact, resource consumption, or failure modes. For a potentially heavy operation, more transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every sentence adds value. There is no fluff, making it highly concise and structured well for an AI agent.
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?
For a tool with one optional parameter and no output schema, the description covers the key aspects: purpose, when to use, and scope (file types). It could mention whether the operation is incremental or full, and what feedback to expect, but it is largely complete given the complexity.
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 input schema already fully describes the single optional parameter 'path' with a clear description. The tool description does not add any additional semantic meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool indexes or re-indexes the Magento codebase for semantic search, specifies when to run it (after code changes), and lists the file types it indexes. This differentiates it from the many sibling search/find tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to run this tool after code changes to update the search index, providing clear usage context. However, it does not mention when not to use it or explicitly contrast with alternatives, though the context of sibling tools implies it is a prerequisite for searches.
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 must disclose behavior. It states it parses di.xml files across modules and lists what it finds, but does not discuss potential performance impacts, read-only nature, or output size. This is adequate but not highly transparent.
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: three sentences front-loading the purpose, technical details, and a practical use case. Every sentence adds value with no fluff.
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 no output schema, the description omits any mention of return format or structure. For a tool that traces dependencies, knowing what the output looks like (e.g., a dependency graph or list) would help an agent interpret results. This is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions, but the description adds valuable examples for className and explains the direction enum options. This enhances understanding beyond schema alone, earning a score above the baseline of 3.
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: tracing dependency injection graphs for PHP classes/interfaces in Magento. It specifies actions (parsing di.xml, finding preferences, plugins, etc.) and a concrete use case ('Cannot instantiate interface' errors), distinguishing it from sibling find tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends use for understanding runtime class resolution, especially for specific errors. While it does not list alternatives or exclusions, the context of sibling tools implies uniqueness, and the guidance is clear enough for an AI agent to decide when to invoke this tool.
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 are provided, so the description carries the full burden. It discloses that the tool analyzes complexity and rates files, implying a read-only operation. No contradictions exist, and for an analysis tool, the behavioral description is adequately transparent.
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 two sentences, containing no extraneous information. Every word adds value, clearly stating the tool's purpose, metrics, and use case.
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 moderate complexity, the description covers the key aspects: what it analyzes (complexity metrics), what it produces (hotspots and ratings), and when to use it. The lack of an output schema is partially mitigated by the description of outputs, though a mention of return format 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?
The input schema has 100% coverage with descriptions for all three parameters (path, module, threshold). The description does not add new parameter-specific details beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes code complexity with specific metrics (cyclomatic complexity, function count, line count) for PHP files. It identifies hotspots and rates files, which distinguishes it from sibling tools that focus on searching, finding, or tracing Magento elements.
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 includes a use case ('Use for refactoring prioritization'), providing clear context. However, it does not explicitly state when not to use it or suggest alternatives, though siblings are diverse and no other tool appears to perform complexity analysis.
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 that the tool extracts DI configuration and constructor signatures, but does not mention potential behaviors such as error handling for missing classes, performance implications, or any destructive actions. The description is adequate but not fully transparent.
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 consists of two efficient sentences. The first sentence lists all retrieved information in a structured bullet-like manner, and the second sentence summarizes the use case. There is no redundant or unnecessary content.
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?
With a single parameter and no output schema, the description covers the tool's functionality well by listing all return elements. However, it does not describe the structure or format of the output, which could leave the agent uncertain about what to expect. Still, it is generally complete for a tool of this complexity.
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 coverage is 100%, giving a baseline of 3. The description adds value by providing concrete examples of valid class name formats (e.g., full or short names) and clarifying that it accepts interfaces. This extra context improves usability beyond the schema alone.
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 retrieves the complete DI wiring for a PHP class, listing specific components like preferences, plugins, constructor arguments, virtual types, and argument overrides. This distinct purpose is explicitly differentiated from sibling tools such as magento_find_plugin and magento_find_preference.
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 includes the explicit guidance 'Use this to understand how a class is configured and extended across all modules,' which clearly indicates when to use the tool. It does not explicitly mention when not to use it or name alternatives, but the context among sibling tools makes the usage scope clear.
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 are provided, so the description carries full burden. It discloses that scanning covers PHP files for 'implements' and di.xml for '<preference>' declarations, which is good behavioral context. Missing details on performance or error handling are acceptable for a search tool.
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 two sentences with zero waste. It defines the tool's action first, then provides usage guidance, making it easy to scan and understand 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?
For a single-parameter search tool with no output schema, the description adequately covers what is searched (PHP files and di.xml) and the method ('implements' keyword and '<preference>' declarations). It could mention return format or limitations but is fairly complete.
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?
With 100% schema description coverage, the schema already provides excellent parameter documentation (full or short names with examples). The description repeats no additional parameter details, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds all classes implementing a given PHP interface, scanning PHP files and di.xml. It distinguishes from siblings like magento_find_preference and others by specifying the search scope and method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to discover all concrete implementations of an interface across the codebase,' providing clear context. However, it does not explicitly state when not to use or mention alternatives.
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, so description carries full burden. It states it finds preference overrides from di.xml, implying a read-only search. But does not disclose any permissions requirements or potential side effects. Adequate but not fully transparent.
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?
Two sentences, no wasted words. Front-loaded with core function, then pointers to related tools.
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 single parameter, no output schema, and no annotations, description adequately covers purpose and context. However, lacks detail on output format or edge 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?
Schema description coverage is 100% with examples. Description adds context that the parameter is used to find preference/implementation, supplementing the 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?
Clear verb+resource: 'Find DI preference overrides'. Specifies purpose: which concrete class implements an interface or replaces another class via di.xml. Distinguishes from sibling tools by mentioning magento_find_class and magento_find_config.
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?
Explicitly references sibling tools (magento_find_class, magento_find_config) with context on when to use them. However, does not explicitly state when to use this tool vs alternatives.
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 must disclose behavioral traits. It explains that the tool scans for components and returns sorted files, but does not explicitly state whether it is read-only, if it modifies data, or any authentication needs. This leaves some ambiguity.
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 appropriately sized with two sentences. The first sentence front-loads the core action, and the second provides additional detail. Every sentence serves a purpose without redundant information.
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 tool has no output schema, so the description should explain return values. It states returns files sorted by complexity score, but lacks details on the exact format or how to interpret results. Given the low parameter count and clear purpose, it is mostly complete but has minor 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 coverage is 100%, with both parameters described. The description adds value beyond the schema by providing an example for the threshold parameter ('Set higher (e.g., 5) to focus on complex files only'), which helps agents use it effectively.
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 profiles a Magento subsystem for performance bottlenecks, specifying scanning for plugins, observers, and collectors. It distinguishes itself from sibling tools like magento_find_plugin by focusing on performance hotspot identification rather than individual element lookup.
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 clearly indicates when to use the tool (to identify performance bottlenecks) but does not explicitly mention when not to use it or suggest alternatives. The context is clear, but lacking exclusions prevents a higher score.
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, so description carries full burden. Mentions token-efficiency of method extraction but does not disclose read-only nature, auth needs, or output format. Adequate but not comprehensive.
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?
Two concise sentences that front-load purpose and provide actionable usage guidance without redundancy.
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 main functionality, batching, line ranges, and method extraction. Lacks output format details and error handling, but sufficient for a simple read tool given parameter richness.
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 covers all parameters with descriptions. Description adds value with example, batching context, and token-efficiency hint, enhancing understanding beyond 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?
Clearly states the tool reads a file from the Magento codebase. Distinguishes from siblings by mentioning integration with magento_batch for batch reading.
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?
Provides explicit guidance on using magento_batch for multiple files and mentions line ranges and method extraction. Could be improved by clarifying when not to use vs specific sibling tools.
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 explains the tool's output (set/get files, XML references) and implies read-only analysis, but does not explicitly disclose safety, side effects, or rate limits. The description adds moderate context beyond the schema.
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 two sentences long, front-loaded with the core purpose, and includes an example. No redundant or missing information; 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 has 2 parameters and no output schema, the description adequately explains what the tool does and what output to expect (PHP files, set/get, XML configs). It's fairly complete but could specify search scope (e.g., recursive or limited to certain directories).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds meaningful context by showing how to use the parameters in a real scenario ('who sets custom_discounted_price_incl_tax on Quote\Address'). This goes beyond just describing the 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's purpose: 'Trace how a data attribute flows through the Magento codebase' with specific verbs ('trace', 'find') and resources ('PHP files', 'XML configs'). It distinguishes from siblings by focusing on data attribute flow, with a concrete example (custom_discounted_price_incl_tax on Quote\Address).
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 provides a clear use case ('Use this to understand data dependencies...') and an example. However, it does not explicitly state when not to use this tool or compare it to sibling trace tools like magento_trace_flow or magento_trace_call_chain, leaving some ambiguity.
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 the description carries full burden. It discloses chaining multiple searches to map controller to plugins to observers to templates, and mentions depth and entryType controls. Good disclosure of behavior, though no mention of side effects 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. First sentence immediately states purpose and examples. Second sentence explains what it does (chains searches) and use case. Front-loaded and 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?
Given the tool's complexity and lack of output schema, the description adequately explains what it traces and how. It covers entry types and depth. Could mention return format (a trace map) but not critical. Good overall.
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 100% with clear parameter descriptions. The description adds marginal value beyond schema (e.g., 'faster' vs 'more complete' for depth), but this is baseline 3 as schema already documents parameters well.
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 uses a specific verb 'trace' and resource 'Magento execution flow', listing multiple entry point types (route, API, GraphQL, event, cron). This clearly distinguishes it from sibling tools like magento_search or magento_find_class.
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?
It explicitly states 'Use this to understand how a request is processed end-to-end.' While it doesn't list when-not-to-use or alternatives, the sibling context implies specialized tools exist for sub-steps, making usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It discloses API usage, required env var, caching, and automatic attachment to search results—all critical for agent decision-making. No contradictions.
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?
Two concise sentences: first states core purpose, second adds critical requirements and side effects. No wasted words; front-loaded with essential information.
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 simplicity (1 param, no output schema), the description covers purpose, requirements, caching, and integration with search results. It could mention return format, but the absence is acceptable for this tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (1 parameter fully described in schema). The tool description does not add extra meaning beyond the schema; it simply restates the purpose. Baseline 3 applies per rubric.
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 natural language descriptions for di.xml files using Claude Sonnet via the Anthropic API. This specific verb+resource combination distinguishes it from sibling tools like magento_search or magento_find_class, which have different purposes.
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 mentions the prerequisite ANTHROPIC_API_KEY and explains caching behavior, but does not explicitly contrast with alternatives or provide when-to-use/when-not-to-use guidance. The context is clear enough for selection.
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 are provided, so the description must fully disclose behavior. It states the method (grep matching, method context, surrounding code) and implies read-only operation. However, it does not mention any side effects or auth requirements, but the behavior is straightforward.
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 (two sentences), front-loaded with the main action, and contains no unnecessary words, efficiently conveying purpose and use.
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 parameter (1 required, fully described) and no output schema, the description is nearly complete. It covers purpose, use cases, and technique, though it could explicitly mention the output format (e.g., file paths with code snippets).
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 input schema already provides a description with examples for eventName (100% coverage). The description adds context about the tool's purpose and technique but does not significantly enhance the parameter's meaning beyond the 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 finds PHP locations where a Magento event is dispatched via eventManager->dispatch(), and distinguishes itself from the sibling magento_find_event_flow by focusing on the trigger location rather than the full chain.
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?
Explicit use cases are provided: 'does class X dispatch event Y?' and 'who triggers this event?', along with a direct comparison to magento_find_event_flow, guiding the agent on when to use this tool over alternatives.
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, the description fully carries behavioral disclosure. It lists the output fields (vectors, dimensions, path), implying a read-only operation. No side effects or destructive actions are indicated.
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?
Two sentences: first states purpose, second adds usage guidance. No unnecessary words; every sentence is valuable.
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 output and usage adequately for a simple parameterless tool. Could mention prerequisites (e.g., index must exist) but sufficient overall.
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?
There are zero parameters, so no parameter documentation is needed. Schema coverage is 100% trivially. Baseline 4 applies.
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 it retrieves index statistics (total indexed vectors, embedding dimensions, database path). This distinguishes it from siblings like magento_search (searching) or magento_index (managing index).
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?
It explicitly says 'Use this to verify the index is loaded and check its size,' providing clear context for when to use. However, it does not mention alternatives or when not to use.
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, the description carries the full burden. It discloses the key behavioral steps (parsing webapi.xml, resolving DI, reading method, checking di.xml) and states it returns the complete chain in one call. It does not mention any destructive actions, which is appropriate for a trace tool.
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 a single paragraph of three sentences, front-loading the purpose and listing steps without redundancy. Every sentence adds essential information, making it efficient and easy to parse.
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 explains the core behavior and output ('complete chain in one call') without an output schema. It covers the tool's functionality for three optional parameters. Minor gaps: no mention of error handling or response format, but adequate for a trace tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are documented. The description adds value by explaining the purpose of the 'url' parameter with examples, clarifying the 'method' enum as HTTP methods, and noting 'interfaceName' as an alternative. However, it could better clarify GraphQL usage.
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 traces a REST or GraphQL API endpoint from URL to implementation, detailing the specific steps (parse webapi.xml, resolve DI preference, etc.). It distinguishes itself from sibling tools like magento_find_api by focusing on the full implementation chain.
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 implies usage for tracing API endpoints to their implementation, but it does not explicitly state when to use this tool over alternatives (e.g., magento_trace_flow). The context of sibling tools hints at its distinct purpose, but explicit guidance is missing.
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, the description carries the full burden. It discloses what types of calls are traced and that a call tree is returned. It does not mention limitations (e.g., dynamic calls) but is reasonably transparent for a static 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each adding value: first states purpose and scope, second details what is traced and return type. No wasted words, 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 the tool's purpose, inputs, and behavior. It lacks details on the output format (call tree structure), but for a simple tracing tool with 3 parameters, it is fairly 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?
All three parameters are well-described in the schema with examples for className and methodName, and maxDepth has default and description. The description adds no additional param info, but schema coverage is 100%. Examples add value, so above baseline.
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 it traces the internal method call chain from a specific class::method, detailing types of calls followed (same class, DI, events). This distinguishes it from siblings like magento_find_callers or magento_trace_flow.
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 provides clear context for when to use the tool (tracing execution path from a method), but does not explicitly exclude alternatives or mention when not to use it. It implicitly differentiates from sibling tools through specificity.
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 are provided, so the description carries the full burden. It states that queries run in parallel and return combined results, and lists supported tools. It does not detail error handling or rate limits, but the parallelism and batching behavior are clearly disclosed.
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 two concise sentences, front-loaded with the core purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch tool with many sub-tools), the description covers usage context, behavior, and supported operations. Schema covers the parameter, and no output schema is needed for this batching tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the effect of the parameter (parallel execution) and listing the compatible tools, which goes beyond the schema's structural description.
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: execute multiple Magector tool calls in a single request to reduce round-trip overhead, with parallel execution and combined results. It lists the supported tools, distinguishing it from siblings that operate individually.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when you need 2+ independent lookups' and provides examples, giving clear context for when to use. It does not explicitly state when not to use, 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.
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 the tool detects triggers created via specific methods and returns relevant details. It suggests a read-only nature (detecting/finding) with no side effects mentioned. Could be more explicit about safety, but sufficient.
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 (3-4 sentences) and front-loaded with the main purpose. Every sentence adds information without redundancy. Structure is clear and scannable.
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?
For a find tool with no output schema, the description adequately explains what it does, how it works, and what it returns. It could mention examples or error handling, but overall it is complete enough for an AI agent to decide whether to use it.
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 100% with descriptions for both optional parameters. The description adds value by explaining the purpose of each parameter and what the tool returns, complementing the schema effectively.
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 it finds MySQL database trigger definitions in Magento Setup scripts, specifically those created via TriggerFactory methods. It lists the returned fields (name, table, event, timing, SQL) and distinguishes itself from sibling tools by focusing on triggers.
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?
Provides explicit usage context: 'Use when investigating DB-level automation, trigger chains, or performance issues caused by cascading triggers.' Does not explicitly mention when not to use or alternatives, but the context is clear.
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, the description carries full burden. It explains the grep-like behavior, return format (file:line:content), and notes it finds EVERY occurrence. No contradictions; adds sufficient 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?
Four sentences, front-loaded with purpose, no wasted words. Efficiently conveys core function, use cases, and output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description includes return format and comprehensive use cases. For a grep tool with well-documented parameters, this is fully 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?
Schema coverage is 100%, so baseline is 3. The description adds value by providing usage tips (e.g., use 0 context for broad scans, then batch-read) and clarifies default behaviors. Slightly above baseline.
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?
Clearly states exact text search (grep) across Magento files, contrasts with semantic search (magento_search), and provides specific use cases (finding call sites, usages, config references). Distinguishes from siblings effectively.
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?
Explicitly lists use cases and contrasts with magento_search. Does not mention when not to use or direct alternatives for other siblings, but the context is clear enough for an agent to decide.
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 carries the full burden. It discloses that the tool combines DI XML tracing with PHP source analysis and maps cross-module dependencies. This gives insight into the operational behavior, though it does not mention auth needs 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first sentence immediately conveys the core action and scope, and the second adds methodological detail. No unnecessary words.
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 one parameter, full schema coverage, and no output schema, the description provides sufficient context. It explains what the tool does and how, but does not describe the output format, which would be helpful for completeness.
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 schema has 100% coverage for the single 'className' parameter. The description adds value by specifying that the parameter can be a full or partial name and provides concrete examples, enhancing the schema's plain string type description.
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 analyzes the impact of changing a PHP class by finding all files that reference it via use statements, DI configuration, instantiation, and type hints. It specifies the resource (PHP class) and action (analyze impact), distinguishing it from sibling tools like magento_find_class or magento_trace_dependency.
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 implies usage: when you need to understand the impact of changing a class. It does not explicitly exclude scenarios or mention alternatives, but the context is clear enough for an agent to infer appropriate use.
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 explains the tool returns unsafe method chains, requires prior enrichment, and runs a fast SQLite query. Could explicitly state read-only nature, but behavioral traits are well covered.
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?
Every sentence adds value: purpose, dependency, performance, filtering guidance, alternative tool for batch. No wasted words; front-loaded with core functionality.
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, dependency, and performance. Lacks explicit return format description, but for a list-returning tool without output schema, the description is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for limit and firstMethod. Description adds concrete examples (e.g., 'getPayment' filters to ->getPayment()->$X() without null guard) and usage context, enhancing understanding beyond 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 finds method chains without null guards using a pre-built enrichment index. It specifies the exact pattern detected and gives concrete examples, distinguishing it from sibling tools like magento_grep or magento_find_class.
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 states dependency on prior enrichment (magento_enrich or magento_index), provides filtering guidance via firstMethod parameter, notes performance advantage, and suggests magento_batch for multi-query workflows.
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 carries the full burden. It discloses limitations: 'Works best for Magento core... semantic search may return 0 results' for custom modules. It also explains behavioral effects of parameters like 'precise' and 'expand'. However, it does not explicitly state that the tool is read-only or mention any side effects. Still, the provided limitations and parameter behavior give solid 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?
Description is front-loaded with the main purpose and usage context. Every sentence serves a purpose: first defines tool, second gives usage guidelines, third mentions limitations, fourth lists alternatives. No redundant or filler text. It is appropriately sized for the tool's complexity.
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 large set of sibling tools, the description adequately positions this tool as a general-purpose fallback and explains its limitations regarding custom modules. However, it does not describe the return format or ranking behavior, which could help an agent interpret results. Since no output schema is provided, a brief note on what results look like would improve 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?
Schema description coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema: for 'precise' it clarifies 'disables query expansion AND applies strict post-filtering'; for 'expand' it mentions 'Magento domain synonyms'; and for query it provides concrete examples. This adds value for an agent to construct proper requests.
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 starts with a clear verb+resource: 'Search Magento codebase semantically... find any PHP class, method, XML config...' It specifies the resource (Magento codebase) and the action (semantic search). Additionally, it distinguishes itself from sibling tools by stating 'Use this as a general-purpose search when no specialized tool fits' and listing alternatives like magento_find_class.
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 states when to use: 'general-purpose search when no specialized tool fits' and when not to use: 'for small/custom project-specific modules... use magento_grep instead.' It also references sibling tools with 'See also: magento_find_class, magento_find_method, magento_find_config for targeted searches.' This provides clear 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.
Behavior4/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 that the tool uses Rust tree-sitter for fast, accurate parsing and that it ignores comments/strings. This is good, but it doesn't explicitly state whether the tool is read-only or if it modifies state (likely read-only). A score of 4 reflects strong transparency with a minor gap in safety disclosure.
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 well-structured. It begins with a clear statement of functionality, then distinguishes from a sibling, lists available patterns with examples, and ends with a performance note and a usage tip. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's medium complexity and the absence of an output schema, the description is complete. It covers purpose, usage guidelines, behavioral traits (speed, AST awareness), and parameter details. No additional context is needed for effective agent use.
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 100%, so baseline is 3. The description adds significant value by explaining each named pattern in detail, describing the default for 'path' and the default/max for 'maxResults'. This goes beyond the schema's minimal descriptions, making parameter semantics very clear.
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 performs structural PHP code search using tree-sitter AST queries. It distinguishes itself from the sibling 'magento_grep' by explicitly noting that it understands PHP AST, matches code structure regardless of variable names, and ignores comments and strings, which provides a specific and differentiated purpose.
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?
The description provides explicit guidance on when to use this tool: for AST-based structural search, contrasted with text-based 'magento_grep'. It also mentions available named patterns with examples, and advises using 'magento_batch' for multi-query workflows, giving clear context on 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it scans PHP files, analyzes method chains, and stores results in .magector/data.db. No hidden side effects are omitted.
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 compact yet complete, with every sentence providing essential information about function, usage, and relation to other tools. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0 parameters, and no output schema, the description fully covers the tool's purpose, input, output, and placement in the workflow. It is self-contained.
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 tool has 0 parameters, so baseline is 4. The description adds no param info, which is appropriate. It mentions the output file location, adding context beyond the 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 verb 'Build' and resource 'the method-chain enrichment index', and distinguishes it from siblings like magento_find_null_risks and magento_index by explaining the dependency and purpose.
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 states when to run (once after magento_index), and offers an alternative (use magento_find_null_risks for null-safety queries instead of grep). Also mentions it runs automatically after magento_index.
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:

[![magector MCP server](https://glama.ai/mcp/servers/krejcif/magector/badges/card.svg)](https://glama.ai/mcp/servers/krejcif/magector)

Score Badge

Copy to your README.md:

[![magector MCP server](https://glama.ai/mcp/servers/krejcif/magector/badges/score.svg)](https://glama.ai/mcp/servers/krejcif/magector)

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/krejcif/magector'

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