Feishu (Lark) MCP
This is the packaged action='manual' entry point and the progressive disclosure
router. A normal schema-sufficient call does not need to load it first. Load
one route only when the call is unfamiliar, consequential, or recovery-sensitive.
PUBLIC TOOL FAMILY: strict LTP-v2
Every call is {action, input, reasoning, summarize?}. action, input, and
string reasoning are required; summarize, if present, is boolean. The root
and each action input are closed: unknown fields, cross-action fields, the old
flat/_reasoning form, and missing required fields fail before provider I/O.
| Goal | Action and required input |
|---|---|
| New message | send: receive_id + exactly one text or content |
| Inspect | check: {}; read: chat_id; search: query |
| Answer a message | reply: exact compound message_id + exactly one text or content |
| Change Bot output | edit: sent message_id + exactly one text or content |
| Delete Bot output | delete: sent message_id |
| Reaction | react: message_id + operation="add" + emoji_type, or operation="remove" + exact reaction_id |
| Contacts/accounts | contacts/accounts: {}; add_contact: open_id + alias; remove_contact: exactly one open_id or alias |
| Read settings/manual | settings/manual: {}; settings is SHOW-only |
send/reply content can be tagged text, markdown, post, complete
schema-2.0 card, media, shares, or sticker. edit accepts text/markdown/post
or complete card replacement, not media. See the message reference for exact
unions and media source shapes.
A safe inbound start without a pending notification is
feishu(action="check", input={}, reasoning="inspect incoming chats"), then
read the affected chat to obtain its exact ID before replying. When a
notification already carries a compound message id and untruncated text
(see reference/message-semantics.md),
reply or react with that id directly instead of a routine re-check/re-read.
BEFORE A SIDE EFFECT
Configuration belongs to the orchestrator/admin; an avatar must not configure or reconfigure this MCP. Setup, credential changes and rollout require explicit owner authorization; routine message schemas do not grant it.
receive_id_typedefaults toopen_id; usechat_idfor a group. An omittedaccountselects the first configured account. Verify the account and recipient beforesend; verify the target beforereply,edit,delete, orreact.- IDs are
{account_alias}:{chat_id}:{feishu_message_id}. Pass an inbound compound ID back toreplyverbatim. A reply target that is gone fails; it never becomes a freshsend. Group/topic inbound messages require an explicit Bot mention (@allalone is ignored);allowed_usersgates senders, and saving a contact does not grant admission. - Each physical outbound chunk is attempted once. A partial result lists exact delivered IDs and the failed chunk; do not replay the whole action or silently downgrade it. Reconcile provider state before another lifecycle operation.
CARDS ARE THREE DIFFERENT THINGS
- A complete schema-2.0 business
cardis outbound content. An authorized click becomes one deduplicatedcard_actioninbox record and wakes the Agent; update itssource_message_reforsenda fresh response. A callback record is not a reply target. - Local command cards (
/help,/status,/kanban,/system,/refresh,/sleep,/clear,/taskcard) update themselves. Their callbacks stay local: no business inbox record and no Agent wake. Group commands still need admission and a Bot mention. - Automatic/programmable resident Task Cards are mechanical projections, not
messages to manage with these actions.
placeholder=trueis separate native progress feedback; edit it only at meaningful phase changes and send the final durable answer separately.
SETTINGS SHOW
settings accepts {} only and returns a read-only inventory. Its seven row
owners are linked below; SHOW never writes or grants configuration authority.
Setting config path
See reference/message-semantics.md#setting-config-path.
Setting account aliases
See reference/message-semantics.md#setting-account-aliases.
Setting account app ids
See reference/message-semantics.md#setting-account-app-ids.
Setting account app secrets
See reference/message-semantics.md#setting-account-app-secrets.
Setting account allowed users
See reference/message-semantics.md#setting-account-allowed-users.
Setting task card enabled
See reference/message-semantics.md#setting-task-card-enabled.
Setting task card normal rows
See reference/message-semantics.md#setting-task-card-normal-rows.
ONE OWNER FOR DEPTH
| Situation | Read |
|---|---|
| Exact content, reply/thread, card callback, media, notification, reaction, chunk/lifecycle, or Task Card semantics | reference/message-semantics.md |
| App permissions, event/callback setup, config fields, accounts, canary, or rollback | reference/setup.md |
| A startup, admission, WebSocket, media, card, reaction, Task Card, or error symptom | reference/diagnostics.md |
| Feishu-vs-Telegram scope and deliberate limits | reference/capability-matrix.md |
For failures, preserve error_code, retryable, and retry_after_seconds.
max_attempts=1 makes retryable guidance a new caller decision, not an
adapter retry. Never expose secrets, raw envelopes, provider keys, or local
paths in external evidence.