feishu_wiki_space_node

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it explains the tool's operations and some conceptual relationships (node_token vs obj_token), it doesn't address critical behavioral aspects: which operations are read-only vs. mutating, authentication requirements, rate limits, error conditions, or what the response format looks like. For a multi-operation tool with 13 parameters and no annotations, this represents significant gaps in behavioral transparency.

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

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

The description is reasonably concise with three sentences that cover the tool's purpose, operations, node concepts, and token relationships. It's front-loaded with the essential information. While efficient, it could be slightly more structured by grouping related concepts or using bullet points for the five operations.

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

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

Given the tool's complexity (13 parameters, 5 distinct operations, no annotations, no output schema), the description is insufficiently complete. It doesn't explain how different operations map to different parameter requirements, what the return values look like, error handling, or operational constraints. For a multi-function tool managing knowledge base nodes, this level of documentation leaves too many gaps for effective agent use.

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

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

Schema description coverage is high at 92%, so the schema already documents most parameters well. The description adds some conceptual context about node_token and obj_token relationships, and mentions node types, but doesn't provide additional parameter-specific guidance beyond what's in the schema. The baseline of 3 is appropriate given the high schema coverage, though the description could have better explained which parameters apply to which actions.

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

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

The description clearly states this is a '飞书知识库节点管理工具' (Feishu knowledge base node management tool) and lists the five specific operations (list, get, create, move, copy). It explains that nodes are documents in the knowledge base including various types like doc, bitable, sheet, etc. However, it doesn't explicitly differentiate this tool from sibling tools like 'feishu_wiki_space' or 'feishu_search_doc_wiki' - it just describes what the tool does without sibling comparison.

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

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

The description implies usage context by explaining node types and the relationship between node_token and obj_token, and mentions that 'get' operation can convert wiki-type node_token to obj_token. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'feishu_wiki_space' or 'feishu_search_doc_wiki', nor does it specify prerequisites or when-not-to-use scenarios.

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