Skip to main content
Glama
AzeevAN

mcp-1c

by AzeevAN
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_object

Fetches 1C configuration object metadata with attributes, tabular sections, and register query field names before coding. Supports brief, fields, full detail levels and cursor for large HTTP services.

Instructions

Структура объекта конфигурации: реквизиты с типами, табличные части, движения, предопределённые. detail: brief | fields | full. Обязательный шаг перед написанием кода или запроса. Только здесь видно то, от чего код зависит и чего нет в поиске: вид и периодичность регистра (СрезПоследних есть лишь у периодического регистра сведений, а непериодических большинство), корреспонденция, предел субконто, и — для регистров — раздел «Таблицы запроса» с уже подставленными именами полей: ресурс Количество в запросе называется КоличествоОстаток или КоличествоОборот, и в конфигураторе таких имён не видно. Большие HTTP-сервисы и подсистемы дочитываются тем же get_object по готовому вызову с непрозрачным cursor; после смены поколения чтение нужно начать заново.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
configNoИмя конфигурации 1С, как его вернул `list_configurations` (например «ОтраслеваяКонфигурация»). Обязателен, если загружено больше одной конфигурации: по умолчанию ничего не подставляется, иначе ответ может относиться к чужой конфигурации.
cursorNoНепрозрачный cursor из ответа get_object для продолжения HTTP-сервиса или подсистемы. Передавайте без изменений с теми же full_name, config и detail.
detailNoУровень детализации: `brief` — пара строк со счётчиками, `fields` — состав для написания кода, `full` — со свойствами и связями. Полное описание крупного документа занимает много контекста, поэтому `full` только когда связи действительно нужны.fields
full_nameYesПолное имя объекта: `Документ.ЧекККМ`, `Справочник.Номенклатура`. Получается из `search_objects`.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.3.0
    • addedInput schema / properties / cursor
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Непрозрачный cursor из ответа get_object для продолжения HTTP-сервиса или подсистемы. Передавайте без изменений с теми же full_name, config и detail.",
+  "title": "Cursor"
+}
  2. First observedv2.0.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals the cursor-based continuation mechanism for large HTTP services and subsystems, warns that reading must restart after a generation change, and explains that the 'full' detail level consumes a lot of context. These are valuable behavioral traits beyond 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?

The description is long and dense, but the core purpose is front-loaded and the examples (e.g., 'СрезПоследних', 'КоличествоОстаток') justify the tool's necessity. Some redundancy exists with the schema's parameter descriptions, but overall each sentence contributes useful context.

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?

The description covers purpose, when to use it, parameter semantics, detail-level trade-offs, and the cursor/generation-change behavior. An output schema exists, so return values are covered elsewhere. The description is sufficiently complete for an agent to invoke and interpret this complex 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 coverage is 100%, so the baseline is 3, but the description adds meaningful guidance: it explains the detail levels in context, warns about the context cost of 'full', and clarifies cursor usage with same full_name, config, and detail. This exceeds simple schema descriptions.

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 returns the configuration object structure: attributes with types, tabular sections, movements, and predefined data. It goes beyond a generic 'get object' by explaining what is included and why it is unique compared to search results. This differentiates it from sibling tools like search_objects and search_procedures.

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 says this is a mandatory step before writing code or a query, and notes that only here can one see details not available in search. It gives a clear usage context but does not explicitly name alternatives or state when not to use it. Still, the guidance is concrete and actionable.

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