Skip to main content
Glama

get_related

Find direct links of a 1C object: references to and from it, and register movements, with signatures and attributes. Assess what breaks if changed; call repeatedly by name to trace deeper chains.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
configNoИмя конфигурации 1С, как его вернул `list_configurations` (например «ОтраслеваяКонфигурация»). Обязателен, если загружено больше одной конфигурации: по умолчанию ничего не подставляется, иначе ответ может относиться к чужой конфигурации.
full_nameYesПолное имя объекта, например `Документ.ЧекККМ`.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv2.0.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the key behavioral trait: the tool only traverses one step and that a second step would be plausible but meaningless due to over-connected objects. This is valuable context. However, it does not explicitly state whether the operation is read-only or has any side effects. Given it is an informational tool, this is a minor omission, but the description does highlight the most critical behavioral caveat.

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 moderately concise but somewhat verbose. It front-loads the purpose and then explains the one-step limitation with a rationale about over-connected objects. The phrase 'Отвечает на «что ещё сломается, если тронуть»' is redundant and could be omitted. The rest could be tightened without losing meaning. It is structured but not exceptionally concise.

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 tool with an output schema present (though not shown here), the description does not need to detail return types. It explains the nature of the output (direct links with signatures and attributes) and explicitly describes the one-step limitation, which is essential for correct usage. It also advises on how to build multi-hop chains by repeated calls, giving practical guidance. This covers the main contextual needs an agent would have.

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%: both 'full_name' and 'config' have clear descriptions in the input schema. The tool description does not add additional semantics to the parameters beyond what the schema already specifies. It merely refers to 'full_name' implicitly when discussing the object. Therefore, it meets the baseline of 3; no extra value is provided 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?

The description clearly states the tool's purpose: it returns direct links of an object (what it references, who references it, which registers it moves) with signatures and the specific attribute or movement for each link. This is a specific verb-resource combination and distinguishes from siblings like get_object (which returns the object itself) and get_callers (which likely focuses on callers only). The explicit mention of 'one step' further differentiates it from multi-chain traversal.

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 when to use this tool: to answer 'what else will break if touched' and to get direct dependencies. It also explicitly states the limitation (only one step) and advises that for multi-hop chains, repeated calls using specific names from the output are needed. While it does not name a specific sibling to choose instead, it provides clear contextual guidance on when the tool is appropriate and when it is not, including a warning about the misleading second step.

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

Latest Blog Posts

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/AzeevAN/mcp-1c'

If you have feedback or need assistance with the MCP directory API, please join our Discord server