Skip to main content
Glama
Sign In
abap-config-mcp

abap-config-mcp

by netweaver1970
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Search ABAP Objects

search_abap_objects
Read-onlyIdempotent

Find ABAP repository objects by name or wildcard and get type, description and ADT URL for each hit, so you can resolve the object URL needed for reading source or where-used.

Instructions

Search ABAP repository objects by name or wildcard pattern and return type, name, description and ADT URL for each hit. Use it to find the URL that get_abap_object_lines, write_abap_object_source or where_used need; use browse_package to list a package instead, search_abap_object_lines to search inside source, and search_database_tables for tables by keyword. Read-only; at most maxResults hits (default 50).

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": {
      "query": "<query>"
    },
    "name": "search_abap_objects"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYesObject name or pattern; * is the wildcard (e.g. ZCL_ORDER*, *_ORDER_*)
maxResultsNoMax results (default 50)
objectTypeNoRestrict to one ADT object type: PROG, CLAS, FUGR, TABL, DTEL, DOMA, INTF, TRAN, etc. Default: all types
connectionIdNoSAP system connection ID from connected_systems (default connection if omitted)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.16.2
    • changedInput schema / properties / connectionId / description
      Previous value: -"SAP system connection ID (uses first if omitted)"New value: +"SAP system connection ID from connected_systems (default connection if omitted)"
    • changedInput schema / properties / objectType / description
      Previous value: -"ABAP object type filter: PROG, CLAS, FUGR, TABL, DTEL, DOMA, INTF, TRAN, etc."New value: +"Restrict to one ADT object type: PROG, CLAS, FUGR, TABL, DTEL, DOMA, INTF, TRAN, etc. Default: all types"
    • changedInput schema / properties / query / description
      Previous value: -"Search query - name or wildcard pattern (e.g. Z_MY_PROG*, *_ORDER*)"New value: +"Object name or pattern; * is the wildcard (e.g. ZCL_ORDER*, *_ORDER_*)"
  2. First observedv1.16.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the description need not restate safety. It still adds real value by disclosing the result fields returned (since there is no output schema) and the result ceiling ('at most maxResults hits'), which annotations do not convey. It stops short of describing ordering or truncation behavior when a wildcard matches more than maxResults.

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 sentences, front-loaded with what it does and returns, followed by routing guidance. Every clause maps to a decision an agent must make; there is no filler or restated naming.

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

Completeness5/5

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

With no output schema present, the description supplies the return fields and the result cap, and the annotations carry the read-only/idempotent profile. An agent has enough to call it correctly and to know where to go next with the returned URL.

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 already documents query wildcard syntax, maxResults default, objectType values and connectionId. The description only reiterates the default result count, adding no syntax or semantics beyond the schema; baseline 3 applies.

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 ('Search ABAP repository objects'), the matching semantics ('by name or wildcard pattern'), and the return shape (type, name, description, ADT URL per hit). This clearly separates it from search_abap_object_lines and search_database_tables, which search different things.

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?

Explicitly says when to use it (to obtain the URL that get_abap_object_lines, write_abap_object_source and where_used need) and names three alternatives with the condition that selects each: browse_package for package listing, search_abap_object_lines for source search, search_database_tables for keyword table lookup.

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