Dataddo Data to AI

Fields and relationships

describe_entity

Read-only

Show an entity's selectable fields and its declared relationships to other entities. An entity modelled automatically can carry hundreds of fields, so the most-filled ones are returned by default and 'fields_selection' says how many were not — use 'matching' to search by name, 'fields' to name the ones you want, or 'offset' to page. A field not shown is not thereby absent. The field names here are the ones query accepts. Relationships listed here are the ONLY joins available — they are declared by the data model, never inferred.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "entity": "<entity>"
    },
    "name": "describe_entity"
  }
}

Input Schema

Name	Required	Description
`limit`	No	how many fields to describe; default 40, maximum 200
`model`	No	model name; omit for the default
`entity`	Yes	the entity name, from list_entities
`fields`	No	describe only these fields; omit for the most-filled ones
`offset`	No	skip this many fields; use with the reported total to page through them all
`matching`	No	describe only fields whose name or description contains this

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

Behavior5/5

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

Beyond the readOnly/non-destructive annotations, it discloses default truncation behavior ('the most-filled ones are returned by default'), points at the 'fields_selection' count reporting what was omitted against a no-output-schema tool, and warns 'A field not shown is not thereby absent'. The join constraint ('Relationships listed here are the ONLY joins available — they are declared by the data model, never inferred') is exactly the kind of non-obvious behavioral fact annotations cannot carry.

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?

Five sentences, front-loaded with purpose, then truncation behavior, then the parameter routing, then the two critical caveats. Nothing is padding and the most surprising facts (hidden fields, fixed join set) are placed where they will be read.

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

Completeness4/5

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

With no output schema, the description carries the return-value burden and does cover the 'fields_selection' count and the omitted-field caveat. It could say more about how relationships are shaped in the response, which leaves a small gap for a six-parameter inspection tool.

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 the rationale and interaction the schema lacks: hundreds of fields on auto-modelled entities explain why truncation and paging exist, and it ties 'offset' to 'the reported total' for full paging. The additions are meaningful though partly restated from 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?

The opening sentence gives a specific verb and two resources ('selectable fields' and 'declared relationships'), and the later line 'The field names here are the ones query accepts' separates it from siblings like list_entities and query. An agent can tell what this returns without opening the 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?

It explicitly routes between the three selection mechanisms — 'use matching to search by name, fields to name the ones you want, or offset to page' — which is real when-to-use guidance. It stops short of saying when to prefer this tool over sample_values or list_entities, so it is strong but not complete.

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?