Server Quality Checklist

Tool Scores

• fathom_healthB
  3.4/5.0
  Behavior3/5

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

  The description discloses 'read-only', which is a useful safety signal given the absence of annotations. However, it does not explain what the health/config check actually returns, how failures are surfaced, or any side effects (though read-only minimizes risk). Minimal context is added beyond the name.

  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 a single, front-loaded sentence: 'Read-only Fathom health/config check.' Every word is informative, and there is no wasted text.

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

  Completeness3/5

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

  For a tool with no parameters and no output schema, the description is almost sufficient but leaves out return value expectations. The agent does not know whether the tool returns a simple status, metrics, or throws on unhealthy conditions. A sentence about output would complete the picture.

  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 tool has zero parameters, so the schema is empty. The description does not need to document parameters, and there is no coverage gap to compensate for. Baseline 4 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 it is a 'health/config check' for Fathom, using specific nouns that distinguish it from sibling tools focused on meetings. It lacks a strong verb like 'verify' or 'inspect', but the intent is unambiguous.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus the meeting-related siblings. The context implies it is for system health verification, but no explicit when-to-use, prerequisites, or alternatives are mentioned.

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

• fathom_get_latest_meetingA
  4.2/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 it explicitly states 'Read-only fetch', disclosing non-mutating behavior. It also references the output shape ('same summarized fields as fathom_list_recent_meetings'), which is useful transparency. It does not cover edge cases like no meetings existing, but the core safety profile is clear.

  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 concise sentence that front-loads the action and scope, then adds relevant context. Every phrase earns its place, with no unnecessary fluff.

  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 read-only tool with one optional parameter, the description covers purpose, output shape by reference, and the limited scope. It lacks explicit mention of empty-result behavior, but this is a minor gap given the low complexity and full schema coverage.

  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 the parameter 'recorded_by' already described in the schema. The description adds no additional parameter semantics, so the baseline of 3 applies.

  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 'Read-only fetch of the single most recent Fathom meeting', identifying a specific verb ('fetch') and resource (most recent meeting). It also differentiates from siblings by referencing 'fathom_list_recent_meetings' and specifying 'exactly one meeting'.

  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 explicitly names the primary use case ('the 90% case for /updateP1') and contrasts with the list tool ('same summarized fields ... for exactly one meeting'), implying when to use this versus the list alternative. It lacks explicit exclusions, but the context is clear.

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

• fathom_list_recent_meetingsA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden. It discloses read-only behavior, result ordering, returned fields, and a major limitation (no title/keyword search). It does not mention authentication or rate limits, but the core safety and behavioral traits are clearly stated.

  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 sentences: a concise functional overview with return fields, and a practical usage note with a limitation and example. No wasted words; every clause 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?

  Without an output schema, the description provides the key return fields and ordering, which is useful. It also covers the main usage scenario and limitations. Gaps remain: meeting_type is ambiguous, pagination (limit max=50) is not discussed, and no response envelope details are given. Overall, it is sufficiently complete for a straightforward list tool.

  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 coverage is 67%, and the description adds context for two parameters (created_after, recorded_by) by explaining their role in narrowing. However, limit, meeting_type, created_before, and invitee_domains are not explained in the description beyond schema notes. The description compensates partially but not fully for the missing 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 states a specific action ('list recent Fathom meetings') with a specific resource and ordering ('newest first'). It distinguishes from siblings by listing returned fields and noting the lack of search, setting it apart from get_latest_meeting and get_transcript.

  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?

  The description explicitly tells when to use this tool: to find a specific meeting when no search exists, narrow by filters, and manually filter. It also provides a concrete example ('yesterday's call with McDonald's') and implies alternatives by noting the API has no search, directing the agent to use this tool instead.

  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.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It states that the fetch is 'read-only', it returns 'raw transcript text/segments', and it explicitly excludes summary generation. However, it does not mention error handling, rate limits, or authentication requirements, which would be useful but are not critical for a simple read-only fetch.

  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 sentences long, front-loaded with the key action and output type, and every word serves a purpose. It is concise without losing necessary details.

  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 one-parameter read-only tool, the description covers the purpose, input source, and output nature. It also references sibling tools for context. Minor gaps include lack of detail on the exact structure of the returned segments and error behavior, but these are not essential for a tool of this simplicity.

  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 provides zero description for recording_id, but the description adds meaning by identifying it as the ID for the recording and instructing the user to obtain it from sibling tools. This goes beyond the bare type information in 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 action ('Read-only fetch'), the resource ('RAW transcript'), and the scope ('by recording_id'). It also distinguishes itself from sibling tools by noting that the who/what/when summary is produced by the skill, not by this tool, making its purpose unambiguous.

  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?

  The description explicitly tells the user how to obtain the required recording_id from fathom_list_recent_meetings or fathom_get_latest_meeting, and clarifies that this tool does not produce summaries, implying it should be used when raw transcript is needed. This provides clear context on when to use the tool.

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