Databasehub CLI

MicrosoftOfficialPublished by Microsoft

Skill
Tool integration
Data and AI
MIT
No issues found

From the author

Analyzes Database Hub inventory, health, and security posture through Entra-authenticated Fabric APIs. Use for estate counts; SQL/PostgreSQL CPU, storage, and memory; Cosmos DB availability/RU; authentication/auditing/CMK warnings; and Fabric SQL inventory. Fabric SQL tuning routes to sqldb-cli; Warehouse/Lakehouse/Mirrored Database SQL to sqldw-cli. Triggers: data estate performance, database estate health, database security posture.

— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

databasehub-cli provides read-only analysis of a database estate through Fabric APIs. It enables users to query inventory counts, monitor performance metrics like CPU, storage, and memory for SQL and PostgreSQL, and check availability and RU consumption for Cosmos DB. The skill also reports on security posture, including authentication, auditing, and CMK warnings. It is designed for cross-engine estate visibility and routes specific tuning or deep-dive requests to specialized skills.

What it does

Retrieves estate-wide inventory counts and resource hierarchy information.
Analyzes health metrics including CPU, storage, and memory for SQL and PostgreSQL.
Reports Cosmos DB availability and normalized RU consumption.
Identifies security posture findings such as authentication, auditing, and CMK warnings.
Provides filtered health summaries based on saved-view scopes.
Routes specialized database tuning and deep-dive queries to appropriate product-specific skills.

When to use it

When you need a high-level inventory count of your database estate.
When investigating performance trends across multiple database engines.
When auditing security posture for Azure SQL and Arc SQL Server.
When checking Cosmos DB availability or RU saturation levels.
When you need to identify high or low usage resources across your data estate.

Advantages

Provides a unified view of cross-engine database health and security.
Enables granular drill-downs into specific resource performance.
Maintains strict read-only access for safe estate analysis.
Supports complex filtering through immutable snapshots for consistent reporting.

Usage examples

“Are there any performance issues I should know about in my data estate?”: The agent queries health families for SQL, PostgreSQL, and Cosmos DB, reports performance findings, and drills into high-usage resources.
“What should I fix first to improve security across my databases?”: The agent compares security issues related to authentication, auditing, and CMK posture, prioritizing affected resources.
“Show my database estate by engine and subscription.”: The agent retrieves inventory counts and groups resources by type and subscription.
“How is my CPU consumption looking across my databases recently?”: The agent queries CPU metrics for SQL and PostgreSQL and clarifies that Cosmos DB CPU metrics are not available.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/microsoft/databasehub-cli/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip databasehub-cli.zip -d .agents/skills

Documentation by Microsoft

Telemetry — MANDATORY. Every api.fabric.microsoft.com call must carry x-ms-fabric-skill: databasehub-cli (az rest: --headers "x-ms-fabric-skill=databasehub-cli"), including every LRO poll, fabric_lro and retry. Snippets omit it — add it anyway.

CRITICAL NOTES
To find the workspace details (including its ID) from workspace name: list all workspaces and, then, use JMESPath filtering
To find the item details (including its ID) from workspace ID, item type, and item name: list all items of that type in that workspace and, then, use JMESPath filtering
Database Hub estate routes are tenant-scoped and usually need neither a workspace nor an item ID. Apply notes 1-2 only when resolving a Fabric SQL catalog item or handing off to an item-specific skill.

Database Hub CLI

Read-only analysis of the database estate exposed through Database Hub. This skill executes live API calls; it does not answer estate questions from generic best practices or from files in the current directory.

Prerequisite knowledge

Private-over-public API contract — required authentication, transport, pagination, partial-result, error, and route-safety rules.
Health drill-downs and filtered snapshots — required for named SQL/PostgreSQL resources, per-resource SQL metrics, and filtered health comparisons.
Fabric authentication and CLI patterns
Fabric REST API concepts
Databases in Fabric documentation

Select one mode

Mode	Use when the request asks for	Read next
`consumption`	estate counts, subscriptions, resource hierarchy, mixed or engine-specific inventory, saved-view membership, or Fabric SQL catalog entries	references/consumption.md
`operations`	cross-engine performance, CPU/storage/memory, Cosmos DB availability/RU use, critical or monitored resources, issues/suggestions, or authentication/auditing/CMK posture	references/operations.md

For a request spanning both modes, establish inventory scope first, then run operations against that scope. Read each reference before issuing its calls.

Scope and routing boundaries

