Skip to main content
Glama
DimiDR

SAP Datasphere MCP Server

by DimiDR

list_repository_objects

List design-time objects in a space via the Datasphere CLI, catching undeployed or unexposed items that catalog search misses. Get a complete inventory of a space's contents.

Instructions

List design-time objects in a space by reading the REPOSITORY through the Datasphere CLI — not the Catalog API. Use this when an object is expected but does not show up in search_catalog, get_space_assets or smart_query: those only see objects that are deployed AND exposed for consumption, while this tool also sees objects with @DataWarehouse.consumption.external: false. Also the right tool for a true inventory of what a space actually contains. Requires the CLI to be installed and logged in — check with datasphere_cli_status. Costs one CLI call per object type, so keep object_types narrow.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topNoMaximum results per object type (CLI default: 25)
skipNoNumber of results to skip per object type, for pagination
space_idYesSpace identifier (e.g., 'SAP_CONTENT', 'DIMITRITEST')
object_typesNoCLI object types to list. Default: views, local-tables, analytic-models. Use ["all"] to sweep all 18 types (slow: one CLI call each). Valid: remote-tables, local-tables, er-models, views, analytic-models, task-chains, data-flows, replication-flows, transformation-flows, data-access-controls, business-entities, fact-models, consumption-models, intelligent-lookups, ontologies, contexts, types, services
status_filterNoFilter by deployment status, e.g. 'Deployed' or 'Changed'
technical_namesNoComma-separated technical names to look for, e.g. 'MY_VIEW,MY_TABLE'. The fastest way to answer 'does this object exist at all?'
include_dependenciesNoAccepted for compatibility; the CLI list command returns no dependency data
Behavior4/5

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

With no annotations, the description carries the full transparency burden. It discloses the repository read path (not Catalog API), visibility of objects with consumption.external false, CLI installation requirement, and per-type CLI call cost. It doesn't mention return format, but the read-only nature and key operational traits are well covered.

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

Conciseness5/5

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

Four sentences, front-loaded with the core purpose, then usage, prerequisites, and cost. No redundancy; each sentence contributes unique information relevant to tool selection and invocation.

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

Completeness5/5

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

For a 7-parameter tool with no annotations and no output schema, the description covers all essential decision-making context: purpose, when to use vs. alternatives, prerequisites, and cost behavior. Parameter details are left to the schema, which is appropriate given 100% schema coverage. This is a complete, practical description.

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 coverage is 100%, so baseline is 3. The description adds valuable context for object_types by explaining each type costs a CLI call, reinforcing the schema's advice to narrow types. It also links technical_names to existence checking, which is already in schema but reinforced. This extra practical guidance justifies a 4.

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

Purpose5/5

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

The description clearly states the tool lists design-time objects in a space via the Datasphere CLI repository, explicitly contrasting with Catalog API-based siblings. It names specific alternatives (search_catalog, get_space_assets, smart_query) and distinguishes their scope, making the purpose unambiguous.

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

Usage Guidelines5/5

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

Provides explicit when-to-use guidance: use when an object is expected but missing from catalog-based tools, and for true inventory of a space. It also notes prerequisites (CLI installed and logged in) and performance advice (keep object_types narrow), giving comprehensive usage direction.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DimiDR/SAP-Datasphere-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server