Server Quality Checklist

Tool Scores

• liveauth_mcp_lnurlB
  3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool retrieves an invoice, but does not clarify side effects, return format, expiration, or whether it is a read-only operation. The mention of 'lnget-compatible' is vague and adds little transparency.

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

  Conciseness3/5

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

  The description is short and front-loaded, but the two sentences are somewhat redundant: 'Get the Lightning invoice' is repeated as 'retrieve the BOLT11 invoice.' It could be condensed into a single sentence without losing information, so it is not maximally concise.

  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 tool has only one parameter with good schema coverage, but no output schema and no annotations. The description does not explain what the response looks like, potential errors, or any behavioral context like payment flow or invoice validity. Given the lack of structured metadata, this is insufficient for an agent to fully understand the tool's role.

  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 input schema already provides 100% coverage by describing quoteId as 'The quoteId from the start response.' The description adds no additional meaning about the parameter, so the baseline score 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 function: 'Get the Lightning invoice for a session' and also mentions 'retrieve the BOLT11 invoice for payment.' This provides a specific verb and resource, but it does not explicitly differentiate from sibling tools like start, status, or charge, so it does not reach a 5.

  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 says 'Use this to retrieve the BOLT11 invoice for payment,' which implies the tool is for obtaining an invoice after starting a session. However, it does not explicitly state when to use it versus alternatives, nor does it mention any prerequisites or exclusions. This falls under implied usage rather than clear guidance.

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

• liveauth_mcp_chargeA
  3.7/5.0
  Behavior2/5

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

  With no annotations provided, the description must disclose behavioral traits on its own. It mentions the action 'Meter API usage' but does not explain side effects like deducting sats, idempotency (e.g., calling twice), prerequisites beyond JWT authentication, or error behavior. As a monetary/charge operation, the lack of these details is a significant 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 extremely concise—two short sentences that front-load the core action ('Meter API usage') and then provide the invocation details. There is no redundant or filler content; every sentence earns its place.

  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 two optional parameters, the description gives a decent overview of purpose and usage. However, with no annotations or output schema, it omits important context such as the expected response, idempotency, and failure modes. It is minimally sufficient but not fully complete for a financial metering 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?

  The input schema already provides full documentation for both parameters (100% coverage). The description adds minor context (e.g., 'cost in sats for each API request') but does not meaningfully enrich the understanding of toolName or callCostSats beyond their schema descriptions. The high schema coverage justifies the baseline score of 3.

  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 function: 'Meter API usage after making an authenticated call.' It identifies a specific verb (meter/charge) and resource (API usage), and the context (after an authenticated call) distinguishes it from sibling tools like liveauth_mcp_usage, which likely queries usage rather than recording it.

  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 explicitly instructs when to call the tool: 'Call this with the cost in sats for each API request made using the JWT.' This clearly conveys per-request usage after authentication. However, it doesn't explicitly mention alternatives or conditions when not to use it, preventing a perfect score.

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

• liveauth_mcp_startA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description must fully disclose behavioral traits. It does state the return types and the default PoW challenge, but it omits potential side effects, such as whether starting a new session invalidates existing ones or requires prior authentication. This leaves important behavioral context 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?

  The description is a single, front-loaded sentence that directly states the action and the possible outcomes. It contains no redundant or filler phrases, making it highly concise 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 simple tool with two optional parameters and no output schema, the description covers the core return types and default behavior. While it could provide more detail about the response structure or next steps, the information given is sufficient to understand the tool's basic 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?

  The input schema has 100% coverage with descriptive definitions for both boolean parameters. The description adds no additional parameter-level meaning, so the baseline score of 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 a specific verb 'Start' and resource 'LiveAuth MCP session', making the purpose unambiguous. It distinguishes itself from sibling tools by clearly indicating this is the initialization action, and it enumerates the distinct return types (PoW challenge, Lightning invoice, L402 bundle).

  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 is the entry point for starting a session, but it does not explicitly state when to use it versus sibling tools like liveauth_mcp_status or liveauth_mcp_charge. No prerequisites or alternative usage scenarios are provided, so the guidance remains at an implied level.

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

