Tulina

slack_act

Destructive

Change Slack — ops: create_usergroup, update_usergroup, disable_usergroup, enable_usergroup, set_usergroup_members, add_usergroup_members, remove_usergroup_members. Reads: slack.

create_usergroup: name (+ handle, description, channels, users) — a group starts empty; users sets its members right after.
update_usergroup: usergroup + any of name, handle (without @), description, channels (default channel IDs, replaces the list).
disable_usergroup / enable_usergroup: usergroup. Disabling is how a group is emptied or retired; it is reversible and keeps the members.
set_usergroup_members: usergroup + users = the FULL new list (whoever is missing leaves). add_usergroup_members / remove_usergroup_members: usergroup + users to add or remove — the current list is read, then replaced. Every member op answers {before, after, added, removed}.

dry_run=true validates and returns that diff (or the fields that would be sent) without writing. Slack refuses an empty member list: removing the last members is refused here — disable the group instead.

Requires usergroups:write. ⚠️ A bot token (author="app") can only write when the workspace lets everyone manage user groups; otherwise use author="me" with the user token of an allowed member.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "op": "<op>"
    },
    "name": "slack_act"
  }
}

Input Schema

Name	Required	Description
`op`	Yes	The change to make (see above).
`_org`	No	Org (id) de CET APPEL. `oto_list_orgs()`.
`name`	No	Display name (`create_usergroup`, `update_usergroup`).
`users`	No	Member user IDs (U…) — the member ops; `create_usergroup` too.
`_group`	No	Équipe (id) de CET APPEL, sous son org parente.
`author`	No	Who acts — `"me"` (user token) or `"app"` (bot token). Required when the workspace holds both tokens.
`handle`	No	Mention handle without `@` (`create_usergroup`, `update_usergroup`).
`_run_id`	No	OBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
`dry_run`	No	Validate and preview, write nothing.
`_project`	No	Projet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
`channels`	No	Default channel IDs (C…) (`create_usergroup`, `update_usergroup`).
`_instance`	No	Instance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
`usergroup`	No	User group ID (S…), from `slack(op="usergroups")`. All ops but `create_usergroup`.
`description`	No	Description (`create_usergroup`, `update_usergroup`).

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag destructiveHint and openWorldHint, but the description goes considerably further: it discloses the `{before, after, added, removed}` diff response for member ops, the `usergroups:write` scope requirement, the Slack constraint rejecting empty member lists, that disabling is reversible and preserves members, and the bot-token (`author="app"`) restriction with the `author="me"` fallback.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the op list, then a tight per-op reference with backticked parameter names; nearly every line carries operational information. Slightly dense and repetitive in places (the `users` semantics are restated across ops), but no filler sentences remain.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter polymorphic mutation tool with no output schema, the description covers permissions, dry-run behavior, member-op return shape, and the empty-list edge case. Return values for the non-member ops (create/update/disable/enable) are not described, a minor gap given no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds genuine semantics the schema lacks: which parameters apply to which op, that `handle` excludes `@`, that `channels` *replaces* the default-channel list, and that `users` on `set_usergroup_members` is the complete new roster ("whoever is missing leaves"). These are behavioral distinctions that materially change how the parameters must be filled.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ("Change Slack") and enumerates every operation the tool can perform, while explicitly naming the read counterpart (`slack`). An agent can immediately tell this is the write surface for Slack user groups, distinct from siblings like `slack_post_message` or `slack`.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives per-op selection guidance (`set_usergroup_members` = full replacement, `add`/`remove` = deltas, disable instead of removing the last members) and states the read alternative for anything else. It also tells the agent to use `dry_run=true` to validate before writing, which is explicit when-to-use/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Tulina tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?