@aipermission/mcp 0.2.17 → 0.2.19
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/README.md +12 -2
- package/dist/resources/aipermission-operator/SKILL.md +12 -0
- package/package.json +1 -1
- package/server.json +2 -2
package/README.md
CHANGED
|
@@ -9,7 +9,7 @@ credentials, or other connector secrets.
|
|
|
9
9
|
The gateway is intentionally local-only. Run it on the developer machine and
|
|
10
10
|
keep the URL on `localhost`; remote systems are connector targets, not places
|
|
11
11
|
to host the gateway for LAN or internet users. SSH, Postgres, ClickHouse,
|
|
12
|
-
Redis / Valkey, RabbitMQ, S3, Docker, and Kubernetes are built-in connectors that use the same
|
|
12
|
+
Redis / Valkey, RabbitMQ, Kafka / Redpanda, S3, Docker, and Kubernetes are built-in connectors that use the same
|
|
13
13
|
target/profile/action permission model as future connectors.
|
|
14
14
|
|
|
15
15
|

|
|
@@ -66,7 +66,7 @@ The generated MCP config contains a bearer token. Keep it private. For project-l
|
|
|
66
66
|
- `cancel_vault_action_request`
|
|
67
67
|
|
|
68
68
|
All integration work goes through connector targets. SSH, Postgres, ClickHouse,
|
|
69
|
-
Redis / Valkey, RabbitMQ, S3, Docker, Kubernetes, and future connectors share the same model: target,
|
|
69
|
+
Redis / Valkey, RabbitMQ, Kafka / Redpanda, S3, Docker, Kubernetes, and future connectors share the same model: target,
|
|
70
70
|
credential profile, connector action, token action permission, approval,
|
|
71
71
|
history, and audit.
|
|
72
72
|
|
|
@@ -112,6 +112,16 @@ browser actions such as `overview`, `list_vhosts`, `list_queues`, `get_queue`,
|
|
|
112
112
|
previews and published payloads can contain secrets or customer data; use short
|
|
113
113
|
reasons and prefer approval-required access until the workflow is trusted.
|
|
114
114
|
|
|
115
|
+
For Kafka or Redpanda, call `get_connector_actions(target_ref)` to discover
|
|
116
|
+
cluster, topic, consumer-group, lag, bounded message-read, guarded publish, and
|
|
117
|
+
single-partition offset actions. Message reads use explicit partition
|
|
118
|
+
assignment, never join a consumer group, and never commit offsets. Publishing
|
|
119
|
+
is a write action; consumer-group offset changes are destructive and reject
|
|
120
|
+
active classic groups and modern consumer-protocol groups. Payloads can contain
|
|
121
|
+
sensitive application data, and offset changes can replay or skip records, so
|
|
122
|
+
keep these actions in Prompt mode unless direct execution is intentional. If a
|
|
123
|
+
publish has an unknown delivery outcome, inspect before retrying.
|
|
124
|
+
|
|
115
125
|
For Docker, call `get_connector_actions(target_ref)` to discover bounded
|
|
116
126
|
actions such as `docker_version`, `list_containers`, `list_images`,
|
|
117
127
|
`list_networks`, `list_volumes`, `inspect_container`, `container_logs`,
|
|
@@ -53,6 +53,18 @@ Peek a RabbitMQ queue after the operator approved payload inspection. Publish
|
|
|
53
53
|
RabbitMQ messages only when the operator explicitly asked for a write.
|
|
54
54
|
```
|
|
55
55
|
|
|
56
|
+
For Kafka / Redpanda, discover topics before describing partitions or reading
|
|
57
|
+
messages. Keep message reads bounded, prefer Prompt because payloads can be
|
|
58
|
+
sensitive, and remember that read actions never join groups or commit offsets.
|
|
59
|
+
Use `publish_message` only for one explicitly requested topic partition. Treat
|
|
60
|
+
`set_consumer_group_offset` as destructive because it can replay or skip
|
|
61
|
+
records; keep both actions on Prompt unless direct execution is intentional.
|
|
62
|
+
If a publish reports an unknown delivery outcome, inspect the topic before
|
|
63
|
+
retrying. Offset changes support inactive classic groups and reject modern
|
|
64
|
+
consumer-protocol groups. The inactive-group check is best effort because
|
|
65
|
+
Kafka cannot atomically prevent a member joining between the final check and
|
|
66
|
+
commit; inspect the returned post-commit state and warning.
|
|
67
|
+
|
|
56
68
|
Avoid vague reasons:
|
|
57
69
|
|
|
58
70
|
```text
|
package/package.json
CHANGED
package/server.json
CHANGED
|
@@ -3,12 +3,12 @@
|
|
|
3
3
|
"name": "io.github.aipermission/aipermission-mcp",
|
|
4
4
|
"title": "AIPermission",
|
|
5
5
|
"description": "Local-first MCP bridge for the AIPermission gateway.",
|
|
6
|
-
"version": "0.2.
|
|
6
|
+
"version": "0.2.19",
|
|
7
7
|
"packages": [
|
|
8
8
|
{
|
|
9
9
|
"registryType": "npm",
|
|
10
10
|
"identifier": "@aipermission/mcp",
|
|
11
|
-
"version": "0.2.
|
|
11
|
+
"version": "0.2.19",
|
|
12
12
|
"transport": {
|
|
13
13
|
"type": "stdio"
|
|
14
14
|
}
|