Help the user search any Microsoft Dataverse table, browse matching records, and
view full record details — all sourced live from Dataverse via the Dataverse MCP
Server tool.
Data source (critical)
- Always source data dynamically from Microsoft Dataverse using the Dataverse
MCP Server tool.
- NEVER fabricate, invent, hardcode, guess, or reuse records from examples or
prior general knowledge. Every record and every field value you show must come
from a live query via the tool.
- If the tool returns no results or fails, say so plainly and ask the user to try
again or refine their search. Do not make up data.
Workflow
Step 1 — Identify the table
- If the user names a table (e.g. "accounts", "opportunities", "contacts"), use
that table.
- If the user is ambiguous, ask: "Which table would you like to search? For
example: contacts, accounts, opportunities, leads, etc."
- Use
describe('tables/') to resolve the table's logical name if needed.
Step 2 — Discover the schema
Before querying, call describe('tables/{tablename}') to retrieve:
- The table's primary name field (used for display).
- The table's primary key field (used internally for record lookup).
- Available columns and their logical names and types.
Note the primary key field name (e.g. accountid) so you can request its
value when querying. The primary key GUID values returned by later queries
stay internal — never display them to the user.
Step 3 — Find records
- Query the table using
read_query, always retrieving at least:
- The primary name field
- A key identifier field (e.g. email, account number, status)
- The primary key (for internal use only)
- Apply any search filters the user provides (name, keyword, status, date range,
related record, etc.).
- Return at most 15 rows. If more than 15 records match, show the first 15
and prompt the user to narrow the search.
- If a field has no value, show
(none).
Present results as a numbered markdown list, or a table with a leading number
column so the user can select by number:
Step 4 — Select a record
When the user selects a record (by number, name, or identifier):
- Re-query the Dataverse table using the internally stored primary key GUID.
- Display the most useful ~20 fields for that record, presented as a readable
labeled list or table.
- Omit empty/null fields unless the user requests the full record.
- Never reveal GUIDs or internal identifiers.
Example detail view:
Remembering preferred fields
- If the user requests a different set of fields (add, remove, or replace),
remember those preferences using memory tools.
- Default to the user's preferred field set on all subsequent detail lookups — in
this and future conversations — until the user changes it again.
Supported tables
The skill works with any Dataverse table. Common examples:
| Table display name |
Logical name |
| Contacts |
contact |
| Accounts |
account |
| Opportunities |
opportunity |
| Leads |
lead |
| Cases |
incident |
| Products |
product |
| Orders |
salesorder |
| Invoices |
invoice |
| Activities |
activitypointer |
| Users |
systemuser |
Use describe('tables/') to discover all available tables in the environment.
Guardrails
- Present matching records as a numbered markdown list, or a table with a leading
number column (# / Record Name / Key Identifier).
- Do not expose raw GUIDs, internal IDs, query syntax, or raw tool payloads
to the user.
- Do not emit adaptive card or suggested-action code blocks.
- When a search yields no results, say so clearly and suggest alternative search
terms.
- When a table is not found, suggest similar table names or ask the user to
clarify.
- When more than 15 records match, always prompt the user to refine the search
rather than paginating silently.
Tone
Be concise and helpful. Explain uncertainty rather than hiding it, and never
present fabricated data as if it came from Dataverse.
1---2name: lookup-dataverse-table3description: Use this skill whenever the user wants to search, browse, or look up records in a Microsoft Dataverse table — for example "look up accounts", "find opportunities for Contoso", "show me contact details", or "search cases by status". Always prefer this skill (which queries Dataverse live via the Dataverse MCP Server) BEFORE answering any question about Dataverse records.4---56Help the user search any Microsoft Dataverse table, browse matching records, and7view full record details — all sourced live from Dataverse via the Dataverse MCP8Server tool.910## Data source (critical)1112- Always source data **dynamically** from Microsoft Dataverse using the Dataverse13 MCP Server tool.14- **NEVER** fabricate, invent, hardcode, guess, or reuse records from examples or15 prior general knowledge. Every record and every field value you show must come16 from a live query via the tool.17- If the tool returns no results or fails, say so plainly and ask the user to try18 again or refine their search. Do not make up data.1920## Workflow2122### Step 1 — Identify the table2324- If the user names a table (e.g. "accounts", "opportunities", "contacts"), use25 that table.26- If the user is ambiguous, ask: *"Which table would you like to search? For27 example: contacts, accounts, opportunities, leads, etc."*28- Use `describe('tables/')` to resolve the table's logical name if needed.2930### Step 2 — Discover the schema3132Before querying, call `describe('tables/{tablename}')` to retrieve:3334- The table's **primary name field** (used for display).35- The table's **primary key field** (used internally for record lookup).36- Available columns and their logical names and types.3738Note the **primary key field name** (e.g. `accountid`) so you can request its39value when querying. The primary key GUID **values** returned by later queries40stay **internal** — never display them to the user.4142### Step 3 — Find records43441. Query the table using `read_query`, always retrieving at least:45 - The **primary name field**46 - A **key identifier field** (e.g. email, account number, status)47 - The **primary key** (for internal use only)482. Apply any search filters the user provides (name, keyword, status, date range,49 related record, etc.).503. Return **at most 15 rows**. If more than 15 records match, show the first 1551 and prompt the user to narrow the search.524. If a field has no value, show `(none)`.5354Present results as a numbered markdown list, or a table with a leading number55column so the user can select by number:5657| # | Record Name | Key Identifier |58|---|-------------|----------------|59| 1 | Example Corp | account@example.com |60| 2 | Another Record | 555-0100 |6162### Step 4 — Select a record6364When the user selects a record (by number, name, or identifier):65661. Re-query the Dataverse table using the internally stored primary key GUID.672. Display the most useful ~20 fields for that record, presented as a readable68 labeled list or table.693. Omit empty/null fields unless the user requests the full record.704. Never reveal GUIDs or internal identifiers.7172Example detail view:7374| Field | Value |75|-------|-------|76| **Name** | Example Corp |77| **Email** | account@example.com |78| **Phone** | 555-0100 |79| **City** | Seattle |80| **State** | WA |8182## Remembering preferred fields8384- If the user requests a different set of fields (add, remove, or replace),85 **remember those preferences** using memory tools.86- Default to the user's preferred field set on all subsequent detail lookups — in87 this and future conversations — until the user changes it again.8889## Supported tables9091The skill works with **any** Dataverse table. Common examples:9293| Table display name | Logical name |94|--------------------|--------------|95| Contacts | contact |96| Accounts | account |97| Opportunities | opportunity |98| Leads | lead |99| Cases | incident |100| Products | product |101| Orders | salesorder |102| Invoices | invoice |103| Activities | activitypointer |104| Users | systemuser |105106Use `describe('tables/')` to discover all available tables in the environment.107108## Guardrails109110- Present matching records as a numbered markdown list, or a table with a leading111 number column (# / Record Name / Key Identifier).112- Do **not** expose raw GUIDs, internal IDs, query syntax, or raw tool payloads113 to the user.114- Do **not** emit adaptive card or suggested-action code blocks.115- When a search yields no results, say so clearly and suggest alternative search116 terms.117- When a table is not found, suggest similar table names or ask the user to118 clarify.119- When more than 15 records match, always prompt the user to refine the search120 rather than paginating silently.121122## Tone123124Be concise and helpful. Explain uncertainty rather than hiding it, and never125present fabricated data as if it came from Dataverse.