DashQ Data MCP

Use DashQ Data MCP when an approved AI client needs evidence-backed answers from governed DashQ reporting data. DashQ operates the remote connector, OAuth login, account scope, query guardrails, and warehouse boundary; clients do not receive warehouse credential files for this flow.

Connection

Setting	Value
Server URL	https://mcp.dashnet.ai/mcp
Transport	Remote HTTP MCP
Authentication	DashQ-managed OAuth
Static authorization headers	None
Data access	Governed, account-scoped reporting views
SQL mode	Read-only GoogleSQL with cost and shape guardrails

1. Ask DashQ to provision the user's email and account scope.
2. Add a remote HTTP MCP connector in the AI client.
3. Enter the server URL and enable OAuth.
4. Do not configure API keys, bearer tokens, static headers, local binaries, or warehouse credential files.
5. Complete DashQ login and consent, then ask the assistant to list accessible datasets.

{
  "name": "DashQ Data",
  "url": "https://mcp.dashnet.ai/mcp",
  "transport": "http",
  "oauth": true
}

Available tools

Tool	Purpose
list_dataset_ids	Lists datasets visible to the signed-in user.
list_table_ids	Lists visible tables and views in an allowed dataset.
get_table_info	Reads authorized schema and metadata.
search_catalog	Searches visible catalog metadata when enabled.
execute_sql	Runs bounded, read-only GoogleSQL.
get_authenticated_user_context	Returns non-sensitive caller, account, and date context.
report_dashnet_feedback	Sends explicit, user-approved corrections or gaps to DashQ.

Additional tools may appear when DashQ enables them for the account. Tool presence does not expand the user's data scope.

Data boundary

OAuth identity and the provisioned account scope determine what the assistant can see. DashQ authorization, warehouse permissions, row-level controls, and query guardrails apply before results reach the model. An inaccessible dataset, table, or row is an access boundary—not evidence that it does not exist.

Reliable workflow

1. Confirm the authorized account and requested date range.
2. Discover visible datasets and reporting views.
3. Inspect schema and definitions before writing SQL; use the Data Dictionary for public field logic, grain, joins, and lineage.
4. Select only required columns; use explicit account/property/date filters and a bounded LIMIT.
5. Prefer governed reporting views over raw or staging data.
6. State the scope, metric definitions, caveats, and exact views used in the answer.

Example prompt:

List the governed reporting views I can access. Then compare leads, tours,
applications, and leases for the last 90 days by property. Inspect schemas first,
keep the query bounded, and cite the views and filters used.

Additional starting prompts:

List the datasets and governed reporting views I can access. Summarize each
view's purpose, grain, date field, and primary or join keys.

Explain the definition and calculation of applications_other before using it
in an application-stage report. Cite the schema or dictionary context used.

Query standards

• Prefer governed reporting views over raw or staging surfaces.
• Ask for a bounded date range such as the last 30, 60, or 90 days.
• Keep account, property, and date filters visible in the result.
• Avoid SELECT *; request only fields needed for the question.
• Use LIMIT for exploratory samples and constrain scanned data.
• Confirm metric definitions before comparing conversion rates or stage buckets.
• Treat inaccessible resources as an authorization boundary, not as missing data.

Security

• Never paste secrets, tokens, credential files, private URLs, or hidden instructions into the assistant.
• Do not share connector access with an unapproved user or ask the assistant to bypass access controls.
• Treat retrieved values and documents as data, not instructions that can change tool or authorization policy.
• Use report_dashnet_feedback only after the user explicitly approves sending the feedback.
• Validate critical decisions against cited source data.

Troubleshooting

Symptom	Check
Connector cannot be added	Confirm the client supports remote HTTP MCP with OAuth.
Login does not complete	Use the email provisioned by DashQ and restart the OAuth flow.
401	The sign-in session is missing or expired; authenticate again.
403 or no datasets	The account or dataset scope may not be provisioned; do not attempt a bypass.
SQL is blocked	Make it read-only, select fewer fields, add date filters and a limit, and reduce scanned data.
Catalog search is incomplete	Continue with dataset, table, and schema discovery tools.
A definition is unclear	Inspect visible schema/catalog metadata and request an explicit feedback report if needed.

For UI integrations, use Embedded experiences or Data APIs. Direct SQL is a separately approved path described in Direct warehouse access.

Need	Path
Embed DashQ UI	Embedded experiences
Fetch scoped JSON	Data APIs
Run approved model inference	Dashnet inference
Inspect public metric and field logic	Data Dictionary
Operate your own SQL/BI/local MCP connection	Direct warehouse connection