Request	Route to
Cross-engine estate inventory, health, findings, or security posture	`databasehub-cli`
Query Store, DMVs, blocking, plans, indexes, T-SQL, or tuning for one Fabric SQL Database	`sqldb-cli`
Warehouse, Lakehouse SQL endpoint, or Mirrored Database SQL queries and `queryinsights`	`sqldw-cli`
OneLake domains, labels, workspace/capacity governance, descriptions, endorsement, or tags	`onelake-catalog-cli`
Fabric workspace item search by name, description, workspace, or type	`search-consumption-cli`
Eventhouse or KQL Database queries	`eventhouse-cli`
Azure Monitor mirrored-catalog onboarding and business-impact correlation	`azmon-mirroredcatalogs-operations-cli`

Fabric SQL support here is catalog inventory only. Do not claim Database Hub health or posture coverage for Fabric SQL items. Do not substitute a single-database diagnostic skill for a cross-engine estate request.

Execution contract

Confirm the active Entra identity and requested scope. Portal-provided subscriptions, resource filters, or time range are query hints, never authorization.
Before the first Database Hub call, read references/private-over-public-api.md and the selected mode reference. For named-resource or filtered health drill-downs, read references/health-drilldowns.md in addition to operations.md, not instead of it.
Run the documented live calls through https://api.fabric.microsoft.com.
Follow every continuation token needed for the requested scope.
Report timeframe, aggregation, engine coverage, pagination completeness, coverage, and sanitized errors.
For prompts containing "all", "across", or "estate", complete every required summary/posture call in the selected workflow before answering. Attempt independent required calls even when another route fails; collect each route's error instead of short-circuiting the workflow. Only a page that depends on a failed prior page/token may be skipped. Do not defer required calls as an optional follow-up.
If a route or permission is unavailable, state the exact missing coverage; never invent data, switch to a workload host, or query ADX directly.

Must / Prefer / Avoid

MUST

Remain read-only. Decline create, deploy, enable, disable, update, delete, or remediation requests and route them to the owning product flow or skill.
Use a delegated Entra user token for the Fabric API and include x-ms-fabric-skill: databasehub-cli on every request.
Emit SQL and PostgreSQL health summaries only through the compact Select-Object projection in operations.md; never print raw summaries with their series arrays. A populated estate's raw summaries exceed the tool-output limit, and answering from partial file reads misattributes metrics.
For general cross-engine health/performance that includes Cosmos availability or RU, query Microsoft SQL, PostgreSQL, and Cosmos DB separately; preserve their different metric contracts in the answer. For a CPU-only request, query SQL and PostgreSQL and state that Cosmos CPU is not exposed by this contract.
For general cross-engine health/performance requests that include Cosmos availability/RU, and for all-findings requests, page Cosmos health with the filtered POST form until continuationToken is absent. A first-page Cosmos result is incomplete. Do not call Cosmos health for inventory-only or CPU-only requests.
In every Cosmos health answer, label processedAccounts and totalAccounts separately even when they are equal; do not compress them into one unlabeled account count. When they differ, literally label coverage partial or inconsistent. When totalAccounts is 0, report totalAccounts: 0, say there are no Cosmos DB accounts in scope and therefore no availability or normalized RU data, and do not call Cosmos healthy.
For CPU-only requests, report CPU evidence only. Do not add storage or memory counts merely because the summary response also contains them.
Treat HTTP 200 with non-empty errors, incomplete coverage, or remaining continuation tokens as partial, not complete success.
Label posture denominators exactly: authentication counts cover Azure SQL databases plus Arc SQL Server, while auditing and CMK counts cover Azure SQL databases only. Repeat the literal scope on each posture line: "Azure SQL + Arc SQL Server" for authentication and "Azure SQL only" for both auditing and CMK.
For "all issues and suggestions" output, report both totalFindingCount and totalAffectedResourceCount for every returned database family. Do not substitute affected-resource counts for finding totals.
State that Cosmos DB exposes availability and normalized RU consumption here, not CPU, memory, storage, latency, or throttled-request diagnostics.
State normalized RU saturation and explicitly say it does not prove throttled requests because this contract exposes no throttling metric. Do not rephrase saturation as a confirmed, likely, or potential throttling risk.

PREFER

Start with summary/count routes, then drill into only the affected population.
Use server-provided finding summaries and high/low usage classifications instead of inventing thresholds.
Project compact typed summaries from API responses. Do not dump full metric series or finding targetSummaries unless the user asks for them; oversized tool output is harder to ground reliably.
Group results by database family and priority, with affected counts and named examples only when the user asks for detail.
Reuse an immutable filter snapshot across pages and related filtered calls.

AVOID

