Server Quality Checklist

Tool Scores

• simplepractice_list_documentsC
  2.9/5.0
  Behavior3/5

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

  The readOnlyHint annotation already covers the safety profile. The description adds that the files are 'shared through the Client Portal', providing a bit of context. However, it does not disclose anything like pagination behavior, sorting, or empty results. With the annotation present, this is a minimal but acceptable addition.

  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?

  One sentence, no wasted words. It is concise and to the point. However, it may be under-specified for a tool with a parameter, but conciseness itself is well executed.

  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?

  The description lacks essential context for a tool with no output schema. It does not explain the pageSize parameter, pagination, or any ordering. While it clarifies the return type (files shared via Client Portal), it is incomplete for an agent to call it correctly without further inference.

  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?

  The schema has zero description coverage, so the description should compensate. It does not mention the only parameter, pageSize, at all. The agent receives no guidance on how to use this parameter (e.g., default, max, or its effect on results). This is a clear gap.

  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 states the resource (files/documents) and context (shared via Client Portal), which clearly indicates a read/list operation. It distinguishes from sibling tools like list_document_requests by specifying actual files rather than requests. The verb is implicit rather than explicit, but the tool name reinforces it.

  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?

  The description gives no guidance on when to use this tool versus alternatives such as list_document_requests or get_document_request. It only defines what it returns, without clarifying selection criteria or context.

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

• simplepractice_list_announcementsB
  3.1/5.0
  Behavior3/5

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

  The readOnlyHint annotation already covers the read-only nature, and the description does not contradict it. The description adds behavioral context about the readAt field indicating read/unread status, which is useful. However, it does not disclose other behaviors like pagination (pageSize parameter), default ordering, or what happens when there are no announcements. Since annotations cover safety, the description adds some value but could be richer.

  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, consisting of two short sentences. The first sentence states the core purpose, and the second adds a relevant detail about the readAt field. Both sentences earn their place with no fluff. Information is front-loaded, with the primary noun first. Ideal conciseness for the amount of content.

  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?

  With only one simple parameter and no output schema, the description provides enough to understand what the tool returns at a high level (announcements with readAt status). However, it does not explicitly state that the response is a list of announcements, nor does it mention pagination behavior or ordering. Since there is no output schema, the description could compensate by outlining the response structure more clearly. It is minimally complete but not fully self-sufficient.

  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%, meaning the description does not explain any parameter. The only parameter, pageSize, is documented in the schema with type, default, and maximum, but the description adds no meaning about its effect (e.g., how to control result count). With low coverage, the description should compensate, but it remains silent on the parameter entirely. This is a gap in parameter explanation.

  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 identifies the resource (announcements posted to the Client Portal) and adds a key semantic detail (readAt is null on unread ones), which differentiates it from other list tools like list_appointments or list_documents. The verb is implied by the name 'list_announcements' but the description reinforces the purpose. It is specific enough to distinguish from siblings, though it could explicitly state it returns a list.

  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?

  The description provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios, exclusions, or comparisons to sibling tools. While the name and description make it obvious it's for announcements, it does not address selection criteria or context, such as 'use this to fetch announcements for the portal' or 'do not use for appointment data.'

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

• simplepractice_get_document_requestA
  3.8/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already establishes this as a read-only operation. The description adds that the response includes full details (body/questions/answers), which is useful context, but does not disclose any additional behavioral traits such as error handling, pagination, or authentication requirements. Given the annotation coverage, this is adequate but not exceptional.

  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, concise sentence that immediately conveys the core functionality ('One document request in full') and elaborates on what 'in full' means. There is no wasted verbiage, and the most important 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 simple retrieval tool with one parameter, no output schema, and a readOnlyHint annotation, the description is sufficient. It tells the agent what the tool returns and implies the need for an ID. It could mention that the ID is required, but the schema already indicates required, so this is adequately covered.

  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 description covers 100% of the parameter ('The document request id.'), and the tool description does not add further nuance beyond that. With full schema coverage, the baseline of 3 applies; the description doesn't need to compensate for any gaps.

  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 ('get'), a single resource ('one document request'), and the content ('in full, including its body or its questions and the answers already given'). This clearly distinguishes it from sibling tools that list document requests, leaving no ambiguity about the tool's function.

  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 this tool is for retrieving a single document request by ID, which is distinct from listing tools like 'list_document_requests'. However, it provides no explicit guidance on when to use this versus alternatives, nor any exclusion conditions. The usage context is inferred rather than stated.

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

