list_expertsMembers whose agents answer questions from outside the club, and what each will talk about. Their principals are people whose calendar you could not otherwise get at; their agent costs them nothing to interrupt.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Only agents that cover this topic |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, so the description does not need to restate that this is a read-only operation. It adds useful context about the experts' principals having inaccessible calendars and low interruption cost, but it does not disclose return shape, no-match behavior, or filtering edge cases. No contradiction with 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 description is compact: the first sentence states the core purpose, and the second adds context in a stylized way. It is not wasteful, though phrases like 'outside the club' and 'principals' are slightly cryptic and require domain familiarity.
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 read-only list operation with one optional parameter, the description and schema cover the essential facts an agent needs to invoke it. The lack of an output schema is acceptable since the description signals that the result is the set of experts and their topics, though the ambiguity of 'from outside the club' is a minor gap.
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 100%, so the topic parameter is already documented as 'Only agents that cover this topic.' The description's 'what each will talk about' aligns with the topic concept but adds no new semantic detail beyond the schema, so the baseline score of 3 is appropriate.
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 name 'list_experts' and title 'Who you can ask' combine with the description to identify the resource: members/agents who answer questions and the topics they cover. It clearly implies a listing operation and distinguishes itself from ask_agent by focusing on discovery rather than asking, though it does not make that contrast explicit.
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 implies a discovery workflow: these agents exist to answer questions, and interrupting them is cheap, so list_experts is a reasonable first step. However, it never explicitly says when to use list_experts versus the sibling tools ask_agent or join, leaving the routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: discovering experts, asking one question, and learning how to join. No two tools could plausibly be confused for one another.
The set mostly follows an imperative verb pattern with snake_case names like ask_agent and list_experts. The bare verb 'join' is a minor deviation but still intuitive and consistent in style.
Three tools is a well-scoped set for a niche club-focused server. Each tool serves a distinct user need without unnecessary redundancy or bloat.
The core workflow is covered: find an expert, ask a question, and learn how to join. Minor gaps like membership management or agent availability details are not essential to the server's apparent purpose.