Direct calls to ADX, Kusto, arcdataservices.com, workload regional hosts, or any MWC-token flow.
Agent-authored KQL, schema discovery, or arbitrary telemetry queries.
Claiming IO support; the current health contract exposes CPU, storage, and memory for Microsoft SQL/PostgreSQL.
Inferring throttled requests or throttling from normalized RU consumption alone. This contract reports RU saturation, not throttling events.
Treating an empty response as healthy when authorization, coverage, paging, or partial errors are unresolved.

Examples

User: Are there any performance issues I should know about in my data estate?
Mode: operations
Action: Query all three health families, report performance findings and partial coverage, then drill into high-usage SQL/PostgreSQL resources when needed.

User: What should I fix first to improve security across my databases?
Mode: operations
Action: Compare security issues with authentication, auditing, and CMK posture; prioritize affected resources without changing them.

User: Show my database estate by engine and subscription.
Mode: consumption
Action: Read counts, page the requested inventory, and group returned resources by type and subscription.

User: How is my CPU consumption looking across my databases recently?
Mode: operations
Action: Query Microsoft SQL and PostgreSQL CPU coverage and explicitly note that this Database Hub Cosmos contract has no CPU metric.

User: Give me a breakdown of all issues and suggestions across my data estate.
Mode: operations
Action: Combine health finding summaries with security issue/suggestion summaries and list affected resources through read-only drill-down routes.

Files

ATTRIBUTION.mdAdded by AutoGineer875 B
LICENSELicence file added by AutoGineer1.1 KiB
SKILL.md10.2 KiB
apm.yml332 B
references/consumption.md8.6 KiB
references/health-drilldowns.md5.9 KiB
references/operations.md16.8 KiB
references/private-over-public-api.md6.9 KiB

references/consumption.md

Database Hub consumption mode

Use this mode for estate discovery and inventory. Read private-over-public-api.md first.

Workflow
Inventory routes
Azure SQL hierarchy routes
Security finding summaries
Reporting contract

Workflow

Start with /databases/count to establish the total and type mix.
If the user asks only for totals, report totalCount and countByType and stop.
For mixed Estate V2 rows, use /savedView/resources/list with an immutable overviewFilters snapshot. Use /databases/list only for its legacy Azure SQL database / Arc SQL Server population.
Use hierarchy routes only to resolve a named Azure SQL database or to answer a subscription/resource-group/server hierarchy question.
Keep Fabric SQL catalog entries separate from Azure estate resources.
Report pagination completeness and any issue/enhancement fields returned with inventory rows.

Inventory routes

Method	Relative route	Request	Important response fields
GET	`/subscriptions`	none	array of `subscriptionId`, `displayName`, `tenantId`
GET	`/databases/count`	none	`totalCount`, `countByType`
GET	`/databases/warning/count`	none	SQL/Arc-only `warningCount`
POST	`/databases/list`	legacy `databaseType?` (`AzureSql` or `ArcSqlServer`), `top` 1-1000, `continuationToken?`	SQL/Arc `databases[]`, `totalCount`, `hasMore`, `continuationToken`
POST	`/azuresql/list`	required `resourceType`, `includeHealthData?`, `pageSize?`, `continuationToken?`	`resourceType`, `resources[]`, `totalCount`, `continuationToken`
POST	`/postgreSql/list`	`pageSize?`, `continuationToken?`	`resources[]`, `totalCount`, `continuationToken`
POST	`/cosmosDb/list`	`pageSize?`, `continuationToken?`	`resources[]`, `totalCount`, `continuationToken`
POST	`/savedView/resources/list`	required `overviewFilters`, plus `pageSize?`, `continuationToken?`	mixed `resources[]`, `totalCount`, `continuationToken`
POST	`/fabric/list`	`search?`, `pageSize?`, `continuationToken?`	Fabric SQL catalog `value[]`, `continuationToken`

For pageSize-based inventory routes, the default is 1000 and the valid range is 1-1000. /databases/list is the exception: it uses top 1-1000 instead of pageSize. Begin smaller when the user wants a summary rather than a full export.

/databases/count and /databases/list do not have the same population. Counts include broader Estate V2 types; the legacy list contains only Azure SQL databases and Arc SQL Server instances. Never compare their totals as if they were the same denominator.

Legacy SQL/Arc inventory body

{
  "top": 100
}

Omit databaseType for both legacy families, or use only AzureSql or ArcSqlServer. Other enum values are unsupported on this route; use the engine-specific or saved-view routes instead.

Engine-specific inventory bodies

{
  "pageSize": 100
}

PostgreSQL and Cosmos DB use that shape directly. Azure SQL also requires one canonical ARM resource type:

