Tulina

lemlist_inbox

Read the unified inbox, write drafts, manage labels. Sends nothing — sending is lemlist_act.

Conversations are keyed by CONTACT, all channels merged.

Args by op:

list: user_id (required — an inbox belongs to a person), page, limit.
messages: contact_id + optional user_id, limit, skip. ⚠️ mark_as_read=True MUTATES on a read call. ⚠️ One HTML email can weigh 300 000+ characters (images pasted as base64): to read what was SAID, pass text_only=True (HTML turned to plain text, inline images dropped) and max_chars (each text cut there). The answer then carries truncated_fields, the number of texts that were cut — 0 means you have them whole.
labels / label_get (label_id) / label_create (label_name).
labels_attach: contact_id + label_ids; append=False REPLACES the conversation's labels. labels_remove: same minus append.
drafts / draft_get / draft_delete: contact_id + draft_owner (a user id — a draft belongs to a person) + draft_id where relevant.
draft_create: contact_id, draft_owner, channel (email, linkedin, whatsapp, sms), content, optional subject, cc, attachments, reply_to_activity_id (answer a specific message), source_metadata.
draft_update: same ids + draft (the fields to change).

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": {
      "op": "<op>"
    },
    "name": "lemlist_inbox"
  }
}

Input Schema

Name	Required	Description
`cc`	No
`op`	Yes
`_org`	No	Org (id) de CET APPEL. `oto_list_orgs()`.
`page`	No
`skip`	No
`draft`	No
`limit`	No
`_group`	No	Équipe (id) de CET APPEL, sous son org parente.
`append`	No
`_run_id`	No	OBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
`channel`	No
`content`	No
`subject`	No
`user_id`	No
`_project`	No	Projet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
`draft_id`	No
`label_id`	No
`_instance`	No	Instance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
`label_ids`	No
`max_chars`	No
`text_only`	No
`contact_id`	No
`label_name`	No
`attachments`	No
`draft_owner`	No
`mark_as_read`	No
`source_metadata`	No
`reply_to_activity_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does real work: it flags that `mark_as_read=True` MUTATES on an otherwise read call, warns that a single HTML email can exceed 300k characters with base64 images, and explains the `truncated_fields` return signal. It does not disclose permission/auth requirements, pagination semantics, or that `draft_delete` is destructive and irreversible, which keeps it below a 5.

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?

Front-loaded: purpose and the send exclusion come first, then the contact-keyed model, then a compact op-by-op argument map with warnings inline where they matter. For 12 operations and 28 parameters this is dense but every line carries operational information; nothing is padding.

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

Completeness4/5

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

For a 12-op, 28-parameter multiplexer with no annotations and no output schema, the description is unusually complete on inputs and hazards. Remaining gaps are return shape for `list`, `labels`, and `drafts` (only `messages` gets a documented response field) and pagination behaviour, which matter because there is no output schema to fall back on.

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 only 18%, so the description must carry the load, and it largely does: it maps every operation to its required ids and adds meaning the schema lacks, notably the allowed `channel` values (email/linkedin/whatsapp/sms) where the schema is a bare string. It also explains `append=False` REPLACES labels, `draft_owner` is a person, `text_only` converts HTML to plain text and drops inline images, and `max_chars` cuts each text with `truncated_fields` reporting how many were cut.

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?

The opening sentence states three specific verbs (read, write drafts, manage labels) against a named resource (unified inbox) and explicitly excludes sending by naming `lemlist_act` as the sibling that does it. It also fixes the data model up front: conversations are keyed by CONTACT with all channels merged, which no schema field conveys.

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?

The per-op `Args by op` block tells the agent which parameters each operation needs, which is effectively usage guidance for a multiplexed tool, and `lemlist_act` is named for the send path. It stops short of saying when to reach for this tool over adjacent siblings such as `lemlist_mailbox` or `lemlist_get_activities`, so selection among lemlist read tools is left to inference.

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

All Tulina tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?