Server Quality Checklist

Tool Scores

• place_outbound_callB
  3.1/5.0
  Behavior2/5

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

  With no annotations, this description carries the full disclosure burden, but it only surfaces the API-key requirement. It does not state that this places a real outbound call, may incur cost, runs asynchronously, or triggers webhooks, so an agent cannot anticipate the side effects.

  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 text is short and front-loads the action, with the API-key requirement in a separate concise sentence. It loses a point because the first sentence partially restates the tool name and carries no usage or behavior detail.

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

  Completeness2/5

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

  For an 8-parameter action tool with no output schema and no annotations, this one-line description is not complete. It omits the call lifecycle, asynchronous behavior, result/transcript retrieval, and any caveats, though the schema covers parameter meaning.

  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%, including E.164 format for target and instruction-set semantics for tasks, so the schema already documents the parameters adequately. The description adds no parameter-level information, leaving the score at baseline.

  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 uses a specific verb ('Place') with a clear resource ('outbound ClawdCall agent call'), and the action is obviously distinct from the sibling tools, which handle OTP verification and transcript retrieval. It tells an agent exactly what operation this tool performs.

  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 given about when to choose this tool over its siblings or when not to use it. The only usage-related note is the CLAWDCALL_API_KEY requirement, which is a prerequisite rather than a selection criterion.

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

• send_signup_otpA
  3.7/5.0
  Behavior2/5

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

  With no annotations, the description bears the full burden for behavioral disclosure. It only states that no API key is required; it does not disclose side effects such as sending an SMS, OTP expiration, retry/resend behavior, rate limits, or what the API returns. For a side-effectful 'send' tool, this is a significant transparency gap.

  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 compact sentences with no filler. The core action is front-loaded and the auth note is a single extra phrase. Every word contributes.

  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?

  The description is reasonably complete for a simple send operation, but with no output schema and no annotations it omits expected return values, error conditions, and any state change/expiry information. An agent can call it correctly for the basic happy path but lacks context for handling failures or next steps.

  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 50%: phone_number is described, but email only has a format. The description adds no direct parameter semantics, though 'phone verification OTP' helps clarify that phone_number is the delivery target and email is the signup identity. This is adequate for two simple parameters but does not go beyond schema content.

  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 uses a specific verb ('Send'), names the exact resource ('ClawdCall signup phone verification OTP'), and is clearly distinguishable from siblings like verify_signup_otp, which handles a later verification step. 'Does not require an API key' adds useful context without obscuring the core function.

  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 phrase 'ClawdCall signup phone verification' establishes when the tool should be used. The explicit no-API-key note is a useful prerequisite. However, it does not explicitly name verify_signup_otp as the follow-up or state when not to use this tool, so it stops just short of full routing guidance.

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

• get_call_transcriptA
  3.8/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the burden. It discloses the CLAWDCALL_API_KEY requirement, a meaningful credential prerequisite, and 'Fetch' implies a read-only operation. However, it does not describe error cases or return format, leaving some behavior undisclosed.

  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?

  Two sentences, both essential: the first states the action and identifier types, the second states the required credential. No filler or redundancy, and the key information is front-loaded.

  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 fetch tool, the description covers the essential action, the accepted identifier, and the authentication requirement. It does not specify the response shape, but with no output schema, a brief note on what the transcript contains would improve completeness; still, it is largely sufficient.

  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?

  The schema already documents the single 'id' parameter with a matching description ('Call ID or campaign ID returned by ClawdCall'), and schema coverage is 100%. The tool description essentially repeats this, adding no new semantic detail, so baseline 3 is appropriate.

  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 uses the specific verb 'Fetch' with the resource 'ClawdCall transcript' and scopes it by 'call ID or campaign ID.' This clearly distinguishes it from sibling tools that send/verify OTPs or place outbound calls.

  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 implies when to use it (when needing a transcript) but does not explicitly contrast with sibling tools or state situations where another tool would be appropriate. The usage context must be inferred from the tool name and sibling set, so it is adequate but not explicit.

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

• verify_signup_otpA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It usefully states the auth prerequisite and the response content, but it does not disclose OTP expiry, single-use/consumption behavior, or failure outcomes such as invalid OTP handling.

  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?

  Two sentences with no filler; the core action is front-loaded and the auth requirement is a separate, useful note. Every sentence earns its place.

  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 three-parameter tool, the description covers the operation, the auth context, and the high-level return value. It is slightly underspecified because there is no output schema and the exact shape of 'account/API-key details' is not described, but enough is present for correct invocation.

  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%; otp and phone_number are described in the schema, while email is only format-constrained. The tool description adds no additional parameter semantics, so it does not materially compensate for the missing email description, though email's self-describing format limits the impact.

  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 states a specific verb ('Verify') and resource ('ClawdCall signup OTP'), and explicitly says the tool returns account/API-key details. This clearly distinguishes it from the sibling send_signup_otp, whose action is sending rather than verifying.

  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 phrase 'signup OTP' and 'Does not require an existing API key' give clear context: it belongs in a signup flow before an API key exists. It does not explicitly name alternatives or exclusion criteria, but the intended scenario is unambiguous relative to the sibling tools.

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