Liliphant

ask_a_question

Read-onlyIdempotent

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 letter or digit, more than 10 tags, or any other field; 401 when the token is missing or expired; 403 SPENDING_STOPPED when a Liliphant admin stopped this company's AI answers. POST https://meet-analyzer-api.50agents.com/api/v1/ui/ask

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ask_a_question"
  }
}

Input Schema

Name	Required	Description
`tags`	No	e.g. [""]
`question`	No
`meetingId`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026
RemovedNov 4, 2026
Changed3 schema fields changedNov 2, 2026
- addedInput schema / properties / meetingId
```
Added value: +{
+  "type": "string"
+}
```
- removedInput schema / properties / question / description
```
Removed value: -"e.g. Which competitors came up most this month?"
```
- changedInput schema / properties / tags / description
```
Previous value: -"e.g. [\"renewal\",\"reporting\"]"New value: +"e.g. [\"\"]"
```
First observedOct 31, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes far beyond the readOnly/idempotent annotations: it discloses latency expectations (one to three minutes), the unusual 200-with-chart-null failure contract with the three exact reason strings, the tag normalisation rules, and that tags are ignored when meetingId is set. This is exactly the non-obvious behavior an agent needs before calling.

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

Conciseness4/5

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

Front-loaded with purpose and the meetingId branch, then permissions, latency, failure modes, and field semantics in a sensible order. Dense but every paragraph carries decision-relevant information; the long error enumeration could be tightened but is not padding.

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

Completeness5/5

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

No output schema exists, yet the description covers the response envelope, the null-chart failure contract, quote traceability behavior, deterministic id reuse, auth header origin, and the full error taxonomy. Nothing material for a correct call is missing.

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

Parameters3/5

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

Schema coverage is low (33%) and the tags schema is essentially undocumented, so the description must compensate – and it partly does, explaining meetingId provenance (meetings[].id) and tag normalisation, limits (10 tags, 40 chars). However, the `question` parameter's constraints are only inferable from the 400 VALIDATION_FAILED note (too short/too long) with no actual bounds, leaving the most important parameter partially underspecified.

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?

Opens with a specific verb+resource (answers a plain-language question from processed meetings) and names the exact output shape (headline, short answer, optional chart, quotes). It also distinguishes itself from siblings by pointing to List Meetings for meetingId, so an agent can tell it apart from the list/search tools without reading schemas.

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

Usage Guidelines5/5

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

Gives explicit when-to-use ("whenever someone asks what was said, decided or promised in their meetings"), a clear branch rule (leave out meetingId for company-wide, set it for a single meeting), and the permission model distinguishing owner/admin vs member scope. Alternatives and exclusions are covered.

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

All Liliphant 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.