F
licenseNot graded
qualityD
maintenanceProvides AI coding assistants with local access to 4500+ MQL5 documentation files and supplementary ebooks via MCP, enabling efficient search, browsing, and error diagnosis for MQL5 development.
24
-
MQL5 EA MCP Server
by ductri-dev
The MQL5 EA MCP Server is a local, offline tool for MQL5 developers that provides documentation lookup, search, and compilation error diagnosis — entirely without external API calls or internet access.
Smart Query (Recommended) – Intelligently query for MQL5 functions, classes, concepts, or compile errors; returns concise answers in quick (~500 tokens) or detailed (~1500 tokens) mode.
Search – Search MQL5 documentation by function name, class name, or keywords across the MQL5 Reference, Algo Book, and Neural Networks Book.
Get Document – Retrieve the full content of a specific documentation page by filename, title,
docId, or alias.Browse Categories – Navigate the documentation index by category, dynamically generated from the actual index.
Diagnose Compile Error – Parse MQL5 compile logs from MetaEditor, identify file/line/column/error codes, and suggest relevant documentation and fixes.
Log Error – Record encountered compile errors and their solutions into a local error database for future reference.
List Common Errors – View the most frequently encountered compile errors, sorted by occurrence frequency.
Manage Error DB – Export, import, or view statistics of the local error database, with optional anonymization for sharing.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@MQL5 EA MCP ServerHow to send a market order with OrderSend?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MQL5 EA MCP Server
MCP server tra cứu tài liệu MQL5 cục bộ. Server lập chỉ mục từ MQL5_HELP, MQL5_Algo_Book và Neural_Networks_Book, sau đó cung cấp các công cụ tìm kiếm, truy vấn nhanh, đọc tài liệu, duyệt danh mục và chẩn đoán lỗi biên dịch.
Tất cả dữ liệu chạy cục bộ. Không cần dịch vụ mạng, không gửi tài liệu hay lỗi biên dịch ra ngoài.
Tính năng chính
Tìm kiếm tài liệu MQL5 bằng SQLite FTS5.
Hỗ trợ ba nguồn tài liệu: Reference, Algo Book và Neural Networks Book.
smart_querytrả lời gọn theo hàm, class, khái niệm hoặc lỗi thường gặp.diagnose_errorphân tích log compile từ MetaEditor/terminal và gợi ý API liên quan.Error DB cục bộ giúp lưu lại lỗi và cách sửa để dùng lại về sau.
browsesinh danh mục từ index thật, không dùng danh sách hard-code.Output của
smart_queryvàgetđược giới hạn độ dài để tiết kiệm token.
Related MCP server: Dedalus MCP Documentation Server
Cài đặt nhanh
Yêu cầu:
Node.js 18 trở lên.
Claude Desktop, Cursor, Codex hoặc MCP client tương thích.
Ví dụ cấu hình MCP:
{
"mcpServers": {
"mql5-ea": {
"command": "npx",
"args": ["-y", "mql5-ea-mcp@1.4.1"]
}
}
}Khi phát triển local:
npm install
npm run build
npm run build:index
node build/index.jsDữ liệu cục bộ
Docs index:
~/.mql5-ea-mcp/indexes/docs-v<schema>-<corpus-hash>.sqliteError DB:
~/.mql5-ea-mcp/mql5_errors.db
Khi publish, package npm chứa sẵn SQLite index. Lần chạy đầu chỉ copy index này vào cache người dùng; các truy vấn sau không scan hay parse tài liệu HTML. Khi nâng phiên bản corpus, server tự tạo cache mới theo manifest; cache cũ có thể xóa an toàn khi không còn cần.
Biến môi trường dành cho development/test:
MQL5_EA_DATA_DIR: thay thư mục chứadocs_index.sqlitevà manifest đã build.MQL5_EA_CACHE_DIR: thay thư mục cache index cục bộ.
Danh sách tool
smart_queryTruy vấn thông minh. Dùng cho hàm, class, lỗi compile, câu hỏi "cách làm" và khái niệm.searchTìm tài liệu theo title, filename, alias, category, summary và nội dung.getĐọc tài liệu chi tiết theodocId, đường dẫn, title hoặc alias.browseDuyệt danh mục sinh từ docs index.diagnose_errorParse log biên dịch MQL5, chỉ ra file/dòng/cột/mã lỗi, thêm migration hints và tài liệu liên quan.log_errorGhi lỗi đã gặp vào error DB cục bộ.list_common_errorsXem lỗi thường gặp theo tần suất.manage_error_dbExport/import/thống kê error DB.
Ví dụ sử dụng
Tra cứu nhanh:
smart_query(query="OrderSend MqlTradeRequest", mode="quick")Tra cứu chi tiết:
smart_query(query="CopyBuffer indicator handle", mode="detailed")Tìm chương trong sách:
search(query="datetime session filters", limit=5)
search(query="GPT transformer self attention", limit=5)Tìm ONNX trong MQL5 Reference:
search(query="ONNX model inference", limit=5)Chẩn đoán log compile:
diagnose_error(
log="ma_cross_ea.mq5(155,39) : error 256: undeclared identifier 'ResultCode'",
limit=5
)Gợi ý dùng tool
Với đa số tình huống, hãy bắt đầu bằng smart_query. Nếu cần xem nhiều kết quả, dùng search. Nếu đã biết chính xác tài liệu cần đọc, dùng get. Khi có cả đoạn log compile, dùng diagnose_error thay vì hỏi từng lỗi rời rạc.
ONNX thuộc MQL5_HELP, không thuộc Neural_Networks_Book. Với Neural book, dùng các query như GPT transformer self attention, perceptron, attention, OpenCL neural network.
Hướng dẫn bổ sung
QUICK_START_SMART_QUERY.md: hướng dẫn bắt đầu nhanh.SMART_QUERY_GUIDE.md: hướng dẫn chi tiết vềsmart_query.AI_USAGE_GUIDE.md: cách dùng với trợ lý lập trình khi sửa lỗi compile.ERROR_COLLECTION_GUIDE.md: cách dùng error DB cục bộ.
Kiểm thử và build
npm run build
npm run build:index
npm testKết quả mong đợi:
TypeScript build thành công.
Vitest pass toàn bộ test.
build/được refresh sau khi sửa TypeScript.data/docs_index.sqlitevàdata/docs_index.manifest.jsonđược tạo trước khi đóng gói/phát hành.
Ghi chú phát triển
Project dùng
better-sqlite3, SQLite FTS5, Cheerio và Vitest.package-lock.jsonhiện không được commit vì.gitignoređang ignore lockfile.Error DB là dữ liệu người dùng, không lưu trong repo.
Tài liệu HTML chỉ là input cho release build. Chạy
npm pack --dry-runđể kiểm tra tarball chỉ chứabuild/,data/, README và LICENSE.
Available Tools
8 toolsbrowseC
Duyệt danh mục tài liệu MQL5 từ index thực tế.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Số lượng tài liệu tối đa trả về | |
| category | No | Tên danh mục (tùy chọn) |
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions 'from actual index' but does not explain side effects, authentication needs, rate limits, or return format. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, but it is under-specified. Every word should earn its place; here, it lacks critical details like return type or pagination, making it inadequate rather than efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description should at least clarify what the output looks like (e.g., list of documents). It fails to do so, leaving the agent without sufficient context to interpret the results.
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 no additional meaning beyond what the schema provides, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('browse') and resource ('MQL5 document catalog'), clearly stating the tool's function. However, it does not differentiate from sibling tools like 'search' or 'get', which could cause confusion about when to use this tool instead of alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description implies it is for browsing the catalog, but does not exclude cases where search or get would be more appropriate, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
diagnose_errorC
Phân tích log lỗi biên dịch MQL5, gợi ý nguyên nhân và tài liệu liên quan.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| log | Yes | Nội dung lỗi compile từ MetaEditor hoặc terminal | |
| limit | No | Số lỗi tối đa cần phân tích |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only says it analyzes and suggests causes/docs. It does not disclose behavioral traits like side effects, required permissions, or rate limits. The description is too sparse for a tool with no annotation support.
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 a single sentence that front-loads the action ('Phân tích log lỗi biên dịch MQL5'). It is efficient and contains no 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?
The description is minimal for a tool with no output schema. It does not explain the format of returned suggestions or documentation, leaving the agent unsure of what to expect.
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?
Both parameters have descriptions in the input schema (100% coverage). The tool description adds no extra meaning beyond the schema, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes MQL5 compilation error logs and suggests causes and documentation, indicating a specific verb-resource pair. However, it does not distinguish from sibling tools like 'list_common_errors' or 'log_error'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for compilation error logs but lacks when-not-to-use or sibling tool comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getA
Lấy nội dung chi tiết của tài liệu được chỉ định (đầy đủ HTML, ~3000 tokens). Để có câu trả lời rút gọn, hãy dùng smart_query.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | Tên tài liệu (có thể không kèm phần mở rộng) |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses output format (full HTML) and approximate token count, which adds transparency. However, it lacks details on error handling, permissions, or side effects, so it 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, front-loaded with the core purpose, and contains no extraneous information. Every word 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?
For a simple retrieval tool with one parameter and no output schema, the description covers the key aspects: content format, size, and an alternative tool. It is reasonably complete though it could mention error cases or prerequisites.
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 baseline is 3. The tool description adds no additional meaning to the 'filename' parameter beyond what the schema already provides ('Document name (can be without extension)').
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 retrieves detailed document content (full HTML, ~3000 tokens) and distinguishes itself from the sibling tool 'smart_query' by specifying when to use each.
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 using 'smart_query' for shortened answers, providing clear context on when to use this tool vs. one sibling. However, it does not discuss other siblings like 'search' or 'browse', leaving some alternatives uncovered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_common_errorsA
📊 Liệt kê các lỗi biên dịch MQL5 thường gặp nhất (sắp xếp theo tần suất xuất hiện). Giúp nhanh chóng nắm bắt các vấn đề thường gặp.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Số lượng lỗi tối đa trả về (mặc định 10) |
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions listing and sorting but does not disclose read-only nature, authorization needs, rate limits, or behavior edge cases (e.g., empty results). Adequate for a simple retrieval tool but limited in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with an emoji, front-loading the purpose. Every word earns its place with no 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 description is adequate for a simple tool with one parameter and no output schema, but it lacks details on return structure (fields like error code, message, count). This omission reduces completeness for an agent needing to parse the output.
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% as the only parameter 'limit' is well-described in the schema. The tool description adds no extra meaning to the parameter, so baseline score of 3 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 the tool lists the most common MQL5 compilation errors sorted by frequency, which is specific and distinguishes it from sibling tools like diagnose_error (for specific errors) and manage_error_db (database management).
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 quickly grasping common issues, and the tool name and siblings provide context, but it does not explicitly state when to use this tool over alternatives or define exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
log_errorA
📝 Ghi nhận lỗi biên dịch MQL5 vào cơ sở dữ liệu cục bộ. Dùng để thu thập các lỗi thường gặp và giải pháp, giúp tra cứu nhanh khi gặp lại lỗi đó.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| solution | No | Mô tả giải pháp xử lý (tùy chọn) | |
| file_path | No | Đường dẫn tệp xảy ra lỗi (tùy chọn, vì lý do bảo mật) | |
| error_code | Yes | Mã lỗi (ví dụ: E512, E308) | |
| related_docs | No | Danh sách tài liệu liên quan dưới dạng mảng JSON (tùy chọn) | |
| error_message | Yes | Thông báo lỗi đầy đủ |
TDQS
A4/5.0
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 mentions recording to a local database but does not detail side effects (e.g., whether duplicates are overwritten, or security considerations). Adequate for a straightforward logging tool but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with a relevant emoji. It is front-loaded with the action and resource, and contains 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 parameter count (5), no output schema, and no annotations, the description provides sufficient context for the tool's purpose and when to use it. However, it lacks details on the database behavior (e.g., how entries are stored or retrieved later), which could be helpful for full understanding.
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 adds no additional meaning beyond the schema descriptions; it only restates the purpose. The parameter details are well covered by the schema itself.
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 (ghi nhận/record), resource (lỗi biên dịch MQL5 vào cơ sở dữ liệu cục bộ), and usage purpose (thu thập lỗi thường gặp và giải pháp). It effectively distinguishes from sibling tools like list_common_errors (listing) and diagnose_error (diagnosing).
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 explains the context of use ('Dùng để thu thập các lỗi thường gặp và giải pháp'), implying when to log errors. While it does not explicitly state when not to use or name alternatives, the sibling list provides enough differentiation for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
manage_error_dbC
🔧 Quản lý cơ sở dữ liệu lỗi: Xuất/nhập bản ghi lỗi, xem thông tin thống kê. Hỗ trợ chia sẻ cơ sở dữ liệu lỗi trong nhóm.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Dữ liệu JSON khi nhập (bắt buộc khi action=import) | |
| action | Yes | Loại thao tác: export=xuất ra JSON, import=nhập từ JSON, stats=xem thống kê | |
| anonymize | No | Có loại bỏ đường dẫn tệp khi xuất để bảo vệ quyền riêng tư hay không (mặc định false) |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It states the actions but omits critical details: whether import overwrites or appends, what data anonymization entails, and any permission or side-effect information. The behavioral profile is incomplete.
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 two sentences with no waste. It front-loads the core purpose and adds a relevant note about sharing. Each word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and three parameters, the description should cover more behavioral aspects like return values, error cases, and operational impact. It only lists actions without elaboration on expected outcomes or constraints.
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 adds no extra meaning beyond the parameter descriptions in the schema (e.g., 'data' is required for import, 'anonymize' defaults to false). No additional context or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: managing error database with export, import, and stats actions. It uses a specific verb ('manage') and resource ('error database'), and the sibling tools suggest it handles bulk operations rather than individual errors, though not explicitly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings like log_error or diagnose_error. The description mentions sharing databases in groups, implying collaborative bulk operations, but lacks clear context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchA
Tìm kiếm tài liệu MQL5 (tên hàm, tên lớp, từ khóa). Trả về danh sách tài liệu, cần gọi tiếp công cụ get để lấy nội dung. Để có câu trả lời trực tiếp, hãy dùng smart_query.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Số lượng kết quả tối đa trả về | |
| query | Yes | Từ khóa tìm kiếm hoặc văn bản lỗi |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it returns a list of documents, not full content. No annotations provided, so description carries full burden. Does not mention permissions or rate limits, but 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?
Two efficient sentences with zero waste. Front-loaded with purpose, followed by usage guidance and alternative. Perfect structure for quick comprehension.
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?
Simple tool with 2 params and no output schema. Description fully explains purpose, return type, next steps, and alternative. No gaps given the tool's 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?
Schema covers both parameters with descriptions. Description adds context that query is for function names, class names, keywords. Baseline 3 due to high schema coverage; limited extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it searches MQL5 documentation (function names, class names, keywords). It distinguishes from siblings by noting it returns a list and suggests using 'get' for content and 'smart_query' for direct answers.
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 tells when to use (search docs) and when not to (use smart_query for direct answers). Provides workflow: call get to retrieve content. No exclusions needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
smart_queryA
🎯 Công cụ truy vấn thông minh (Khuyến nghị): Nhập thông tin lỗi, tên hàm hoặc câu hỏi để tự động tìm kiếm và trả về câu trả lời rút gọn. Hoàn toàn chạy cục bộ, không tốn chi phí API, tiết kiệm hơn 80% token. Thích hợp cho: Chẩn đoán lỗi, tra cứu hàm, học nhanh.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Chế độ trả về: quick=Trả lời rút gọn (~500 tokens, khuyến nghị), detailed=Giải thích chi tiết (~1500 tokens) | quick |
| query | Yes | Nội dung truy vấn: 1) Thông báo lỗi như 'error 256: undeclared identifier ResultCode' 2) Tên hàm như 'OrderSend' 3) Tên lớp như 'CTrade' 4) Câu hỏi như 'how to send order' |
TDQS
A3.6/5.0
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 runs locally, has no API cost, saves over 80% tokens, and offers two response modes with token estimates. It does not cover state modification, permissions, or error handling, but for a read-only query tool, this is adequate.
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 fairly concise, using an emoji and bullet-like examples. It is front-loaded with purpose and benefits. A minor improvement could be clearer structuring, but overall it's effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description covers purpose, usage, mode options, and examples. It is complete enough for an AI agent to understand and invoke the tool correctly.
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%. The description adds value by providing concrete examples of query content (error messages, function names, class names, questions) and explaining the mode options with token estimates (quick: ~500 tokens, detailed: ~1500 tokens), going beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool as a smart query tool for error information, function names, or questions, returning concise answers. It somewhat distinguishes itself from siblings like search and browse by emphasizing local execution and token savings, but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides recommended use cases (error diagnosis, function lookup, quick learning) and mentions benefits (local, no API cost, token savings). However, it does not specify when not to use or compare to sibling tools like search or diagnose_error.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
8 tool updates
v1.3.0- First observed
browse - First observed
diagnose_error - First observed
get - First observed
list_common_errors - First observed
log_error - First observed
manage_error_db - First observed
search - First observed
smart_query
TDQS
B3.3/5.0
Disambiguation3/5
There is overlap between get, search, and smart_query for retrieving documentation, and between diagnose_error, list_common_errors, log_error, and manage_error_db for error handling. However, each tool has a distinct focus (full content, list, summary, diagnosis, listing common, logging, management) so boundaries are fuzzy but not catastrophic.
Naming Consistency2/5
Tool names mix styles: some are verb_noun (diagnose_error, list_common_errors, log_error, manage_error_db), while others are single verbs (browse, get, search) or adjective_noun (smart_query). The verb 'get' is overly generic. No consistent pattern.
Tool Count4/5
With 8 tools, the server is well-scoped for its purpose of MQL5 documentation and error assistance. Not excessive nor too thin, each tool serves a clear role.
Completeness4/5
The tool set covers browsing, searching, retrieving documentation, error diagnosis, error logging, and database management. Missing features like updating or contributing to docs, but core workflows are complete and agents can accomplish common tasks without dead ends.
Maintenance
ActivitySlowing
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server for querying Forkast documentation
Stimulsoft Reports & Dashboards docs MCP server. Semantic search for all platforms.
MCP server with quote and live cryptocurrency price tools, local and cloud-deployed transports.
21MCP server for Russian books search, details, and recommendation candidates.
Related MCP Servers
- AlicenseAqualityDmaintenanceAn MCP server that serves documentation and enables AI-powered search, Q\&A, and document analysis for developer tools and guides.54MIT
- AlicenseNot gradedqualityDmaintenanceMCP server for documentation search that automatically indexes web documentation sites and provides semantic, full-text, or hybrid search capabilities.14MIT
- AlicenseNot gradedqualityBmaintenanceMCP server providing 100% offline access to QuantConnect/Lean documentation with semantic search, code validation, repair, and scaffolding tools for AI coding assistants.2MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/ductri-dev/mql5-ea-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server