No user-submitted related servers found.
Scored across 256 tools
The type-prefixed tools (CheckClass, CheckTable, GetDdl, ...) are cleanly distinct from one another, but the surface is duplicated by generic twins: GetClassVersions/GetTableVersions/... coexist with GetObjectVersions, ActivateClass/ActivateTable with ActivateObjects, and GetObjectInfo/GetObjectStructure/GetObjectsList/GetObjectsByType/GetPackageContents/GetPackageTree all traverse or flatten repository trees with subtly different semantics. An agent must read long descriptions to pick between the generic and per-type variant, and the Debug* vs AmdpDebug* parallel families add further near-collisions. Descriptions do help disambiguate, but the tool set itself offers many equally valid routes to the same answer.
The dominant pattern is consistent CamelCase VerbNoun with stable verb semantics: Get/Create/Update/Delete/Check/Activate/List/Run + ObjectType. Deviations are minor: ReadTransportObjects and ReadTransportActionLog use 'Read' where peers use 'Get', the MemorySnapshotGet/MemorySnapshotList/MemorySnapshotDelta family is noun-first, and BatchBegin/DebugBatchBegin/AmdpDebugStart use three different phrasings for starting a batch. Still predictable enough that an agent can guess a name.
256 tools is far past any usable working set for an agent and much of the volume is mechanical multiplication of the same six verbs across ~20 object types plus four debugger families and two batch systems. The generic tools already present (GetObjectVersions, GetObjectVersionSource, ActivateObjects, DescribeByList) prove that per-type variants could be collapsed substantially. The domain is genuinely broad, which earns some leniency, but the surface is bloated well beyond what earns its place.
Coverage is exhaustive: full create/read/update/delete/activate/syntax-check cycles for classes, programs, interfaces, function groups and modules, tables, structures, CDS views, behavior definitions and implementations, metadata extensions, service definitions and bindings, domains, data elements, message classes, packages, and transports, plus version history and diffs, unit tests, ATC, debugging, runtime dumps/profiler, search, where-used, and session hygiene. No obvious dead ends for an ABAP development workflow.