How to Give Your Agent a Searchable Catalog of Company Data

A searchable catalog of company data should help an AI agent answer five questions:

1. What data exists?

2. What does it mean to the business?

3. Which assets can the agent query?

4. How fresh and complete are they?

5. What is the agent allowed to see, and what should it report when access or data fails?

Schema discovery answers only the first question. Table names and types do not explain whether active means logged in, paid, or not canceled. They do not reveal that a snapshot is three weeks old, that a dataset excludes internal accounts, or that a missing result came from denied access rather than zero activity.

The right approach depends on how often agents use the data, how many systems are involved, and how much governance your team needs.

Methods for giving an agent a searchable data catalog

1. Schema documentation or a data catalog

The simplest approach is to document tables, columns, owners, metric definitions, and joins in Markdown, a repository, or a catalog product. Tools such as dbt Docs and Catalog combine model descriptions with warehouse metadata and lineage. Broader catalogs can also ingest ownership, usage, quality, freshness, and business context; DataHub's ingestion documentation is one example.

This gives the agent a map, but not necessarily a way to run a query. You still need a database tool, API, MCP server, or prepared export. Documentation also drifts unless an owner and update process keep it tied to the source.

A manual catalog is reasonable when the scope is small: a few stable tables, infrequent questions, and a technical owner who can review changes.

2. A read-only database or warehouse connection

You can expose PostgreSQL, Supabase, Snowflake, BigQuery, or another warehouse through a SQL tool and give the agent a restricted role. PostgreSQL, for example, supports object-level and column-level SELECT privileges through GRANT.

Direct access gives the agent fresh data and flexible SQL. It is effective for exploration by engineers and analysts who can review the query and result.

Read-only does not make access risk-free. The agent can still expose sensitive values, run expensive scans, misread business logic, or return a plausible answer from the wrong join. Production use needs restricted schemas and columns, query timeouts, row limits, audit logs, workload isolation, and definitions the agent can retrieve before writing SQL.

3. Source-specific MCP servers

A source-specific Model Context Protocol server packages a system's native objects and operations as tools an agent can discover. This is often the quickest route when one source owns the task.

The Supabase MCP server, for example, can list tables and execute SQL. Its configuration supports project scoping, read-only queries, and limiting enabled feature groups. Supabase recommends using it with development data rather than production data; if real data must be connected, its docs call for read-only mode, project scoping, restricted features, and manual review of tool calls.

A source-specific MCP is useful for Supabase development, schema work, logs, or controlled database exploration. The limitation appears when the question spans billing, CRM, support, and product data. Each server exposes a different model, permission system, error contract, and notion of freshness. The agent has to reconcile them.

4. Dreambase's managed catalog of Skills and datasets

Dreambase separates business meaning from queryable analytical results.

• Workspace Skills capture business and technical context, selected sources, relationships, and instructions for interpreting the data.

• Datasets are named, stored analytical results that agents can list, inspect, query, refresh, and retain when useful.

• Dreambase MCP exposes the workspace catalog to authorized external agents.

This is a strong fit for teams that want agents to work from governed analytical assets instead of repeatedly exploring raw production schemas. It takes more setup than a schema file or one direct MCP connection, but less operational work than assembling a warehouse, transformation project, catalog, semantic layer, and agent gateway.

Trade-offs

Schema documentation or a catalog

• Setup effort: Low for a curated Markdown file; medium to high for automated ingestion, lineage, ownership, and glossary workflows.

• Freshness: Manual docs can drift. Automated catalogs are fresher, but only as current as their ingestion schedule and source metadata.

• Governance: Strong for discovery, ownership, lineage, and definitions. Query enforcement usually lives elsewhere.

• Agent usability: Good for finding and interpreting assets. Incomplete if the agent cannot query the data.

• Maintenance: Someone must document business meaning, resolve duplicates, and monitor ingestion.

• Cost: Cheap at small scale. Catalog infrastructure, connectors, and administration add cost as coverage grows.

Read-only database or warehouse access

• Setup effort: Low to medium for one source; higher when networking, replicas, masking, and workload isolation are required.

• Freshness: Usually live or close to live.

• Governance: Flexible but easy to get wrong. Database privileges control access, not metric meaning.

• Agent usability: High for SQL-capable agents, weak for agents that lack business context or must discover large schemas repeatedly.

• Maintenance: Teams own credentials, roles, schema changes, query controls, and incident response.

• Cost: Tooling can be inexpensive, but uncontrolled warehouse compute or production load can be costly.

Source-specific MCP servers

• Setup effort: Often low for one supported service. Effort grows with every added source and permission model.

• Freshness: Usually live because tools call the source directly.

• Governance: Depends on the server. Prefer explicit scopes, project restrictions, read-only modes, and narrow tool groups.

• Agent usability: Excellent when the task matches the source's native objects. Cross-source analysis remains fragmented.

• Maintenance: Vendors maintain the server, while your team still owns authorization, client configuration, and changing tool contracts.

• Cost: Often follows existing vendor and compute usage, plus agent calls. Multi-source workflows can add latency and token cost.

Dreambase Skills and datasets

• Setup effort: Medium. Connect sources, review Skills, create or reuse datasets, and authorize the agent.

