Provides tools for searching ABAP objects, retrieving source code and DDIC metadata, previewing data, and accessing runtime diagnostics via SAP ADT services.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-abap-adt find classes related to customer management"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
SAP ABAP ADT용 MCP 서버 - ADT(ABAP Development Tools) 서비스를 통해 SAP ABAP 메타데이터, 소스 코드, 진단 정보를 통합적으로 제공하는 경량 Model Context Protocol(MCP) 어댑터입니다.
🔍 ABAP 객체 검색 - 클래스, 프로그램, 인터페이스 등 다양한 객체를 검색합니다.
📖 소스 코드 조회 - ABAP 클래스, 프로그램, 함수 모듈, include를 확인합니다.
🗂️ DDIC 메타데이터 - 테이블 구조, CDS 뷰, 데이터 요소, 도메인을 조회합니다.
📊 데이터 미리보기 - DDIC 엔터티의 실제 데이터를 미리 봅니다.
🔧 런타임 진단 - ABAP trace와 runtime dump 분석에 접근합니다.
🧪 ATC 품질 검사 - ATC(ABAP Test Cockpit) 실행 결과 목록과 상세 findings를 조회합니다.
🚀 이중 모드 지원 - stdio(MCP 표준)와 HTTP/SSE를 모두 지원합니다.
🐳 Docker 지원 - 배포용 컨테이너 이미지를 제공합니다.
🔐 유연한 인증 - Basic Auth, 헤더 기반 인증, 환경 변수 인증을 지원합니다.
Related MCP server: dassian-adt
Node.js ≥ 18 (운영 환경에는 Node.js 22 LTS 권장)
npm (Node.js에 포함)
TypeScript (devDependencies로 설치됨)
ADT 서비스가 활성화된 SAP 시스템
# 저장소 복제
git clone https://github.com/workskong/mcp-abap-adt.git
cd mcp-abap-adt
# 의존성 설치
npm ci
# TypeScript 빌드
npm run build
# 환경 템플릿 복사(선택 사항)
cp .env.example .envnpm start이 모드는 MCP 표준 방식으로 stdio를 통해 서버를 실행하며, MCP 클라이언트와 inspector에 적합합니다.
# 필요한 환경 변수 설정
$env:PORT = '6969'
# SSE 지원이 포함된 HTTP 서버 시작
npm run start-remote원격 모드는 웹 기반 클라이언트를 위해 HTTP 엔드포인트와 Server-Sent Events를 제공합니다.
npm run dev디버깅과 개발을 위해 MCP inspector와 함께 실행됩니다.
HTTP/SSE 모드(--remote)로 실행하면 다음 엔드포인트를 사용할 수 있습니다.
Method | Endpoint | Description | Content-Type |
🟢 GET |
| 서버 상태 및 헬스 정보 |
|
📋 GET |
| 사용 가능한 모든 도구와 스키마 목록 |
|
🔧 POST |
| 이름으로 도구 실행 |
|
📡 GET |
| 실시간 업데이트용 Server-Sent Events 스트림 |
|
🧪 POST |
| 테스트용 SSE 이벤트 전송(개발 전용) |
|
🔌 POST |
| 대체 MCP JSON-RPC 엔드포인트 |
|
서버는 여러 인증 방식을 지원합니다.
Basic Authentication - 표준 HTTP Basic Auth 헤더 사용
사용자 정의 헤더 - 일반 인증에 X-Username/X-Password 사용
SAP 헤더 - SAP 전용 인증에 X-SAP_USERNAME/X-SAP_PASSWORD 사용
환경 변수 - stdio 모드에서 환경 변수로 자격 증명 설정
아래 예시는 MCP 클라이언트(VS Code, Eclipse)를 위한 설정 예시입니다. 실제 자격 증명은 그대로 사용하고, 예시에서는 플레이스홀더를 사용합니다.
{
"inputs": [
{ "id": "SAP_USERNAME", "type": "promptString", "description": "SAP Username", "password": false },
{ "id": "SAP_PASSWORD", "type": "promptString", "description": "SAP Password", "password": true },
{ "id": "SAP_CLIENT", "type": "promptString", "description": "SAP Client", "password": false },
{ "id": "SAP_LANGUAGE", "type": "promptString", "description": "SAP Language", "password": false },
{ "id": "SAP_URL", "type": "promptString", "description": "SAP URL", "password": false }
],
"servers": {
"mcp-abap-adt": {
"type": "sse",
"url": "http://localhost:6969",
"headers": {
"X-SAP_USERNAME": "${input:SAP_USERNAME}",
"X-SAP_PASSWORD": "${input:SAP_PASSWORD}",
"X-SAP_CLIENT": "${input:SAP_CLIENT}",
"X-SAP_LANGUAGE": "${input:SAP_LANGUAGE}",
"X-SAP_URL": "${input:SAP_URL}"
}
}
}
}{
"servers": {
"mcp-abap-adt": {
"type": "stdio",
"command": "node",
"cwd": "C:/Users/{...}/Documents/mcp-abap-adt",
"args": [
"C:/Users/{...}/Documents/mcp-abap-adt/dist/index.js"
],
"env": {
"SAP_USERNAME": "DEV00",
"SAP_PASSWORD": "XXXX",
"SAP_CLIENT": "001",
"SAP_LANGUAGE": "EN",
"SAP_URL": "http://your-sap-server:50000"
}
}
}
}이 예시들은 HTTP 기반 SSE 원격 연결 또는 서버를 자식 프로세스로 실행해 stdio로 통신하는 로컬 연결을 보여줍니다. 빌드 후 dist/index.js가 존재해야 합니다.
{
"servers": {
"mcp-abap-adt": {
"url": "http://localhost:6969",
"requestInit": {
"headers": {
"X-SAP_USERNAME": "DEV00",
"X-SAP_PASSWORD": "XXXX",
"X-SAP_CLIENT": "001",
"X-SAP_LANGUAGE": "EN",
"X-SAP_URL": "http://your-sap-server:50000"
}
}
}
}
}{
"servers": {
"mcp-abap-adt": {
"type": "stdio",
"command": "node",
"cwd": "C:/Users/{...}/Documents/mcp-abap-adt",
"args": [
"C:/Users/{...}/Documents/mcp-abap-adt/dist/index.js"
],
"env": {
"SAP_USERNAME": "DEV00",
"SAP_PASSWORD": "XXXX",
"SAP_CLIENT": "001",
"SAP_LANGUAGE": "EN",
"SAP_URL": "http://your-sap-server:50000"
}
}
}
}Eclipse는 원격 HTTP 래퍼에 연결하거나, 서버를 직접 실행해 stdio로 통신할 수 있습니다.
참고:
원격 모드에서는 클라이언트가 연결하기 전에 --remote와 PORT(예: 6969)를 지정해 서버를 먼저 실행해야 합니다.
stdio 모드에서는 TypeScript 빌드 결과물인 dist/index.js가 생성되어 있어야 하며, Node.js 18+가 PATH에 있어야 합니다.
docker build -t mcp-abap-adt:latest .기본 HTTP/SSE 모드:
docker run --rm \
-e PORT=6969 \
-e TLS_REJECT_UNAUTHORIZED=0 \
-p 6969:6969 \
mcp-abap-adt:latestSAP 연결 포함:
docker run --rm \
-e PORT=6969 \
-e SAP_URL="http://your-sap-server:50000" \
-e TLS_REJECT_UNAUTHORIZED=0 \
-p 6969:6969 \
mcp-abap-adt:latest환경 파일 사용:
docker run --rm \
--env-file .env \
-p 6969:6969 \
mcp-abap-adt:latest이 Docker 이미지는 서버 상태를 감시하는 자동 헬스 체크를 포함합니다. 서버가 연결을 받을 준비가 되면 컨테이너는 healthy 상태가 됩니다.
Variable | Required | Default | Description |
| Yes (remote mode) |
| HTTP 서버 포트 |
| No |
| 실행 환경( |
| No |
| TLS 인증서 검증(0=비활성화, 1=활성화) |
| Yes | - | ADT 서비스가 활성화된 SAP ABAP 서버 URL |
| No | - | SAP 사용자명(함수 파라미터가 없을 때 대체값) |
| No | - | SAP 비밀번호(함수 파라미터가 없을 때 대체값) |
| No | - | SAP 클라이언트 번호(함수 파라미터가 없을 때 대체값) |
| No |
| 기본 SAP 언어(함수 파라미터가 없을 때 대체값) |
Windows PowerShell:
$env:PORT = "6969"
$env:SAP_URL = "https://your-sap-server.company.com:8000"
$env:SAP_USERNAME = "your_username"
$env:SAP_PASSWORD = "your_password"
$env:SAP_CLIENT = "100"
$env:SAP_LANGUAGE = "EN"
$env:TLS_REJECT_UNAUTHORIZED = "0"Linux/macOS:
export PORT=6969
export SAP_URL="https://your-sap-server.company.com:8000"
export SAP_USERNAME="your_username"
export SAP_PASSWORD="your_password"
export SAP_CLIENT="100"
export SAP_LANGUAGE="EN"
export TLS_REJECT_UNAUTHORIZED=0.env 파일 사용:
cp .env.example .env
# .env 파일에 SAP 연결 정보를 입력서버는 다음 우선순위로 여러 인증 방법을 지원합니다.
함수 파라미터 - 가장 높은 우선순위(각 도구 호출에 직접 전달)
환경 변수 - 함수 파라미터가 비어 있을 때 대체
헤더 - 원격 HTTP 모드에서 요청별 인증에 사용
SAP 인증 파라미터(_sapUsername, _sapPassword, _sapClient, _sapLanguage)가 함수 호출에 전달되지 않으면, 서버는 자동으로 환경 변수 값을 사용합니다. 이를 통해 자격 증명을 한 번만 환경에 설정해도 다양한 배포 방식에 대응할 수 있습니다.
이 서버는 SAP ABAP 시스템에 대한 포괄적인 접근을 위해 24개의 도구를 제공합니다. 각 도구의 상세 입력 스키마는 /tools 엔드포인트에서 확인할 수 있습니다.
Tool | Description | Key Parameters |
| 시스템 전반에서 ABAP 객체 검색 |
|
| ADT 객체의 API 릴리스 정보 조회 |
|
Tool | Description | Key Parameters |
| ABAP 클래스 소스 코드 조회 |
|
| ABAP 프로그램 소스 코드 조회 |
|
| 함수 모듈 소스 조회 |
|
| 함수 그룹 소스 조회 |
|
| ABAP include 소스 조회 |
|
| ABAP 인터페이스 소스 조회 |
|
| ABAP 트랜잭션 정보 조회 |
|
Tool | Description | Key Parameters |
| 데이터베이스 테이블 정의 조회 |
|
| CDS 뷰 정의 조회 |
|
| DDIC 구조 정의 조회 |
|
| 데이터 요소 정의 조회 |
|
| 도메인 정의 조회 |
|
| DDIC 타입 정보 조회 |
|
Tool | Description | Key Parameters |
| DDIC 엔터티의 실제 데이터 미리보기 |
|
| 패키지 정보 및 내용 조회 |
|
| 메시지 클래스 정보 조회 |
|
Tool | Description | Key Parameters |
| ABAP runtime dump 목록 조회 |
|
| runtime dump 상세 정보 조회 |
|
| ABAP 성능 trace 데이터 조회 |
|
| ABAP trace 상세 정보 조회 |
|
Tool | Description | Key Parameters |
| ATC 실행 결과 목록 조회. |
|
| 특정 ATC 결과의 상세 findings 조회 (우선순위·체크항목·위치 포함) |
|
💡 ATC 사용 예시:
Get_ATC_ResultList로 결과 ID를 먼저 확인한 뒤, 해당 ID로Get_ATC_ResultDetail을 호출해 구체적인 findings를 조회합니다.
💡 팁:
GET /tools를 사용하면 각 도구의 JSON 스키마가 포함된 전체 목록을 확인할 수 있습니다.
PowerShell(Windows):
# ABAP 객체 검색
Invoke-RestMethod -Uri http://localhost:6969/call -Method POST `
-Headers @{
"X-SAP_USERNAME"="DEV00"
"X-SAP_PASSWORD"="your-password"
"X-SAP_URL"="http://your-sap-server:50000"
"Content-Type"="application/json"
} `
-Body (@{
tool="SearchObject"
arguments=@{ query="SBOOK"; maxResults=10 }
} | ConvertTo-Json -Compress)
# ABAP 클래스 소스 조회
Invoke-RestMethod -Uri http://localhost:6969/call -Method POST `
-Headers @{
"X-SAP_USERNAME"="DEV00"
"X-SAP_PASSWORD"="your-password"
"X-SAP_URL"="http://your-sap-server:50000"
} `
-Body (@{
tool="Get_Class"
arguments=@{ class_name="CL_ABAP_CHAR_UTILITIES" }
} | ConvertTo-Json)curl(Linux/macOS):
# 테이블 구조 조회
curl -X POST http://localhost:6969/call \
-H "X-SAP_USERNAME: DEV00" \
-H "X-SAP_PASSWORD: your-password" \
-H "X-SAP_URL: http://your-sap-server:50000" \
-H "Content-Type: application/json" \
-d '{
"tool": "GetDDIC_Table",
"arguments": {
"object_name": "SBOOK"
}
}'
# 테이블 데이터 미리보기
curl -X POST http://localhost:6969/call \
-H "X-SAP_USERNAME: DEV00" \
-H "X-SAP_PASSWORD: your-password" \
-H "X-SAP_URL: http://your-sap-server:50000" \
-H "Content-Type: application/json" \
-d '{
"tool": "DataPreview",
"arguments": {
"ddicEntityName": "SBOOK",
"rowNumber": 50
}
}'
# ATC 결과 목록 조회 (최근 14일)
curl -X POST http://localhost:6969/call \
-H "X-SAP_USERNAME: DEV00" \
-H "X-SAP_PASSWORD: your-password" \
-H "X-SAP_URL: http://your-sap-server:50000" \
-H "Content-Type: application/json" \
-d '{
"name": "Get_ATC_ResultList",
"arguments": {
"scope": "local",
"period": "older",
"maxResults": 10
}
}'
# ATC 결과 상세 조회 (위 결과에서 얻은 displayId 사용)
curl -X POST http://localhost:6969/call \
-H "X-SAP_USERNAME: DEV00" \
-H "X-SAP_PASSWORD: your-password" \
-H "X-SAP_URL: http://your-sap-server:50000" \
-H "Content-Type: application/json" \
-d '{
"name": "Get_ATC_ResultDetail",
"arguments": {
"id": "BE5D9646474E1FE1A2B8B41723C198A6",
"includeExemptedFindings": false
}
}'JavaScript/Node.js:
const axios = require('axios');
const client = axios.create({
baseURL: 'http://localhost:6969',
headers: {
'X-SAP_USERNAME': 'DEV00',
'X-SAP_PASSWORD': 'your-password',
'X-SAP_URL': 'http://your-sap-server:50000',
'Content-Type': 'application/json'
}
});
async function getProgram(programName) {
const response = await client.post('/call', {
tool: 'Get_Program',
arguments: {
program_name: programName
}
});
return response.data;
}
// 사용 예시
getProgram('YSAPBC_DATA_GENERATOR')
.then(result => console.log(result))
.catch(error => console.error(error));# 의존성 설치
npm ci
# TypeScript 빌드
npm run build
# 테스트 실행
npm test
# 개발용 MCP inspector로 시작
npm run dev
# 개발 중 watch 모드 실행
npm run build -- --watch# 전체 테스트 실행
npm test
# watch 모드로 테스트 실행
npm run test -- --watch
# 커버리지 포함 테스트 실행
npm run test -- --coverage새로운 ABAP 기능을 추가하려면 다음 단계를 따르세요.
핸들러 생성 - src/handlers/에 새 핸들러 파일을 추가합니다.
// src/handlers/handle_MyNewTool.ts
export async function handleMyNewTool(args: any, config: SapConfig) {
// 구현 내용
return { result: "success" };
}핸들러 내보내기 - src/lib/handlerExports.ts에 추가합니다.
export * as handle_MyNewTool from '../handlers/handle_MyNewTool';도구 정의 - src/lib/toolDefinitions.ts에 정의를 추가합니다.
{
name: 'MyNewTool',
description: '이 도구가 수행하는 작업 설명',
inputSchema: {
type: 'object',
properties: {
param1: { type: 'string', description: '파라미터 설명' }
},
required: ['param1']
},
handler: handlers.handle_MyNewTool.handleMyNewTool
}빌드 및 테스트
npm run build
npm testmcp-abap-adt/
├── src/
│ ├── handlers/ # 도구 구현 핸들러
│ └── lib/
│ ├── config.ts # 설정 관리
│ ├── toolDefinitions.ts # 도구 스키마 및 라우팅
│ ├── handlerExports.ts # 핸들러 export
│ ├── remoteServer.ts # HTTP/SSE 서버
│ ├── utils.ts # 유틸리티 함수
│ └── mcpErrorHandler.ts # 에러 처리
├── tests/ # 통합 테스트
├── dist/ # 컴파일된 TypeScript 출력물
├── index.ts # 메인 서버 진입점
├── Dockerfile # 컨테이너 설정
└── package.json # 의존성과 스크립트🚫 PORT 필요 오류
Error: PORT environment variable is required for remote mode해결 방법:
# Windows PowerShell
$env:PORT = "6969"
# Linux/macOS
export PORT=6969🌐 SAP URL 누락
Error: SAP_URL is required해결 방법: 환경 변수 또는 요청 헤더를 통해 SAP URL을 제공하세요.
# 환경 변수
export SAP_URL="http://your-sap-server:50000"
# 또는 요청 시 X-SAP_URL 헤더 사용
curl -H "X-SAP_URL: http://your-sap-server:50000" ...🔐 인증 실패
Error: 401 Unauthorized해결 방법:
Basic Auth 사용: Authorization: Basic <base64(username:password)>
사용자 정의 헤더 사용: X-SAP_USERNAME, X-SAP_PASSWORD
SAP 사용자 권한이 ADT 접근을 허용하는지 확인
🏥 컨테이너 헬스 체크 문제
Container unhealthy해결 방법:
PORT 환경 변수가 설정되어 있는지 확인
컨테이너 로그 확인: docker logs <container-id>
SAP 시스템 연결 상태 확인
📦 빌드/런타임 오류
Module not found or TypeScript compilation errors해결 방법:
# 정리 후 재빌드
rm -rf dist/ node_modules/
npm ci
npm run build
# Node.js 버전 확인(≥18 필요)
node --version🔗 연결 타임아웃
Error: connect ETIMEDOUT해결 방법:
SAP 시스템에 접근 가능한지 확인
네트워크 연결과 방화벽 설정 확인
SAP 시스템에서 ADT 서비스가 활성화되어 있는지 확인
자체 서명 인증서를 사용하는 경우 TLS_REJECT_UNAUTHORIZED=0으로 설정
✅ Node.js ≥ 18 설치됨
✅ TypeScript가 컴파일됨(dist/ 폴더 존재)
✅ 환경 변수가 올바르게 설정됨
✅ SAP 시스템 접근 가능 및 ADT 활성화됨
✅ 인증 정보가 유효함
✅ 네트워크 연결 정상(프록시/방화벽 차단 없음)
아래 방법으로도 해결되지 않으면 다음을 확인하세요.
로그 확인 - NODE_ENV=development로 디버그 로깅 활성화
설정 재검토 - 모든 환경 변수와 헤더 값 검증
SAP 연결 테스트 - ADT 서비스가 직접 응답하는지 확인
이슈 등록 - 로그와 설정 정보를 포함해 GitHub 이슈를 생성
MIT License - 자세한 내용은 LICENSE 파일을 확인하세요.
기여를 환영합니다. Pull Request를 자유롭게 제출해 주세요. 큰 변경의 경우, 먼저 이슈를 열어 변경 내용을 논의해 주세요.
저장소를 포크
기능 브랜치 생성 (git checkout -b feature/amazing-feature)
변경 사항 작성 및 테스트 추가
테스트 실행 (npm test)
커밋 생성 (git commit -m 'Add amazing feature')
브랜치 푸시 (git push origin feature/amazing-feature)
Pull Request 열기
Repository: https://github.com/workskong/mcp-abap-adt
NPM Package: @orchestraight.co/mcp-abap-adt
Model Context Protocol: https://modelcontextprotocol.io/
v1.3.3 - 최신 릴리스
Node.js 22 기반 Docker 지원 강화
에러 처리 및 진단 개선
포괄적인 도구 카탈로그 추가
SAP ABAP 커뮤니티를 위해 ❤️로 만들었습니다
Retrieve API Release information for an ADT object
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ADT object search query (e.g. SBOOK, C_GREGORIANCALSGLDATEFUNCVH) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as read-only status, required permissions, pagination, or response format. The single line does not suffice for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence), but it lacks structure or front-loading of key details. It is adequate but not well crafted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with no output schema, the description should at least hint at the return format or purpose of the release information. It does not, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a description that includes examples. The tool description adds no further meaning, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves 'API Release information for an ADT object', which is a specific verb+resource combination that distinguishes it from sibling tools that deal with other ABAP object details. However, it is somewhat vague on what qualifies as an ADT object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like Get_Class or Get_Function. Given the many sibling tools, explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview ABAP data for a DDIC entity
| Name | Required | Description | Default |
|---|---|---|---|
| rowNumber | No | Number of rows to retrieve | |
| ddicEntityName | Yes | DDIC entity name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral info. It does not disclose that the operation is read-only, what happens if the entity does not exist, the output format, or any rate limits. The description adds minimal value beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only one sentence. However, it lacks essential information; brevity at the expense of completeness reduces effectiveness. Still, it is well-structured with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema, no annotations), the description is incomplete. It does not mention the output format (e.g., JSON array), pagination, or any limitations. A preview tool should describe what the agent gets back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents both parameters. The description does not add meaning beyond the schema, such as explaining that rowNumber has a default or that ddicEntityName is the case-sensitive name. Baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Preview', resource 'ABAP data', and target 'DDIC entity'. It distinguishes from sibling tools that focus on metadata (e.g., GetDDIC_Table, GetDDIC_Structure) by indicating this tool retrieves actual data rows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not tell when to use this tool over alternatives like GetDDIC_Table or GetDDIC_Structure, nor does it mention prerequisites or typical contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve ABAP Trace (performance) information
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | User ID | DEV00 |
| maxResults | No | Max results | |
| objectNameFilter | No | Object name filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Retrieve', implying a read-only operation, but fails to mention any authentication requirements, rate limits, or what information the trace contains. For a performance tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. However, it may be too brief given the complexity of the tool and lack of annotations, sacrificing informational value for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is severely lacking. It does not explain what the output looks like, how results are ordered, or what 'ABAP Trace (performance) information' entails. Users must infer from the parameter names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions already present. The tool description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Retrieve) and resource (ABAP Trace (performance) information). However, it does not differentiate from the sibling tool Get_ABAPTracesDetails, leaving ambiguity about whether this tool returns a list or summary vs. details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its many siblings (e.g., Get_ABAPTracesDetails, GetRuntimeDumps). The description lacks any context about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve detailed ABAP Trace information
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Trace id | |
| type | Yes | Trace type (dbAccesses, hitlist, statements) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only states the action without disclosing side effects, permissions, or limitations. As a read operation, minimal transparency is acceptable but not informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no wasted words. However, could be more structured to separate key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has simple params and no output schema; description explains the core purpose but lacks details about return data or behavior, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so params are well-documented. The description adds no extra meaning beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Retrieve' and resource 'detailed ABAP Trace information', clearly indicating it gets detailed data. It distinguishes from the sibling Get_ABAPTraces (likely listing traces) by implying details, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when or when not to use this tool vs alternatives like Get_ABAPTraces. Missing context about prerequisites or comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve detailed ATC (ABAP Test Cockpit) findings for a specific result entry by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ATC result ID (e.g. BE5D9646474E1FE1A2B8D4FAB25918A6) | |
| activeResult | No | Whether to retrieve only active results. Default: false | |
| contactPerson | No | Contact person filter (* = any). Default: * | |
| includeExemptedFindings | No | Include exempted findings. Default: false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the basic retrieval action. With no annotations provided, the description carries the full burden. It omits critical details such as whether the tool is read-only, error behavior for invalid IDs, and response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the tool's purpose. Every word is necessary, and no extraneous information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is insufficiently complete. It does not explain the format of returned findings, pagination (if any), or error states. A retrieval tool for detailed results should provide more context about what the details contain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are described in the input schema (100% coverage), so the schema already provides clear meaning. The tool description adds no additional semantics beyond what the schema provides, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve', the specific resource 'detailed ATC (ABAP Test Cockpit) findings', and the method 'by its ID'. It effectively distinguishes the tool from its sibling 'Get_ATC_ResultList' which retrieves a list of result entries without details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like Get_ATC_ResultList or other retrieval tools. It does not specify prerequisites, when to choose this tool, or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve ATC (ABAP Test Cockpit) result list. Use scope=central for central hub results or scope=local for local system results. Filter by period (today/yesterday/older), createdBy, and contactPerson.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Result scope: "central" (central ATC hub) or "local" (local system). Default: local | |
| period | No | Time period filter. today=ageMin/Max 0, yesterday=1, older=2-14 days. Default: today | |
| createdBy | No | Filter by user who created the ATC run (* = any). Default: * | |
| maxResults | No | Maximum number of results to return (default 20, max 50) | |
| contactPerson | No | Filter by contact person responsible for findings (* = any). Default: * |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It indicates a read operation ('retrieve') but does not mention side effects, permissions, rate limits, or pagination details beyond maxResults. Sufficient but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences with front-loaded purpose. Every word adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core functionality and key parameters. However, with no output schema and no annotations, it could describe the return format or behavior (e.g., 'returns a list of result IDs'). Adequate for a simple list retrieval but not overly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the existing parameter descriptions are comprehensive. The description adds little beyond what is in the schema (e.g., 'Filter by period...' is already covered). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the ATC result list, with specific scopes and filters. However, it does not explicitly differentiate from the sibling Get_ATC_ResultDetail tool, which likely provides individual result details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on using scope=central vs local, and lists filters. However, it lacks explicit when-to-use vs when-not-to-use compared to sibling tools, and no prerequisites or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve ABAP class source code
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes | Class name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description indicates a read operation but provides no details about authentication, side effects, rate limits, or expected behavior beyond retrieval. With no annotations, the description carries full burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. Highly efficient and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter, the description adequately conveys the action and resource. Could optionally mention output format or scope, but not strictly necessary given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description ('Class name') matches the schema. No additional semantics or constraints are provided, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the specific verb 'Retrieve' and resource 'ABAP class source code', distinguishing it from sibling tools like Get_Function, Get_Program, etc. that target different ABAP objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives or prerequisites. Given the many sibling tools, explicit usage context would help an agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve CDS view definition
| Name | Required | Description | Default |
|---|---|---|---|
| object_name | Yes | CDS view name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It does not state that the operation is read-only, require any authorization, or disclose any side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single, concise sentence with no redundant words. It effectively communicates the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should clarify what the retrieved definition includes (e.g., fields, annotations). It does not, leaving the agent uncertain about the return value's structure and content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter object_name, which is described as 'CDS view name'. The description adds no extra meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve CDS view definition' clearly states the action (retrieve) and the resource (CDS view definition), distinguishing it from siblings like GetDDIC_Table or GetDDIC_Structure, though it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., GetDDIC_Table for tables, GetDDIC_Structure for structures). The description does not mention context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve data element definition
| Name | Required | Description | Default |
|---|---|---|---|
| object_name | Yes | Data element name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It merely states the action ('Retrieve') without confirming it is read-only, safe, or any side effects. The agent gets no insight into behavior beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just one sentence, with no wasted words. However, it is perhaps too brief, missing opportunities to add useful context while remaining efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and sibling tools, the description should provide hints about return values or usage context. It does neither, leaving the tool underdefined for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, object_name, which is described as 'Data element name'. The description adds no extra meaning or formatting details, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve data element definition' clearly states the verb (Retrieve) and resource (data element definition), making the purpose obvious. However, it does not distinguish this tool from similar siblings like GetDDIC_Table or GetDDIC_Structure, which also retrieve definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or context, leaving the agent to guess when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve domain definition
| Name | Required | Description | Default |
|---|---|---|---|
| object_name | Yes | Domain name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility. It only states 'Retrieve', implying read-only behavior, but does not confirm or disclose other traits like error handling, permission requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is efficient for a simple retrieval tool, though slightly more detail could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is minimally adequate. However, given the many sibling tools and lack of usage guidance, an agent may find it incomplete for confident selection and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage: 'object_name' is described as 'Domain name'. The description adds no extra meaning beyond the schema, which is acceptable given the coverage. No additional context like format or validation is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve domain definition' clearly identifies the verb (retrieve) and resource (domain definition). It sufficiently distinguishes from sibling tools (e.g., GetDDIC_Table) which target different object types. However, it does not elaborate on what a domain definition encompasses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. There is no indication of when to use this tool versus similar 'Get' siblings, nor any prerequisites or exclusions. This leaves the agent without guidance for correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve structure definition
| Name | Required | Description | Default |
|---|---|---|---|
| object_name | Yes | DDIC structure name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, the description is only 'Retrieve structure definition' and reveals nothing about side effects, permissions, rate limits, or the nature of the response. There is no indication of whether this is a read-only operation or what the output contains, leaving the agent completely in the dark.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at only two words, which is efficient but sacrifices necessary detail. It front-loads the key idea but omits any context that would help an agent understand its scope or relationship to sibling tools. It is concise but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description should provide more context about what the tool returns. For a retrieval tool for ABAP DDIC structures, an agent would need to know the structure of the response (e.g., fields, data elements). The description is incomplete and relies heavily on the tool name and param name for inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'object_name', described as 'DDIC structure name'. The description adds no additional detail beyond what the schema already provides, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve structure definition' clearly indicates the action (retrieve) and the resource (structure definition). However, it does not differentiate from sibling tools like GetDDIC_Table or GetDDIC_CDS, which also retrieve definitions of related DDIC objects. The purpose is clear but lacks specificity to distinguish among the many similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool versus alternatives such as GetDDIC_Table or GetDDIC_DataElements, nor does it mention any prerequisites or context for its use. An agent would have no guidance on selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve table definition
| Name | Required | Description | Default |
|---|---|---|---|
| object_name | Yes | Table name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. 'Retrieve table definition' does not explain if the operation is read-only, what data is returned, or any side effects. This is insufficient for a retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words, making it efficient. However, it could be slightly more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description fails to provide sufficient context. It does not clarify what a 'table definition' includes (e.g., columns, keys), leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with parameter 'object_name' described as 'Table name'. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve table definition' uses a specific verb and resource, clearly indicating the tool's purpose. It effectively distinguishes itself from sibling tools like Get_Class and GetDDIC_DataElements, which target different objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when or when not to use this tool. The naming convention and sibling list imply usage for table definitions but lack explicit alternatives or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve DDIC type information
| Name | Required | Description | Default |
|---|---|---|---|
| object_name | Yes | DDIC type name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It only says 'Retrieve', implying read-only, but no details on side effects, permissions, or other traits are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It is appropriately short but could benefit from more information without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not explain what information is returned. For a complex domain like DDIC, the description is insufficient for an agent to understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the sole parameter. The tool description adds no extra meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Retrieve' is clear, but the resource 'DDIC type information' is vague. With siblings like GetDDIC_DataElements and GetDDIC_Table, 'DDIC type' is ambiguous and not differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus the many sibling tools for specific DDIC objects. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve ABAP function module source code
| Name | Required | Description | Default |
|---|---|---|---|
| function_name | Yes | Function module name | |
| function_group | Yes | Function group name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Retrieve', implying a read operation, but lacks details on authentication, rate limits, error handling, or what happens if the function module does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the action. No redundant words; it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (2 params, no output schema), the description is minimally complete. However, it lacks explanation of the return value (e.g., source code as a string) and usage context, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond what is in the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' and resource 'ABAP function module source code'. It clearly distinguishes from sibling tools like Get_FunctionGroup by specifying 'source code'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, context, or situations where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve ABAP function group source code
| Name | Required | Description | Default |
|---|---|---|---|
| function_group | Yes | Function group name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only states 'Retrieve' but fails to mention if it's read-only, what the output format is, or any side effects. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words, but it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description should explain what the response contains (e.g., full source code as text). It leaves ambiguity about format and completeness, which is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes the 'function_group' parameter. The tool description adds no extra meaning beyond the schema, meeting the baseline but not enhancing it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve ABAP function group source code' uses a specific verb 'Retrieve' and clearly identifies the resource (function group source code), distinguishing it from siblings like Get_Function which retrieves individual functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as Get_Function or Get_Program. The description only states the action without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve ABAP include source code
| Name | Required | Description | Default |
|---|---|---|---|
| include_name | Yes | Include name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavioral traits. It only states the action without indicating that it is read-only, required permissions, or error handling. Some behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the tool's purpose. There is no wasted text, and it is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description is minimally adequate. However, it could be improved by specifying the return format or that it returns source code text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'include_name', so the schema already documents its purpose. The description adds no additional meaning beyond the schema's definition, yielding a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'Retrieve' and the resource 'ABAP include source code'. It effectively distinguishes this tool from siblings that retrieve other ABAP objects like classes, functions, or programs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or exclusions mentioned. The description lacks any contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve ABAP interface source code
| Name | Required | Description | Default |
|---|---|---|---|
| interface_name | Yes | Interface name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states 'Retrieve' (a read operation), but omits details such as required authorizations, potential errors, or effect on the system. The description is too minimal for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single phrase—and front-loaded with the key action. While it could benefit from slight expansion, every word currently earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and the presence of comprehensive schema documentation, the description adequately states the tool's purpose. However, the absence of output description (no output schema) leaves the agent uncertain about what is returned, pulling the score below 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the parameter 'interface_name' described as 'Interface name'. The description adds no additional meaning beyond what the schema provides, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve ABAP interface source code' provides a specific verb and resource, clearly distinguishing it from sibling tools like Get_Class, Get_Function, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when needing interface source code) but offers no explicit guidance on alternatives or when not to use it. With many similar Get_* tools, clearer directives would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve ABAP message class information
| Name | Required | Description | Default |
|---|---|---|---|
| MessageClass | Yes | Message class name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only says 'Retrieve... information'. It implies a read operation but does not disclose return format, side effects, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the purpose without wasted words. However, it could benefit from more detail while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the description lacks completeness: it does not specify what 'information' includes, return behavior, or how to interpret results. No output schema or annotations compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema describes the parameter. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Retrieve' and resource 'ABAP message class information', making the purpose clear. However, it does not distinguish from sibling Get_* tools for other ABAP objects, though the name itself provides differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like search tools. There is no context for usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve ABAP package details
| Name | Required | Description | Default |
|---|---|---|---|
| package_name | Yes | Package name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states 'retrieve details' but does not disclose whether the operation is idempotent, what side effects (if any) exist, performance implications, or what 'details' encompasses. For a read-like operation, more transparency about the nature of the data returned is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise but lacking substance. It does not include any additional structure or front-loaded key information. While it is short, it misses the opportunity to add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (one parameter, no output schema), the description is incomplete. It does not explain what 'details' means, the format of the output, or any special behavior. A retrieval tool should give the user an idea of what is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter with description). The description does not add any meaning beyond the schema; it only repeats the parameter's purpose indirectly. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve') and the resource ('ABAP package details'). Among sibling tools like Get_Class, Get_Function, etc., it is uniquely identifiable as targeting ABAP packages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling list implies it is one of many 'Get_*' tools for ABAP objects, but there is no explicit context like 'Use this for package details; for other objects, use the corresponding Get_* tool'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve ABAP program source code
| Name | Required | Description | Default |
|---|---|---|---|
| program_name | Yes | Program name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states a read operation but omits details such as whether the full source code is returned, any constraints (e.g., active programs only), or potential side effects. This leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 words) but lacks essential details for agent usage. While it avoids fluff, it does not provide sufficient trade-offs between brevity and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a simple parameter set, the description fails to provide enough context for correct usage. The lack of output schema or behavioral details means an agent may not know what to expect or how to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter 'program_name' is already described. The description adds no additional meaning or constraints beyond the schema, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve ABAP program source code' clearly states a specific verb and resource, making the tool's purpose unmistakable. It effectively distinguishes from sibling tools like Get_Class which retrieve class source code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Given the large set of sibling tools for retrieving different ABAP objects, explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve detailed ABAP runtime dump information
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Runtime dump id (if known) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only states 'retrieve' without disclosing behavioral traits like permissions, side effects, or what 'detailed' entails. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no unnecessary words. It is front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally adequate but lacks details about the return value or how to obtain the dump ID. More context would improve agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the single parameter. The tool description adds no additional meaning beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve') and the resource ('detailed ABAP runtime dump information'). It distinguishes from the sibling 'GetRuntimeDumps' by implying detail retrieval vs. listing, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives like 'GetRuntimeDumps'. No prerequisites or context provided, such as needing the dump ID from a prior list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve ABAP runtime dump list
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Category filter | |
| end_date | No | End date (YYYY-MM-DD or YYYYMMDD) | |
| end_time | No | End time (00:00:00 or 235959, default 235959) | |
| maxResults | No | Max results | |
| start_date | Yes | Start date (YYYY-MM-DD or YYYYMMDD) | |
| start_time | No | Start time (00:00:00 or 000000, default 000000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides minimal behavioral information. It does not disclose side effects (likely a read-only operation), result ordering, error handling, or authentication requirements. The parameter descriptions give some format constraints but not behavior beyond retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the core action. However, it is too sparse, omitting important context. It earns its place but does not fully inform the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description is inadequate. It does not explain the purpose of runtime dumps, how results are formatted, or how to handle edge cases like no results. The agent lacks sufficient context for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions explaining formats and defaults. However, the tool description adds no extra meaning beyond the schema. For example, 'Category filter' is not explained. The baseline of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'ABAP runtime dump list', indicating it returns a list of dumps. It distinguishes from the sibling tool 'GetRuntimeDumpDetails' which likely retrieves a single dump's details. However, it could be more explicit about the list nature and what constitutes a runtime dump.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'GetRuntimeDumpDetails'. It does not state prerequisites, typical use cases, or scenarios to avoid. The agent must infer usage from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve ABAP transaction details
| Name | Required | Description | Default |
|---|---|---|---|
| transaction_name | Yes | Transaction name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Retrieve', suggesting a read operation, but does not confirm idempotency, authorization needs, rate limits, or whether it might modify state. The description is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant information. It is efficient but could briefly explain what 'details' entails without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description should provide more context about returned details or constraints. It leaves ambiguity about what constitutes 'details' and whether any prerequisites exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single parameter 'transaction_name' described as 'Transaction name'. The description adds no extra meaning beyond this, meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieve' and clearly identifies the resource as 'ABAP transaction details'. It effectively distinguishes this tool from sibling tools like Get_Class or Get_Function, which target different ABAP objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving transaction details, but provides no explicit guidance on when to use this tool versus alternatives, or any conditions where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for ABAP objects
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| maxResults | No | Max results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'Search for ABAP objects' without revealing whether results are paginated, what fields are returned, authentication requirements, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. It is appropriately concise, though it could benefit from brief structured additions like output details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should explain return value structure, behavior on no matches, and interaction with sibling tools. It provides none of this, leaving agents to infer critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents parameters ('Search query', 'Max results') with 100% coverage. The description adds no additional meaning about parameter usage, format, or constraints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search for ABAP objects' clearly indicates a generic search across multiple object types. This distinguishes it from sibling tools like Get_Class and Get_Function that retrieve specific objects. However, it doesn't specify which object types are covered, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use SearchObject over specific getter tools. The description does not mention that specific getters should be preferred when the object type is known, nor does it provide context like typical use cases or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct ABAP object or operation (e.g., class, function, DDIC entity, runtime dump, ATC result). There is no ambiguity between tools; their names and descriptions clearly differentiate them.
Most tools follow a `Get_<Object>` pattern (e.g., Get_Class, Get_Function), but several deviate: GetRuntimeDumpDetails, SearchObject, API_Releases, DataPreview, and GetDDIC_* use different prefixes or casing. This inconsistency, while not chaotic, makes the naming less predictable.
24 tools cover a wide range of ABAP development tasks (source retrieval, runtime analysis, DDIC, ATC, data preview). The count is slightly high but remains scoped to the server's purpose; no tool feels superfluous.
The tool set covers retrieval and inspection of many ABAP artifacts and diagnostic data. However, it lacks any creation, update, or deletion operations, which are notable gaps for a fully capable server. It serves well as a read-only interface but misses typical lifecycle operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Query, browse, and automate OmegaAI workspaces from any MCP client. Streamable HTTP with OAuth 2.0.
An MCP server that provides access to Testiny projects, test cases and test runs
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/workskong/mcp-abap-adt'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
