db-mcp 1.1.1 → 2.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (84) hide show
  1. package/.gitleaks.toml +9 -0
  2. package/.trivyignore +8 -0
  3. package/README.md +193 -120
  4. package/dist/{chunk-TVIZ3XJH.js → chunk-5Y42NPBP.js} +4168 -2411
  5. package/dist/{chunk-AOUL5SHS.js → chunk-645ZEFLA.js} +70 -20
  6. package/dist/chunk-OKOVZ5QE.js +28 -0
  7. package/dist/chunk-SFJQCNG7.js +131 -0
  8. package/dist/{chunk-FW7UCRLN.js → chunk-VIDSICEL.js} +3 -0
  9. package/dist/chunk-WBER5YY4.js +2053 -0
  10. package/dist/{chunk-4IA3DB5C.js → chunk-X3MUUOWM.js} +19 -2
  11. package/dist/{chunk-Z2GFQU3G.js → chunk-Z7C2TM4L.js} +114 -21
  12. package/dist/cli.js +79 -5
  13. package/dist/{http-VSB7DBJR.js → http-6KF4ULDI.js} +199 -77
  14. package/dist/index.d.ts +231 -8
  15. package/dist/index.js +6 -5
  16. package/dist/{sqlite-26V3Y4MK.js → sqlite-U5KSYQXK.js} +62 -138
  17. package/dist/{sqlite-native-5O7FZJGB.js → sqlite-native-JXMCFQBA.js} +575 -113
  18. package/dist/worker-script.js +34 -10
  19. package/logs/.gitkeep +1 -0
  20. package/mcp-config-example.json +83 -0
  21. package/package.json +9 -8
  22. package/playwright.config.ts +1 -1
  23. package/scripts/update-badges.ts +99 -0
  24. package/server.json +7 -5
  25. package/test-server/README.md +20 -23
  26. package/test-server/code-map.md +45 -33
  27. package/test-server/reset-database.ps1 +59 -17
  28. package/test-server/scripts/README.md +27 -0
  29. package/test-server/{test-help-resources.mjs → scripts/test-help-resources.mjs} +12 -5
  30. package/test-server/scripts/test-prompts.mjs +251 -0
  31. package/test-server/{test-tool-annotations.mjs → scripts/test-tool-annotations.mjs} +9 -4
  32. package/test-server/test-advanced/README.md +70 -0
  33. package/test-server/test-advanced/test-codemode-advanced-admin.md +174 -0
  34. package/test-server/test-advanced/test-codemode-advanced-core.md +193 -0
  35. package/test-server/test-advanced/test-codemode-advanced-geo.md +157 -0
  36. package/test-server/test-advanced/test-codemode-advanced-introspection.md +171 -0
  37. package/test-server/test-advanced/test-codemode-advanced-json.md +169 -0
  38. package/test-server/test-advanced/test-codemode-advanced-migration.md +160 -0
  39. package/test-server/test-advanced/test-codemode-advanced-stats.md +185 -0
  40. package/test-server/test-advanced/test-codemode-advanced-text.md +183 -0
  41. package/test-server/test-advanced/test-codemode-advanced-transactions.md +136 -0
  42. package/test-server/test-advanced/test-codemode-advanced-vector.md +141 -0
  43. package/test-server/test-codemode/README.md +121 -0
  44. package/test-server/test-codemode/test-codemode-admin.md +223 -0
  45. package/test-server/test-codemode/test-codemode-core.md +286 -0
  46. package/test-server/test-codemode/test-codemode-geo.md +177 -0
  47. package/test-server/test-codemode/test-codemode-introspection.md +190 -0
  48. package/test-server/test-codemode/test-codemode-json.md +237 -0
  49. package/test-server/test-codemode/test-codemode-migration.md +278 -0
  50. package/test-server/test-codemode/test-codemode-sandbox.md +413 -0
  51. package/test-server/test-codemode/test-codemode-stats.md +232 -0
  52. package/test-server/test-codemode/test-codemode-text.md +237 -0
  53. package/test-server/test-codemode/test-codemode-transactions.md +236 -0
  54. package/test-server/test-codemode/test-codemode-vector.md +244 -0
  55. package/test-server/test-codemode/test-codemode-wasm-degradation.md +394 -0
  56. package/test-server/test-database.sql +37 -1
  57. package/test-server/test-resources.md +43 -16
  58. package/test-server/test-tool-groups/README.md +100 -0
  59. package/test-server/test-tool-groups/test-admin-core.md +165 -0
  60. package/test-server/test-tool-groups/test-admin-extensions.md +133 -0
  61. package/test-server/{test-tools.md → test-tool-groups/test-core-data.md} +103 -17
  62. package/test-server/test-tool-groups/test-core-schema.md +240 -0
  63. package/test-server/test-tool-groups/test-geo-haversine.md +130 -0
  64. package/test-server/test-tool-groups/test-geo-spatialite.md +110 -0
  65. package/test-server/test-tool-groups/test-introspection-diagnostics.md +123 -0
  66. package/test-server/test-tool-groups/test-introspection-schema.md +133 -0
  67. package/test-server/test-tool-groups/test-json-read.md +219 -0
  68. package/test-server/test-tool-groups/test-json-write.md +157 -0
  69. package/test-server/test-tool-groups/test-migration.md +193 -0
  70. package/test-server/test-tool-groups/test-stats-advanced.md +118 -0
  71. package/test-server/test-tool-groups/test-stats-basic.md +156 -0
  72. package/test-server/test-tool-groups/test-text-advanced.md +169 -0
  73. package/test-server/test-tool-groups/test-text-basic.md +177 -0
  74. package/test-server/test-tool-groups/test-transactions.md +179 -0
  75. package/test-server/test-tool-groups/test-vector-read.md +130 -0
  76. package/test-server/test-tool-groups/test-vector-write.md +115 -0
  77. package/test-server/tool-reference.md +79 -58
  78. package/tsconfig.build.json +6 -0
  79. package/dist/chunk-RHVEZ42P.js +0 -873
  80. package/test-server/test-agent-experience.md +0 -243
  81. package/test-server/test-group-tools.md +0 -861
  82. package/test-server/test-tools-advanced-1.md +0 -517
  83. package/test-server/test-tools-advanced-2.md +0 -487
  84. package/test-server/test-tools-codemode.md +0 -629
@@ -0,0 +1,133 @@
1
+ # db-mcp Tool Group Testing: [introspection-schema]
2
+
3
+ > [!IMPORTANT]
4
+ > **Do not track progress in this file.** Track your test progress, coverage matrix, and findings in your internal task tracking system (artifact). However, you SHOULD edit this file to fix any factual errors, broken code, or incorrect assertions in the test prompts.
5
+ > If there is nothing to fix, don't update UNRELEASED.md.
6
+ > We're currently testing Native mode.
7
+
8
+ ## WASM Mode
9
+
10
+ > When testing against a **WASM backend** (`sqlite-wasm` / sql.js): All 6 schema introspection tools are fully WASM-compatible. No items to skip.
11
+ >
12
+ > **Minor difference**: `sqlite_schema_snapshot` may report `test_articles_fts` in the `tables` array but it is not queryable (FTS5 is unavailable in WASM). Treat its presence as expected but non-functional.
13
+
14
+ **Step 1:** Confirm you read the server help content sourced from `C:\Users\chris\Desktop\db-mcp\src\constants\server-instructions\gotchas.md` using `view_file` (not grep or search) — to understand documented behaviors, edge cases, and response structures for this tool group.
15
+
16
+ **Step 2:** Please conduct an exhaustive test of the **introspection-schema** tool group specified in the group-specific checklist below using live MCP server tool calls directly — not scripts/terminal.
17
+
18
+ **Step 3:** The agent should update C:\Users\chris\Desktop\db-mcp\UNRELEASED.md with any/all changes/fixes.
19
+
20
+ **Note** If temp tables are present from a previous test pass, it's because the database is locked. Ignore them.
21
+
22
+ ## Reporting Format
23
+
24
+ - ❌ Fail: Tool errors or produces incorrect results (include error message)
25
+ - ⚠️ Issue: Unexpected behavior or improvement opportunity
26
+ - 📦 Payload: Unnecessarily large response that should be optimized.
27
+
28
+ ## Test Database Schema
29
+
30
+ | Table | Rows | Columns | JSON Columns |
31
+ | ----------------- | ---- | ----------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
32
+ | test_products | 16 | id, name, description, price, category, created_at | — |
33
+ | test_orders | 20 | id, product_id (FK), customer_name, quantity, total_price, order_date, status | — |
34
+ | test_jsonb_docs | 6 | id, doc, metadata, tags, created_at | **doc**, **metadata** (nested), **tags** (array) |
35
+ | test_articles | 8 | id, title, body, author, category, published_at | — |
36
+ | test_users | 9 | id, username, email, phone, bio, created_at | — |
37
+ | test_measurements | 200 | id, sensor_id, temperature, humidity, pressure, measured_at | — |
38
+ | test_embeddings | 20 | id, content, category, embedding | **embedding** (8-dim float array); category values: database, fitness, food, tech, travel |
39
+ | test_locations | 15 | id, name, city, latitude, longitude, type | — |
40
+ | test_categories | 17 | id, name, path, level | — |
41
+ | test_events | 100 | id, event_type, user_id (INT, 8 values), payload, event_date | **payload** (JSON) |
42
+
43
+ **Key FK:** `test_orders.product_id → test_products.id`
44
+
45
+ ## Testing Requirements
46
+
47
+ > [!CAUTION]
48
+ > **Zero tolerance for raw MCP errors.** ANY response that is a raw MCP error (e.g., `-32602`, `isError: true`, no `success` field) is a **bug that must be reported and fixed**.
49
+
50
+ 1. Use existing `test_*` tables for read operations
51
+ 2. **Error path testing**: For **every** tool, test (a) domain error and (b) Zod validation error (`{}`). Both must return `{success: false, error: "..."}`.
52
+ 3. **Output schema testing**: For tools with `outputSchema`, confirm valid calls return structured JSON.
53
+
54
+ ## Structured Error Response Pattern
55
+
56
+ ```json
57
+ { "success": false, "error": "Human-readable error message" }
58
+ ```
59
+
60
+ | Type | Source | What you see | Verdict |
61
+ | -------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------- | ------------------ |
62
+ | **Handler error** ✅ | Handler catches error and returns `{success: false, error: "..."}` | Parseable JSON object with `success` and `error` fields | Correct |
63
+ | **MCP error** ❌ | Uncaught throw propagates to MCP framework | Raw text error string, `isError: true` — no `success` field | Bug — report as ❌ |
64
+
65
+ ### Zod Validation Errors
66
+
67
+ **Zod refinement leak pattern:** `.partial()` does NOT strip `.min(N)` / `.max(N)` refinements. **Fix:** Remove refinements from schema, validate inside handler.
68
+
69
+ ### Output Schema Validation Errors
70
+
71
+ If valid inputs return raw MCP `-32602` mentioning "output schema", report as ❌.
72
+
73
+ ---
74
+
75
+ ## Group Focus: introspection-schema
76
+
77
+ > **Instructions**: Execute every numbered checklist item with the exact inputs shown. Compare responses against the expected results. Report any deviation.
78
+
79
+ ### introspection-schema Group Tools (6)
80
+
81
+ 1. sqlite_dependency_graph
82
+ 2. sqlite_topological_sort
83
+ 3. sqlite_cascade_simulator
84
+ 4. sqlite_schema_snapshot
85
+ 5. sqlite_constraint_analysis
86
+ 6. sqlite_migration_risks
87
+
88
+ **Checklist:**
89
+
90
+ **Graph Analysis:**
91
+
92
+ 1. `sqlite_dependency_graph({})` → nodes ≥ 2, edges includes `test_orders → test_products` (FK); stats.totalRelationships ≥ 1
93
+ 2. `sqlite_topological_sort({})` → order array with `test_products` before `test_orders` (FK dependency); hasCycles = false
94
+ 3. `sqlite_topological_sort({direction: "drop"})` → order array with `test_orders` before `test_products` (reverse topo sort)
95
+ 4. `sqlite_cascade_simulator({table: "test_products"})` → affectedTables includes `test_orders` (FK dependent)
96
+ 5. `sqlite_cascade_simulator({table: "test_measurements"})` → affectedTables is empty (no tables reference it via FK)
97
+ 6. `sqlite_cascade_simulator({table: "nonexistent_table_xyz"})` → `{success: false, error: "..."}`
98
+
99
+ **Schema Analysis:**
100
+
101
+ 7. `sqlite_schema_snapshot({})` → snapshot.tables ≥ 11 (10 test\_ tables + FTS virtual); stats.indexes ≥ 4; generatedAt present
102
+ 8. `sqlite_schema_snapshot({sections: ["tables"]})` → snapshot.tables is populated, but views/indexes should be missing or empty
103
+ 9. `sqlite_schema_snapshot({compact: true})` → columns array should be omitted or minimal
104
+ 10. `sqlite_constraint_analysis({})` → findings array; summary.totalFindings ≥ 0; summary.byType and bySeverity objects present
105
+ 11. `sqlite_constraint_analysis({table: "test_orders"})` → findings restricted to `test_orders`
106
+ 12. `sqlite_constraint_analysis({checks: ["unindexed_fk"]})` → findings restricted to `unindexed_fk`
107
+ 13. `sqlite_migration_risks({statements: ["DROP TABLE test_products"]})` → risks array non-empty; risk category includes data_loss or destructive
108
+ 14. `sqlite_migration_risks({statements: ["ALTER TABLE test_users ADD COLUMN age INTEGER"]})` → low risk
109
+ 15. `sqlite_migration_risks({statements: ["CREATE TABLE new_table (id INTEGER PRIMARY KEY)", "DROP TABLE test_products"]})` → summary.totalStatements = 2; summary.highestRisk ≥ "high"
110
+
111
+ **Error path testing:**
112
+
113
+ 🔴 16. `sqlite_cascade_simulator({})` → Zod validation error (missing required `table`). Must be handler error, NOT raw MCP error.
114
+ 🔴 17. `sqlite_migration_risks({statements: []})` → report behavior for empty array
115
+
116
+ **Zod validation sweep** — call each tool with `{}` (empty params). Must return handler error, NOT raw MCP error:
117
+
118
+ 🔴 18. `sqlite_dependency_graph({})` → handler error (or success if no required params)
119
+ 🔴 19. `sqlite_topological_sort({})` → handler error (or success if no required params)
120
+ 🔴 20. `sqlite_schema_snapshot({})` → handler error (or success if no required params)
121
+ 🔴 21. `sqlite_constraint_analysis({})` → handler error (or success if no required params)
122
+ 🔴 22. `sqlite_migration_risks({})` → handler error
123
+
124
+ ---
125
+
126
+ ## Post-Test Procedures
127
+
128
+ 1. **Triage findings**: Create implementation plan if issues found
129
+ 2. **Scope of fixes**: Handler code, server-instructions, test database, this prompt
130
+ 3. **Validate**: Instruct the user to run the test suite (Vitest/Playwright), lint, and typecheck. Do NOT run them yourself.
131
+ 4. **Commit**: Stage and commit — do NOT push
132
+ 5. **Live re-test**: After server rebuild
133
+ 6. **Final summary**: After testing/re-testing
@@ -0,0 +1,219 @@
1
+ # db-mcp Tool Group Testing: [json-read]
2
+
3
+ > [!IMPORTANT]
4
+ > **Do not track progress in this file.** Track your test progress, coverage matrix, and findings in your internal task tracking system (artifact). However, you SHOULD edit this file to fix any factual errors, broken code, or incorrect assertions in the test prompts.
5
+ > If there is nothing to fix, don't update UNRELEASED.md.
6
+ > We're currently testing Native mode.
7
+
8
+ ## WASM Mode
9
+
10
+ > When testing against a **WASM backend** (`sqlite-wasm` / sql.js): All 18 JSON read tools are fully WASM-compatible. No items to skip or adjust.
11
+
12
+ **Step 1:** Confirm you read the server help content sourced from `C:\Users\chris\Desktop\db-mcp\src\constants\server-instructions\gotchas.md` using `view_file` (not grep or search) — to understand documented behaviors, edge cases, and response structures for this tool group.
13
+
14
+ **Step 2:** Please conduct an exhaustive test of the **json-read** tool group specified in the group-specific checklist below using live MCP server tool calls directly — not scripts/terminal.
15
+
16
+ **Step 3:** The agent should update C:\Users\chris\Desktop\db-mcp\UNRELEASED.md with any/all changes/fixes.
17
+
18
+ **Note** If temp tables are present from a previous test pass, it's because the database is locked. Ignore them.
19
+
20
+ ## Reporting Format
21
+
22
+ - ❌ Fail: Tool errors or produces incorrect results (include error message)
23
+ - ⚠️ Issue: Unexpected behavior or improvement opportunity
24
+ - 📦 Payload: Unnecessarily large response that should be optimized — **blocking, equally important as ❌ bugs**. Oversized payloads waste LLM context window tokens and degrade downstream tool-calling quality. Report the response size in KB and suggest a concrete optimization.
25
+
26
+ ## Test Database Schema
27
+
28
+ The test database (test-server/test.db) contains these tables with JSON-relevant columns:
29
+
30
+ | Table | Rows | Columns | JSON Columns |
31
+ | ----------------- | ---- | ----------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
32
+ | test_products | 16 | id, name, description, price, category, created_at | — |
33
+ | test_orders | 20 | id, product_id (FK), customer_name, quantity, total_price, order_date, status | — |
34
+ | test_jsonb_docs | 6 | id, doc, metadata, tags, created_at | **doc**, **metadata** (nested), **tags** (array) |
35
+ | test_articles | 8 | id, title, body, author, category, published_at | — |
36
+ | test_users | 9 | id, username, email, phone, bio, created_at | — |
37
+ | test_measurements | 200 | id, sensor_id, temperature, humidity, pressure, measured_at | — |
38
+ | test_embeddings | 20 | id, content, category, embedding | **embedding** (8-dim float array); category values: database, fitness, food, tech, travel |
39
+ | test_locations | 15 | id, name, city, latitude, longitude, type | — |
40
+ | test_categories | 17 | id, name, path, level | — |
41
+ | test_events | 100 | id, event_type, user_id (INT, 8 values), payload, event_date | **payload** (JSON) |
42
+
43
+ **Primary JSON test tables:**
44
+
45
+ - `test_jsonb_docs.doc` — Row 1: `{"type":"article","title":"Getting Started with SQLite","author":"Alice","views":1250,"rating":4.5}`, Row 3: `{"type":"video",...,"duration":3600}`, Row 4 has `nested.level1.level2 = "deep value"`
46
+ - `test_jsonb_docs.metadata` — Object with keys: source, language, version, quality, subscribers
47
+ - `test_jsonb_docs.tags` — Array of strings like `["database","tutorial","beginner"]`
48
+ - `test_events.payload` — Object with keys: page (values: home, products, cart, checkout), session (values: sess_1000+)
49
+
50
+ > **Note:** String values in test data use **lowercase**. Use case-sensitive matching.
51
+
52
+ ## Testing Requirements
53
+
54
+ > [!CAUTION]
55
+ > **Zero tolerance for raw MCP errors.** ANY response that is a raw MCP error (e.g., `-32602`, `isError: true`, no `success` field) is a **bug that must be reported and fixed** — never an acceptable design choice, SDK limitation, or expected behavior. If you see one, report it as ❌ immediately. Do not rationalize it as "the SDK rejecting at the boundary" or "by design for range-constrained params." The handler MUST catch it.
56
+
57
+ 1. Use existing `test_*` tables for read operations.
58
+ 2. Test each tool with realistic inputs based on the schema above.
59
+ 3. Report all failures, unexpected behaviors, improvement opportunities, or unnecessarily large payloads.
60
+ 4. **Error path testing**: For **every** tool, test at least **two** invalid inputs: (a) a domain error and (b) a **Zod validation error** (call the tool with `{}` empty params). Both must return a **structured handler error** (`{success: false, error: "..."}`) — NOT a raw MCP error frame.
61
+ 5. **Output schema testing**: For **every** tool that has an `outputSchema`, confirm that at least one valid happy-path call returns a structured JSON response — NOT a raw MCP `-32602` "output schema" error. Output schema mismatches produce the same `-32602` code as input errors but are only caught with valid inputs.
62
+ 6. **Code Over Docs**: Fix the handler code if standards (Structured Errors/Zod) are violated. Do NOT change docs/prompts to accommodate broken code.
63
+
64
+ ## Structured Error Response Pattern
65
+
66
+ All tools should return errors as structured objects instead of throwing. The expected pattern:
67
+
68
+ ```json
69
+ { "success": false, "error": "Human-readable error message" }
70
+ ```
71
+
72
+ ### Handler Error vs MCP Error — How to Distinguish
73
+
74
+ | Type | Source | What you see | Verdict |
75
+ | -------------------- | ------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- | ------------------ |
76
+ | **Handler error** ✅ | Handler catches error and returns `{success: false, error: "..."}` | Parseable JSON object with `success` and `error` fields | Correct |
77
+ | **MCP error** ❌ | Uncaught throw propagates to MCP framework | Raw text error string, often prefixed with `Error:`, wrapped in an `isError: true` content block — no `success` field | Bug — report as ❌ |
78
+
79
+ ### Zod Validation Errors
80
+
81
+ Calling a tool with wrong parameter types or missing required fields triggers a Zod validation error. If the handler has no outer `try/catch`, this surfaces as a raw MCP error (often `-32602`). Test every tool with `{}` (empty params) if it has required parameters — the response must be a handler error, not an MCP error.
82
+
83
+ **Fix:** Remove ALL `.min(N)` / `.max(N)` refinements from the schema and validate inside the handler instead.
84
+
85
+ ### Wrong-Type Numeric Parameter Coercion
86
+
87
+ For every tool with optional numeric parameters (e.g., `limit`), call the tool with `param: "abc"` (string instead of number). The tool must NOT return a raw MCP `-32602` error.
88
+
89
+ ### Output Schema Validation Errors
90
+
91
+ The MCP SDK enforces `additionalProperties: false` on **output** schemas. If a handler returns fields not declared in its output schema, the SDK rejects the response with a raw `-32602` error.
92
+
93
+ **How to detect:** If a tool call with **correct, valid inputs** returns a raw MCP `-32602` mentioning "does not match the tool's output schema" or "additional properties", report as ❌ with both the tool name and the missing field(s).
94
+
95
+ ### Error Consistency Audit
96
+
97
+ 1. **Throw-vs-return**: If a tool throws a raw error instead of returning `{success: false}`, report as ❌.
98
+ 2. **Error field name**: All `{success: false}` responses should use `error` as the field name.
99
+ 3. **Zod validation leaks**: If calling a tool with missing required field produces a raw MCP `-32602` error instead of a structured response, report as ❌.
100
+ 4. **Output schema leaks**: If calling a tool with valid inputs produces a raw MCP `-32602` mentioning "output schema", report as ❌.
101
+
102
+ ---
103
+
104
+ ## Group Focus: json-read
105
+
106
+ > **Instructions**: Execute every numbered checklist item with the exact inputs shown. Compare responses against the expected results. Report any deviation. These are the minimum-bar tests that must pass every run — freeform testing comes after.
107
+
108
+ ### json-read Group Tools (18)
109
+
110
+ 1. sqlite_json_valid
111
+ 2. sqlite_json_extract
112
+ 3. sqlite_json_type
113
+ 4. sqlite_json_array_length
114
+ 5. sqlite_json_keys
115
+ 6. sqlite_json_each
116
+ 7. sqlite_json_group_array
117
+ 8. sqlite_json_group_object
118
+ 9. sqlite_json_pretty
119
+ 10. sqlite_jsonb_convert
120
+ 11. sqlite_json_storage_info
121
+ 12. sqlite_json_normalize_column
122
+ 13. sqlite_json_select
123
+ 14. sqlite_json_query
124
+ 15. sqlite_json_validate_path
125
+ 16. sqlite_json_analyze_schema
126
+ 17. sqlite_json_security_scan
127
+ 18. sqlite_execute_code
128
+
129
+ **Test data reference (test_jsonb_docs):**
130
+
131
+ | id | doc.type | doc.author | doc.views | metadata.source | tags |
132
+ | --- | -------- | ---------- | --------- | --------------- | ------------------------------------ |
133
+ | 1 | article | Alice | 1250 | blog | ["database","tutorial","beginner"] |
134
+ | 2 | article | Bob | 890 | docs | ["json","advanced","sqlite"] |
135
+ | 3 | video | Carol | 5400 | youtube | ["mcp","protocol","ai"] |
136
+ | 4 | article | David | 670 | wiki | ["fts5","search","indexing"] |
137
+ | 5 | podcast | Eve | — | spotify | ["performance","tips","podcast"] |
138
+ | 6 | article | Frank | 2100 | medium | ["vector","embeddings","similarity"] |
139
+
140
+ Row 4 has nested path: `doc → nested → level1 → level2 = "deep value"`
141
+
142
+ **Checklist:**
143
+
144
+ 1. `sqlite_json_extract({table: "test_jsonb_docs", column: "doc", path: "$.author", whereClause: "id = 1"})` → result contains `"Alice"`
145
+ 2. `sqlite_json_extract({table: "test_jsonb_docs", column: "doc", path: "$.nested.level1.level2", whereClause: "id = 4"})` → result contains `"deep value"`
146
+ 3. `sqlite_json_keys({table: "test_jsonb_docs", column: "doc", whereClause: "id = 1"})` → keys include `type`, `title`, `author`, `views`, `rating`
147
+ 4. `sqlite_json_type({table: "test_jsonb_docs", column: "tags", whereClause: "id = 1"})` → `"array"`
148
+ 5. `sqlite_json_type({table: "test_jsonb_docs", column: "doc", whereClause: "id = 1"})` → `"object"`
149
+ 6. `sqlite_json_array_length({table: "test_jsonb_docs", column: "tags", whereClause: "id = 1"})` → `3`
150
+ 7. `sqlite_json_valid({json: "{\"type\":\"article\",\"title\":\"Getting Started with SQLite\",\"author\":\"Alice\",\"views\":1250,\"rating\":4.5}"})` → `{valid: true}`
151
+ 8. `sqlite_json_validate_path({path: "$.author"})` → valid
152
+ 9. `sqlite_json_pretty({json: "{\"type\":\"article\",\"author\":\"Alice\",\"views\":1250}"})` → formatted JSON with indentation
153
+ 10. `sqlite_json_each({table: "test_jsonb_docs", column: "tags", whereClause: "id = 1", limit: 2})` → exactly 2 expanded rows: `database`, `tutorial` (Tests `limit` parameter)
154
+ 11. `sqlite_json_analyze_schema({table: "test_jsonb_docs", column: "doc"})` → inferred schema with `type`, `author`, etc.
155
+ 12. `sqlite_json_select({table: "test_jsonb_docs", column: "doc", paths: ["$.author", "$.views"]})` → rows with author and views columns
156
+ 13. `sqlite_json_query({table: "test_jsonb_docs", column: "doc", filterPaths: {"$.type": "article"}, limit: 2})` → exactly 2 rows (Tests `limit` parameter)
157
+ 14. `sqlite_json_storage_info({table: "test_jsonb_docs", column: "doc"})` → storage analysis
158
+ 15. `sqlite_json_group_array({table: "test_jsonb_docs", valueColumn: "json_extract(doc, '$.author')", allowExpressions: true})` → array of all authors
159
+ 16. `sqlite_json_group_object({table: "test_jsonb_docs", valueColumn: "json_extract(doc, '$.views')", allowExpressions: true})` → object mapping keys (rowid by default) to view counts (Tests missing groupByColumn parameter)
160
+ 17. `sqlite_jsonb_convert({table: "test_jsonb_docs", column: "doc", whereClause: "id = 1"})` → JSONB binary conversion result
161
+ 18. `sqlite_json_normalize_column({table: "test_jsonb_docs", column: "doc", outputFormat: "text"})` → normalization report for the doc column as raw text (Tests `outputFormat` parameter)
162
+ 19. `sqlite_json_security_scan({table: "test_events", column: "payload"})` → security scan report
163
+
164
+ **Code mode testing:**
165
+
166
+ 20. `sqlite_execute_code({code: "const result = await sqlite.json.extract({table: 'test_jsonb_docs', column: 'doc', path: '$.author', whereClause: 'id = 1'}); return result;"})` → result contains `"Alice"`
167
+ 21. `sqlite_execute_code({code: "const keys = await sqlite.json.keys({table: 'test_jsonb_docs', column: 'doc', whereClause: 'id = 1'}); return keys;"})` → keys include `type`, `title`, `author`
168
+
169
+ **Error path testing:**
170
+
171
+ 🔴 22. `sqlite_json_extract({table: "nonexistent_table_xyz", column: "doc", path: "$.x"})` → structured error
172
+ 🔴 23. `sqlite_json_extract({table: "test_jsonb_docs", column: "nonexistent_col", path: "$.x"})` → report behavior
173
+ 🔴 24. `sqlite_json_validate_path({path: "invalid path !@#"})` → report behavior
174
+
175
+ **Zod validation sweep** — call each tool with `{}` (empty params). Must return handler error, NOT raw MCP error:
176
+
177
+ 🔴 25. `sqlite_json_valid({})` → handler error
178
+ 🔴 26. `sqlite_json_extract({})` → handler error
179
+ 🔴 27. `sqlite_json_type({})` → handler error
180
+ 🔴 28. `sqlite_json_array_length({})` → handler error
181
+ 🔴 29. `sqlite_json_keys({})` → handler error
182
+ 🔴 30. `sqlite_json_each({})` → handler error
183
+ 🔴 31. `sqlite_json_group_array({})` → handler error
184
+ 🔴 32. `sqlite_json_group_object({})` → handler error
185
+ 🔴 33. `sqlite_json_pretty({})` → handler error
186
+ 🔴 34. `sqlite_jsonb_convert({})` → handler error
187
+ 🔴 35. `sqlite_json_storage_info({})` → handler error
188
+ 🔴 36. `sqlite_json_normalize_column({})` → handler error
189
+ 🔴 37. `sqlite_json_select({})` → handler error
190
+ 🔴 38. `sqlite_json_query({})` → handler error
191
+ 🔴 39. `sqlite_json_validate_path({})` → handler error
192
+ 🔴 40. `sqlite_json_analyze_schema({})` → handler error
193
+ 🔴 41. `sqlite_json_security_scan({})` → handler error
194
+ 🔴 42. `sqlite_execute_code({})` → handler error
195
+
196
+ ---
197
+
198
+ ## Post-Test Procedures
199
+
200
+ ### Reporting Rules
201
+
202
+ - Use ✅ only in inline notes during testing; omit from Final Summary
203
+ - Do not mention what already works well or issues already documented in help resources and runtime hints
204
+
205
+ ### After Testing
206
+
207
+ 1. **Triage findings**: If issues were found, create an implementation plan, making sure they are consistent with working patterns in other tools/tool groups. If the plan requires no user decisions, proceed directly to implementation
208
+ 2. **Scope of fixes** includes corrections to any of:
209
+ - Handler code
210
+ - `src/constants/server-instructions/*.md` (per-group help files) — run `npm run generate:instructions` after editing to regenerate `server-instructions.ts`
211
+ - Test database (`test-server/test.db`)
212
+ - This prompt
213
+
214
+ ### After Implementation
215
+
216
+ 3. **Validate**: Instruct the user to run the test suite (Vitest/Playwright), lint, and typecheck. Do NOT run them yourself.
217
+ 4. **Commit**: Stage and commit all changes — do NOT push
218
+ 5. **Live re-test**: Test fixes with direct MCP tool calls. I will have already rebuilt and restarted the server.
219
+ 6. **Final summary**: If no issues found, provide the final summary after testing. If issues were fixed, provide the summary after live MCP re-testing confirms fixes are working.
@@ -0,0 +1,157 @@
1
+ # db-mcp Tool Group Testing: [json-write]
2
+
3
+ > [!IMPORTANT]
4
+ > **Do not track progress in this file.** Track your test progress, coverage matrix, and findings in your internal task tracking system (artifact). However, you SHOULD edit this file to fix any factual errors, broken code, or incorrect assertions in the test prompts.
5
+ > If there is nothing to fix, don't update UNRELEASED.md.
6
+ > We're currently testing Native mode.
7
+
8
+ ## WASM Mode
9
+
10
+ > When testing against a **WASM backend** (`sqlite-wasm` / sql.js): All 7 JSON write tools are fully WASM-compatible. No items to skip or adjust.
11
+
12
+ **Step 1:** Confirm you read the server help content sourced from `C:\Users\chris\Desktop\db-mcp\src\constants\server-instructions\gotchas.md` using `view_file` (not grep or search) — to understand documented behaviors, edge cases, and response structures for this tool group.
13
+
14
+ **Step 2:** Please conduct an exhaustive test of the **json-write** tool group specified in the group-specific checklist below using live MCP server tool calls directly — not scripts/terminal.
15
+
16
+ **Step 3:** The agent should update C:\Users\chris\Desktop\db-mcp\UNRELEASED.md with any/all changes/fixes.
17
+
18
+ **Note** If temp tables are present from a previous test pass, it's because the database is locked. Ignore them.
19
+
20
+ ## Reporting Format
21
+
22
+ - ❌ Fail: Tool errors or produces incorrect results (include error message)
23
+ - ⚠️ Issue: Unexpected behavior or improvement opportunity
24
+ - 📦 Payload: Unnecessarily large response that should be optimized — **blocking, equally important as ❌ bugs**. Oversized payloads waste LLM context window tokens and degrade downstream tool-calling quality. Report the response size in KB and suggest a concrete optimization.
25
+
26
+ ## Test Database Schema
27
+
28
+ The test database (test-server/test.db) contains these tables with JSON-relevant columns:
29
+
30
+ | Table | Rows | Columns | JSON Columns |
31
+ | ----------------- | ---- | ----------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
32
+ | test_products | 16 | id, name, description, price, category, created_at | — |
33
+ | test_orders | 20 | id, product_id (FK), customer_name, quantity, total_price, order_date, status | — |
34
+ | test_jsonb_docs | 6 | id, doc, metadata, tags, created_at | **doc**, **metadata** (nested), **tags** (array) |
35
+ | test_articles | 8 | id, title, body, author, category, published_at | — |
36
+ | test_users | 9 | id, username, email, phone, bio, created_at | — |
37
+ | test_measurements | 200 | id, sensor_id, temperature, humidity, pressure, measured_at | — |
38
+ | test_embeddings | 20 | id, content, category, embedding | **embedding** (8-dim float array); category values: database, fitness, food, tech, travel |
39
+ | test_locations | 15 | id, name, city, latitude, longitude, type | — |
40
+ | test_categories | 17 | id, name, path, level | — |
41
+ | test_events | 100 | id, event_type, user_id (INT, 8 values), payload, event_date | **payload** (JSON) |
42
+
43
+ ## Testing Requirements
44
+
45
+ > [!CAUTION]
46
+ > **Zero tolerance for raw MCP errors.** ANY response that is a raw MCP error (e.g., `-32602`, `isError: true`, no `success` field) is a **bug that must be reported and fixed** — never an acceptable design choice, SDK limitation, or expected behavior. If you see one, report it as ❌ immediately. Do not rationalize it as "the SDK rejecting at the boundary" or "by design for range-constrained params." The handler MUST catch it.
47
+
48
+ 1. Use existing `test_*` tables for read operations.
49
+ 2. Create temporary tables with `temp_*` prefix for write operations.
50
+ 3. Test each tool with realistic inputs based on the schema above.
51
+ 4. Report all failures, unexpected behaviors, improvement opportunities, or unnecessarily large payloads.
52
+ 5. **Error path testing**: For **every** tool, test at least **two** invalid inputs: (a) a domain error and (b) a **Zod validation error** (call the tool with `{}` empty params). Both must return a **structured handler error** (`{success: false, error: "..."}`) — NOT a raw MCP error frame.
53
+ 6. **Output schema testing**: For **every** tool that has an `outputSchema`, confirm that at least one valid happy-path call returns a structured JSON response — NOT a raw MCP `-32602` "output schema" error. Output schema mismatches produce the same `-32602` code as input errors but are only caught with valid inputs.
54
+ 7. **Code Over Docs**: Fix the handler code if standards (Structured Errors/Zod) are violated. Do NOT change docs/prompts to accommodate broken code.
55
+
56
+ ## Structured Error Response Pattern
57
+
58
+ All tools should return errors as structured objects instead of throwing. The expected pattern:
59
+
60
+ ```json
61
+ { "success": false, "error": "Human-readable error message" }
62
+ ```
63
+
64
+ ### Handler Error vs MCP Error — How to Distinguish
65
+
66
+ | Type | Source | What you see | Verdict |
67
+ | -------------------- | ------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- | ------------------ |
68
+ | **Handler error** ✅ | Handler catches error and returns `{success: false, error: "..."}` | Parseable JSON object with `success` and `error` fields | Correct |
69
+ | **MCP error** ❌ | Uncaught throw propagates to MCP framework | Raw text error string, often prefixed with `Error:`, wrapped in an `isError: true` content block — no `success` field | Bug — report as ❌ |
70
+
71
+ ### Zod Validation Errors
72
+
73
+ Calling a tool with wrong parameter types or missing required fields triggers a Zod validation error. If the handler has no outer `try/catch`, this surfaces as a raw MCP error (often `-32602`). Test every tool with `{}` (empty params) if it has required parameters — the response must be a handler error, not an MCP error.
74
+
75
+ **Fix:** Remove ALL `.min(N)` / `.max(N)` refinements from the schema and validate inside the handler instead.
76
+
77
+ ### Output Schema Validation Errors
78
+
79
+ The MCP SDK enforces `additionalProperties: false` on **output** schemas. If a handler returns fields not declared in its output schema, the SDK rejects the response with a raw `-32602` error.
80
+
81
+ **How to detect:** If a tool call with **correct, valid inputs** returns a raw MCP `-32602` mentioning "does not match the tool's output schema" or "additional properties", report as ❌ with both the tool name and the missing field(s).
82
+
83
+ ### Error Consistency Audit
84
+
85
+ 1. **Throw-vs-return**: If a tool throws a raw error instead of returning `{success: false}`, report as ❌.
86
+ 2. **Error field name**: All `{success: false}` responses should use `error` as the field name.
87
+ 3. **Zod validation leaks**: If calling a tool with missing required field produces a raw MCP `-32602` error instead of a structured response, report as ❌.
88
+ 4. **Output schema leaks**: If calling a tool with valid inputs produces a raw MCP `-32602` mentioning "output schema", report as ❌.
89
+
90
+ ---
91
+
92
+ ## Group Focus: json-write
93
+
94
+ > **Instructions**: Execute every numbered checklist item with the exact inputs shown. Compare responses against the expected results. Report any deviation.
95
+
96
+ ### json-write Group Tools (7)
97
+
98
+ 1. sqlite_create_json_collection
99
+ 2. sqlite_json_set
100
+ 3. sqlite_json_update
101
+ 4. sqlite_json_insert
102
+ 5. sqlite_json_remove
103
+ 6. sqlite_json_array_append
104
+ 7. sqlite_json_merge
105
+
106
+ **Write operations (use temp tables):**
107
+
108
+ 1. `sqlite_create_json_collection({tableName: "temp_json_test"})` → creates table with JSON columns (the default column name is 'data')
109
+ 2. `sqlite_json_insert({table: "temp_json_test", column: "data", data: {"key": "val"}})` → insert new row with JSON data
110
+ 3. `sqlite_json_set({table: "temp_json_test", column: "data", path: "$.key", value: "new_val", whereClause: "1=1"})` → modify a JSON value
111
+ 4. `sqlite_json_update({table: "temp_json_test", column: "data", path: "$.key", value: "updated_val", whereClause: "1=1"})` → update an existing key's value (distinct from json_set: update requires key to exist)
112
+ 5. `sqlite_json_merge({table: "temp_json_test", column: "data", mergeData: {"new_key": true}, whereClause: "1=1"})` → merge a JSON object
113
+ 6. `sqlite_json_array_append({table: "temp_json_test", column: "data", path: "$.arr", value: "item", whereClause: "1=1"})` → add to array (may need to set an empty array first if path $.arr doesn't exist)
114
+ 7. `sqlite_json_remove({table: "temp_json_test", column: "data", path: "$.key", whereClause: "1=1"})` → remove a key
115
+
116
+ **Cleanup:**
117
+
118
+ 8. Clean up: `DROP TABLE temp_json_test`
119
+
120
+ **Error path testing:**
121
+
122
+ 🔴 9. `sqlite_json_set({table: "nonexistent_table_xyz", column: "doc", path: "$.x", value: "1"})` → structured error
123
+
124
+ **Zod validation sweep** — call each tool with `{}` (empty params). Must return handler error, NOT raw MCP error:
125
+
126
+ 🔴 10. `sqlite_create_json_collection({})` → handler error
127
+ 🔴 11. `sqlite_json_set({})` → handler error
128
+ 🔴 12. `sqlite_json_update({})` → handler error
129
+ 🔴 13. `sqlite_json_insert({})` → handler error
130
+ 🔴 14. `sqlite_json_remove({})` → handler error
131
+ 🔴 15. `sqlite_json_array_append({})` → handler error
132
+ 🔴 16. `sqlite_json_merge({})` → handler error
133
+
134
+ ---
135
+
136
+ ## Post-Test Procedures
137
+
138
+ ### Reporting Rules
139
+
140
+ - Use ✅ only in inline notes during testing; omit from Final Summary
141
+ - Do not mention what already works well or issues already documented in help resources and runtime hints
142
+
143
+ ### After Testing
144
+
145
+ 1. **Triage findings**: If issues were found, create an implementation plan, making sure they are consistent with working patterns in other tools/tool groups. If the plan requires no user decisions, proceed directly to implementation
146
+ 2. **Scope of fixes** includes corrections to any of:
147
+ - Handler code
148
+ - `src/constants/server-instructions/*.md` (per-group help files) — run `npm run generate:instructions` after editing to regenerate `server-instructions.ts`
149
+ - Test database (`test-server/test.db`)
150
+ - This prompt
151
+
152
+ ### After Implementation
153
+
154
+ 3. **Validate**: Instruct the user to run the test suite (Vitest/Playwright), lint, and typecheck. Do NOT run them yourself.
155
+ 4. **Commit**: Stage and commit all changes — do NOT push
156
+ 5. **Live re-test**: Test fixes with direct MCP tool calls. I will have already rebuilt and restarted the server.
157
+ 6. **Final summary**: If no issues found, provide the final summary after testing. If issues were fixed, provide the summary after live MCP re-testing confirms fixes are working.