Add Azure SQL MCP quickstart with azd deployment templates

[kshyju]

Summary

Adds a new Azure SQL MCP sample under samples/applications/azure-sql-mcp. The sample deploys a hosted mcp-sql server in Azure Connector Namespace backed by Azure SQL Database, using azd and Bicep.

https://learn.microsoft.com/en-us/azure/logic-apps/connector-namespace/hosted-mcp-quickstart?pivots=sql

What's included

• Provisions Azure SQL Database with a seeded dbo.BlogPosts table
• Deploys Azure Connector Namespace and a hosted SQL MCP server
• Configures Data API Builder through the included dab-config.json
• Passes SQL and Application Insights connection strings as hosted MCP configuration values
• Grants the Connector Namespace managed identity access to the SQL database
• Adds Application Insights and Log Analytics for telemetry
• Includes post-provision scripts for database seeding, firewall setup, and managed identity grants
• Provides README instructions for deployment, VS Code MCP setup, Azure Portal inspection, cleanup, and related docs

Validation

• Built Bicep template successfully
• Validated PowerShell scripts parse
• Validated Bash script syntax
• Scanned sample for generated artifacts and hardcoded credentials

[lilyjma]

Testing feedback: 3 fixes needed for azd up to work end-to-end

I deployed the azure-sql-mcp sample via azd up (Connector Namespace + hosted MCP, SystemAssigned identity, eastasia) and hit three issues. With the changes below it provisions cleanly and the describe_entities → read_records agent flow works. All changes are under samples/applications/azure-sql-mcp/.

1. azure.yaml — invalid hook shell kind (blocking)
azd rejects shell: bash (The 'bash' kind is not supported; valid kinds: sh, pwsh, python, js, ts). The script's #!/usr/bin/env bash shebang still runs it under bash.

     posix:
-      shell: bash
+      shell: sh
         run: ./scripts/post-provision.sh

2. scripts/*.sh committed as non-executable (blocking)
pre-provision.sh and post-provision.sh are committed as 100644, so azd execs them under sh and fails with Permission denied (exit 126). Fix in the PR by committing them as 100755:

git update-index --chmod=+x scripts/pre-provision.sh scripts/post-provision.sh

This is a one-time repo change — deployers don't run anything; a fresh clone checks the scripts out executable automatically.

3. Entity-name mismatch breaks the describe → read flow (usability)
describe_entities surfaces the GraphQL singular name (BlogPost), but read_records only accepts the plural name (BlogPosts) — so an agent following the documented "describe then read" guidance fails the first call with EntityNotFound. Making singular == plural fixes it (the source table stays dbo.BlogPost). Apply in dab-config.json and the equivalents in scripts/post-provision.sh and scripts/post-provision.ps1:

   "entities": {
-    "BlogPost": {
+    "BlogPosts": {
       "source": { "object": "dbo.BlogPost", "type": "table" },
       "graphql": {
         "type": {
-          "singular": "BlogPost",
+          "singular": "BlogPosts",
           "plural": "BlogPosts"

After these three changes I verified a fresh deployment: describe_entities reports BlogPosts and read_records entity=BlogPosts returns both seeded rows. 🎉

[kshyju]

@lilyjma Pushed an update addressing the comments. Testing on windows looks good for me.

[lilyjma]

Follow-up on issue #2 (non-executable scripts) — who it affects

Just to clarify the impact, since it's easy to miss: this one specifically hits macOS/Linux users, and it blocks their first azd up.

Git stores the executable bit in the commit. The scripts are currently committed as 100644 (non-executable), so any fresh git clone on macOS/Linux checks them out non-executable. azd invokes the post-provision hook directly via /bin/sh <path>, and the OS refuses to exec a non-executable file:

/bin/sh: .../scripts/post-provision.sh: Permission denied
ERROR: 'postprovision' hook failed with exit code: '126'

Until it's fixed in the PR, every macOS/Linux user would have to manually run chmod +x scripts/*.sh before azd up succeeds — an easy step to miss.

Windows users are unaffected (azd runs the pwsh hook, and Windows doesn't enforce a Unix execute bit), and committing the scripts as 100755 is a no-op for them — so the fix is purely beneficial with no downside.

I re-tested against the latest PR head: with the scripts at 100644, azd provision failed at the post-provision hook with exit 126; after a local chmod +x it deployed cleanly and the describe_entities → read_records flow worked (BlogPosts resolves correctly). So issues #1 and #3 look resolved — only #2 remains.

[lilyjma]

@kshyju I pushed out a fix for #2. I think we're good to go now!