• simplepractice_sign_outA
  3.8/5.0
  Behavior3/5

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

  The annotations already state readOnlyHint=false and idempotentHint=true, indicating a mutating but idempotent operation. The description adds that the action affects local state only, which is helpful context beyond the annotations. However, it does not disclose potential side effects (e.g., whether server-side session is invalidated) or behavior when no session exists. It adds some value 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.

  Conciseness5/5

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

  The description is a single concise sentence with no redundant words. It front-loads the essential action and includes the meaningful qualifier 'from local state.' Every word contributes to understanding the tool's behavior, and it is appropriately sized for a simple operation.

  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 simplicity (no parameters, no output schema, straightforward action), the description is largely sufficient. It clearly states what the tool does and its scope. However, it could optionally mention the effect on the user's authentication state (e.g., requiring re-authentication), but that is not essential for correct invocation. The description covers the core functional requirements.

  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?

  This tool has zero parameters, and schema description coverage is 100% (vacuously). Per the rubric, a 0-parameter tool receives a baseline of 4. The description does not need to elaborate on parameters since none exist. It effectively communicates that no arguments are required, which is sufficient.

  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: 'Discard the stored Client Portal session from local state.' It specifies the verb (discard), the resource (session), and the scope (local state). This distinguishes it from sibling tools like simplepractice_session_status (which checks status) and simplepractice_request_sign_in_link (which initiates sign-in). The purpose 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?

  The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that this should be used when a user explicitly logs out, nor does it contrast with other session-related tools. The tool's purpose is implied by its name and description, but no alternatives or exclusions are mentioned, leaving the agent to infer usage context.

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

• simplepractice_list_appointmentsA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, and the description adds useful behavioral context beyond that: it explains the meaning of the two statuses (scheduled vs. requested) and mentions pagination ('Pages by number'). No contradiction with annotations; the description enriches the behavior profile.

  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 concise—three short sentences with no fluff. The purpose is front-loaded, and every sentence adds value: the subject, the status semantics, and the pagination note. Excellent structure.

  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 covers the core behavior (listing appointments with status filter and pagination) but omits the compact parameter and pageSize details, which are present in the schema. For a read-only listing tool with no output schema, this is a reasonable but not exhaustive description; an agent might need to consult the schema for full parameter guidance.

  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%, and the description adds meaning for the status parameter (explains the enum values) and hints at page usage, but it does not mention compact or pageSize. Since it partially compensates for the schema gaps, it earns a middle score.

  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 lists appointments from the Client Portal, with explicit meaning for the status values ('scheduled' vs 'requested'). It distinguishes from sibling list tools by naming the specific resource (appointments) and domain (Client Portal), making its purpose unmistakable.

  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 gives clear context on how to use the status filter and mentions pagination, but it does not explicitly say when to use this tool over alternatives or provide exclusions. The usage is implied by the tool name and resource, but there's no direct comparison to siblings, so guidance 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.

