Skip to main content
Glama

find_magic_collision

Read-onlyIdempotent

Scans a MetaTrader project directory recursively to detect duplicate or conflicting magic-number variables, preventing order-identification issues in automated trading.

Instructions

DEPRECATED (removed in 0.6.0): use inspect_source(root=..., aspects=["magic"]).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rootYesAbsolute path to the project folder to scan recursively.
var_patternNoSubstring identifying magic-number variables.Magic

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.5.0
    • addedInput schema / properties / root / description
      Added value: +"Absolute path to the project folder to scan recursively."
    • addedInput schema / properties / var_pattern / description
      Added value: +"Substring identifying magic-number variables."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "title": "find_magic_collisionDictOutput",
      +  "type": "object"
      +}
  2. First observedv0.4.1

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already communicate read-only, idempotent, and non-destructive behavior. The description adds the important lifecycle fact that the tool is removed in 0.6.0, which is useful context beyond the annotations, but it does not describe what happens if the tool is still invoked or what its original return behavior was.

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 entire description is one sentence, front-loaded with 'DEPRECATED' and immediately followed by the exact replacement call. There is no wasted text or 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?

For a deprecated tool, the most essential context is that it should not be used and what to use instead, both of which are present. The original tool's behavior is not described, but the output schema, annotations, and explicit redirect to inspect_source make the description sufficient for correct agent behavior.

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 description provides no parameter details, but the input schema documents both 'root' and 'var_pattern' with 100% coverage. With the schema handling parameter semantics, 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.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description does not directly state what find_magic_collision does, but the replacement call inspect_source(root=..., aspects=['magic']) and the tool name imply it was about magic-number collision detection. The purpose is discernible only indirectly, making it vague rather than explicit.

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 clearly says the tool is deprecated and removed, and gives the exact alternative invocation: inspect_source(root=..., aspects=['magic']). This is explicit do-not-use and use-this-instead guidance, which fully covers the when and why.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.