Skip to main content
Glama
fr0ster

mcp-abap-adt

by fr0ster
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

CreateTable

Creates a new ABAP table in an SAP system in initial state, using a table name and package, with optional transport request for transportable packages.

Instructions

Create a new ABAP table in SAP system. Creates the table object in initial state.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
detailNoHow much of the answer to return: "terse" (default, the fields you need to act), "full" (the whole parse), "raw" (the document as ADT sent it).terse
table_nameYesTable name.
descriptionNoDoes not reach creation — the shipped create endpoint has no description field of its own. Use UpdateTable (with ddl_code) after creating to set the DDL source, which carries the description.
package_nameYesPackage name
master_languageNoOptional master/original language for the created object (e.g. "EN", "DE", "ZH"). Defaults to the session language (SAP_LANGUAGE) or EN.
transport_requestNoTransport request number, not a task. Required for transportable packages.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv16.0.0
    • changedInput schema / properties / description / description
      Previous value: -"Table description for validation and creation."New value: +"Does not reach creation — the shipped create endpoint has no description field of its own. Use UpdateTable (with ddl_code) after creating to set the DDL source, which carries the description."
    • addedInput schema / properties / detail
      Added value: +{
+  "default": "terse",
+  "description": "How much of the answer to return: \"terse\" (default, the fields you need to act), \"full\" (the whole parse), \"raw\" (the document as ADT sent it).",
+  "enum": [
+    "terse",
+    "full",
+    "raw"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / package_name / description
      Previous value: -"Package name (e.g., ZOK_LOCAL, $TMP for local objects)"New value: +"Package name"
    • changedInput schema / properties / table_name / description
      Previous value: -"Table name (e.g., ZZ_TEST_TABLE_001). Must follow SAP naming conventions."New value: +"Table name."
    • changedInput schema / properties / transport_request / description
      Previous value: -"Transport request number (e.g., E19K905635). Required for transportable packages."New value: +"Transport request number, not a task. Required for transportable packages."
  2. Changed1 schema field changedv8.1.0
    • addedInput schema / properties / master_language
      Added value: +{
+  "description": "Optional master/original language for the created object (e.g. \"EN\", \"DE\", \"ZH\"). Defaults to the session language (SAP_LANGUAGE) or EN.",
+  "type": "string"
+}
  3. Changed3 schema fields changed
    • removedInput schema / properties / activate
      Removed value: -{
-  "description": "Activate table after creation. Default: true. Set to false for batch operations (activate multiple objects later).",
-  "type": "boolean"
-}
    • removedInput schema / properties / ddl_code
      Removed value: -{
-  "description": "Complete DDL code for table creation. Example: '@EndUserText.label : \\'My Table\\' @AbapCatalog.tableCategory : #TRANSPARENT define table ztst_table { key client : abap.clnt not null; key id : abap.char(10); name : abap.char(255); }'",
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "table_name",
-  "ddl_code",
-  "package_name"
-]New value: +[
+  "table_name",
+  "package_name"
+]
  4. First observed

TDQS

C2.9/5.0
Behavior2/5

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

There are no annotations, so the description carries the full disclosure burden. 'Creates the table object in initial state' usefully implies the object is not yet active, but the description says nothing about permissions, transport requirements, collision behavior when the table already exists, or reversibility — much of that is buried in the parameter 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?

Two short sentences, front-loaded with the action and then the resulting state. Nothing is wasted, though the brevity leaves it thin for a mutation tool with six parameters.

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?

With no output schema and no annotations, the description should ideally cover the creation-to-activation workflow and transport implications. 'Initial state' gestures at the activation step but the transport-request prerequisite and the follow-up UpdateTable flow are only implied, leaving moderate gaps for a mutating 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?

Schema description coverage is 100% and the parameter descriptions are rich (transport request caveat, description-not-reaching-creation note, master language defaulting), so the schema does the heavy lifting. The tool description adds no parameter meaning beyond it, matching the baseline 3.

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?

States a specific verb and resource ('Create a new ABAP table in SAP system') and adds a state qualifier ('initial state') that distinguishes it from ActivateTable and UpdateTable. It doesn't explicitly name a sibling, but the create-vs-modify distinction is clear from the repository of sibling verbs.

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 guidance on when to use CreateTable versus CheckTable, ActivateTable, or the UpdateTable follow-up. The only usage hint lives in the schema's `description` parameter, not in the tool description itself, so an agent gets no tool-level context on preconditions or next steps.

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