Add Tenant Access Token (TAT) support for MCP tools

[marco0158]

Summary

This PR adds Tenant Access Token (TAT) support for MCP tools, allowing MCP tools to operate with application-level permissions without requiring user authorization.

Changes

• Add mcpAuthMode config option (user | tenant | auto) to FeishuAccountConfigSchema
• Implement TAT caching mechanism in tool-client for efficient token reuse
• Add getMcpAuthMode() function to read auth mode from config
• Update callMcpTool() to support both UAT and TAT via header flags
• Update registerMcpTool() to handle three auth modes:
  • tenant: Use Tenant Access Token for all MCP calls
  • auto: Try TAT first, fallback to UAT on failure
  • user (default): Use User Access Token as before

Use Cases

This is suitable for background tasks and automation scenarios where user authorization is not practical or possible.

Example Configuration

{
  "channels": {
    "feishu": {
      "mcpAuthMode": "tenant"
    }
  }
}

Testing

• Test tenant mode with various MCP tools
• Test auto mode fallback to UAT on failure
• Test user mode (default behavior unchanged)

[HanShaoshuai-k]

Review: PR #263 — Add Tenant Access Token (TAT) support for MCP tools

Thanks for the contribution! Adding TAT support for MCP tools makes sense directionally — Feishu's MCP gateway already supports X-Lark-MCP-TAT, and the plugin side is missing this. However, I have concerns about the use case and config design that I think should be resolved first.

1. Does the use case exist in the current architecture?

The PR description mentions "background tasks and automation scenarios where user authorization is not practical or possible." However, in openclaw-lark, all tool invocations are triggered by user messages — there's no scheduler, no external API trigger, no background task mechanism. Every call has a senderOpenId. So the "no user context" scenario doesn't actually exist today.

Could you clarify the real-world scenario you're solving for? If it's about reducing OAuth friction or providing a fallback when UAT is unavailable, that would lead to a different design.

2. Account-level config is too coarse

Per Feishu MCP docs, different tools support different auth methods (e.g., search-user only supports UAT). A global mcpAuthMode: "tenant" would silently break these tools.

Auth mode compatibility is a server-side property of each tool, not a user preference. Rather than a global config, consider letting each tool declare its supported auth modes, and determining the actual mode from runtime context.

3. auto mode fallback is wasteful

auto tries TAT first, falling back to UAT on failure. For UAT-only tools, this means a wasted request on every call. The fallback direction should be reconsidered.

---

I'd suggest aligning on the use case and config design before diving into implementation details. Happy to discuss!