Server Quality Checklist

Tool Scores

• get_meetingA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It indicates a read operation on meeting metadata and enumerates the included data, but it does not disclose error behavior, permissions, or return format. This is acceptable for a simple get, but leaves some room for improvement.

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

  Conciseness5/5

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

  The description is one sentence, front-loaded with the core purpose, and every word adds value. It is extremely concise without losing important information.

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

  Completeness4/5

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

  For a simple one-parameter tool with no output schema, the description adequately scopes the result by listing key metadata components. It omits potential error cases or exact return shape, but given the simplicity, it is fairly complete for an agent to use correctly.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description adds no explanation of meeting_id beyond its name. Since the tool has one parameter and the description does not compensate for the lack of schema descriptions, the agent must infer the intended meaning from the parameter name alone.

  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 description clearly states the tool retrieves full metadata for one meeting, listing specific components (roster, named speakers, transcript availability, pending clarification count). This distinguishes it from siblings like list_meetings and get_transcript, which have clearly different functions.

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

  Usage Guidelines4/5

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

  The description gives clear context on what this tool returns, implying it should be used when detailed metadata for a specific meeting is needed. It does not explicitly mention alternatives or when not to use it, but the focus on 'one meeting' differentiates it from list_meetings and get_transcript.

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

• list_meetingsA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful context like 'newest first' sorting, inclusive date boundaries, and case-insensitive substring matching for the app filter. However, it does not mention pagination behavior, what happens when filters are omitted, or any permissions needed, leaving some behavioral aspects unclear.

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

  Conciseness5/5

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

  The description is two short paragraphs. The first sentence states the primary purpose, and the second paragraph details parameter behavior. There is no redundant information or filler; every sentence contributes to understanding how the tool works.

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

  Completeness4/5

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

  Given that an output schema exists, the description does not need to explain return values. It adequately covers the core behavior (listing recorded meetings with optional date and app filters, sorted newest first). The only minor gap is the lack of explicit mention of the limit parameter's behavior, but the schema provides a default, making the tool usable without further detail.

  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?

  The schema has zero parameter descriptions, so the description must compensate. It adds meaning for three of the four parameters: from_date/to_date are described as inclusive ISO dates, and app is described as a case-insensitive substring. The 'limit' parameter is left entirely to the schema, but its meaning is obvious from its name and default value, so the description covers most parameter semantics effectively.

  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 description starts with 'List recorded meetings, newest first,' which clearly states the action (list) and resource (recorded meetings). It also distinguishes itself from siblings like get_meeting (which retrieves a specific meeting) and get_transcript (which retrieves a transcript) by focusing on the list operation.

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

  Usage Guidelines3/5

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

  The description explains the filtering semantics (from_date/to_date inclusive, app as case-insensitive substring) and implies usage for listing meetings with optional filters. However, it does not explicitly state when to use this tool vs alternatives (e.g., search_transcripts) or mention any exclusions or prerequisites, so the guidance is implied but not fully explicit.

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

• get_transcriptA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden and does well: it discloses that by default it does NOT return the transcript text, returns a `path` to a rendered file, and warns about context flooding. It also clarifies the inline alternative, providing essential behavioral expectations beyond the schema.

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

  Conciseness5/5

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

  Every sentence provides value: the first states the core output, the second explains the default and the reasoning, the third explains the inline alternative. Well-structured in two readable paragraphs with no redundancy.

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

  Completeness4/5

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

  For a read-only tool with 3 parameters and no output schema, the description covers the essential behavior, default vs. inline modes, and the file path usage. It could be more explicit about when to prefer search_transcripts, but given the sibling list, the description is sufficiently complete for effective invocation.

  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 0%, so the description must compensate, and it does: `limit` and `offset` are explained as controlling a slice of segment lines, and `meeting_id` is implied via 'meeting transcript'. The distinction between default (no text) and passing `limit` clarifies the meaning of the parameter effectively.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides 'the meeting transcript, with resolved speaker names and clock timestamps' and distinguishes itself by describing its default behavior (metadata plus path, not text). The lack of an explicit verb like 'retrieves' is compensated by the tool name and the detailed description of what is returned.

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

  Usage Guidelines4/5

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

  It explains when to use the default mode (avoid flooding context) versus when to pass `limit`/`offset` for inline text (e.g., no filesystem access). This gives clear usage context, though it does not explicitly name sibling tools like search_transcripts as alternatives.

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

• search_transcriptsA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden and provides meaningful behavioral details: case-insensitive matching, newest-first ordering, and inclusion of matching transcript lines as excerpts. It does not cover limit behavior or edge cases, but the core behavior is disclosed.

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

  Conciseness5/5

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

  The description is extremely concise: two sentences with no filler, immediately stating the action and key return characteristics. Every word adds value.

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

  Completeness4/5

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

  For a simple search tool with an output schema, the description covers purpose, scope, sorting, and excerpt behavior. It does not need to explain return structure since the output schema exists, though limit behavior is not addressed.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate but only implicitly covers 'query'. It does not explain the 'limit' parameter's meaning or effect, leaving a gap in parameter semantics.

  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 description clearly specifies a unique action ('Search all transcripts for a phrase') with scope, case-insensitivity, and return format. It distinguishes from sibling tools (list/get) by focusing on search across all transcripts.

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

  Usage Guidelines4/5

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

  The description implies its use for finding content within transcripts, clearly distinct from listing or retrieving specific meetings. However, it does not explicitly mention exclusions or alternative tools when other actions would be more appropriate.

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