• simplepractice_list_billing_itemsA
  3.9/5.0
  Behavior4/5

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

  The annotation readOnlyHint=true already marks the tool as non-destructive. The description adds value beyond this by noting empty lists are a legitimate response (many practices bill externally) and by documenting cursor-based pagination. Together, these give a clear behavioral profile.

  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 carry all essential information: the resource scope, the empty-list nuance, and the pagination mechanism. Nothing is wasted, and the most important info 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 list tool with no output schema, the description covers pagination, edge cases, and scope. It does not describe the item shape or error handling, but the core calling contract is clear and complete given the simplicity of the operation.

  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 only 33% (only 'before' has a description), so the description must compensate. It does: the opening list covers 'kind' values, and it explains the 'before' cursor semantics. 'pageSize' remains trivial but is well defined by schema defaults and max.

  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 lists invoices, statements, superbills, receipts, or account history from the Client Portal. It names the specific resource and action, which distinguishes the tool from siblings like list_payment_methods or get_billing_overview, though it does not explicitly name them.

  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 practical usage guidance: it assures empty lists are valid and explains pagination via cursor. However, it does not explicitly state when to use this tool versus alternatives like get_billing_overview, leaving that differentiation to inference.

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

• simplepractice_list_payment_methodsA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds valuable behavioral detail beyond annotations: it specifies that full card numbers are NOT returned, which is a critical privacy constraint. It also enumerates the exact fields returned (brand, last four digits, expiry). This is strong supplementary disclosure for a simple read operation.

  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 sentence that front-loads the core purpose and immediately states the key constraint (no full card numbers). Every word earns its place, and there is no fluff or 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 zero-parameter, read-only list tool with no output schema, the description is largely complete. It tells the agent what data to expect and what not to expect. It does not discuss response format or pagination, but these are minor gaps for such a simple tool, and the annotation covers the safety profile.

  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?

  There are no parameters, and schema description coverage is 100% (vacuous). The baseline for zero-parameter tools is 4, and the description does not need to explain parameters. It adds no parameter-specific information, which is appropriate here.

  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 resource (payment methods saved to the Client Portal) and the specific data returned (brand, last four digits, expiry). It is distinct from all sibling tools, which deal with sessions, appointments, billing, documents, etc. The purpose 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?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any alternative tools or scenarios where it should or should not be used. While the tool is obviously for listing saved payment methods, the absence of explicit usage context leaves the agent to infer intent.

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

• simplepractice_verify_sign_in_tokenA
  4/5.0
  Behavior4/5

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

  Annotations mark this as non-read-only and non-idempotent. The description adds critical behavioral details beyond that: tokens are single-use and expire after 24 hours. This helps the agent understand side effects and limitations, providing value beyond 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?

  Two concise sentences with no wasted words. The primary purpose is front-loaded, and each sentence delivers distinct value: purpose, input format, and token lifecycle. Efficient and well-structured.

  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 single-parameter tool without an output schema, the description covers the input format, token lifecycle, and the session outcome. It does not describe the response format, which is a minor gap, but overall it is sufficiently complete for a low-complexity 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 description coverage is 100% and the tool description essentially repeats the same guidance about accepting the whole link or token after '#'. No additional information about the parameter is provided beyond what the schema already states.

  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 (exchange a sign-in link/token), the resource (emailed link), and the outcome (Client Portal session). This distinguishes it from siblings like verify_sign_in_pin (PIN-based) and request_sign_in_link (sends the link).

  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 explicit input format guidance (whole link or token after '#'), but it does not mention when to prefer this tool over alternatives such as verify_sign_in_pin. Usage context is clear but no exclusions or alternative routing is given.

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

