Skip to main content
Glama
ClementRingot

ADAM

by ClementRingot
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Find ABAP objects

abap_search
Read-onlyIdempotent

Find ABAP repository objects by name, prefix, or wildcard pattern across any type—classes, CDS views, service bindings, programs—and return each object's exact name, type, package, and description.

Instructions

Find repository objects of any type by name, name start or pattern: classes, interfaces, programs and includes, function groups and modules, CDS views, behavior definitions, service definitions and bindings, UI5 apps… — each with its exact name, type, what it is, package and description. E.g. the service binding and definition behind a Fiori app (then the CDS views and behavior pools they lead to), or the unit-test class to use as triggerName.

Input Schema

NameRequiredDescriptionDefault
queryYesObject name or its start (ZUI_TRAVEL also finds ZUI_TRAVEL_O4), or a pattern with * anywhere (*TRAVEL*). Case-insensitive; exact names come first.
typesNoOnly these types, e.g. ["SRVB", "SRVD"] for the service binding and definition behind a Fiori app, ["CLAS"], ["PROG"], ["DDLS", "BDEF"]. Slash types such as PROG/I (includes) work too. Default: every type.
packageNoOnly objects of this package, or of the packages a pattern with * matches (ZTRAVEL*).
maxResultsNoAt most this many results (default 30).
includeTechnicalNoAlso list the objects SAP generates around an OData service (IWMO, IWSG, OA2S, SIA6, STOB, …), left out by default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, and open-world behavior. The description adds useful return-value context ('exact name, type, what it is, package and description') and search examples, though it does not discuss rate limits, auth, or pagination.

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?

The definition is front-loaded and has only two sentences, but the first sentence is a dense enumeration of object types and return fields. The examples earn their place, though the description could be slightly easier to scan.

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?

Given rich annotations, full schema coverage, and no output schema, the description supplies what an agent needs: search scope, object-type coverage, return fields, and representative use cases. Nothing essential for correct invocation is missing.

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 schema already documents query patterns, type filtering, package filtering, maxResults, and includeTechnical. The description reiterates some query semantics but adds no meaningful parameter guidance beyond the schema.

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?

The description opens with a specific verb and resource: 'Find repository objects of any type by name...' and enumerates the object types covered. This makes the tool's scope clear and distinct from the debugging and source-code siblings.

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?

It provides concrete usage examples, such as finding the service binding and definition behind a Fiori app or the unit-test class to use as triggerName. It does not explicitly state when to use this instead of abap_source or another sibling, but the discovery context is clear.

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