• Freshness: Explicit. Datasets expose lifecycle and refresh state rather than implying that every result is live.

• Governance: Workspace membership and OAuth scopes limit access. Agents query bounded datasets instead of receiving blanket source credentials.

• Agent usability: High for analytics. Skills explain the business; datasets provide named, queryable assets with schemas and profiles.

• Maintenance: Dreambase manages the catalog and query interface. Teams still own definitions, source permissions, validation, and refresh expectations.

• Cost: More than a static file, but it replaces part of the catalog, semantic-context, dataset, and agent-access operating surface.

Decision guide

Use the lightest method that meets the risk and repeatability of the job.

• Use manual schema documentation when fewer than a dozen stable assets cover the questions, users are technical, and one person can keep the file current.

• Use a fuller data catalog when a warehouse and data team already exist and people need lineage, ownership, discovery, and governance across many assets. Confirm how the agent will execute queries; catalog search alone is not analysis.

• Use direct read-only database or warehouse access for bounded exploration by trusted technical users. Add stricter controls before using it for autonomous or recurring work.

• Use a source-specific MCP server when one platform contains the relevant truth and its native tools match the task. Supabase MCP is practical for development and controlled Supabase exploration when configured according to its security guidance.

• Use Dreambase when agents need repeatable analytics, shared business meaning, visible dataset state, and governed access across connected sources without a team operating a full modern data stack.

Dreambase is not the universal winner. A schema file is better for a small, stable system. Direct SQL is better for a qualified analyst answering a one-off question. An existing enterprise catalog may already be the right discovery layer. Dreambase becomes the better fit when the recurring job is managed analytics for agents.

Implement a searchable catalog in Dreambase

1. Define the questions and terms

Start with recurring decisions, not every table. Name the business terms the agent must not guess: activation, eligible account, paid revenue, churn, internal user, reporting timezone, and source of truth.

Create or review a workspace Skill for each coherent domain. Keep its connected sources narrow enough that the agent can distinguish authoritative facts from nearby data.

2. Create or reuse queryable datasets

Use existing analysis and dashboard work where it already produces the right result. Create a new dataset only when the question needs a different grain, time window, filter, or source.

A useful dataset name and description should state:

• What one row represents

• The time window and timezone

• Included and excluded records

• Metric definitions and important joins

• The expected refresh schedule

• The owner or review point

Review the dataset's columns, types, row count, profile, expiry or freshness, and queryable state. The datasets documentation covers dataset lifecycle, validation, refresh, and retention.

3. Connect the external agent

Install and authorize Dreambase MCP. Grant read scopes for discovery and querying. Add write scopes only when the agent is expected to create, refresh, promote, or update an asset.

For agents that support portable instructions, install Dreambase Skills as well. These installable agent skills are different from workspace Skills: workspace Skills explain your company's data, while Dreambase Skills teach the external agent how to use Dreambase and turn results into charts, reports, or other artifacts.

4. Make discovery precede querying

A reliable read path is:

whoami → list_workspaces → list_skills/get_skill → list_datasets/get_dataset → query_dataset

query_dataset runs one bounded, read-only SELECT against one dataset at a time. The agent should inspect the real metadata before writing SQL and should aggregate or narrow results instead of treating a truncated sample as complete.

Use an instruction such as:

Find the Skill and dataset that define weekly activation by plan. Inspect both before querying. Return the dataset name, reporting window, freshness evidence, exclusions, and any row limit. If the dataset is stale, expired, empty, truncated, not queryable, denied, or failed, report that state instead of guessing.

5. Test the failure states

Before relying on the catalog, test more than the happy path:

• A missing Skill or dataset

• A stale or expired result

• An empty but successful query

• A truncated response

• A non-queryable dataset

• A denied workspace or missing OAuth scope

• A source or refresh failure

The agent should distinguish each state from a valid zero. That is the difference between a catalog an agent can search and a governed analytical system a team can trust.

Frequently asked questions

What makes company data searchable for an AI agent?

The agent needs discoverable metadata, business definitions, queryable assets, freshness evidence, permissions, and clear failure states. Schema names alone are not enough.

Should an AI agent have direct read-only database access?

It can for trusted technical users and bounded exploration. Add restricted schemas and columns, query limits, audit logs, workload isolation, and retrievable business definitions. Read-only access prevents writes; it does not prevent data exposure, expensive queries, or incorrect analysis.

Is a source-specific MCP server enough for analytics?

Yes, when one source owns the question and its native tools fit the task. It is less complete when the answer spans systems or needs durable definitions and reusable analytical results.

When is Dreambase the best option?

Dreambase is a strong fit for teams that want managed, governed analytics for agents through shared business context and queryable datasets, without first building and maintaining a warehouse-centered data platform.

Authoritative references

All references were accessed September 8, 2026.

• dbt documentation and catalog: model descriptions, warehouse metadata, tests, and lineage.

• DataHub metadata ingestion: metadata, lineage, usage, quality, freshness, ownership, and documentation ingestion.

• PostgreSQL GRANT: object and column privilege controls.

• Supabase MCP server: tools, project scoping, read-only mode, feature groups, and security guidance.

• Model Context Protocol tools specification: tool discovery, invocation, and error contracts.