Skip to main content
Glama

search_cubes

Read-onlyIdempotent

Find statistical data cubes in Swiss open data by topic, returning cube URIs for further analysis. Supports language, publisher, and version filters.

Instructions

Find statistical data cubes in LINDAS by topic.

The entry point. Returns cube URIs you then pass to get_cube_structure. By default only the newest published version of each cube is returned; set latest_only=False to see every version.

Check truncated before you conclude anything from the result. returned alone cannot tell a complete answer from a first page.

  • truncated: false — cubes holds every cube that matched. You may say so.

  • truncated: true — more cubes matched than you got back, or that could not be ruled out cheaply. Do NOT report the result as the complete set, and do NOT answer "there are N cubes about X" from returned.

On truncated: true, widen in this order:

  1. Raise limit (up to 100) and search again — usually enough.

  2. Still truncated at 100? Narrow instead of paging: add creator_uri from list_publishers to ask one federal body at a time.

  3. Set latest_only=False if you specifically need historical versions. It widens rather than narrows — every version becomes its own hit — so use it to inspect a cube's history, not to escape truncation.

total_matched carries the exact number when one is available and null otherwise. null is not an error and not zero: with latest_only=true the count the store can give cheaply counts cube versions, while this tool returns version-collapsed cubes (measured: 127 versions collapse to 35 cubes for "wald"), so no comparable number exists. truncated is still reliable there — prefer it over guessing from total_matched.

Args: query: Topic term, e.g. "Wald", "Abfluss", "Energie". Matched against cube names and descriptions in the chosen language. language: Language for names and descriptions. creator_uri: Restrict to one publishing body (from list_publishers). limit: Maximum cubes to return (1-100). latest_only: Collapse versions to the newest per cube.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
languageNode
creator_uriNo
latest_onlyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
cubesYes
queryYes
sourceNoData: LINDAS Linked Data Service, Swiss Federal Archives — https://lindas.admin.ch. Each cube declares its own licence; check the `licence` field before reuse.
languageYes
returnedYes
truncatedYesTrue when more cubes match than are returned, or when that could not be ruled out. False means `cubes` holds every match. Errs towards True: a wrong True costs one more query, a wrong False silently hides results.
match_typeNo'none' when nothing matched — distinguishes a real miss from an error.exact
provenanceNolive_sparql
suggestionNoActionable next step when match_type is 'none' (e.g. which tool to try).
latest_onlyYes
retrieved_atYes
total_matchedNoTotal cubes matching the query, on the same unit as `returned`. None means the store could not be asked cheaply for a comparable number — with latest_only=true the count LINDAS gives counts cube VERSIONS, not the version-collapsed cubes returned here (measured: 127 versions vs 35 cubes for 'wald'), so a number would be misleading. Read `truncated` instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.3.0
    • addedOutput schema / properties / total_matched
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Total cubes matching the query, on the same unit as `returned`. None means the store could not be asked cheaply for a comparable number — with latest_only=true the count LINDAS gives counts cube VERSIONS, not the version-collapsed cubes returned here (measured: 127 versions vs 35 cubes for 'wald'), so a number would be misleading. Read `truncated` instead.",
      +  "title": "Total Matched"
      +}
    • addedOutput schema / properties / truncated
      Added value: +{
      +  "description": "True when more cubes match than are returned, or when that could not be ruled out. False means `cubes` holds every match. Errs towards True: a wrong True costs one more query, a wrong False silently hides results.",
      +  "title": "Truncated",
      +  "type": "boolean"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "retrieved_at",
      -  "query",
      -  "language",
      -  "latest_only",
      -  "returned",
      -  "cubes"
      -]New value: +[
      +  "retrieved_at",
      +  "query",
      +  "language",
      +  "latest_only",
      +  "returned",
      +  "truncated",
      +  "cubes"
      +]
  2. First observedv0.2.0

TDQS

A5/5.0
Behavior5/5

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

Annotations already indicate `readOnlyHint`, `openWorldHint`, and `idempotentHint`, but the description adds meaningful behavioral detail beyond them: the semantics of `truncated`, why `total_matched` may be `null`, and the measured version-collapse behavior (127 versions to 35 cubes). These are exactly the kind of non-obvious behaviors an agent must know.

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?

The description is long but every section earns its place: purpose is front-loaded, the `truncated` warning is highlighted and prominent, the troubleshooting list is numbered, and parameter explanations are compact. There is no filler or repetition beyond what is necessary for safe use.

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 search/discovery tool with 5 parameters and an output schema, the description covers input semantics, output fields (`cubes`, `truncated`, `total_matched`), critical caveats, and next-step routing to `get_cube_structure`. The presence of an output schema means return-value structure need not be restated, and nothing needed for correct invocation is missing.

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

Parameters5/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 meaning, and it does. Each parameter is explained with purpose and constraints: `query` is matched against names and descriptions, `creator_uri` filters by publisher from `list_publishers`, `limit` has range 1-100, and `latest_only` collapses versions. This fully compensates for the bare schema.

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 states a specific verb and resource: 'Find statistical data cubes in LINDAS by topic.' It also identifies the tool as 'The entry point' and explains that it returns cube URIs that feed into `get_cube_structure`, clearly separating it from sibling tools.

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?

The description explicitly says when to use it (entry point for finding cubes) and gives concrete guidance for alternatives: passing URIs to `get_cube_structure`, using `list_publishers` to narrow by `creator_uri`, and avoiding `latest_only=False` as a truncation workaround. This is strong when-to-use guidance with exclusions.

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