Skip to main content
Glama
Sign In
INFATON MCP35

INFATON MCP35

Official
by infaton
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

get_form_structure

Retrieve the structure of a managed form including attributes, commands, and elements to understand an object's user interface.

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_form_structure"
  }
}

Input Schema

NameRequiredDescriptionDefault
form_nameNoИмя формы (если пусто — основная форма)
full_nameYesПолное имя объекта (например: Документ.РеализацияТоваровУслуг)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.0

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description carries full burden. It implies a read operation but does not confirm read-only nature, side effects, or permissions. The tool name 'get' hints at safety, but description adds no behavioral traits beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two concise sentences, no wasted words. Front-loaded with the verb and resource, followed by a use-case statement. Excellent structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema provided, and description only lists high-level return components without detailing format or nesting. Also lacks prerequisites (e.g., object must have a managed form). Adequate but incomplete for a complex tool.

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?

Input schema has 100% coverage, so baseline is 3. The description does not add any meaning beyond the schema; it focuses on output instead of parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the structure of a managed form, listing the components (attributes, commands, elements). It distinguishes from siblings like get_object_attributes and get_metadata_tree, but does not explicitly contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives like get_object_attributes or get_metadata_tree. The phrase 'useful for understanding UI' implies context but lacks exclusions or comparisons.

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