Skip to main content
Glama

Liliphant

list_meetings

Read-onlyIdempotent

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

Input Schema

NameRequiredDescriptionDefault
qNoOptional. 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
toNoOptional. End of a custom date range, a date or date-time (ISO 8601), exclusive
tagNoOptional. A tag, a value from filters.tags[].value
fromNoOptional. Start of a custom date range, a date or date-time (ISO 8601), inclusive. Either end may be left open
typeNoOptional. Meeting type, a value from filters.types[].value, e.g. SALES, SUPPORT, PARTNERSHIP, MARKETING, INTERNAL
limitNoOptional. Page size, 1 to 100. Omit to get every matching meeting at once. e.g. 20
cursorNoOptional. The nextCursor from the previous page. Omit for the first page
personNoOptional. A participant's name, a value from filters.people[].value
statusNoOptional. open (still needs something) or handled
teamIdNoOptional. 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
withinNoOptional. Whole number 1 to 3650: only meetings that started within this many days

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources