Skip to main content
Glama

SAPNavigate

Read-only

Navigate SAP ABAP code to locate definitions, references, completions, and hierarchies, then trace dependencies or package neighborhoods for impact analysis.

Instructions

Navigate code: definitions, references, completion, hierarchy. references: scope-based where-used with lines/snippets/package; objectType filters results (e.g. CLAS/OC, PROG/P); type+name replaces uri. hierarchy queries SEOMETAREL for superclass/interfaces/direct subclasses: requires data/SQL opt-in + matching scope; otherwise inspect class MAIN with SAPRead. CDS (DDLS) impact: SAPContext(action="impact") classifies where-used into RAP buckets. Experimental relations: dependency maps or package neighborhoods, then selected reads. Consumer locations: references; objectType="CLAS/OC" for class-only; otherwise omit. Active metadata, not source-call/runtime proof. Coverage unknown. type+name required, no uri/source.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uriNoDefinition needs source URI, line, column and source; references also accepts type+name.
lineNoLine (1-based integer)
nameNoObject name — alternative to uri for references.
typeNoRoot object type, paired with name instead of uri (e.g. type="INTF"). Not the result-type filter. relations: CLAS, INTF, DDLS, DCLS, BDEF, SRVD, TABL, TTYP, DTEL, DOMA, PROG, INCL, FUGR, FUNC, VIEW, ENHO, MSAG, TRAN, SHLP, SKTD, ENHS, ENQU, TYPE, EVTB, DSFD. ENHO/XHB, ENHS/XSB only; TTYP=table type; MSAG=message class.
depthNorelations: native steps (default 1), not source-call hops.
actionYesNavigation action
columnNoColumn (0-based integer)
sourceNoCurrent source for definition/completion
directionNorelations: incoming=users; outgoing=dependencies (default).
maxResultsNoreferences: max entries (default 100, max 1000). "total" counts every match of the filter. relations: node cap incl. root, 1–100 (default 50); may stop earlier.
objectTypeNoreferences RESULT filter, not the root type: CLAS/OC, PROG/P, FUGR/FF. Omit for all consumer types. A bare prefix ("CLAS") matches every subtype.
expandPackagesNorelations: expand exact packages beyond root; others visible. Not authorization.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.5.1
    • changedInput schema / properties / column / description
      Previous value: -"Column number (1-based)"New value: +"Column (0-based integer)"
    • changedInput schema / properties / line / description
      Previous value: -"Line number (1-based)"New value: +"Line (1-based integer)"
    • changedInput schema / properties / source / description
      Previous value: -"Current source code (for definition/completion)"New value: +"Current source for definition/completion"
    • changedInput schema / properties / uri / description
      Previous value: -"Source URI of the object. Optional for references if type+name are provided."New value: +"Definition needs source URI, line, column and source; references also accepts type+name."
  2. Changed7 schema fields changedv1.3.0
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "definition",
      -  "references",
      -  "completion",
      -  "hierarchy"
      -]New value: +[
      +  "definition",
      +  "references",
      +  "completion",
      +  "hierarchy",
      +  "relations"
      +]
    • addedInput schema / properties / depth
      Added value: +{
      +  "description": "relations: native steps (default 1), not source-call hops.",
      +  "maximum": 3,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / direction
      Added value: +{
      +  "description": "relations: incoming=users; outgoing=dependencies (default).",
      +  "enum": [
      +    "incoming",
      +    "outgoing"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / expandPackages
      Added value: +{
      +  "description": "relations: expand exact packages beyond root; others visible. Not authorization.",
      +  "items": {
      +    "maxLength": 120,
      +    "minLength": 1,
      +    "pattern": "^(?:/[A-Za-z0-9_]+/)?[A-Za-z0-9_$]+$",
      +    "type": "string"
      +  },
      +  "maxItems": 8,
      +  "type": "array"
      +}
    • changedInput schema / properties / maxResults / description
      Previous value: -"references: max entries (default 100, max 1000). \"total\" counts every match of the filter."New value: +"references: max entries (default 100, max 1000). \"total\" counts every match of the filter. relations: node cap incl. root, 1–100 (default 50); may stop earlier."
    • changedInput schema / properties / objectType / description
      Previous value: -"references: keep only results of this ADT type, slash format (CLAS/OC, PROG/P, FUGR/FF). A bare prefix (\"CLAS\") matches every subtype."New value: +"references RESULT filter, not the root type: CLAS/OC, PROG/P, FUGR/FF. Omit for all consumer types. A bare prefix (\"CLAS\") matches every subtype."
    • changedInput schema / properties / type / description
      Previous value: -"Object type (PROG, CLAS, INTF, FUNC, etc.) — alternative to uri for references."New value: +"Root object type, paired with name instead of uri (e.g. type=\"INTF\"). Not the result-type filter. relations: CLAS, INTF, DDLS, DCLS, BDEF, SRVD, TABL, TTYP, DTEL, DOMA, PROG, INCL, FUGR, FUNC, VIEW, ENHO, MSAG, TRAN, SHLP, SKTD, ENHS, ENQU, TYPE, EVTB, DSFD. ENHO/XHB, ENHS/XSB only; TTYP=table type; MSAG=message class."
  3. Changed3 schema fields changedv1.0.2
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / maxResults
      Added value: +{
      +  "description": "references: max entries (default 100, max 1000). \"total\" counts every match of the filter.",
      +  "type": "number"
      +}
    • changedInput schema / properties / objectType / description
      Previous value: -"For references action: filter where-used results by ADT object type in slash format (e.g., PROG/P, CLAS/OC, FUGR/FF, INTF/OI). On systems supporting the scope endpoint, only returns references from objects of the specified type. On older systems, the filter is ignored and all references are returned with a note."New value: +"references: keep only results of this ADT type, slash format (CLAS/OC, PROG/P, FUGR/FF). A bare prefix (\"CLAS\") matches every subtype."
  4. Addedv0.9.6
  5. Removedv0.9.3
  6. Changed1 schema field changedv0.9.0
    • changedInput schema / properties / objectType / description
      Previous value: -"For references action: filter where-used results by ADT object type in slash format (e.g., PROG/P, CLAS/OC, FUNC/FM, INTF/OI). On systems supporting the scope endpoint, only returns references from objects of the specified type. On older systems, the filter is ignored and all references are returned with a note."New value: +"For references action: filter where-used results by ADT object type in slash format (e.g., PROG/P, CLAS/OC, FUGR/FF, INTF/OI). On systems supporting the scope endpoint, only returns references from objects of the specified type. On older systems, the filter is ignored and all references are returned with a note."
  7. First observedv0.6.4

TDQS

A3.8/5.0
Behavior4/5

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

Annotations only declare readOnlyHint, so the description carries most of the burden and delivers useful caveats the annotations cannot: 'Active metadata, not source-call/runtime proof' and 'Coverage unknown' set honest expectations about result reliability, and 'may stop earlier' qualifies the relations node cap. It also discloses that hierarchy needs a data/SQL opt-in. What it omits is any note on latency/cost or error behavior for the experimental relations path.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

For a 5-action, 12-parameter tool the density is defensible and nothing looks purely decorative, but the telegraphic clause-per-semicolon style and unglossed identifiers (SEOMETAREL, RAP buckets, CLAS/OC) make it hard to scan and easy to misparse. The action list is front-loaded, yet the cross-cutting constraints are interleaved rather than grouped.

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 12 parameters, no output schema, and only a readOnlyHint annotation, the description does substantial work: it documents scope limitations, the opt-in prerequisite, result-filter semantics, and the metadata-not-runtime caveat. Gaps remain around what definition/completion return and how the experimental relations path behaves on failure, but given the tool's complexity the coverage is reasonably complete.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 12 parameters and the baseline is 3. The description reinforces key distinctions (objectType is a result filter not the root type; type+name replaces uri; depth is native steps not source-call hops), but these largely restate the schema rather than adding format, default or interaction detail beyond it.

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?

Opens with a specific verb+resource+action list: 'Navigate code: definitions, references, completion, hierarchy' plus relations. It goes further than most by routing one sub-case away from itself ('otherwise inspect class MAIN with SAPRead') and deflecting CDS impact to SAPContext(action="impact"), so the agent can partly distinguish it from siblings. The remaining weakness is that it never states in plain terms what the tool is overall beyond a per-action menu, and jargon like SEOMETAREL and RAP buckets assumes SAP fluency.

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?

Gives concrete when-to-use conditions: hierarchy 'requires data/SQL opt-in + matching scope' else use SAPRead; consumer locations should use references with objectType='CLAS/OC' for class-only or omit otherwise; relations needs type+name with no uri/source. Alternatives (SAPRead, SAPContext) are named with their triggering condition. It stops short of explicit when-NOT to use the tool as a whole.

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