Loading ToolBench
SAP object translation MCP server. Standalone MCP server for SAP object translation (XCO i18n). Deployable on SAP BTP or runnable locally.
LISA demonstrates strong schema completeness and domain-specific parameter design for SAP translation workflows. All 6 tools have detailed input schemas with proper enums and nested structures. Descriptions are comprehensive (100-500+ chars) and explain WHEN/WHY to use each tool. However, naming conventions deviate from standard verb_noun patterns (TranslateListLanguages vs list_translate_languages), and output schemas are not documented in the tool definitions. Error handling guidance is absent, tools do not describe recovery paths or categorize failures. Security considerations (transport, auth) are handled server-side but not declared in tool metadata.
LISA TranslateGetTexts (whole-object reader, list_texts), as an ARC-1 extension tool. Reuses the core reader — including the position decomposition + guaranteed `populated` (normalizeListTextEntry) — then applies the same client-side field_name/position narrowing the standalone server does. READ op exposed as POST, hence scope:'write' (see ListLanguages note).
LISA TranslateListLanguages, as an ARC-1 extension tool. READ operation — but LISA exposes EVERY action as a POST (the ABAP handler reads the action from ~path_info and parses params from the JSON body), and ctx.http gates by HTTP method, so this still needs scope:'write' + SAP_ALLOW_PLUGIN_RAW_WRITES. `opType: Read` keeps the DECLARED operation honest (it only reads). To make this a clean scope:'read', expose list_languages over GET (query-string) in ZCL_I18N_SERVICE — see the package README.
LISA TranslateSetTexts, as an ARC-1 extension tool — the actual WRITE. Gated: refused unless SAP_ALLOW_PLUGIN_RAW_WRITES=true + SAP_ALLOW_WRITES=true and scope:'write'. The write lands in the caller-supplied `transport`; the object is locked once even when the `texts` array addresses several CDS fields (per-entry field_name/position). Non-ADT path, so SAP_ALLOWED_PACKAGES does not apply — SAP-side auth on ZI18N_SERVICE is the backstop.
Read all translatable texts of an SAP object in a given language, or in the object's original language when none is specified. Returns every text slot with its full key (level, field_name, attribute), its value, and a `populated` flag (false = the slot exists but is empty in this language, i.e. still to translate). To list only filled texts, keep entries with populated=true; to compare two languages, call it once per language and diff on (key, populated, value). For a CDS entity use target_type=cds_entity: a single call returns the merged texts of ONE named entity — the view itself (data_definition) AND its OWN metadata extension/DDLX (metadata_extension) together, so the DDLX labels come back without a separate metadata_extension call.
Tool naming does not follow verb_noun convention. 'TranslateListLanguages' should be 'list_languages' or 'list_translate_languages'. Non-standard names reduce LLM discoverability and increase reasoning overhead when multiple tools are available.
Output schemas are not documented in tool definitions. LLMs cannot plan downstream calls or extract required fields (e.g., what does TranslateGetTexts return? Is it an array of text entries with 'populated' flags?). This forces agents to guess structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | <=2025-11-25 | v2 |
List all languages installed on the SAP system.
Write translations of an SAP object in a given language. Accepts an array of text entries (attribute, value) and optional per-entry field_name/position selectors so that translations for MULTIPLE fields of one object (e.g. several ui_lineitem_label labels of a CDS view) are written in a single call — the object is then locked only once. For a CDS entity use target_type=cds_entity: LISA groups the provided texts by their `owner` (data_definition | metadata_extension) and writes each group back to the matching real target in its own call (so each physical object is locked once); the per-row `owner` returned by a read routes the write, so pass the rows back unchanged.
No error handling guidance. Tools do not describe what errors are retryable, what user-fixable errors look like, or how to recover. E.g., TranslateSetTexts may fail if transport request is invalid, but the tool description does not guide the LLM on recovery.
Custom_* tools have redundant descriptions that reference the core tools. 'LISA TranslateGetTexts (whole-object reader, list_texts), as an ARC-1 extension tool' is confusing, it should clearly state what the ARC-1 variant does differently or why it exists.
Parameter descriptions lack format/constraint details. E.g., 'language' accepts 'ISO 639-1 (EN, DE, FR…) or SAP SPRAS single-char code (E, D, F…)' but does not specify which format is preferred or if both are always valid. This invites LLM confusion.