Skip to main content
Glama

get_related

Shows direct relationships of a 1C object: what it references, what references it, and which registers it moves, with the attribute or movement behind each link to show what else may break if changed.

Instructions

Прямые связи объекта: на что ссылается, кто ссылается на него, какие регистры двигает — с подписью, через какой реквизит или движение идёт каждая связь. Отвечает на «что ещё сломается, если тронуть». Только один шаг: дальше связь идёт через объекты, которые соединены почти со всем (дополнительные реквизиты, значения доступа), и список имён на втором шаге правдоподобен, но бессмыслен. Нужна цепочка через несколько объектов — стройте её повторными вызовами по конкретному имени из выдачи. Длинный список дочитывается готовым вызовом из блока «Продолжение».

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": {
      "full_name": "<full_name>"
    },
    "name": "get_related"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoСвязей на странице, от 1 до 200.
configNoИмя конфигурации 1С, как его вернул `list_configurations` (например «ОтраслеваяКонфигурация»). Обязателен, если загружено больше одной конфигурации: по умолчанию ничего не подставляется, иначе ответ может относиться к чужой конфигурации.
cursorNoНепрозрачный cursor из блока «Продолжение» предыдущего ответа get_related; передавайте без изменений с теми же full_name и config.
full_nameYesПолное имя объекта, например `Документ.ЧекККМ`.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.5.0
    • addedInput schema / properties / cursor
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Непрозрачный cursor из блока «Продолжение» предыдущего ответа get_related; передавайте без изменений с теми же full_name и config.",
      +  "title": "Cursor"
      +}
    • addedInput schema / properties / limit
      Added value: +{
      +  "default": 40,
      +  "description": "Связей на странице, от 1 до 200.",
      +  "maximum": 200,
      +  "minimum": 1,
      +  "title": "Limit",
      +  "type": "integer"
      +}
  2. First observedv2.0.0

TDQS

A4.2/5.0
Behavior4/5

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

No annotations exist, so the description carries the full load, and it does disclose the key non-obvious trait: results beyond depth one are 'plausible but meaningless' because they pass through ubiquitous objects (additional attributes, access values). It also discloses the pagination mechanism. It does not say the tool is read-only or comment on cost/latency, which is a gap for a graph-walking query.

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?

Front-loaded with what the tool returns, then the one-step caveat, then the workaround — a sensible order with no filler sentences. The caveat sentence is a long run-on with stacked parentheticals, which costs some readability.

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?

An output schema exists, so return values need no explanation; the description instead covers exactly the parts structure cannot: the one-hop semantic limit, why deeper results are untrustworthy, the multi-call workaround, and the continuation block. Nothing an agent needs to invoke it correctly is missing.

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 full parameter meaning (limit range, config selection, cursor reuse) is already in the structured data, setting the baseline at 3. The description adds only a light reinforcement by naming the 'Продолжение' block as the cursor source; it adds no semantics beyond the schema.

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?

Names a specific operation on a specific resource and enumerates the three relation classes it returns (outgoing references, incoming referrers, register movements), each with its signature and the attribute/movement that carries it. The 'what else breaks if I touch it' framing makes the intent unmistakable and clearly puts it in a different lane from the narrower get_callers sibling.

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?

Explicitly states the hard boundary — 'only one step' — and explains why deeper traversal is misleading, then gives the correct alternative ('build the chain with repeated calls by a concrete name from the output'). It also tells the agent how to continue a long list via the 'Продолжение' block. It never contrasts against get_callers, which is the one sibling an agent could reasonably confuse it with.

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