Skip to main content
Glama
Hollway

mcp-abap-abap-adt-api

by Hollway
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

tableFields

Read-only

Lists all fields of an ABAP table or structure with includes expanded, showing position, key flags, data element, ABAP type, length, decimals, and texts. Read-only; executes nothing.

Instructions

The fields of a table or structure, with the includes spliced in where they sit. Each field carries its position, key and not-null flags, data element, domain, ABAP type, length and decimals, the table its value is checked against, the field holding its unit or currency, and its text in the connection language. This is the answer to "what is in this table": getStructureSource gives the DDL text, where the type of a field is the name of its data element and an .INCLUDE is a line of text rather than the fields it brings - for EKPO, most of them. Reading only, and it executes nothing, so it works on a system where nothing may run.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesTable or structure, e.g. EKPO or ZAPPSTEP_POS.
fieldsNoKeep only the fields whose name contains this text, case-insensitive - for a table with hundreds of them.
keysOnlyNoKeep only the key fields. Default false.
maxFieldsNoFields to return, default 200. The full count is reported either way.
withTextsNoRead the data element texts. Default true; false saves one query per 60 elements.
expandIncludesNoSplice the fields of an .INCLUDE into the list. Default true; false lists the include markers instead, which is the shape of the definition.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it 'executes nothing' and works on locked-down systems, and clearly discloses the include-splicing default behavior, going beyond the annotation bare minimum.

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 the core purpose, then enumerates return field attributes and the key alternative. The description is a bit long but each part earns its place by shaping agent expectations about output and tool selection.

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?

Given there is no output schema, the description compensates by listing exactly what each returned field contains. It also explains the include behavior, the distinction from getStructureSource, and the read-only nature. Minor gaps like pagination or defaults are already in the parameter schemas.

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 the schema fully documents all six parameters. The description adds context about include splicing (aligning with expandIncludes) and the field list, but does not add new parameter-level meaning beyond what the schema already covers.

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?

States a specific verb and resource: the fields of a table or structure, including the include expansion behavior. It explicitly contrasts with getStructureSource, naming the distinct question it answers ('what is in this table') and the DDL alternative.

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?

Identifies the relevant alternative (getStructureSource) and gives the selection criterion: when you need the field inventory vs the DDL text. Also notes it works on systems where nothing may execute, but does not explicitly describe when NOT to use it beyond that contrast.

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