Liliphant
REMOTE · MCP.LILIPHANT.COM
Liliphant turns every meeting into connected knowledge, decisions, and actionable insights.
Available components
Last scanned (21 hours ago)
Scores higher than 44% of remote servers
Reachable. Last reached 4 Nov 2026.
Category Productivity and Notes
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security57
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (call_any_api_of_liliphant). See how to fix → View diagnostics → Fail
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability61
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 3009 tokens (~376/item across 8 items; 8 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management13
- Stability observed for 4 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage97
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 92% of tool parameters carry a description.Partial
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 8 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 4 Nov 26 0
- Tool “list_meetings” rewrote its description, which is the text the model reads security
- “list_meetings” reworded the description of “limit” cosmetic
- 3 Nov 26 0
- Tool “ask_a_question” rewrote its description, which is the text the model reads security
- Tool “get_me” rewrote its description, which is the text the model reads security
- Tool coverage: 100% → 92% ▼ functional
- “ask_a_question” added an optional parameter “meetingId” cosmetic
- “ask_a_question” reworded the description of “question” cosmetic
- “ask_a_question” reworded the description of “tags” cosmetic
- 2 Nov 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.
- 1 Nov 26 0
- Stability: unverified → 0.03 ▲ functional
- 31 Oct 26 62
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 4 Nov 2026 · Probed https://mcp.liliphant.com/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=mcp.liliphant.com | CN=WR3,O=Google Trust Services,C=US | 30 Oct 2026 | 28 Jan 2027 | RSA 2048 | SHA256-RSA | 1a926b4ff3a46e6f10925daf1448de57 |
| SANs: mcp.liliphant.com | ||||||
| CN=WR3,O=Google Trust Services,C=US (CA) | CN=GTS Root R1,O=Google Trust Services LLC,C=US | 13 Dec 2023 | 20 Feb 2029 | RSA 2048 | SHA256-RSA | 7ff005a91568d63abc22861684aa4b5a |
| CN=GTS Root R1,O=Google Trust Services LLC,C=US (CA) | CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE | 19 Jun 2020 | 28 Jan 2028 | RSA 4096 | SHA256-RSA | 77bd0d6cdb36f91aea210fc4f058d30d |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of mcp.liliphant.com. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| com. | present | 19718 | 13 | Verified |
| liliphant.com. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://mcp.liliphant.com/mcp | Verified | 200 | |
| http (plaintext) | http://mcp.liliphant.com/mcp | HTTPS enforced | 301 | https://mcp.liliphant.com:443/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
ask_a_question ~522
Answers a plain-language question from the company's processed meetings, with a headline, a short answer, an optional chart and the quotes it is based on. Use it whenever someone asks what was said, decided or promised in their meetings. Leave out meetingId to search every meeting the asker may see; set it to answer from one meeting only. Who may call it: any member of the company. An owner or admin asks over every meeting in the company; a member asks only over the meetings they may see (ones they booked or were invited to, plus their teams' meetings). The company comes from the x-company-id header. meetingId comes from List Meetings (meetings[].id). This is slow: a minute is normal and up to three minutes happens, so allow a long timeout. A question it cannot answer is still a 200 with chart null and the reason in body: "No conversations in this company yet" when the company has no processed meetings or meetingId names a meeting that does not exist or that the asker may not see; "No conversation covers that yet" when nothing matches; "Could not answer that" when the engine fails, with the reason in body and any failures in warnings and a "What went wrong" block in detail. tags narrow a company-wide question to meetings carrying any of those tags or topic names. Each tag is normalised before matching: trimmed, upper-cased, spaces and underscores turned into dashes, other characters dropped, so "Renewal terms" matches the topic "Renewal terms". tags are ignored when meetingId is set. id is the same for the same question (case and spacing ignored) and the same meetingId, so it can be used to keep the answer on the board with Keep Question on Board. Quotes are only traced to transcript lines in this company's meetings; one that cannot be traced keeps its words with affiliation "from the conversation" and no meetingId. Errors: 400 VALIDATION_FAILED for a missing, too short or too long question, an empty or too long meetingId, a tag over 40 characters or with no…
| Name | Type | Req | Description |
|---|---|---|---|
| meetingId | string | – | – |
| question | string | – | – |
| tags | array | – | e.g. [""] |
No output schema declared.
No examples provided.
call_any_api_of_liliphant ~462
Send a POST, PUT, PATCH or DELETE request to any Liliphant API API endpoint for the user and return its response. Use it once you know the exact endpoint: look it up with get_liliphant_api_docs first to get its URL, headers, query params and body, unless the skill or a dedicated tool on this server already gives them exactly. Load the quickstart-liliphant skill first: it explains which tool to use when. For GET requests use call_any_read_api_of_liliphant. Pass the full url with path variables filled in, the headers the docs list, query params in `query` (not in the url) and the JSON body in `body`. For the auth header the docs name (Authorization, proxy_auth_token, x-api-key, ...), pass it with an empty value "": the signed-in user's token is filled in automatically. Never put a real or made-up token there; if the docs name no auth header, leave it out and the token is sent as Authorization. If the API needs the user to sign in, they're asked the first time. Returns { status, ok, headers, data }: the HTTP status and the response body, including error details on failure.
| Name | Type | Req | Description |
|---|---|---|---|
| body | object | – | JSON request body, as the endpoint's docs show it. Leave it out when the endpoint takes no body. |
| headers | object | yes | Request headers as name/value pairs, as the docs list them. Give the auth header (Authorization, proxy_auth_token, x-api-key, ...) an empty value "" so the signed-in user's token is filled in; never… |
| method | string | yes | HTTP method from the endpoint's docs |
| query | object | – | Query params as name/value pairs; an array sends the param once per item. Example: {"type": "flow", "bringflows": true} |
| url | string | yes | Full endpoint URL with path variables replaced by real values, e.g. https://api.example.com/users/42. Put query params in `query`, not here. |
No output schema declared.
No examples provided.
call_any_read_api_of_liliphant ~413
Read from any Liliphant API API endpoint with a GET request for the user and return its response. Use it once you know the exact endpoint: look it up with get_liliphant_api_docs first to get its URL, headers, query params and body, unless the skill or a dedicated tool on this server already gives them exactly. Load the quickstart-liliphant skill first: it explains which tool to use when. For POST, PUT, PATCH and DELETE use call_any_api_of_liliphant. Pass the full url with path variables filled in, the headers the docs list, and query params in `query` (not in the url). For the auth header the docs name (Authorization, proxy_auth_token, x-api-key, ...), pass it with an empty value "": the signed-in user's token is filled in automatically. Never put a real or made-up token there; if the docs name no auth header, leave it out and the token is sent as Authorization. If the API needs the user to sign in, they're asked the first time. Returns { status, ok, headers, data }: the HTTP status and the response body, including error details on failure.
| Name | Type | Req | Description |
|---|---|---|---|
| headers | object | yes | Request headers as name/value pairs, as the docs list them. Give the auth header (Authorization, proxy_auth_token, x-api-key, ...) an empty value "" so the signed-in user's token is filled in; never… |
| query | object | – | Query params as name/value pairs; an array sends the param once per item. Example: {"type": "flow", "bringflows": true} |
| url | string | yes | Full endpoint URL with path variables replaced by real values, e.g. https://api.example.com/users/42. Put query params in `query`, not here. |
No output schema declared.
No examples provided.
get_liliphant_api_docs ~206
Browse the Liliphant API API docs, one level at a time. Call it without arguments to get the top level: the modules and pages with a short description and the endpoints they hold. Call it with `path` set to a module's or page's link (or path) to get what is inside it; each listing links the next level. Call it with `path` set to an endpoint's link ending in ".openapi.yml" to get that endpoint as an OpenAPI file: method, url, headers, query params, path variables, a request body example and sample responses. Fetch only the level you need.
| Name | Type | Req | Description |
|---|---|---|---|
| path | string | – | A link from a listing, exactly as given (e.g. "https://docs.example.com/sms/llms.txt" or ".../sms/send-sms.openapi.yml"), or just the path ("sms", "sms/send-sms.openapi.yml"). Leave it out for the to… |
No output schema declared.
No examples provided.
get_me ~375
Returns who is signed in and every company they can open, with their role in each. This is the first call a client makes after sign-in: almost every other call needs a company id from companies[].id. Any signed-in person may call it. It also does housekeeping on the way: it makes sure the person's personal company exists and turns any email invitations waiting for them into memberships, so a company someone was just added to shows up here. The x-company-id header is optional here. currentCompanyId tells you which company the server will use for requests that send this header; with no header, or one naming a company the person is not in, it falls back to their personal company instead of failing. Other fields: companyLimit is how many companies a person may create (null means no limit) and companiesCreated is how many they have created so far, for a "New company" button. onboardedAt on each company is null until its setup is finished. paused on each company lists what a Liliphant admin has stopped there because it costs money (recording, processing, ask, automations); empty means nothing is, and ask means AI answers are refused, so a screen can say so instead of offering them. operator is true for the people who may open the admin panel. logoUrl and brandColor appear on a company whose profile has a website that Things of Brand knows; both are left out otherwise. hasMeetings is true once the current company has at least one meeting (one still being processed counts); until then the app shows only the first-meeting screen and Settings. Errors: 401 NOT_SIGNED_IN when no token is sent; 401 SESSION_EXPIRED when the token is no longer valid. GET https://meet-analyzer-api.50agents.com/api/v1/ui/me
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
list_meetings ~915
Lists the analysed meetings the caller may see, as cards, newest first, with the filter choices the Meetings screen offers. Use it to show or search the meeting list, and to find a meetingId for Get Meeting, Get Meeting Transcript, Get Share Link or the notes routes (meetings[].id). Any member of the company may call it, but what comes back depends on their role. An owner or admin sees every meeting in the company. A member sees only the meetings they booked or were invited to, plus every meeting of each team they are in (only their own when they are in no team). It never returns meetings from a company other than the one named in x-company-id. Paging: send limit (1 to 100) to get pages. When there are more results, nextCursor holds a token; pass it back as cursor to get the next page. nextCursor is null on the last page. Without limit, every matching meeting comes back in one response. Never build a cursor yourself. The first page (no cursor) also carries the extras: filters (the types, tags, people and teams that actually occur, each with a count), totals (all meetings the caller may see, and how many of them still need attention, ignoring the filters) and processing (up to 50 meetings the caller may see that are still being analysed, newest first). On later pages filters and totals are null and processing is empty, so keep the first page's copy. meetingCount is the number of matches across all pages. In filters.people, team is true for someone who was ever on the company's side of a call. Filters combine: q searches title, headline, summary, type, tag, a participant's name or email, a team's name, or an exact meeting id; type, tag and person take values from filters; teamId limits to meetings booked by or with that team's members (an id from filters.teams[].value); within keeps meetings from the last N days; from and to pick a custom date range instead; status is open (still needs something) or handled. Team filter: an owner or admin may pass any of the com…
| Name | Type | Req | Description |
|---|---|---|---|
| cursor | string | – | Optional. The nextCursor from the previous page. Omit for the first page |
| from | string | – | Optional. Start of a custom date range, a date or date-time (ISO 8601), inclusive. Either end may be left open |
| limit | string | – | Optional. Page size, 1 to 100. Omit to get every matching meeting at once |
| person | string | – | Optional. A participant's name, a value from filters.people[].value |
| q | string | – | Optional. Free-text search, up to 200 characters. Matches title, headline, summary, type, tag, a participant's name or email, a team's name, or an exact meeting id |
| status | string | – | Optional. open (still needs something) or handled |
| tag | string | – | Optional. A tag, a value from filters.tags[].value |
| teamId | string | – | Optional. A team id from filters.teams[].value. Keeps meetings that team's members booked or were invited to. A member may only pass a team they are in |
| to | string | – | Optional. End of a custom date range, a date or date-time (ISO 8601), exclusive |
| type | string | – | Optional. Meeting type, a value from filters.types[].value, e.g. SALES, SUPPORT, PARTNERSHIP, MARKETING, INTERNAL |
| within | string | – | Optional. Whole number 1 to 3650: only meetings that started within this many days |
No output schema declared.
No examples provided.
quickstart-liliphant ~56
Liliphant API quickstart: read the user's meetings and ask questions answered from what people actually said. Load before any Liliphant task. Call this to load the full instructions for this skill before doing the task.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
search_liliphant_docs ~60
Search the Liliphant API documentation with a natural-language question. Returns the most relevant passages with their page URLs.
| Name | Type | Req | Description |
|---|---|---|---|
| query | string | yes | What to look for, e.g. "how do I send a WhatsApp template message" |
No output schema declared.
No examples provided.
How do I install the Liliphant MCP server?
Liliphant is a hosted endpoint at https://mcp.liliphant.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · mcp.liliphant.com
claude mcp add --transport http com-liliphant-mcp-mcp 'https://mcp.liliphant.com/mcp'
What is the Liliphant MCP server?
Liliphant is an MCP server listed in the public MCP registry as com.liliphant.mcp/mcp. Liliphant turns every meeting into connected knowledge, decisions, and actionable insights. This page covers its hosted endpoint (https://mcp.liliphant.com/mcp).
Is the Liliphant MCP server safe to use?
Liliphant scores 63 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Liliphant MCP server expose?
Liliphant exposes 8 tools: search_liliphant_docs, get_liliphant_api_docs, call_any_read_api_of_liliphant, call_any_api_of_liliphant, get_me, and 3 more. Their descriptions and schemas cost roughly 3,009 tokens of context every time the server is loaded.
Does the Liliphant MCP server require authentication?
No. We connected to Liliphant without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the Liliphant MCP server still maintained?
Liliphant is still listed as active in the MCP registry. We last reached this channel on 4 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.