Skip to main content
Glama
Sign In

Milanote MCP Server and API by Cotlet

by dev.cotlet
OverviewDiscussionsAdmin

Remove editor

remove_editor
Destructive

Take away someone's access to a board, or cancel an invite they have not accepted. Removes one editor, by user_id or email, as the Share dialog's Remove does. They lose the board and the boards inside it unless a parent board is shared with them too; Milanote does not tell them. The owner cannot be removed. invite_editor adds them back. By default you confirm each call; you can switch that off for this tool. Waits for the owner's approval.

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": {
      "board_id": "<board_id>"
    },
    "name": "remove_editor"
  }
}

Input Schema

NameRequiredDescriptionDefault
emailNoTheir email address, instead of user_id.
user_idNoTheir user_id from get_sharing or invite_editor.
board_idYesBoard ID from list_boards, or the board URL.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true, idempotentHint=false, openWorldHint=true, and the description adds real behavioral detail beyond them: the target loses the board and its nested boards unless a parent share exists, the person is not notified, the owner is protected, a per-call confirmation is on by default and can be disabled, and the call waits for owner approval.

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 core action and kept to a handful of short clauses, each carrying distinct information (scope, side effects, notification, restriction, confirmation, approval). Slightly dense with several separate facts packed into the tail, but no filler sentences.

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 destructive three-parameter tool with no output schema, the description covers impact, notification, permission limits, confirmation, and approval latency. Minor gaps remain: behavior when the target is not an editor, and what happens when both email and user_id are passed.

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% with all three parameters self-documented, so the baseline is 3. The description only reinforces 'one editor, by user_id or email' and adds nothing about format, precedence when both are supplied, or the mutual exclusivity of email and user_id.

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?

Starts with a specific verb+resource ('Take away someone's access to a board') and immediately adds a second real case ('or cancel an invite they have not accepted'), plus scope ('Removes one editor'). This clearly separates it from invite_editor and get_sharing, so an agent can pick it without opening the schema.

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?

Usage context is explicit: revoke existing access or cancel a pending invite, addressed by user_id or email, matching the Share dialog's Remove. It also states the key exclusion ('The owner cannot be removed') and names invite_editor as the inverse operation, though it never says which sibling to use to discover the user_id in the first place.

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

All Milanote MCP Server and API by Cotlet toolsInspect
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