• liveauth_mcp_refreshA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses a key behavior (no re-authentication required) and the outcome (new JWT). However, it does not mention token rotation, single-use semantics, error handling, or response format, leaving gaps for an agent.

  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, no filler. The main purpose is front-loaded, and the parameter guidance is integrated naturally. 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 simple one-parameter tool with no output schema, the description is nearly complete: it explains the purpose, the input source, and the expected result (new JWT). It lacks only minor details like potential errors or whether the refresh token is reusable, but these are not critical for basic 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?

  The schema description for refreshToken already provides full coverage (100%), and the tool description essentially restates the same source. Since the schema does the heavy lifting, the description adds minimal extra meaning, hence the baseline score of 3.

  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+resource ('refresh the JWT token') and explicitly states what it achieves ('get a new JWT'). It also distinguishes itself from siblings by referencing the confirm response, making its role in the auth flow clear.

  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 clearly states when to use this tool: after confirm, using the refreshToken from confirm. It implies it is the alternative to re-authenticating, providing a clear context. It does not explicitly list exclusions or alternatives, but the sibling set makes the intended use obvious.

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

• liveauth_mcp_statusA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It reveals that the tool returns an invoice via lnurl compatibility and implies a read-only polling nature, but it doesn't explicitly state read-only behavior, side effects, or what constitutes a 'status.' This is adequate but lacks rich safety or state-change disclosure.

  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, front-loaded with the primary purpose, and includes a specific usage example. Every sentence adds value with 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?

  Given the tool's simplicity (single parameter, no output schema), the description covers the essential context: what it does, when to use it, and a hint about the returned invoice. However, it doesn't describe the full status response structure or possible statuses, which might be useful for a polling tool, but overall it's sufficient for the low complexity.

  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 only parameter 'quoteId' described as 'The quoteId from the start response.' The description adds no additional parameter-level meaning, but the schema already covers it fully, so the baseline of 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 clearly states the tool's function: 'Check the status of an MCP session' with a specific use case ('poll for Lightning payment confirmation'). It also distinguishes itself from siblings by focusing on status and polling, and the added detail about lnurl compatibility further clarifies the tool's unique role.

  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 explicitly says 'Use to poll for Lightning payment confirmation,' which provides clear guidance for when to invoke this tool. It doesn't mention alternatives or exclusions, but the polling context is sufficient for a status tool in a payment flow, making it clear this is the follow-up to start/confirm actions.

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

• liveauth_mcp_confirmA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It discloses the dual-mode behavior (PoW vs Lightning), that polling is possible, and the outcome (JWT). However, it does not disclose failure modes, side effects like challenge invalidation, or retry semantics, leaving important behavioral gaps.

  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, front-loaded with the main action, and the second provides a specific usage tip. No waste or redundancy.

  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 tool has 8 parameters and two distinct flows, with no annotations and no output schema. The description covers the core purpose and outcome but lacks details on error conditions, success/failure responses, and safety of repeated calls. It is adequate but not comprehensive for the complexity.

  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 baseline is 3. The description adds mode-specific guidance: 'call with just quoteId' for Lightning, implying PoW uses the other fields. This clarifies how to select parameters by mode, going beyond the schema's individual 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 states a specific action: submitting a solved proof-of-work challenge or polling for Lightning payment to receive a JWT. This clearly distinguishes it from siblings like start (which likely initiates) and status (which likely checks overall status).

  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 provides explicit guidance: for Lightning, call with just quoteId to check/poll payment status, and PoW requires the challenge-solution fields. It does not explicitly name alternatives or when-not-to-use, but the sibling names and context make it inferable.

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

• liveauth_mcp_usageA
  4.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the full burden. It does disclose a key behavioral trait: 'without making a charge' indicates the call is non-destructive and free. However, it doesn't clarify whether the usage query itself counts as a call or affect the budget, nor does it explain any side effects or limit conditions. This is a minor gap for a read-only usage 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 two sentences long, front-loaded with the core purpose, and contains no filler. Every word contributes to understanding the tool's function and when to use it.

  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 simple tool with no parameters and no output schema, the description is complete. It clearly states what it queries (usage and remaining budget), the metrics (sats and calls), and the key safety aspect (no charge). No additional context is necessary.

  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 baseline is 4. The description adds no parameter details, but none are needed. It correctly focuses on the tool's purpose and usage rather than param syntax.

  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 'Query' and identifies a clear resource: 'current usage and remaining budget for the MCP session.' It also distinguishes itself from siblings like 'status' and 'charge' by focusing on budget/calls usage, making the 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 Guidelines4/5

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

  The description explicitly states when to use the tool: 'Use this to check how many sats and calls have been used without making a charge.' This provides clear context and implies it's a non-charging alternative to 'liveauth_mcp_charge'. It doesn't explicitly name alternatives or exclusions, but the guidance is practical and sufficient.

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