Skip to main content
Glama
environ-mcp

environ-mcp

by renhail

解除绑定

unbind_user

Unbind the current client from its environ account so later queries require re-binding. Use when switching accounts or handing off duties; a confirm flag is required to execute.

Instructions

解除当前客户端与 environ 账号的绑定,之后的查询会要求重新绑定。换账号、离职交接时用这个。⚠️ 这是破坏性操作:必须显式传 confirm=true 才会真正执行;不传或传 false 时只返回当前绑定状态,不会解绑。

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "unbind_user"
  }
}

Input Schema

NameRequiredDescriptionDefault
confirmNo确认要解绑时传 true;缺省只查看绑定状态,不执行解绑

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.5

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full burden and does so: it labels the call destructive, explains the confirm=true gate, and specifies the default behavior when confirm is absent or false (status only, no unbind). It also discloses the post-condition, that subsequent queries require re-binding.

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 sentences, front-loaded with the action and consequence, then the usage context, then a clearly marked warning. No redundant or filler wording.

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

Completeness5/5

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

A single-parameter, no-output-schema tool whose entire risk surface (destructiveness, confirmation gate, default no-op) is documented. Nothing an agent needs to avoid an accidental unbind is missing.

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 coverage is 100%, so the baseline is 3, but the description goes slightly beyond the schema by emphasizing that only an explicit true executes the operation and that omitting the flag degrades to a status read. The added meaning is real but largely reinforces the schema rather than extending it.

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 — severing the binding between the current client and the environ account — and adds the consequence ('之后的查询会要求重新绑定'), which lets an agent distinguish it from bind_user and check_bind without opening either 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?

Gives explicit use cases ('换账号、离职交接时用这个') and makes the confirm=true precondition part of the usage rule. It does not name a sibling as the alternative for the read-only path (check_bind), but the confirm=false dry-run behavior effectively covers that case.

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