Laxis
Server Details
Search and read your Laxis meeting transcripts, AI summaries, and participants from Claude.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 4 of 4 tools scored.
Each tool has a distinct purpose: listing meetings, getting details, retrieving transcripts, and searching content. No overlap exists, and descriptions clearly differentiate their use cases.
All tools follow a consistent verb_noun pattern in snake_case (get_meeting, get_transcript, list_meetings, search_meetings), making naming predictable and clear.
With 4 tools, the count is on the lower end but still reasonable for a focused retrieval server. It doesn't feel overly sparse given the domain.
Core retrieval operations (list, detail, transcript, search) are covered. Missing features like meeting management or participant details are minor gaps for the intended retrieval-focused scope.
Available Tools
4 toolsget_meetingAInspect
Get one meeting's details: title, date, participants, keywords, and summary.
Does NOT include the transcript text — use get_transcript for that, or
search_meetings to find the relevant part of a long meeting. If the meeting is
plan-restricted, returns {accessible: false, needs_upgrade: true, reason,
upgrade_url}; tell the user it needs a Laxis plan upgrade and share upgrade_url
so they can upgrade, rather than treating it as an error.
| Name | Required | Description | Default |
|---|---|---|---|
| meeting_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the return values (title, date, etc.), what is excluded (transcript), and the specific response for plan-restricted meetings. It does not mention other behaviors like authorization or rate limits, but for a simple get tool this is adequate.
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 description is concise with 4 sentences covering purpose, exclusions, and edge case. Information is front-loaded and each sentence adds value without redundancy.
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?
Given the tool's simplicity (one parameter, no output schema), the description is complete: it states what is returned, what is not, and how to handle restricted meetings. It also references sibling tools for alternative use cases.
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?
There is only one parameter (meeting_id) and the schema coverage is 0%, so the description should add meaning. The description does not explicitly describe the parameter, but the tool's purpose implies its role. The parameter name is self-explanatory, so minimal additional context is needed. Score reflects that no explicit parameter description is given.
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 description clearly states it gets one meeting's details listing specific fields (title, date, participants, keywords, summary). It differentiates from sibling tools by explicitly noting what it does not include (transcript) and referencing get_transcript and search_meetings.
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?
Provides explicit when to use (get details), when not to use (for transcript), and alternatives (use get_transcript for text, search_meetings for searching). Also includes handling of plan-restricted meetings with instructions for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transcriptAInspect
Read a meeting's transcript as '[m:ss] Speaker: text' lines, paginated.
Returns at most max_chars characters starting at offset; if next_offset is
not null, call again with offset=next_offset for the next page. Use this
only when you need to read the actual conversation — for locating a topic
inside meetings, search_meetings is much cheaper. If the meeting is
plan-restricted, returns {accessible: false, needs_upgrade: true, reason,
upgrade_url, transcript: null}; tell the user it needs a Laxis plan upgrade and
share upgrade_url.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | ||
| max_chars | No | ||
| meeting_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It explains pagination (offset, next_offset), character limits, and the plan-restricted error response with specific fields and recommended user action. This is comprehensive behavioral disclosure.
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 description is efficiently structured: core functionality first, then pagination details, usage guidelines, and edge case handling. Each sentence adds value with no redundancy.
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?
Given no output schema and no annotations, the description covers pagination, error handling, and format. It doesn't mention behavior for invalid meeting IDs or missing transcripts, but those may be standard. Still, adequate for its complexity.
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 description coverage is 0%, so description must compensate. It explains how offset and max_chars work together for pagination, and the required meeting_id is implied. While not explicitly describing each parameter, the usage context provides sufficient meaning.
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 description clearly states the tool reads a meeting transcript with a specific format '[m:ss] Speaker: text' and is paginated. It distinguishes itself from siblings like search_meetings by specifying that this tool is for reading the actual conversation, not for locating topics.
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?
Provides explicit guidance: 'Use this only when you need to read the actual conversation — for locating a topic inside meetings, search_meetings is much cheaper.' This clearly tells the agent when to use and when not to use, naming the alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_meetingsAInspect
List the user's meetings, newest first (id, title, date, duration, short summary).
Call this when the user asks about their meetings ("what meetings did I have
last week?") or when you need a meeting_id for get_meeting / get_transcript
and don't have one. For content questions ("what did we say about pricing?"),
prefer search_meetings.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| page_size | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses ordering (newest first) and returned fields. Missing details about pagination behavior (e.g., total pages, next page hints) but no misleading info.
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?
Three sentences, front-loaded with key info (list, order, fields). Every sentence earns its place; no wasted words.
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?
Given no output schema, description covers returned fields. However, pagination details (total count, page navigation) are omitted. For a list tool, this is a minor gap but still fairly complete.
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 has 2 parameters (page, page_size) with 0% description coverage. Description does not mention these parameters, leaving their meaning and defaults unexplained. Parameters are simple but description should compensate.
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?
Description clearly states the tool lists meetings sorted newest first, with specific fields (id, title, date, duration, short summary). It distinguishes from siblings by name: search_meetings for content questions, get_meeting/get_transcript for specific IDs.
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 states when to use: when user asks about meetings or when needing a meeting_id. Also explicitly states when to prefer search_meetings for content questions, providing clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_meetingsAInspect
Semantic search across the user's meeting transcripts; returns matching snippets.
This is the first tool to reach for on content questions ("what did we
decide about pricing?", "上次和客户聊了什么"). Each snippet carries its
meeting_id and timestamp metadata, so you can cite sources and follow up
with get_meeting / get_transcript. Optionally restrict to one meeting
(meeting_id) or a date range (from_date/to_date, YYYY-MM-DD). Answer from
the returned snippets; if they are insufficient, refine the query or read
the transcript directly.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| query | Yes | ||
| to_date | No | ||
| from_date | No | ||
| meeting_id | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It states that the tool performs semantic search and returns snippets with metadata. It does not list any side effects, auth requirements, or limitations such as indexing dependencies, which would improve transparency.
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 description is a single paragraph of 4 sentences, front-loading the purpose and then adding usage guidance and parameters. Every sentence is necessary and there is no fluff.
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?
Given 5 parameters, no output schema, and no annotations, the description covers the core functionality, parameters (except k), and usage flow. It explains the snippets carry metadata for citation. Missing explicit default for k, but overall adequate for a search tool.
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 0%, but the description adds meaning for 4 of 5 parameters: query, meeting_id (optional restrict), from_date/to_date (YYYY-MM-DD format). It omits the 'k' parameter (number of snippets). The added context compensates partially, but missing 'k' leaves a gap.
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 description clearly states 'Semantic search across the user's meeting transcripts; returns matching snippets.' It uses a specific verb (search) and resource (meeting transcripts), and distinguishes from siblings by positioning itself as the first tool for content questions.
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?
The description explicitly says 'This is the first tool to reach for on content questions' and gives example queries. It suggests following up with get_meeting/get_transcript if snippets are insufficient. It mentions optional parameters for filtering, but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!