Skip to main content
Glama
Sign In
mcp-1c

mcp-1c

by AzeevAN
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

search_syntax

Finds 1C platform methods, properties, events, or objects from a natural-language or exact-name query, returning concise list rows; use the found name with get_syntax for signatures and details.

Instructions

Найти метод, свойство или объект платформы 1С. Для вызываемого действия задайте kind=method: иначе в выдаче могут оказаться свойства и сходные по названию механизмы. Даёт только строку списка. Сигнатура, параметры, доступность по контекстам, версия появления, порог устаревания и рекомендуемая замена — в get_syntax по найденному имени. При режиме совместимости компиляция метода остаётся непроверенной и помечается unknown.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search_syntax"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNoОграничить вид. query_table — виды таблиц платформы (шаблоны); таблицы объекта конфигурации — в `get_object`. Значения: method, property, event, object, query_table, query_field.
limitNoСколько результатов вернуть. По умолчанию 10, максимум 50 (большее молча урезается). Поднимать выше 10 стоит только когда нужного не оказалось в первой десятке: правильный ответ почти всегда в первой пятёрке, а длинная выдача тратит контекст.
queryYesЧто ищем: «разделить строку», «ЗаписьJSON», «StrFind» по платформе. Русские и английские имена равнозначны.
configNoИмя конфигурации 1С, как его вернул `list_configurations` (например «ОтраслеваяКонфигурация»). Обязателен, если загружено больше одной конфигурации: по умолчанию ничего не подставляется, иначе ответ может относиться к чужой конфигурации.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.5.0
    • changedInput schema / properties / kind / description
      Previous value: -"Ограничить вид: method, property, event, object, query_table, query_field."New value: +"Ограничить вид. query_table — виды таблиц платформы (шаблоны); таблицы объекта конфигурации — в `get_object`. Значения: method, property, event, object, query_table, query_field."
  2. First observedv2.0.0

TDQS

A4.6/5.0
Behavior4/5

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

No annotations, so the description carries the burden; it discloses the shallow result shape (list row only) and a real edge case — in compatibility mode compilation is unverified and flagged `unknown`. It does not discuss ordering, matching/fuzzy behavior, or that exceeding `limit` is silently truncated (that lives only in 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with the purpose, then the kind pitfall, then the result-shape limit, then the compatibility caveat — no filler. It is dense and slightly compressed, but every sentence adds distinct information.

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?

For a search tool with full schema coverage and an output schema, this covers everything an agent needs: what it searches, how to scope by kind, that results are shallow, where to go next, and a version-specific caveat. Nothing material is missing.

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 the baseline is 3; the description earns above baseline by explaining the semantic consequence of `kind` (omitting method yields properties and similarly-named mechanisms). It adds no meaning for `query`, `limit` or `config`, which the schema already documents 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?

Opens with a specific verb and resource ("Найти метод, свойство или объект платформы 1С") and immediately bounds the result ("Даёт только строку списка"). It names the sibling that carries the detail (`get_syntax`), so an agent can distinguish the two without inspecting either schema.

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?

Gives an explicit selection rule for the ambiguous case: "Для вызываемого действия задайте kind=method: иначе в выдаче могут оказаться свойства". It also routes the agent to `get_syntax` for signature, parameters, availability, version and replacement, which is a concrete when-to-use-this-vs-alternative statement.

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

Deploy Server

Other Tools