servicenow-mcp-server 2.1.9 → 2.1.10
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/docs/COLLABORATION_PROPOSAL.md +109 -0
- package/package.json +1 -1
|
@@ -0,0 +1,109 @@
|
|
|
1
|
+
# Let's Do This — Response to Chris
|
|
2
|
+
|
|
3
|
+
**From:** Nick Zitzer
|
|
4
|
+
**Date:** March 2026
|
|
5
|
+
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
Hey Chris —
|
|
9
|
+
|
|
10
|
+
First, totally hear you on the package names. You've put in the work to get those published, cleaned up, and stable on npm — the last thing we should do is break that for people who already depend on them. That's not on the table, full stop. Your packages keep their names, your npm scope stays as-is. No disruption to anyone already using `@sonisoft/now-sdk-ext-*`.
|
|
11
|
+
|
|
12
|
+
Same goes for mine — `servicenow-mcp-server` stays published and available where it is.
|
|
13
|
+
|
|
14
|
+
And honestly, re-reading my initial proposal I think I got ahead of myself on the restructuring side. You're right to push back on that. Let me recalibrate.
|
|
15
|
+
|
|
16
|
+
---
|
|
17
|
+
|
|
18
|
+
## What I Think Actually Makes Sense
|
|
19
|
+
|
|
20
|
+
### Shared Org — Your SNOS Idea Is Great
|
|
21
|
+
|
|
22
|
+
I love the SNOS-Coalition concept (or just SNOS). It's exactly the right framing: a community org for ServiceNow open-source work, not a rebrand of either of our existing projects.
|
|
23
|
+
|
|
24
|
+
**What the org would be:**
|
|
25
|
+
- A shared GitHub home — `github.com/snos-coalition/` (or `github.com/sn-os/`, whatever feels right)
|
|
26
|
+
- Both of us as Owners/maintainers
|
|
27
|
+
- A place for collaborative work that builds on what we've each already shipped
|
|
28
|
+
|
|
29
|
+
**What the org would NOT be:**
|
|
30
|
+
- A rename of your packages
|
|
31
|
+
- A migration that breaks anyone's existing installs
|
|
32
|
+
- A requirement that either of us stops maintaining our own repos
|
|
33
|
+
|
|
34
|
+
### How the Repos Could Work
|
|
35
|
+
|
|
36
|
+
I think the simplest path is:
|
|
37
|
+
|
|
38
|
+
**Option A: Fork into the org (preserve originals)**
|
|
39
|
+
Your repos stay exactly where they are under `sonisoft-cnanda/`. Mine stays under my account. We fork the relevant ones into the SNOS org as the "collaborative edition" — a place where we merge the best of both, experiment with consolidation, and ship new features together. Your originals remain the stable, published packages. The org fork becomes the next-gen version when it's ready.
|
|
40
|
+
|
|
41
|
+
**Option B: Transfer repos, keep names (your suggestion)**
|
|
42
|
+
Move the repos into the org with their original names intact. npm packages don't change — `@sonisoft/now-sdk-ext-core` still resolves, still installs, nothing breaks. The only thing that changes is the GitHub URL, and GitHub handles redirects automatically. This is cleaner if we're both comfortable with it.
|
|
43
|
+
|
|
44
|
+
Either way, the principle is: **nothing breaks for existing users.**
|
|
45
|
+
|
|
46
|
+
---
|
|
47
|
+
|
|
48
|
+
## Where I Think We Build Together
|
|
49
|
+
|
|
50
|
+
Rather than restructuring what exists, I think the highest-value work is combining our strengths into something neither of us has alone. Here's what I'd focus on:
|
|
51
|
+
|
|
52
|
+
### 1. Tool Consolidation (New Collaborative Work)
|
|
53
|
+
|
|
54
|
+
This is where I think the real win is, and it doesn't require renaming anything. Between us we have 90+ MCP tools. The research from Anthropic, Block, and Microsoft is clear that this hurts AI performance — sweet spot is 12-15 tools per server. I laid out a consolidation strategy in my earlier doc that I think is worth discussing on a call, but the short version:
|
|
55
|
+
|
|
56
|
+
- Fewer tools with richer parameters (one `SN-Query` instead of 8 table-specific list tools)
|
|
57
|
+
- Metadata-driven behavior so tools work on any table without per-table code
|
|
58
|
+
- Anthropic's `defer_loading` for specialist tools
|
|
59
|
+
|
|
60
|
+
This would be net-new work in the SNOS org, built on your core library, incorporating my metadata patterns. Not a replacement of either existing server — a next-gen version.
|
|
61
|
+
|
|
62
|
+
### 2. Cross-Pollinate Unique Features
|
|
63
|
+
|
|
64
|
+
Some things I've built that your server doesn't have yet (and vice versa) that would be straightforward to bring over:
|
|
65
|
+
|
|
66
|
+
**From mine → into yours (or the shared project):**
|
|
67
|
+
- Natural language query parser (15+ patterns, table-aware state mappings)
|
|
68
|
+
- SSE/HTTP transport (for Docker and hosted deployments)
|
|
69
|
+
- MCP Resources (8 read-only URIs for ambient AI context)
|
|
70
|
+
- sys_trigger background execution method
|
|
71
|
+
- Metadata-driven table definitions (94 tables, extraction scripts, runtime fallback)
|
|
72
|
+
|
|
73
|
+
**From yours → into mine (or the shared project):**
|
|
74
|
+
- Flow Designer integration (11 tools — huge gap in my server)
|
|
75
|
+
- ATF test execution (critical for CI/CD)
|
|
76
|
+
- WebSocket/AMB real-time events
|
|
77
|
+
- Aggregation queries (Stats API)
|
|
78
|
+
- Knowledge, Catalog, and App Management tools
|
|
79
|
+
- CMDB graph traversal
|
|
80
|
+
- Instance health monitoring
|
|
81
|
+
|
|
82
|
+
### 3. Documentation & Community Building
|
|
83
|
+
|
|
84
|
+
This is honestly where I think the ServiceNow ecosystem needs the most help, and where a shared org gives us leverage. I've got 40+ guides, research docs, and troubleshooting content. A docs site under the SNOS org — covering both our tools plus general ServiceNow MCP development patterns — could become the go-to resource for the community.
|
|
85
|
+
|
|
86
|
+
---
|
|
87
|
+
|
|
88
|
+
## The Bigger Picture (Why I Care)
|
|
89
|
+
|
|
90
|
+
I'll keep this brief since you said you don't care much about the marketing side, but I want you to know what's driving me beyond the code.
|
|
91
|
+
|
|
92
|
+
The ServiceNow developer community has been underserved for years. The platform itself is powerful, but the ecosystem around it has been starved while ServiceNow focuses on sales and enterprise licensing. Every other major enterprise platform has thriving open-source tooling. ServiceNow's is barely getting started.
|
|
93
|
+
|
|
94
|
+
I think open-source, community-built tools — like what we're both already doing — are how that changes. Not waiting for ServiceNow to prioritize developers, but just building the things developers need and putting them out there. The SNOS org could be a home for that kind of work, and not just from us — it's an open door for anyone in the community who wants to contribute.
|
|
95
|
+
|
|
96
|
+
That's the flag I want to plant. The code is the vehicle, but the point is: ServiceNow developers deserve better, and we can build it.
|
|
97
|
+
|
|
98
|
+
---
|
|
99
|
+
|
|
100
|
+
## Practical Next Steps
|
|
101
|
+
|
|
102
|
+
1. **A quick call** — 30 minutes to align on the org name, repo structure (Option A vs B), and what we want to build first
|
|
103
|
+
2. **Create the GitHub org** — both as Owners, minimal governance to start
|
|
104
|
+
3. **Pick a first project** — I'd suggest the consolidated MCP server as the flagship, but open to your thinking
|
|
105
|
+
4. **Keep shipping our own stuff** — none of this blocks either of us from continuing to maintain and publish what we've already built
|
|
106
|
+
|
|
107
|
+
No rush on any of this. You just finished a cleanup cycle and I respect that you want to protect the stability of what you've shipped. Whenever you're ready to hop on a call, I'm in.
|
|
108
|
+
|
|
109
|
+
**— Nick**
|
package/package.json
CHANGED