abap-config-mcp

Execute Data Query

execute_data_query

Read-onlyIdempotent

Run read-only ABAP SQL SELECT queries against dictionary tables or CDS views and return rows as an aligned text table or JSON; non-SELECT statements are rejected.

Instructions

Run one freestyle SELECT (ABAP SQL, as in the ADT data preview) against dictionary tables or CDS views and return the rows as an aligned text table or JSON. Statements containing INSERT, UPDATE, DELETE, DROP, ALTER, CREATE, EXEC, EXECUTE, TRUNCATE or MERGE are rejected, and the query must start with SELECT. Use read_table_contents for a plain table read and describe_database_table to learn the field names. Needs data preview and table read authorization (S_TABU_DIS); returns at most maxRows rows.

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": {
      "sql": "<sql>"
    },
    "name": "execute_data_query"
  }
}

Input Schema

Name	Required	Description
`sql`	Yes	ABAP SQL SELECT statement starting with SELECT (e.g. SELECT matnr, mtart FROM mara WHERE mtart = 'FERT' UP TO 10 ROWS, or SELECT * FROM t001w). Table names are those of the ABAP dictionary.
`format`	No	table (default): aligned text, cells cut at 50 characters. json: { columns, rows } with every value in full
`maxRows`	No	Maximum rows to return (default: 100)
`connectionId`	No	SAP system connection ID

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.16.2Nov 12, 2026

changedInput schema / properties / sql / description

Previous value: -"SQL SELECT statement (e.g. SELECT * FROM MARA WHERE MATNR LIKE 'Z%' UP TO 100 ROWS)"New value: +"ABAP SQL SELECT statement starting with SELECT (e.g. SELECT matnr, mtart FROM mara WHERE mtart = 'FERT' UP TO 10 ROWS, or SELECT * FROM t001w). Table names are those of the ABAP dictionary."

First observedv1.16.0Nov 12, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint=true, so the safety profile is covered; the description adds genuinely useful context beyond that: the S_TABU_DIS authorization requirement, the keyword blacklist enforcement, the mandatory SELECT prefix, and a row cap. It stops short of describing result-set edge cases or error behavior, which keeps it at 4 rather than 5.

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?

Three tight sentences, front-loaded with what the tool does, then constraints, then alternatives and prerequisites. Every clause carries operational information; nothing is redundant with the title or restates the name.

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?

With no output schema, the description correctly explains both return formats and the row cap, and it covers auth and SQL restrictions for a 4-parameter query tool. Minor gap: it does not describe error responses for rejected statements or per-connection behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds dialect framing ("ABAP SQL, as in the ADT data preview") and notes that table names are ABAP dictionary names, which helps an agent construct a valid sql value. It adds nothing beyond the schema for format, maxRows, or connectionId, which are already fully documented.

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 ("Run one freestyle SELECT ... against dictionary tables or CDS views") plus the return shape (aligned text table or JSON), and explicitly contrasts itself with read_table_contents and describe_database_table, so an agent can distinguish it from siblings without opening their schemas.

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

Usage Guidelines5/5

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

Gives explicit routing: use read_table_contents for a plain table read and describe_database_table to learn field names, implying this tool is for freestyle/ad-hoc queries. It also states hard exclusions (must start with SELECT; INSERT/UPDATE/DELETE/DROP/ALTER/CREATE/EXEC/TRUNCATE/MERGE rejected), which is concrete when-not guidance.

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

Deploy Server