Skip to main content
Glama
Sign In

Tulina

by ai.tulina.mcp
OverviewDiscussionsAdmin

data_list_datastores

List the datastores of the active org: the org's and your teams' tables, and those shared with the org or your teams — never a personal table nor one shared with you as a person. Those are listed in your PERSONAL org only, which also lists ALL your personal tables (whatever org they were created under) and the tables shared with you as a person (shared: true).

A table missing from this list is not gone: it still opens by its number from any org.

Each entry carries the table's NUMBER under BOTH names — ns_id (the form to pass as datastore from here on, and the one every other reply uses) and id (the same number, kept for the dashboard's deep links).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "data_list_datastores"
  }
}

Input Schema

NameRequiredDescriptionDefault
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses scoping/exclusion rules, the non-destructive fact that absent tables still open by number, and the dual-field return semantics (ns_id vs id). It does not cover pagination, ordering, or permission requirements, keeping it short of a 5 for a listing tool with rich server-side scope.

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?

Purpose and scope are front-loaded, then the exclusion rule, then the field semantics in a logical order. It is somewhat long with parenthetical asides and the id/ns_id paragraph is dense, but every sentence conveys actionable scope or return information.

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

Completeness3/5

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

No output schema exists, and the description describes the key returned fields but not the full entry shape, ordering, or size of the list. For a listing tool with no annotations, an agent can call it but lacks detail on pagination and response structure.

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% and the parameters are context injectors (_org, _group, _run_id, _project) already well documented. The description adds genuinely new meaning by specifying that the returned `ns_id` is the exact value to pass as the `datastore` parameter in subsequent calls, clarifying downstream usage beyond the 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?

States a precise verb and resource ('List the datastores of the active org') and immediately delimits scope: org and team tables plus those shared with org/teams, explicitly excluding personal tables. It also names the contrasting scope (PERSONAL org) so the agent can tell the two listing behaviors apart without opening another schema.

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?

The description effectively routes usage by explaining which datastores appear here versus in the PERSONAL org, and reassures that a missing table is still reachable by number. It does not name a specific sibling tool for the personal case, so the alternative is described conceptually rather than by tool name.

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

All Tulina toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources