bms-session-plugin 1.0.3 → 1.0.5

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.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "bms-session-plugin",
3
- "version": "1.0.3",
3
+ "version": "1.0.5",
4
4
  "description": "Claude Code plugin for BMS Session API and HOSxP hospital databases",
5
5
  "files": [
6
6
  ".claude-plugin/",
@@ -7,16 +7,17 @@ description: This skill should be used when the user asks to "query HOSxP databa
7
7
 
8
8
  ## CRITICAL: Immediate Action Required
9
9
 
10
- **Check if the MCP server `bms-session` is connected.** The server name in Claude Code is `plugin:bms-session-plugin:bms-session`.
10
+ **DO NOT ask the user for a session ID or any other setup questions.** The MCP server is already connected and authenticated. Start using tools immediately.
11
11
 
12
- **If connected DO NOT ask the user for a session ID.** The session is already authenticated. Start using tools immediately:
12
+ **Use these MCP tools directly (do NOT use Bash to run `claude mcp` commands):**
13
13
 
14
- 1. Read the `bms://session-info` resource from server `plugin:bms-session-plugin:bms-session` to get database type and constraints
15
- 2. Use `list_tables` with a pattern filter to discover relevant tables (e.g., `list_tables({ pattern: "patient*" })`)
16
- 3. Use `describe_table` to understand column structure before writing queries
17
- 4. Use `query` to execute SQL and return results
14
+ 1. Call `list_tables` with a pattern to discover relevant tables (e.g., `list_tables({ pattern: "patient*" })`)
15
+ 2. Call `describe_table` to understand column structure before writing queries
16
+ 3. Call `query` to execute SQL and return results
18
17
 
19
- **If NOT connected** — then ask the user for a `bms-session-id` and help them set up the MCP server or use the REST API directly.
18
+ **Do NOT attempt to read the `bms://session-info` resource** — it may fail due to timing. Instead, call `query({ sql: "SELECT VERSION()" })` to verify the connection works, then proceed with the user's request.
19
+
20
+ **Database info to know:** The database is either MariaDB or PostgreSQL. Use `SHOW TABLES LIKE 'pattern%'` for MariaDB or `information_schema` queries for PostgreSQL. If unsure, try MariaDB syntax first — most HOSxP deployments use MariaDB.
20
21
 
21
22
  ## Purpose
22
23
 
@@ -28,6 +29,20 @@ Always use `LIMIT` to avoid returning excessive rows. Always use the `pattern` p
28
29
 
29
30
  When the user asks to "analyze the database", "show patient data", "query hospital data", or similar — start working immediately by calling the MCP tools. Do not ask unnecessary questions. Use list_tables and describe_table to discover the schema, then write and execute queries.
30
31
 
32
+ ## How Applications Receive bms-session-id
33
+
34
+ HOSxP passes the session ID to destination applications via **URL parameter**:
35
+
36
+ ```
37
+ https://your-app.com/?bms-session-id=CB411DB0-B121-43C6-B795-80ADECE6A13C
38
+ ```
39
+
40
+ When building apps that integrate with HOSxP:
41
+ - Accept `bms-session-id` from the URL query string
42
+ - The session ID is dynamic — it changes per user and per session
43
+ - After first successful validation, optionally store in a cookie (7-day expiry) for convenience
44
+ - Always validate the session before using it — sessions expire (default 10 hours)
45
+
31
46
  ## When MCP Server Is Not Available
32
47
 
33
48
  Build queries using the REST API directly. The flow: