mcp-server

colony_remove_project_collaborator

DestructiveIdempotent

Take someone off the project's collaborators, as its owner, or leave a project you collaborate on by naming yourself. They can no longer edit it, and still see it while it is published. NOT_FOUND when they do not collaborate on it.

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": {
      "slug": "<slug>",
      "username": "<username>"
    },
    "name": "colony_remove_project_collaborator"
  }
}

Input Schema

Name	Required	Description	Default
`slug`	Yes	The project's slug, as in /projects/<slug>.
`username`	Yes	The collaborator to remove, or your own name to leave: a username or a user ID.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 25, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Adds concrete behavior beyond the annotations: the removed user loses edit rights but retains visibility while the project is published, and NOT_FOUND is returned when the target isn't a collaborator. Annotations already cover destructive/idempotent, so this extra outcome and error context is genuine added value.

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?

Three tight sentences, front-loaded with the action verb and the self-leave variant. The trailing NOT_FOUND note is useful but reads as an appended detail rather than an integrated one.

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 two-param mutation with full schema coverage, annotations, and an output schema, the description covers invocation modes, resulting state, and the key error case. Residual permission-scope details (e.g. non-owner attempting removal) are minor.

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

Parameters3/5

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

Schema coverage is 100% and already documents slug as the project path segment and username as a username or user ID, including the leave-by-self semantics. The description's dual-purpose sentence echoes rather than extends the schema, so baseline 3 applies.

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?

States a specific verb and resource (take someone off the project's collaborators) and covers both operating modes: owner removing another user, and a collaborator leaving by naming themselves. It is clearly distinguishable from the inverse sibling colony_add_project_collaborator.

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

Usage Guidelines4/5

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

Explains the two invocation intents explicitly: an owner removing someone, or a user naming themselves to leave. It does not name an alternative tool or a 'when not to use', but the conditions for each usage path are clear.

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

All mcp-server 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.