Server Quality Checklist

Tool Scores

• fathom_meeting_statsA
  3.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and behavior. The description adds valuable context beyond this: it explains how duration is calculated ('from recording start to end time'), team breakdown logic ('based on recorder's team'), and defines 'external' meetings ('one or more external participants'). This enhances understanding without contradicting annotations.

  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?

  The description is well-structured with clear sections (Args, Returns, Examples, Notes) and front-loaded purpose. It's appropriately sized for a tool with 4 parameters and no output schema, though some redundancy exists (e.g., parameter descriptions in both schema and description). Most sentences earn their place by providing examples or clarifying notes.

  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 the tool's complexity (analytics with filtering), rich annotations (4 hints), and 100% schema coverage, the description is mostly complete. It explains key behavioral aspects (e.g., calculation methods) and provides examples. However, without an output schema, it could benefit from more detail on return value formats or limitations, but the Returns section partially compensates.

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

  Parameters3/5

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

  Schema description coverage is 100%, with each parameter well-documented in the schema (e.g., 'Filter meetings created after this ISO 8601 timestamp'). The description repeats parameter names and adds minimal extra semantics (e.g., examples for 'created_after' and 'teams'), but doesn't significantly enhance meaning beyond what the schema provides. With high schema coverage, the baseline of 3 is appropriate.

  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's purpose: 'Get analytics and statistics about your Fathom meetings' and specifies what it calculates ('aggregate statistics about your meetings including duration metrics, team breakdowns, and internal vs external meeting ratios'). It distinguishes from siblings like 'fathom_list_meetings' by focusing on analytics rather than listing. However, it doesn't explicitly differentiate from 'fathom_participant_stats' which might also provide statistical insights.

  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 provides implied usage through examples (e.g., 'All time stats', 'This month', 'Sales team'), suggesting when to use this tool for aggregated analytics. However, it lacks explicit guidance on when to choose this over alternatives like 'fathom_list_meetings' for raw data or 'fathom_participant_stats' for participant-focused stats. No when-not-to-use scenarios or prerequisites are mentioned.

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

• fathom_participant_statsA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds valuable context beyond annotations: it specifies the analytics scope (participants and recorders), mentions filtering by time range, and describes the return structure (top_participants, domain_breakdown, top_recorders), which is helpful since there's no output schema. 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.

  Conciseness4/5

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

  The description is well-structured with clear sections (purpose, Args, Returns, Examples) and efficiently conveys information. However, the Args section slightly repeats schema details without adding new insights, and the purpose statement could be more front-loaded. Overall, it's concise but has minor 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?

  Given the tool's moderate complexity (analytics with filtering), rich annotations, and 100% schema coverage, the description is largely complete. It explains the return values (since no output schema exists) and provides usage examples. However, it lacks explicit guidance on sibling tool differentiation, which slightly reduces completeness for an agent.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal value beyond the schema: it repeats parameter names and basic purposes in the Args section but doesn't provide additional syntax, constraints, or usage nuances. Baseline 3 is appropriate as the schema does the heavy lifting.

  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's purpose: 'Get analytics about meeting participants and recorders in Fathom' and elaborates with 'analyzes who attends your meetings most frequently and which domains are most common.' It distinguishes from siblings like fathom_get_summary or fathom_meeting_stats by focusing specifically on participant statistics rather than meeting content or general metrics.

  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 provides implied usage through examples (e.g., 'All time stats', 'This quarter'), but lacks explicit guidance on when to use this tool versus alternatives like fathom_meeting_stats or fathom_list_meetings. No clear exclusions or prerequisites are stated, leaving the agent to infer context from the analytics focus.

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

• fathom_search_meetingsA
  4.1/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond annotations: it notes the search is case-insensitive, searches across transcripts and summaries (fetched automatically), and is limited to most recent meetings for performance. Annotations already declare readOnlyHint=true and idempotentHint=true, so the description appropriately supplements rather than contradicts them.

  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?

  The description is well-structured with clear sections (purpose, args, returns, examples, notes) and front-loads the core functionality. Some redundancy exists between the Args section and schema, but overall it's appropriately sized and organized for a search tool with multiple parameters.

  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 search tool with rich annotations (readOnlyHint, openWorldHint, idempotentHint) and comprehensive schema coverage, the description provides adequate context. It explains what gets searched, behavioral constraints, and includes helpful examples. The lack of output schema is partially compensated by the Returns section describing the response format.

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

  Parameters3/5

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

  With 100% schema description coverage, the schema already documents all parameters thoroughly. The description's 'Args' section mostly repeats schema information, though it adds minor clarification about default values. The examples provide helpful usage patterns but don't add significant semantic value beyond the schema.

  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's purpose: 'Search across Fathom meeting titles, transcripts, and summaries' with the specific verb 'search' and resource 'meetings'. It distinguishes from siblings like 'fathom_list_meetings' by emphasizing text search functionality rather than simple listing.

  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 provides clear context about when to use this tool ('to find relevant discussions, mentions, or topics') and mentions it searches across transcripts and summaries. However, it doesn't explicitly contrast with alternatives like 'fathom_list_meetings' or specify 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.

• fathom_list_teamsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds valuable context beyond annotations: it specifies that results are paginated, shows the return structure with name and created_at fields, and provides concrete examples of usage patterns. No contradiction with annotations exists.

  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?

  The description is well-structured with clear sections (purpose, args, returns, examples) and front-loaded with the core functionality. However, the repetition of parameter details that are already in the schema adds minor redundancy, preventing a perfect score. Most sentences earn their place by providing examples or clarifying returns.

  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?

  Given the tool's low complexity (2 optional parameters), rich annotations covering safety and behavior, and the description's inclusion of return structure and examples, this is complete enough for effective use. The lack of an output schema is compensated by the description detailing what the paginated list returns. No significant gaps remain for a list operation.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both parameters fully documented in the schema. The description repeats the same information about cursor and response_format without adding additional semantic meaning or usage nuances beyond what's in the schema. This meets the baseline of 3 when schema coverage is complete.

  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 specific action ('List all teams'), resource ('teams accessible to the authenticated user in Fathom'), and scope ('in your Fathom workspace'). It distinguishes from siblings like fathom_list_team_members by focusing on teams rather than members, and from fathom_list_meetings by targeting teams instead of meetings.

  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 provides clear context about when to use this tool ('to organize recordings and control access to meeting content'), but doesn't explicitly state when not to use it or name specific alternatives among siblings. The examples imply usage for pagination and format selection, but lack explicit comparison to other list tools.

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

• fathom_get_summaryA
  4.3/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it specifies that summaries are 'always in English regardless of the meeting's original language' and describes what the summary includes ('key discussion points, decisions made, and important topics covered'), which helps the agent understand the tool's output characteristics.

  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 well-structured and front-loaded: the first sentence states the core purpose, followed by details on what the summary includes, parameter explanations, return information, examples, and notes. Every section adds value without redundancy, and the length is appropriate for the tool's complexity.

  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?

  Given the tool's low complexity (2 parameters, 100% schema coverage), rich annotations (covering read-only, non-destructive, idempotent behavior), and no output schema, the description is complete. It explains what the tool does, what the summary contains, parameter usage with examples, and important behavioral notes (like English-only output), leaving no significant gaps for the agent.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both parameters well-documented in the schema. The description's Args section repeats this information but adds minimal extra meaning (e.g., 'The recording_id can be found in the meeting list response' provides sourcing context). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, with slight credit for the sourcing note.

  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 specific action ('retrieves'), resource ('AI-generated summary for a specific Fathom recording'), and scope ('for each meeting'). It distinguishes from siblings like fathom_get_transcript (which gets raw transcripts) and fathom_list_meetings (which lists meetings rather than retrieving summaries).

  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 provides clear context for when to use this tool ('to get the AI-generated summary for a meeting'), and the notes section offers practical guidance ('recording_id can be found in the meeting list response'). However, it doesn't explicitly state when NOT to use it or name alternatives (like using fathom_get_transcript for raw content instead of summaries).

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

• fathom_get_transcriptA
  4.3/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond annotations: it notes transcripts can be large for long meetings, speaker names are matched to calendar invitees when possible, and timestamps are relative to recording start. Annotations already declare readOnlyHint=true, destructiveHint=false, etc., so the bar is lower, but the description provides useful operational details about data characteristics and matching behavior.

  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 well-structured with clear sections (Args, Returns, Examples, Notes), front-loaded with the core purpose, and every sentence adds value. No wasted words or redundant information, making it efficient for an agent to parse and understand.

  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?

  Given the tool's moderate complexity, rich annotations (readOnlyHint, openWorldHint, etc.), and 100% schema coverage, the description is complete. It explains what the tool returns (array structure with speaker, text, timestamp), provides examples, and adds operational notes about data size and matching behavior. No output schema exists, so the return value documentation is particularly valuable.

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

  Parameters3/5

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

  With 100% schema description coverage, the schema already fully documents both parameters. The description adds minimal value beyond the schema: it mentions the recording_id is required and response_format has a default, but these are already clear in the schema. The examples provide usage context but don't add semantic meaning beyond what's in the structured fields.

  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 specific action ('Get the full transcript'), resource ('Fathom recording'), and scope ('complete timestamped transcript including speaker identification and timestamps'). It distinguishes from sibling tools like fathom_get_summary (which provides summaries) and fathom_list_meetings (which lists meetings rather than providing 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 usage context by specifying it retrieves transcripts for recordings, but doesn't explicitly state when to use this versus alternatives like fathom_get_summary for summaries or fathom_search_meetings for finding meetings. It provides clear examples but lacks explicit 'when-not-to-use' guidance or named alternatives.

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

• fathom_list_team_membersA
  4.3/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true. The description adds valuable context beyond annotations by specifying the pagination behavior ('Paginated list'), describing the return data structure, and providing concrete examples. It doesn't contradict annotations and enhances understanding of the tool's behavior.

  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 well-structured with clear sections (purpose, args, returns, examples). Every sentence earns its place by providing necessary information. It's appropriately sized for a tool with 3 parameters and no output schema, with no redundant or unnecessary content.

  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?

  For a read-only list tool with comprehensive annotations and 100% schema coverage, the description provides excellent completeness. It covers purpose, parameters, return format, pagination behavior, and includes practical examples. The lack of an output schema is compensated by the detailed return description in the text.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema - it restates the team parameter's purpose and provides examples, but doesn't add significant semantic context. The baseline of 3 is appropriate when the schema does most of the parameter documentation work.

  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 verb ('List') and resource ('team members') with specific scope ('of a specific team or all teams in Fathom'). It distinguishes from sibling tools like fathom_list_teams (which lists teams, not team members) and fathom_list_meetings (which lists meetings). The description provides concrete details about what information is retrieved.

  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 provides clear context about filtering options ('specific team or all teams') and includes examples showing different usage scenarios. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among siblings (like when to use fathom_list_teams instead). The guidance is helpful but not exhaustive about alternatives.

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

• fathom_delete_webhookA
  4.5/5.0
  Behavior5/5

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

  The description adds valuable behavioral context beyond annotations: it notes that the action 'cannot be undone', specifies immediate effects ('will immediately stop receiving notifications'), and mentions potential side effects ('Any pending notifications may still be delivered'). This complements annotations like destructiveHint=true and idempotentHint=true, providing practical insights without contradiction.

  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 well-structured and front-loaded with the core action, followed by organized sections (Args, Returns, Examples, Notes). Each sentence adds value, such as clarifying irreversible consequences and notification behavior, with no wasted words or redundancy.

  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?

  Given the tool's complexity (destructive action with one parameter), the description is complete: it covers purpose, usage, behavioral details, and examples. Although there is no output schema, the Returns section provides adequate information. The annotations and description together offer a comprehensive view without gaps.

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

  Parameters3/5

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

  With 100% schema description coverage, the input schema already fully documents the 'id' parameter. The description repeats this information in the Args section but adds no additional meaning or context beyond what the schema provides, meeting the baseline for high schema coverage.

  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 specific action ('Delete') and resource ('an existing webhook from Fathom'), distinguishing it from sibling tools like fathom_create_webhook. It explicitly mentions what happens ('removes a webhook subscription, stopping all future notifications'), making the purpose unambiguous and distinct.

  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 provides clear context for when to use this tool ('Delete an existing webhook'), but does not explicitly mention when not to use it or name alternatives. It implies usage by stating the action, though lacks explicit guidance on prerequisites or comparisons with other tools.

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

• fathom_list_meetingsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true. The description adds valuable behavioral context beyond this: it specifies this retrieves 'meeting recordings' (not just metadata), mentions pagination behavior, describes what optional content can be included (summaries, transcripts, etc.), and provides examples of common use cases. This goes well beyond what annotations provide.

  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 well-structured and front-loaded: the first sentence states the core purpose, followed by logical groupings of functionality, then parameter explanations, return information, and practical examples. Every section earns its place by adding distinct value. The information density is high without being verbose.

  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?

  For a list/retrieve tool with comprehensive annotations (readOnly, openWorld, idempotent, non-destructive) and 100% schema coverage, this description provides excellent context. It explains what kind of data is retrieved, filtering capabilities, optional inclusions, pagination behavior, output format options, and includes practical examples. The lack of output schema is compensated by the clear 'Returns' statement and format parameter explanation.

  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?

  With 100% schema description coverage, the baseline is 3. The description adds significant value by grouping parameters into logical categories ('You can filter by:' and 'You can optionally include:'), providing context about what each filter type does, and giving concrete examples in the Examples section. This helps the agent understand parameter relationships and typical usage patterns beyond the schema's individual parameter descriptions.

  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 verb 'retrieves' and resource 'meeting recordings from your Fathom account', distinguishing it from siblings like fathom_search_meetings (which likely has different search capabilities) and fathom_get_summary/fathom_get_transcript (which focus on specific meeting details rather than listing). The opening sentence establishes the core functionality with optional filtering and pagination.

  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 provides clear context about when to use this tool - for listing meetings with various filtering options. It doesn't explicitly state when NOT to use it or name specific alternatives, but the examples and parameter descriptions help guide usage. The distinction from siblings like fathom_search_meetings is implied but not explicitly stated.

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

• fathom_create_webhookA
  4.7/5.0
  Behavior5/5

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

  The description adds significant behavioral context beyond what annotations provide. While annotations indicate this is a non-destructive, non-idempotent write operation, the description adds crucial details: webhooks use HMAC-SHA256 signatures, the secret is only shown once upon creation, webhooks must return 2xx status to acknowledge receipt, and the tool returns specific webhook details. This provides valuable operational context not captured in annotations.

  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 well-structured and efficiently organized. It starts with the core purpose, then provides parameter details, return values, examples, and important notes. Each section serves a clear purpose with no redundant information. The formatting with clear sections (Args, Returns, Examples, Notes) makes it easy to parse.

  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?

  For a creation tool with no output schema, the description provides excellent completeness. It explains what the tool does, all parameters, return values with their purpose, practical examples, and important operational notes about security and acknowledgment requirements. This gives the agent everything needed to correctly invoke and understand the tool's behavior.

  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?

  With 100% schema description coverage, the baseline would be 3, but the description adds meaningful context beyond the schema. It explains what 'triggered_for' values represent in practical terms (types of recordings), provides examples of parameter usage, and clarifies that 'include_*' parameters control what content appears in the payload. This enhances understanding beyond the schema's technical definitions.

  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's purpose with specific verb ('create') and resource ('webhook'), and distinguishes it from siblings by specifying it's for receiving real-time notifications when meetings are processed. The first sentence explicitly states what the tool does: 'Create a webhook to receive real-time notifications when meetings are processed in Fathom.'

  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 provides clear context for when to use this tool (to receive real-time notifications when meetings are processed) and mentions the sibling tool 'fathom_delete_webhook' indirectly through the return value note about using the ID for deletion. However, it doesn't explicitly state when NOT to use this tool or provide direct alternatives among siblings.

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