mcp-mt5

Overview Schema Source Related Servers Discussions Admin

inspect_source

Read-onlyIdempotent

Analyze MQL4/5 source files to extract input declarations, resolve include trees, parse doc blocks, locate symbol usages, and detect duplicate magic numbers.

Instructions

Read-only facts about MQL source: input declarations, #include tree (with missing files), MetaEditor doc blocks, symbol usages, duplicate magic numbers.

Replaces extract_inputs / resolve_includes / extract_doc / find_symbol / find_magic_collision.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`root`	No	Absolute project folder to scan (for symbol, magic); defaults to the source file folder.
`limit`	No	Max symbol matches to return.
`source`	No	Absolute path to one .mq4/.mq5/.mqh file (for inputs, includes, docs).
`symbol`	No	Identifier to grep for (whole word, comments and strings skipped); enables the "symbol" aspect.
`aspects`	No	Which analyses to run; defaults to inputs, includes and docs for a source, plus symbol when `symbol` is given and magic when only `root` is given.
`mql_root`	No	MQL root used to resolve <angle> includes; defaults to the active terminal.
`var_pattern`	No	Substring identifying magic-number variables for the "magic" aspect.	Magic

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.5.0Sep 11, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior; the description reinforces this and adds useful behavioral detail such as '#include tree (with missing files)' and 'duplicate magic numbers', explaining what kind of facts are produced. It does not deeply describe edge-case behavior, but the output schema and annotations cover the rest.

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 efficient sentences with no filler. The primary capability is front-loaded, and the sibling replacement list is packed into a single closing line.

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 that the schema has 100% parameter coverage Appendix and an output schema exists, the description only needs to orient the agent on what the tool is for and how it relates to alternatives. It does this completely, while the read-only annotations cover the safety model.

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% and all parameters have useful descriptions, so the baseline is 3. The description adds semantic nuance to the 'aspects' parameter by clarifying that includes means '#include tree (with missing files)', docs means 'MetaEditor doc blocks', and magic means 'duplicate magic numbers', which the schema's bare enum names do not fully convey.

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 states a specific scope ('Read-only facts about MQL source') and enumerates five concrete capabilities: input declarations, #include tree with missing files, MetaEditor doc blocks, symbol usages, and duplicate magic numbers. It also explicitly names the sibling tools it replaces, so an agent can distinguish it from extract_inputs, resolve_includes, extract_doc, find_symbol, and find_magic_collision.

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 'Replaces extract_inputs / resolve_includes / extract_doc / find_symbol / find_magic_collision' line is an explicit routing instruction: use this tool instead of those five siblings for those analysis needs. The 'Read-only' qualifier also marks the boundary against mutation tools.

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