| name | mcp-1c-tools |
| description | Catalog of MCP servers for 1C development — search, code navigation, metadata, code review, docs, ITS, templates. Use whenever a 1C task requires calling tools from any 1c-*-mcp / 1C-*-mcp server. Each server has its own detail file under `docs/` — load it when you are about to call tools from that server, and only if the server is actually available in the current session. |
MCP tools for 1C — dispatcher
This skill is the single source of truth for the project's MCP server catalog, task→tool mapping, fallback order, and project-index search retries. Detailed per-tool descriptions for each server live in separate files under docs/. Load a specific docs/<server>.md when you are about to call tools from that server and want to tune parameters; the server must be actually available in the current session (its tools are exposed in the tool schema; the mere presence of an entry in mcp-servers.json does not count as availability).
What is mandatory vs. conditional
- Mandatory for risk-bearing 1C work. If a relevant server is exposed, call the fitting MCP tool for BSL / metadata edits or review, metadata XML, forms, integrations, refactoring, performance, runtime errors, platform API checks, impact analysis, syntax / quality validation, and project-memory operations.
- Conditional for external knowledge. Use platform docs, БСП / SSL, and ITS MCP tools when the task depends on versioned platform behavior, reusable БСП APIs, or standards compliance. Do not call them for generic prose cleanup or rule-file editing unless such a fact is actually needed.
- Not required for Markdown / rules / documentation-only work. For rule files, README, commands documentation, and similar prose-only edits, validate structure, links, paths, and internal consistency instead of calling 1C project MCP tools. Exception: OpenSpec artifacts that state concrete 1C facts (metadata / attribute names, API signatures, БСП subsystems, platform-version behaviour) are spec authoring, not documentation-only work — the mandatory scope above applies (
AGENTS.md → MCP Tool Calling → A.1, content/rules/sdd-integrations.md).
- Mandatory before parameter-rich calls. Read
docs/<server>.md before the first call in the session to every parameter-rich tool listed below, and re-read it when switching tools on that server. A genuinely simple one-shot lookup with obvious arguments may skip the detail file only when it is not in the parameter-rich list.
Parameter-rich tools — read the doc first
For these tools default parameters are usually suboptimal; consult the server's docs/<server>.md before the first call in the session and adjust the parameters to the task:
1c-graph-metadata-mcp: search_code (search_type, detail_level), search_metadata (JSON templates), search_metadata_by_description (alpha, use_fuzzy), trace_impact (direction, depth, relationship_types), trace_call_chain (direction, depth), get_object_dossier (sections), business_search (include_structure, filter_type).1c-code-metadata-mcp: metadatasearch (object_type, names_only), get_method_call_hierarchy (direction, depth), graph_dependencies (direction), bsl_scope_members (member_type).
If docs/<server>.md conflicts with the descriptor exposed by the current environment, the environment descriptor wins.
When to use this skill
- Before writing code / a query / metadata XML — pick the MCP tool that best fits the task (template search, metadata check, syntax validation, code review).
- Before implementing a specialized capability (cryptography, СЛАУ / numerical methods, data analysis, collaboration system / bots, integration bus / queues, full-text search, regular expressions, …) — run the platform-capability check:
docsearch → docinfo on 1C-docs-mcp (+ ssl_search where a БСП solution is plausible). Do not trust model memory about what the platform does or does not have. Canon — AGENTS.md → MCP Tool Calling → A.7; procedure and trigger domains — docs/1C-docs-mcp.md → Platform capability discovery.
- For impact analysis and code navigation — decide which server to use first (
graph → code-metadata → Grep — see Fallback chain below).
- For ITS standards (
its_help → fetch_its) and platform documentation (docinfo / docsearch).
- For code templates and project memory (
templatesearch, remember, recall). Before templatesearch: load docs/1c-templates-mcp.md → Query formulation (templatesearch only) — that rule applies only to templatesearch, not to other MCP searches.
Short obligation rules and verification budgets live in AGENTS.md → MCP Tool Calling (sections A, B, C). This skill owns the MCP catalog, routing, and fallback details.
Server catalog
| Server (id) | Purpose | Details |
|---|
| 1c-graph-metadata-mcp | Graph metadata (Neo4j / Cypher): structural object passport, impact analysis, call graph, usage search, business semantic search | docs/1c-graph-metadata-mcp.md |
| 1c-code-metadata-mcp | Metadata and BSL code search, navigation (modules, procedures, functions, call hierarchy), forms, XSD schemas, validation | docs/1c-code-metadata-mcp.md |
| 1c-templates-mcp | Code template library + project vector memory (remember / recall) | docs/1c-templates-mcp.md |
| 1c-ssl-mcp | Standard Subsystems Library (БСП / SSL) search | docs/1c-ssl-mcp.md |
| 1C-docs-mcp | 1C platform documentation (search by description / by exact name) | docs/1C-docs-mcp.md |
| 1c-code-check-mcp | 1С:Напарник — code review, technical check, AI rewrite/modify, ITS documentation | docs/1c-code-check-mcp.md |
| 1c-syntax-checker-mcp | BSL syntax and style via BSL Language Server: syntaxcheck_file (the default — check a file on disk by path, optionally line-filtered; exposed only when a sources directory is mounted) and syntaxcheck (fallback — code as text, for a fragment that has no file yet) | docs/1c-syntax-checker-mcp.md |
| 1c-data-mcp |
edt-mcp is conditional and does not replace the bundle. It exists only in projects developed in 1C:EDT (.dev.env USE_EDT=true, plugin installed via /install-edt-mcp, EDT running with the workspace open). The bundle keeps ownership of indexed search, impact analysis, docs / БСП / ITS, templates, memory and the BSL validators; edt-mcp owns the live IDE state and the EDT-format tree. Routing, the source-format check and the model↔disk rule — content/rules/edt-workflow.md.
Fallback chain (highest priority to lowest)
Use only the applicable branch; stop as soon as the collected evidence is sufficient. Before each call, check that it closes a concrete context gap and is not a duplicate of an earlier call.
Project-source search before Grep / Glob / rg
Native discovery tools (Grep / rg, Glob / file search by pattern, directory listing, sequential Read-scanning) substitute only the project-indexing layer — locating files by mask (**/*.bsl, **/*.xml) or bulk-reading modules "to get oriented" is the same fallback as Grep, not a separate free action. Before falling back to any of them for 1C project-source search, exhaust:
1c-graph-metadata-mcp — search_code, search_metadata, search_metadata_by_description, get_object_dossier, trace_impact, trace_call_chain as appropriate.1c-code-metadata-mcp — default indexed search / navigation (codesearch, metadatasearch, search_function, search_forms, get_module_structure, etc.).1c-code-metadata-mcp with grep=true — substring retry inside the MCP index only after indexed / semantic / exact search did not find enough and only for tools that expose the parameter: codesearch, metadatasearch, search_function, helpsearch, search_forms. Typical scenarios: exact identifier, fragment of a query, metadata path, event handler name, error text, or literal string where semantic search is likely to miss.- Only then a native discovery tool (
Grep / rg / Glob / Read-scanning) — with a mandatory short note in the response listing which project-index MCP attempts were tried and why they did not return what was needed.
The chain is a bounded priority, not a prohibition: when the project-index servers are not exposed, the chain collapses and native tools apply immediately (one-line note). When a tuned call plus the documented retry missed — fall back without spending further MCP calls on this rule. After fresh local edits the index may be stale — reading the disk state directly is legitimate. For understanding a single routine prefer fragment-level retrieval (get_module_structure, search_code detail_level="L0", search_function) over a full-module Read; reading a direct edit target or an MCP-located file is normal work. Boundary cases — content/rules/mcp-first-search.md.
External knowledge
These servers have no Grep / rg equivalent; call them only when their knowledge is needed:
1c-templates-mcp — code templates and project memory (templatesearch, remember, recall). templatesearch only: query pre-flight (A.8) + reuse found template (A.9, docs/1c-templates-mcp.md → Using a found template).1c-ssl-mcp — БСП / SSL reusable APIs and patterns.1C-docs-mcp — versioned platform documentation; also the mandatory platform-capability check before hand-rolling a specialized mechanism (see docs/1C-docs-mcp.md → Platform capability discovery).1c-code-check-mcp — 1С:Напарник checks, ITS standards (its_help → fetch_its for every document used), AI drafts.1c-syntax-checker-mcp — BSL syntax / style validation after edits. Default to syntaxcheck_file (check by path — it costs a path instead of the module body, and it is the only mode the full-configuration index can answer); use syntaxcheck with code text only when the file tool is not exposed or the code has no file yet.1c-data-mcp — execution against the live infobase (run a BSL fragment, run a query, parse-check a query, fetch the last event-log error). No Grep / rg equivalent — there is no offline substitute for "what does this running IB do right now". Call only when the question genuinely requires the live IB; default to read-only fragments and ask before any mutation. Details — docs/1c-data-mcp.md.
Quick map: "task → MCP tool"
| Task | First choice (graph) | Fallback (code-metadata) |
|---|
| BSL code search | search_code (fulltext / semantic / hybrid, detail_level L0–L3) | codesearch |
| Metadata object structure | get_object_dossier | get_metadata_details |
| Impact analysis before refactoring | trace_impact (recursive, depth 1–5; up to 10 for CALLS) | graph_dependencies (single-level) |
| Call graph | trace_call_chain | get_method_call_hierarchy |
| Metadata search by name / structure | search_metadata (JSON templates) | metadatasearch |
| Object usage search | find_objects_using_object / find_usages_of_object | graph_dependencies (direction="reverse") |
| Description / synonym / comment search | search_metadata_by_description | metadatasearch (names_only=true) |
Step-by-step playbooks per task type (writing code, review, architecture, error fixing, performance, refactoring, metadata XML, forms, integrations, documentation, comparing platform versions) — content/rules/tooling-playbooks.md.
