get_entity_schema

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose a concrete output trait — choice-style columns carry an option_set summary with is_global and option_count — which is genuinely useful. However, it says nothing about pagination, permissions, or how large tables are handled, leaving meaningful gaps.

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

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

Three compact sentences, front-loaded with the core purpose, then the choice-column detail, then the handoff to a sibling. Every sentence earns its place with no filler.

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

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

With no output schema, the description must convey the return shape; it covers the choice-column case well but is silent on the general shape of returned attribute metadata (types, required flags, etc.). For a single-parameter read tool with no annotations this is close to, but not fully, complete.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter and schema description coverage is 100%, so the schema already documents entity_logical_name with examples. The description adds no naming-format or syntax guidance beyond that, which is the expected baseline when the schema does the work.

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

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

States a specific verb and resource: 'Get attributes (columns) of a specific Dataverse table.' An agent can distinguish this from data-reading siblings (get_record, query_records) and from list_entities, though the distinction is implied rather than stated. It also explicitly positions get_picklist_options as a complementary tool.

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

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

Provides clear context for when this tool pays off ('one dump shows which choice lists are shared org-wide') and routes to get_picklist_options when per-column option values are needed. It lacks an explicit when-not or prerequisite statement (e.g., needing an existing connection/solution), so it stops short of a 5.

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