yimu-mcp

get_account_members

get_account_members

Fetch all members of a Yimu bookkeeping ledger by providing the book ID, enabling you to view participant roles and manage access.

Instructions

查询账本成员（GET /accountBook/getAccountMember/{userId}/{bookId}）。

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": {
      "book_id": "<book_id>"
    },
    "name": "get_account_members"
  }
}

Input Schema

Name	Required	Description	Default
`book_id`	Yes	账本 ID
`user_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.2Sep 15, 2026

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation, whether authentication is required, what the response contains, or any side effects. The endpoint pattern suggests a GET request, but that is not explicitly disclosed.

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?

The description is a single compact sentence that includes the purpose and the HTTP endpoint. It is front-loaded with the action and resource. It could be slightly more informative, but it is appropriately sized and not verbose.

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

Completeness2/5

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

For a tool with no annotations, no output schema, and only 50% parameter coverage, the description is too thin. It does not explain the return value, whether user_id is required in practice, or any behavioral context. An agent would need to guess at important details before invoking it.

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 description coverage is 50%: book_id has a description ('账本 ID'), but user_id has none. The description's endpoint template shows both {userId} and {bookId} in the path, which adds some meaning for user_id, but it does not explain the relationship or optionality. This is adequate but not strong.

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 states a specific verb and resource: '查询账本成员' (query account book members), and includes the HTTP endpoint. It is clear enough to distinguish from siblings like get_book_bills or get_share_accounts, though it does not explicitly name a sibling alternative.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. The description only provides the endpoint and a terse purpose; it does not mention context, prerequisites, or exclusions. An agent must infer usage from the name and endpoint alone.

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