Add io.decisionrules/mcp-server - #1524
Closed
ivanperesta-alt wants to merge 4 commits into
Closed
Conversation
add io.decisionrules/mcp-server
add icon to mcp server
Member
|
Hi @ivanperesta-alt 👋 — thanks for your interest in the MCP Registry! It looks like this PR is trying to publish an MCP server by adding or editing files in this repository (under servers/ or in data/seed.json). That isn't how servers get published, so I'm closing this PR automatically. Servers are published with the mcp-publisher CLI, not by opening a pull request against this repo. The CLI verifies that you own your namespace and submits your server.json directly to the live registry API. To publish your server, follow the Publishing Quickstart. In short: Build the publisher CLI Authenticate (e.g. via GitHub) and publish your server.json If you believe this was closed in error, please leave a comment and a maintainer will take a look. 🙇 |
rdimitrov
added a commit
to rdimitrov/registry
that referenced
this pull request
Aug 20, 2026
PR modelcontextprotocol#1524 added `data/servers/io.decisionrules/server.json` and the detector logged `match=false`, so it was never auto-closed. The path list only knew `servers/**` at the repo root and exactly `data/seed.json`; putting the file under `data/servers/` is a natural guess given `data/seed.json` exists. Add `data/servers/**` plus root-level `server.json` / `servers.json`. Nothing legitimate lives at any of these paths today (`find` finds no server.json, servers.json or servers/ directory anywhere in the tree). The list stays explicit rather than becoming a broad `**/server.json` glob. The classifier only flags a PR when *every* changed file matches, which makes widening asymmetric: too narrow silently misses spam, too broad auto-closes a legitimate single-file PR. `internal/servers/service.go` and `data/servers.md` correctly do not match. Both copies of the list (stage 1 and stage 2) are updated identically, with a comment on each pointing at the other. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
rdimitrov
added a commit
that referenced
this pull request
Aug 20, 2026
#1524 tried to publish by adding `data/servers/io.decisionrules/server.json`. The detector ran fine and logged: ``` Non-publish file changed: data/servers/io.decisionrules/server.json PR #1524 match=false ``` The path list only knew `servers/**` at the repo root and exactly `data/seed.json`. Putting the file under `data/servers/` is a natural guess given `data/seed.json` exists, and it fell straight through. Adds `data/servers/**` plus root-level `server.json` / `servers.json`. `find` confirms nothing legitimate lives at any of those paths today. The list stays explicit rather than becoming a broad `**/server.json` glob. The classifier only flags a PR when *every* changed file matches, which makes widening asymmetric: too narrow silently misses spam, too broad auto-closes a legitimate single-file PR. Both copies of the list (stage 1 and stage 2) are updated identically, with a comment on each pointing at the other. ## Testing `actionlint` clean. macOS ships bash 3.2, so I extracted the literal `if [[ ... ]]` condition from each workflow file and ran it under bash 5 in Docker — testing the shipped text rather than a retyped copy. Both copies are byte-identical and agree: ``` MATCH data/servers/io.decisionrules/server.json # PR 1524 MATCH servers/com.aradia/x.json # PR 1549 MATCH data/seed.json MATCH server.json MATCH servers.json keep internal/api/handler.go keep internal/servers/service.go keep data/servers.md keep docs/README.md ``` Also dry-ran the full classifier against all 35 currently-open PRs from untrusted authors: **0 would be closed**. No legitimate open PR is affected. ## Known remaining gap (deliberately not fixed here) The detector does not run at all for authors new to GitHub. This repo's Actions approval policy is `first_time_contributors_new_to_github`, so their fork PRs sit in `action_required` until a maintainer approves the run. That is why #1549 was never flagged. I'm leaving that alone for now because the numbers don't justify the fix. Since the automation landed on 2026-07-09 it has had **71 detect runs: 70 ran, 1 was gated**. It has correctly closed 3 publish attempts (SAGE, Diagram Generation API, Kairos Signal) and missed 2 — one to the path bug this PR fixes, one to the gate. So the gate costs roughly one missed PR every six weeks, and those get closed manually within a day. The only ways around it are `pull_request_target` (runs untrusted PRs in a privileged context — one future `actions/checkout` from being a privilege-escalation hole) or a scheduled sweep (works, but trades the two-stage design for cron semantics and a ~15 min delay). Neither seems worth it at that rate. Happy to open a follow-up if you'd rather close the gap. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation and Context
Adds DecisionRules to the official MCP Registry. DecisionRules is a business rules engine (decision tables, decision flows, lookup tables, scripting rules); this remote MCP server exposes rule authoring, testing, and execution to MCP clients.
How Has This Been Tested?
Tested against the production endpoint (https://api.decisionrules.io/mcp) using MCP Inspector and as a custom connector in Claude. Verified the initialize handshake, tools/list (60 tools returned), and solve_rule execution against real rule data with expected outputs matching.
Breaking Changes
None, this is a new server entry, no existing users or configurations affected.
Types of changes
Checklist
Additional context
Server uses OAuth 2.0 with Dynamic Client Registration (RFC 7591) for authentication. Icon and repository URL confirmed reachable. Reverse-DNS name (io.decisionrules/mcp-server) matches domain ownership.