• simplepractice_get_accountA
  4.2/5.0
  Behavior4/5

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

  The readOnlyHint annotation already signals a safe read operation. The description adds valuable behavioral context by explaining that a single portal login may cover multiple clients and that clients is always a list, which helps the agent anticipate the return shape. 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.

  Conciseness5/5

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

  The description is two sentences with no fluff. It front-loads the core content (practice, client, clients list) and uses an illustrative example to clarify a non-obvious behavior. Every word 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 zero-parameter tool with a readOnly annotation and no output schema, the description sufficiently explains the conceptual return (practice, signed-in client, all visible clients). It lacks explicit output format details, but given the simplicity and existing annotations, it is largely complete.

  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 zero parameters, the schema already fully covers parameter documentation (100% coverage). The description has no need to add parameter meaning, and adheres to the baseline of 4 for tools with no parameters.

  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 returns the practice, the signed-in client, and every client visible to the login, with the specific clarification that clients is always a list. This precise scope distinguishes it from sibling tools that focus on specific operations like session status or sign-in links.

  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 what the tool returns and clarifies the multi-client nature, but it does not explicitly state when to use this tool versus alternatives. Since it's a general 'get account' tool, usage is implied, but no explicit exclusions or comparisons to siblings are given.

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

• simplepractice_get_billing_overviewA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so no contradiction. The description adds account scoping and a performance trait (cheaper), but doesn't disclose other behaviors such as rate limits or data freshness. This is comparable to the baseline for read-only tools 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.

  Conciseness5/5

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

  Two sentences with zero wasted words. The primary function is front-loaded, and the second sentence provides a clear usage hint. Perfectly sized for a zero-parameter overview tool.

  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 zero-parameter tool with no output schema, the description sufficiently explains the return content (balance due, per-category counts) and scope. It could mention what categories are included, but that may be overkill; the current text is complete enough for an agent to decide and call it appropriately.

  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?

  There are zero parameters and the schema is effectively empty (100% coverage). The description adds semantic value by explaining what the tool returns, which serves as the only parameter-related info needed. Baseline for zero params is met.

  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?

  States exactly what it returns (balance due, per-category counts) and scopes it to the Client Portal account. The verb is implicit but the resource and output are clear, and it distinguishes from detailed list tools like list_billing_items by being an aggregate overview.

  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?

  Explicitly gives a use case: cheaper than paging the billing collections when you only need to check whether anything is there. While it doesn't name the sibling, the phrase clearly points to the list-based alternative, giving the agent a decision rule.

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

