micro-mcp

Overview Schema Source Related Servers Discussions Admin

Set Micro project member

micro_member_set

DestructiveIdempotent

Assign or replace an existing account's project role by email with explicit confirmation. Select viewer, developer, or admin; viewers can never gain promotion authority.

Instructions

Add or replace one existing account's project role. Viewers can never receive promotion authority.

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": {
      "email": "<email>",
      "role": "<role>",
      "confirm": "<confirm>"
    },
    "name": "micro_member_set"
  }
}

Input Schema

Name	Required	Description
`path`	No	Micro project directory; defaults to the server working directory
`role`	Yes
`email`	Yes
`confirm`	Yes	Explicit confirmation to grant or replace this account's project access
`canPromote`	No

Output Schema

Name	Required	Description	Default
`ok`	Yes
`json`	No
`stderr`	Yes
`stdout`	Yes
`command`	Yes
`exitCode`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.1Aug 30, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already indicate a mutating, destructive, idempotent operation. The description adds value by explicitly saying 'replace', implying the previous role is overwritten, and by warning that viewers can never receive promotion authority. This provides a meaningful behavioral constraint beyond the structured annotations.

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

Conciseness5/5

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

Two short, front-loaded sentences convey the core operation and a key constraint with no filler. Every sentence earns its place, and the most important behavioral warning comes second for emphasis.

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?

Given the rich schema, output schema, and annotations, the description covers the critical action and the main safety constraint. The main gap is that 'promotion authority' is not explicitly linked to the canPromote parameter in the description, but the schema and output schema compensate for most missing detail.

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

Parameters4/5

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

Schema description coverage is only 40%, so the description does important work by framing 'role' and clarifying that 'promotion authority' cannot apply to viewers, which maps to the canPromote field. It does not explicitly describe email or confirm, but the schema already covers those with format, const, and descriptions.

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

Purpose4/5

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

The description clearly states the action ('Add or replace') and the resource ('one existing account's project role'). It is semantically distinct from sibling tools such as micro_member_remove and micro_invitation_create, though it does not explicitly name those alternatives.

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

Usage Guidelines3/5

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

The intended use is implied: set or replace the project role for an existing member, with the added rule that viewers cannot receive promotion authority. However, the description does not explicitly state when to prefer this tool over related member/invitation tools, nor does it name alternatives or exclusions.

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

Deploy Server