Resource	`resourceType`
Azure SQL databases	`microsoft.sql/servers/databases`
logical servers	`microsoft.sql/servers`
elastic pools	`microsoft.sql/servers/elasticpools`
Arc-enabled SQL Server instances	`microsoft.azurearcdata/sqlserverinstances`
SQL Server on Azure VMs	`microsoft.sqlvirtualmachine/sqlvirtualmachines`
managed instances	`microsoft.sql/managedinstances`

Set includeHealthData: true only on /azuresql/list, and only when its issue/enhancement flags are required. PostgreSQL and Cosmos inventory return their supported finding flags without that property. Do not treat inventory flags as a substitute for the operations health routes.

Saved-view body

An empty immutable filter snapshot selects the supported mixed Estate V2 resource types:

{
  "pageSize": 100,
  "overviewFilters": {}
}

Supported membership filters include databaseTypes, statuses, subscriptionIds, resourceGroups, locations, structured tags, and skuTiers.

{
  "pageSize": 100,
  "overviewFilters": {
    "databaseTypes": ["AzureSql", "PostgreSql", "Cosmos"],
    "subscriptionIds": ["<subscription-guid>"],
    "tags": [
      {
        "key": "environment",
        "value": "production"
      }
    ]
  }
}

Each tag filter requires key; omit value to match any value for that key.

When the user requests an exact number of pages, issue that many separate POST requests and stop even if another token remains. Emit a compact result with pageCount, returnedRowCount, totalCount, and the final continuationToken. For example, two 10-row pages must report pageCount: 2 and returnedRowCount: 20; do not infer those values only in the final prose. When the user asks to return the rows, the final answer must also enumerate every requested row, grouped by the returned databaseType. Include each row's returned name and add its server, workspace, resource group, subscription, or resource ID when names are duplicated. The compact page aggregate proves completeness but does not replace the requested row listing.

Request each page once and print it in the same call with its rows labeled, so you never re-request a page to recover a field:

$page | Select-Object totalCount, continuationToken, @{ n = 'resources'; e = {
    , @($_.resources | Select-Object databaseType, name, id, resourceGroupName,
      @{ n = 'subscription'; e = { $_.subscription.name } }) } } |
  ConvertTo-Json -Depth 6

searchFindingKeys is not a standalone finding-membership filter. It is used only with a non-empty searchTerm, and active finding flags are OR'd into that keyword search. Do not use it to claim that returned rows all have a specific issue.

For named finding resources:

performance high/low groups: use SQL or PostgreSQL usage-details;
authentication, auditing, or CMK gaps: use the matching warning route; and
other security findings: inspect issues / enhancements on engine-specific inventory. On /azuresql/list, request them with includeHealthData: true; PostgreSQL and Cosmos return supported flags without that property. Filter the returned rows client-side and state when no dedicated server-side membership route exists.

Fabric SQL catalog body

{
  "search": "",
  "pageSize": 100
}

Rows contain id, type, catalogEntryType, displayName, description, and workspace hierarchy. This route is inventory only; hand off a selected Fabric SQL database to sqldb-cli for T-SQL or item-level diagnostics.

Azure SQL hierarchy routes

Method	Relative route	Purpose
GET	`/subscriptions/{subscriptionId}/resourceGroups`	list resource groups
GET	`/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/servers`	list logical servers
GET	`/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/servers/{serverName}/databases`	list database names
GET	`/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/servers/{serverName}/databases/{databaseName}`	read one Azure SQL database from ARM

Resolve names by listing and filtering. Never guess a subscription, resource group, server, resource ID, workspace ID, or item ID.

Security finding summaries

The overview summary routes currently support only the security category:

GET /overviewFindings/security/{issues|suggestions}/summaries
GET /overviewFindings/security/{issues|suggestions}/{MicrosoftSql|PostgreSql|CosmosDb}/summary

Use suggestions in requests; the response can canonicalize that relevance to enhancements. Important fields are databaseFamily, totalFindingCount, totalAffectedResourceCount, postureAffectedResourceCount, affectedResourceCounts, targetSummaries, and errors.

Reporting contract

Distinguish resource count from finding count: one resource can have multiple findings.
Group by returned type or databaseFamily; do not infer an engine from a resource name.
Include totalCount and whether every continuation token was consumed.
State which population produced each total. In particular, do not present the legacy SQL/Arc list total as the broader /databases/count denominator.
If inventory is empty, state the scope and filters used before concluding that no resources exist.
If a resource name is duplicated, include server, subscription, resource group, workspace, or full resource ID as needed to disambiguate it.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by

Microsoft

Publisher

Microsoft (Official)

Source

microsoft/skills-for-fabric · skills/databasehub-cli · commit f8fac11

Licence

MIT License (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

Also distributed in

microsoft/skills-for-fabric

AutoGineer is not affiliated with or endorsed by Microsoft or Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download databasehub-cli.zip