Dataddo Data to AI

Askable data and metrics

list_entities

Read-only

List the business entities and blessed metrics in ONE model. Entities are business nouns (customer, invoice, deal), not source tables. This is what can be ASKED, which is narrower than what the account HAS — for that, use list_flows. declared_rows is what the PLATFORM says a flow holds, not a measurement. Returns a PAGE: 40 by default, at most 200, answerable first, with 'counts.entities_in_model' giving the true total — advance 'offset' rather than concluding the model ends there, and read 'counts.answerable_in_model' before judging from one page how much can be queried. A page can come back SHORTER than you asked when the response budget trims it; 'entities_truncated' says so, and you then advance by the number you RECEIVED, never by the limit you requested. Metrics are listed once, on the first page, and are model-wide.

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": "list_entities"
  }
}

Input Schema

Name	Required	Description
`limit`	No	maximum entities to return; default 40, maximum 200
`model`	No	model name from list_models; omit for the default
`offset`	No	skip this many entities; use with counts.entities_in_model to page through them all

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 7, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
First observedOct 6, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds substantial non-obvious behavior: default page size 40, cap 200, budget-driven truncation signalled by entities_truncated, and the rule to advance offset by rows received rather than requested. It also warns that declared_rows is platform-declared, not measured, and that metrics appear only on the first page. Only the exact response shape of counts remains slightly underspecified.

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?

Front-loaded with purpose, then scope, then pagination caveats, in a logical order with zero filler sentences. Dense uppercase emphasis makes it slightly harder to scan than plain prose, but every sentence carries distinct information.

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?

There is no output schema, so the description carries the burden of explaining return values, and it does: page semantics, counts fields, entities_truncated, and that metrics are model-wide and first-page-only. For a zero-required-parameter read tool with three optional args, nothing an agent needs to call it correctly is missing.

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 the baseline is 3, but the description adds operational meaning beyond the schema: offset must be advanced by the number actually received, and counts.entities_in_model / counts.answerable_in_model are the reference totals for paging and judging coverage. It also reinforces the limit ceiling and that model resolution comes from list_models.

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 specific verb and resource ("List the business entities and blessed metrics in ONE model") and immediately clarifies the resource semantics: entities are business nouns, not source tables. It also names the narrower scope versus list_flows, so the agent can distinguish this from siblings without reading schemas.

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?

Explicitly routes the agent: this tool is what can be ASKED, and "for that, use list_flows" covers the broader inventory case. It also gives when-not guidance for treating a single page as the whole set, telling the agent to check counts and advance offset.

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

All Dataddo Data to AI tools Inspect

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

Need Help?