Liliphant joins your meetings and remembers the work across all of them. Most tools stop at one transcript. Liliphant connects every conversation, so you can ask what was decided, who promised what, what changed since the first meeting, or what's still blocked. Every answer comes with the exact quote, the speaker and the meeting it came from, and if something is unclear, Liliphant tells you. Open promises and unanswered questions stay in view until someone marks them done.
Scored across 8 tools
The core tools are clearly distinct: list_meetings, ask_a_question, and get_me target different needs, and the read/write generic API tools are split by HTTP method. The docs-oriented tools have some conceptual overlap, but their descriptions make browse vs. search vs. quickstart usage reasonably clear.
Most names use snake_case, but quickstart-liliphant breaks the pattern with a hyphen and no verb, while ask_a_question, get_me, list_meetings, and the call_any_* tools mix verb styles. The names are still readable, but the convention is not fully predictable.
Eight tools is a well-scoped size for a meeting-analytics server with identity, meeting listing, question answering, docs help, and generic API escape hatches. Each tool has a plausible role and the set is not bloated.
The surface covers listing meetings, asking questions, identity, and documentation, with generic read/write API tools to reach endpoints not exposed as dedicated tools. Dedicated get-meeting, transcript, share-link, and notes tools are missing, but agents can work around this through the generic API tools and docs.
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. POST https://meet-analyzer-api.50agents.com/api/v1/ui/ask
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | e.g. ["renewal","reporting"] | |
| question | No | e.g. Which competitors came up most this month? |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive), yet the description adds genuinely non-obvious behavior: a one-to-three minute latency with a long-timeout recommendation, unanswerable questions returning 200 with chart null and specific reason strings, warning/detail blocks on engine failure, and quote-tracing fallback. That is substantial context the annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The critical scoping rule and the 'use it whenever' trigger are front-loaded, and nearly every sentence earns its place (latency, error bodies, tag normalization, stable id). It is a single dense block, though, and the long enumeration of 400 validation cases could be tightened without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a slow, permission-scoped, non-destructive query tool with no output schema, the description covers everything an agent needs: output shape, latency expectations, permission model, scoping via meetingId/tags, idempotency key usage, and the full failure taxonomy with status codes. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline would be 3, but the description adds real semantics: meetingId comes from List Meetings (meetings[].id), tags match meetings carrying any of those tags or topic names, tags are normalized (trim, uppercase, spaces/underscores to dashes) and ignored when meetingId is set, and id is stable per question+meetingId. These are matching rules the schema cannot convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('answers a plain-language question from the company's processed meetings') and names the output shape (headline, short answer, optional chart, quotes). It is clearly distinguishable from siblings like list_meetings or search_liliphant_docs, which find meetings/docs rather than synthesize answers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger ('use it whenever someone asks what was said, decided or promised') and an explicit scoping rule: omit meetingId to search everything the asker may see, set it to answer from one meeting only. It also states who may call it and what each role can see, which resolves the main ambiguity an agent would face.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| url | 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. | |
| body | No | JSON request body, as the endpoint's docs show it. Leave it out when the endpoint takes no body. | |
| query | No | Query params as name/value pairs; an array sends the param once per item. Example: {"type": "flow", "bringflows": true} | |
| method | Yes | HTTP method from the endpoint's docs | |
| headers | 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 put a token here yourself. Pass {} when the endpoint needs no headers. Example: {"proxy_auth_token": "", "Content-Type": "application/json"} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructive=true, non-idempotent, and openWorld, so the safety profile is covered; the description goes further by explaining the auth mechanism (empty-string header value triggers automatic token injection, never supply a real token), the interactive sign-in on first use, and the exact return shape {status, ok, headers, data} with error details. It does not mention rate limits or whether failures are retried, so not a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence, followed by prerequisite, routing, and parameter guidance in a logical order. It is dense and somewhat run-on across several sentences, but nearly every sentence carries actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter open-world mutation tool with no output schema, the description covers prerequisites, method restriction, auth handling, parameter placement, and the return envelope. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the structured fields already document all five params; the description nevertheless reinforces the non-obvious rules: query params belong in `query` not the url, path variables must be pre-filled, and the auth header must be passed with an empty value. The 'never put a real token' caveat adds genuine semantic value beyond the schema text, pushing past the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (send POST/PUT/PATCH/DELETE) and resource (any Liliphant API endpoint) plus the scope ('for the user'), and explicitly distinguishes itself from the sibling call_any_read_api_of_liliphant, which handles GET. An agent can tell exactly which of the two endpoints tools to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit sequencing: look up the endpoint with get_liliphant_api_docs first, load the quickstart-liliphant skill, and route GET requests to the read sibling. It names both the prerequisite tools and the exclusion condition, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| url | 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. | |
| query | No | Query params as name/value pairs; an array sends the param once per item. Example: {"type": "flow", "bringflows": true} | |
| headers | 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 put a token here yourself. Pass {} when the endpoint needs no headers. Example: {"proxy_auth_token": "", "Content-Type": "application/json"} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, but the description adds genuinely new behavior: auth headers must be passed with an empty string and the signed-in user's token is injected, never a fabricated token, with a fallback to Authorization when docs name no auth header. It also discloses the interactive sign-in flow on first use and the error-detail-bearing return shape, none of which is in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and the docs-lookup prerequisite are front-loaded, and every sentence carries operational content (alternatives, auth trick, return shape). It is still a single dense block with a stutter ("API API") and some clauses that could be split for faster scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic open-world HTTP passthrough with no output schema, the description covers everything an agent needs: how to discover the endpoint spec, how to position path/query/header values, how auth is injected, what happens on first sign-in, and the { status, ok, headers, data } return shape including failure details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description goes beyond it by stating the token-injection convention and the fallback rule ("if the docs name no auth header, leave it out"), plus reinforcing that query params belong in `query` rather than the URL. Most of the per-parameter mechanics are still duplicated from the schema, keeping it short of a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource+constraint: "Read from any ... API endpoint with a GET request ... and return its response." It explicitly contrasts itself with the write sibling call_any_api_of_liliphant, which handles POST/PUT/PATCH/DELETE, so an agent can separate the two read/write tools without inspecting either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit precondition chain: look up the endpoint with get_liliphant_api_docs first, and load the quickstart-liliphant skill before use. It also names the alternative tool and the exact condition that selects it (non-GET methods), and carves out an exception when a dedicated tool already supplies the details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| path | No | 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 top level. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to explain what comes back—which it does for each mode: listings with short descriptions and contained endpoints, or an OpenAPI file with method, url, headers, query params, path variables, request body example and sample responses. No pagination or depth-limit caveats are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core model, then three parallel 'Call it with...' sentences that map cleanly to the modes. The repeated 'Call it with `path` set to...' phrasing is slightly verbose but each sentence carries distinct information, so nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema present, the description must explain return values—and it does so for all three modes. Combined with the annotations covering safety and a fully documented single parameter, an agent has everything needed to call this correctly on the first try.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema does not: the semantic effect of each path form—a module/page link yields a listing, a '.openapi.yml' link yields an OpenAPI document, omission yields the top level. That behavioral mapping of parameter values is genuinely value-adding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (browse) and resource (Liliphant API docs) with an explicit traversal model ('one level at a time'). It distinguishes itself from siblings like search_liliphant_docs and call_any_api_of_liliphant by framing itself as the navigation/index layer rather than a search or call tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete invocation guidance for three modes: no argument for the top level, a module/page link for a listing, and a '.openapi.yml' link for endpoint detail. 'Fetch only the level you need' is a clear efficiency instruction. It doesn't explicitly say when to prefer this over search_liliphant_docs, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool performs housekeeping by ensuring the personal company exists and converting waiting email invitations into memberships, which are write operations. This directly contradicts the readOnlyHint=true annotation, which declares the tool does not modify its environment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded, followed by usage, side effects, header semantics, fields, and errors. It is longer than average but structured, and most sentences add materially useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still explains key response fields such as currentCompanyId, companyLimit, companiesCreated, and onboardedAt. It also covers auth errors and the fallback behavior when the optional header is missing or invalid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description also explains response fields and optional header behavior, though those are not formal input parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: returns the signed-in person and every company they can open with roles. It also names the tool's role as the first call after sign-in, making it clearly distinguishable from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says this is the first call after sign-in and that almost every other call needs a company id from companies[].id. It also states any signed-in person may call it and explains the optional x-company-id header behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 company's teams. A member may pass only a team they are in, and filters.teams lists only their teams.
A company with no meetings gets an empty list, not an error.
Errors: 400 VALIDATION_FAILED when a query value is out of range, a date cannot be read, or the cursor is not one this server issued; 401 when not signed in or the sign-in expired; 404 TEAM_NOT_FOUND when teamId is not one of this company's teams, or (for a member) not a team they are in. GET https://meet-analyzer-api.50agents.com/api/v1/ui/meetings
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | 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 | |
| to | No | Optional. End of a custom date range, a date or date-time (ISO 8601), exclusive | |
| tag | No | Optional. A tag, a value from filters.tags[].value | |
| from | No | Optional. Start of a custom date range, a date or date-time (ISO 8601), inclusive. Either end may be left open | |
| type | No | Optional. Meeting type, a value from filters.types[].value, e.g. SALES, SUPPORT, PARTNERSHIP, MARKETING, INTERNAL | |
| limit | No | Optional. Page size, 1 to 100. Omit to get every matching meeting at once. e.g. 20 | |
| cursor | No | Optional. The nextCursor from the previous page. Omit for the first page | |
| person | No | Optional. A participant's name, a value from filters.people[].value | |
| status | No | Optional. open (still needs something) or handled | |
| teamId | No | 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 | |
| within | No | Optional. Whole number 1 to 3650: only meetings that started within this many days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent and closed-world, so the description is free to spend its words on things annotations cannot express: exactly who sees which meetings (owner/admin vs member vs team membership), that results never cross the x-company-id boundary, that page 1 alone carries filters/totals/processing and later pages null them, and the specific 400/401/404 error semantics. That is unusually rich operational context for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well front-loaded and chunked into purpose, permissions, paging, first-page extras, filters, team filter and errors, with each block earning its place. It is long, though, and a few passages (q's match list, the limit range, cursor round-tripping) duplicate the schema descriptions almost word for word, which is redundant for an agent that also sees the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 optional parameters and no output schema, the description carries the return-shape burden and does: cards, nextCursor null on the last page, meetingCount across all pages, filters/totals/processing only on page 1, and empty-list semantics. Auth and error conditions are enumerated, so nothing an agent needs in order to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description adds genuine relational meaning the schema cannot: filters combine, type/tag/person/teamId must take values from the first page's filters arrays, within and from/to are alternatives, and cursors must never be hand-built. It does restate some schema text nearly verbatim (q's match list, teamId's rule), which caps it below 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific verb and resource ("Lists the analysed meetings"), the ordering (newest first), the response shape (cards) and the caller's visibility scope. It also routes the agent to distinct downstream tools (Get Meeting, Get Meeting Transcript, Get Share Link) rather than leaving it to guess which list-like call to make.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use it to show or search the meeting list, and to find a meetingId for..." states the positive use cases explicitly, and the following paragraphs define the boundaries: role-dependent visibility, cross-company isolation, empty-list-not-error behaviour. Filter interaction rules ("Filters combine", "within... from and to pick a custom date range instead") tell the agent how to compose a query rather than leaving it to trial and error.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the tool returns instruction text rather than data, but does not say anything about the size, format, or persistence of what is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, but the second half of sentence one pre-empts the actual instruction in sentence two, and 'before any Liliphant task' / 'before doing the task' repeat the same timing rule. The load-first directive should be front-loaded instead of buried after capability prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-param loader this is close to sufficient, and there is no output schema to explain. However, with no output schema and no statement of what the returned instructions look like or how long they are, an agent cannot anticipate the payload it is about to ingest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to explain; the baseline for a no-param tool is 4. The description correctly describes an argument-free invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The operative sentence, 'Call this to load the full instructions for this skill,' states the real function, but the opening clause describes the API's capabilities (read meetings, ask questions) rather than what this zero-param tool does. An agent must reconcile two different framings to understand this is an instructions/skill loader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Load before any Liliphant task' gives an explicit, unconditional timing rule that an agent can act on without inference. It stops short of naming specific siblings (ask_a_question, list_meetings) as the follow-on tools this quickstart enables.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Liliphant API documentation with a natural-language question. Returns the most relevant passages with their page URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to look for, e.g. "how do I send a WhatsApp template message" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds useful return context ('most relevant passages with their page URLs') but says nothing about result count, ranking behavior, or empty-result behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste, with the action front-loaded and the return shape following it. Nothing is repeated from the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with full annotation coverage and an inline schema example, this is nearly complete: the action and the shape of the response are both stated. The only real gap is the absence of routing guidance against its many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and includes a concrete example, so the schema does the heavy lifting. The description only reinforces that the query is natural language; it adds no format, length, or scoping guidance beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search the Liliphant API documentation') plus the input mode (natural-language question). It is clearly distinguishable from get_liliphant_api_docs in spirit, but never names the siblings it differs from, so differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage through 'natural-language question,' which suggests this is the semantic-search path rather than a direct doc fetch. However, it never states when to pick this over get_liliphant_api_docs, ask_a_question, or call_any_api_of_liliphant, so the agent must guess at the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
ask_a_questioncall_any_api_of_liliphantcall_any_read_api_of_liliphantget_liliphant_api_docsget_melist_meetingsquickstart-liliphantsearch_liliphant_docs
Add one secure layer between your agents and this server.