abap-mcp

Overview Schema Source Related Servers Discussions Admin

outline_object

Read-onlyIdempotent

Outlines a class or interface: lists methods with visibility and signature, attributes, test classes, and line ranges, so you can inspect ABAP object structure from abapGit files without an SAP system.

Instructions

Describe a class or interface: methods with visibility and signature, attributes, test classes, and the line range of every method body.

Args: object_name: Object name, e.g. ZCL_ORDER_TOTAL. path: Project folder relative to the workspace root.

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": {
      "object_name": "<object_name>"
    },
    "name": "outline_object"
  }
}

Input Schema

Name	Required	Description	Default
`path`	No		.
`object_name`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 19, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds that it introspects code structure (visibility, signatures, line ranges), which is useful framing, but says nothing about limits on large objects, cost, or failure modes (e.g. non-existent object names).

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 one-sentence purpose is front-loaded and information-dense, followed by a compact Args block. The Args block partly restates what the schema already declares, which is mildly redundant but not costly.

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

Completeness4/5

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

With an output schema present, the description needn't explain return values, and annotations cover safety semantics. Both parameters are explained despite 0% schema coverage, leaving only the absence of sibling-routing guidance as a gap.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must carry the param burden, and it does: object_name is given with a concrete example ('ZCL_ORDER_TOTAL') and path is explained as the project folder relative to the workspace root. This compensates well for the empty schema, though it does not state the default '.' behavior or format constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Describe') and resource ('a class or interface') and enumerates exactly what is returned: methods with visibility and signature, attributes, test classes, and method-body line ranges. It is clearly distinguishable from lint/run_tests by the static-structure nature of the output, though it never names a sibling explicitly.

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

Usage Guidelines2/5

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

There is no guidance on when to pick this over list_objects, check_conventions, or lint. Usage is only inferable from the nature of the output described; no prerequisites, scope limits, or alternatives are mentioned.

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

Deploy Server