• simplepractice_list_document_requestsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the bar is lower. The description adds valuable context about the nature of the resource (types of forms) and the practical meaning of outstandingOnly, going beyond the annotation. It does not disclose any undocumented mutations or side effects, but none exist given the read-only hint.

  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, zero filler. The main purpose is front-loaded, and the outstandingOnly hint adds actionable value without redundancy. Every word 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?

  No output schema exists, so the description should convey the return concept. It implies a list of requests by the verb 'list' and enumerates categories. Pagination is partially covered by the pageSize parameter in the schema. Combined with the readOnly annotation, the description is sufficient for an agent to call the tool correctly.

  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 description coverage is 67%, with includeBody and outstandingOnly documented in the schema. The description adds a human-oriented rationale for outstandingOnly ('see just what still needs the client's attention'), which is more interpretable than the schema's 'not completed or locked.' It does not add new meaning for pageSize, but that parameter is intuitive and covered by its name and default.

  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 clear verb+resource: lists document requests (paperwork the practice has sent). It enumerates concrete types (consents, questionnaires, etc.), which distinctively frames what this tool returns. The mention of outstandingOnly further clarifies the function, making it unmistakable what the tool does.

  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?

  Usage guidance is implied rather than explicit. The description says 'Use outstandingOnly to see just what still needs the client's attention,' which is a parameter-level hint, but it does not compare this tool to siblings like get_document_request or list_documents, nor state when to prefer one over the other. Context is present but no explicit exclusions or alternatives.

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

• simplepractice_session_statusA
  4.3/5.0
  Behavior4/5

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

  The annotation readOnlyHint=true already conveys read-only behavior. The description adds valuable context that it 'Reads local state only — makes no network call,' which is important for an agent to understand efficiency and side-effect-free execution. This goes beyond the annotation, justifying a 4.

  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 concise sentences with no redundancy. The primary purpose is front-loaded, and the behavioral note about local state follows naturally. Every word earns its place.

  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 zero parameters, a readOnly annotation, and no output schema, the description is fully sufficient. It tells the agent exactly what the tool does and its side-effect-free nature, which is all that is needed to decide whether and how to call it.

  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, and the schema is empty. The baseline for 0 params is 4 because there is nothing to explain. The description does not need to add parameter semantics, and it doesn't contradict 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 states a specific verb ('Report') and resource ('whether this server holds a Client Portal session, and for which practice'). It clearly defines the tool's function and is easily distinguishable from sibling tools like sign-in or sign-out, which have different purposes.

  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 does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. However, the context (checking session status) implies it is for verifying whether a session exists. It lacks explicit guidance on when to call this vs. other session-related tools, so it falls at the 'implied usage' level.

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

• simplepractice_verify_sign_in_pinA
  4.4/5.0
  Behavior4/5

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

  Annotations only indicate mutating (readOnlyHint=false) and non-idempotent (idempotentHint=false). The description adds meaningful behavioral detail: it is a single-use exchange that creates a session. This goes beyond annotations by explaining the one-time nature and the session outcome, which is valuable for an agent calling this tool.

  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, concise sentence that front-loads the core action ('Exchange a 6-digit Client Portal sign-in PIN for a session') and appends the usage context and single-use caveat. There is no fluff or redundant wording.

  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 two-parameter, no-output-schema tool, the description adequately conveys what it does, when to use it, and key behavioral constraints. It does not specify error handling or the exact session object returned, but given the simplicity and annotations, these are minor omissions.

  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 50%: only email has a schema description ('The address the PIN was sent to.'). The pin parameter only has a pattern, but the tool description clarifies pin as a '6-digit Client Portal sign-in PIN', adding meaning beyond the schema. Thus both parameters are effectively covered via schema and description, exceeding the 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 states a specific verb ('Exchange'), resource ('6-digit Client Portal sign-in PIN'), and outcome ('for a session'), and distinguishes itself by noting 'for practices that email a code instead of a link', which clearly differentiates it from the sibling verify_sign_in_token that handles link-based authentication.

  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 gives the usage context: 'for practices that email a code instead of a link' and notes 'Single-use'. This tells the agent when to use this tool (email-code-based sign-in) and implies not to use it for link-based flows. However, it does not explicitly name the alternative tool (e.g., verify_sign_in_token), so the guidance is clear 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.

• simplepractice_request_sign_in_linkA
  4.6/5.0
  Behavior5/5

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

  Discloses rich behavioral details beyond the annotations: it sends a real email, is rate-limited per email and IP, requires confirmation, and hides account existence (success does not prove the address has an account). These are not present in the schema or annotations and significantly aid the agent in setting expectations and avoiding misuse.

  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?

  Three sentences, all substantive. The purpose is front-loaded, followed by critical behavioral caveats. No filler or repeated information. Every sentence contributes to correct usage.

  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 side-effect-free-looking but actually side-effect-heavy tool (sends email), the description covers the key operational facts: real email, rate limits, confirmation requirement, and the ambiguity of success. It does not describe the response format or what a preview contains, but given there is no output schema, some gap remains. Overall, sufficient for safe 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 100%, so parameters already have descriptions. The description adds meaning by explaining why confirm is required (rate limiting) and by directly stating the requirement. This goes slightly beyond the schema's description, which only says it returns a preview without confirmation, to explain the underlying rationale.

  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 begins with a clear verb-resource pair: 'Ask SimplePractice to email a sign-in link to a Client Portal address.' It states the purpose precisely and distinguishes it from siblings (verify token/pin) by explaining this is the only way to sign in since the portal has no password.

  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 when to use this tool (to initiate sign-in) and provides important prerequisites: confirm:true is required because it sends a real, rate-limited email. It does not explicitly name sibling alternatives, but the context of 'how you sign in' makes the use case clear. Slightly lacking explicit exclusions, but adequate.

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