Server Quality Checklist

Tool Scores

• plurk_get_meC
  2.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full disclosure burden. While 'Return' implies a read-only operation, the description fails to disclose error behaviors (invalid credentials), rate limits, or what profile fields are returned. It mentions 'credentials supplied' but doesn't clarify these are OAuth 1.0a tokens requiring specific procurement steps.

  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?

  Single efficient sentence that front-loads the action ('Return') and resource ('authenticated Plurk account profile'). No redundant phrases, though extreme brevity contributes to informational gaps.

  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?

  Given zero schema descriptions, no output schema, complex nested authentication requirements, and presence of sibling tools, the description is incomplete. It should explain the OAuth credential structure, indicate what profile data is returned, and clarify error conditions for invalid authentication.

  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% for the four nested credential fields (appKey, appSecret, accessToken, accessTokenSecret). The description mentions 'credentials supplied' which maps to the parameter name, but provides no semantic explanation for the OAuth credential components, their format, or how to obtain them, leaving the complex nested object effectively undocumented.

  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 'Return[s] the authenticated Plurk account profile' with specific resource (account profile) and action (Return/Retrieve). It implicitly distinguishes from siblings (get_alerts, get_thread_context, post, reply) by specifying this retrieves the user's own profile rather than content or alerts.

  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 siblings (e.g., when needing user ID or display name versus getting mentions), nor does it mention prerequisites like required OAuth permissions or token validity checks.

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

• plurk_get_mentions_contextC
  2.8/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 disclosure burden. It mentions 'recent' and 'interactions' but fails to state whether this is read-only (implied only by 'Return'), what 'recent' means temporally, rate limits, or what the return format contains.

  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?

  Single sentence with reasonable density. 'Suitable for summarization or reply planning' adds value, though 'for the supplied credentials' is somewhat redundant with the required schema parameter. Adequately front-loaded but not exceptional.

  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?

  Given zero annotations, no output schema, and 0% parameter documentation, the description should work harder to explain parameter semantics, differentiate from siblings (get_alerts vs. mentions), and disclose behavioral traits. It covers basic purpose but leaves critical gaps unfilled.

  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 has 0% description coverage, yet the description only mentions 'credentials' in passing without explaining the OAuth structure (4 nested fields) or the 'limit' parameter (default 20, max 100). Insufficient compensation for the undocumented schema.

  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?

  Clear verb ('Return') and resource ('mention-driven interactions and context'). Specifies the domain (mentions vs. general alerts or threads), though it could more explicitly contrast with siblings like plurk_get_alerts or plurk_get_thread_context.

  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?

  Provides implied usage via 'suitable for summarization or reply planning,' giving the agent a hint about when to invoke it. However, lacks explicit when-not-to-use guidance or named alternatives (e.g., 'use plurk_get_thread_context instead for specific conversation threads').

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

• plurk_get_alertsC
  2.9/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 disclosure burden. It adds useful context with 'recent' (temporal scope) and 'normalized' (data format), but omits critical behavioral details such as the time window for 'recent', pagination behavior, sorting order, or rate limit implications of the OAuth credentials.

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

  Conciseness4/5

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

  The description is a single sentence that places the action and resource at the front. However, the phrase 'for the credentials supplied in this call' is slightly redundant (credentials are inherent to the call) and could be replaced with more useful parameter or behavioral documentation.

  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?

  Given the complex nested credentials object (4 required fields), the limit parameter with constraints (1-100, default 20), lack of annotations, and absence of an output schema, the description is insufficient. It fails to prepare the agent for the OAuth credential structure, pagination limits, or the structure of normalized alert events.

  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 0% description coverage, requiring the description to compensate. While it acknowledges the 'credentials' parameter ('for the credentials supplied in this call'), it fails to document the four required nested OAuth fields (appKey, appSecret, etc.) or explain their semantics. It completely omits the 'limit' parameter, leaving both top-level parameters effectively undocumented.

  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 provides a clear verb ('Return') and resource ('recent normalized alert events'), establishing what the tool does. However, it does not explicitly differentiate 'alerts' from sibling tools like 'mentions' or 'threads' (plurk_get_mentions_context, plurk_get_thread_context), which could help an agent select the correct endpoint.

  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 alternatives like plurk_get_mentions_context or plurk_get_me. There is no mention of prerequisites, required user states, or conditions that would indicate when alerts are the appropriate resource to fetch.

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

• plurk_replyB
  3/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 of disclosure. It successfully conveys the write-operation nature ('reply') and critical eligibility constraints, but fails to address error behavior (what happens if the thread is ineligible), rate limits, or side effects. The mention of credentials implies authentication requirements.

  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 a single sentence achieving brevity, but suffers from slightly awkward phrasing ('for the supplied credentials' rather than 'using'). The eligibility clause is grammatically attached to the credentials rather than the reply action, creating minor parsing friction. Every word is functional but the structure could be clearer.

  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?

  Given the tool's complexity—including a nested OAuth credentials object, 4 parameters with 0% schema coverage, no output schema, and platform-specific eligibility rules—the single-sentence description is insufficient. It lacks explanation of return values, error conditions, the purpose of the 'qualifier' field, and Plurk-specific behavioral context needed for safe invocation.

  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?

  With 0% schema description coverage, the description must compensate significantly but falls short. While it implicitly references 'credentials' and the reply action suggests 'content' and 'plurkId' usage, it provides no explanation for the 'qualifier' parameter (which is optional but undocumented) and no format guidance for any parameter. The complex nested credentials object particularly requires description support that is absent.

  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 specific action (reply) and resource (Plurk thread), and includes eligibility criteria (owned thread or explicit mention) that implicitly distinguish it from the sibling 'plurk_post' tool. However, it could more explicitly contrast with 'plurk_post' to make the distinction clearer.

  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 eligibility constraints specifying when the tool can be used (owned threads or explicit mentions), which serves as contextual guidance. However, it lacks explicit guidance on when NOT to use this tool versus alternatives like 'plurk_post', and omits prerequisites beyond credential requirements.

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

• plurk_postB
  3.2/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 disclosure burden. It successfully notes the quota enforcement mechanism, but omits other critical mutation behaviors: error handling when quotas are exceeded, whether the operation is idempotent, and what side effects occur.

  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 single sentence is front-loaded with the action ('Create') and avoids redundancy. However, given the complex nested auth schema and 0% coverage, extreme brevity becomes a liability rather than a virtue.

  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 a write operation with complex authentication, platform-specific jargon ('qualifier'), and no output schema, the description is incomplete. It misses credential field explanations, valid qualifier values, return structure, and error scenarios essential for correct invocation.

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

  Parameters1/5

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

  Schema description coverage is 0%, yet the description fails to compensate. It vaguely references 'supplied credentials' without explaining the four nested OAuth fields (appKey, appSecret, etc.), completely ignores the 'qualifier' parameter (a Plurk-specific concept), and provides no formatting guidance for 'content'. This is a significant documentation gap.

  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 ('Create') and resource ('Plurk post'), clearly distinguishing it from the sibling 'get' tools (alerts, me, mentions, thread) and the 'reply' tool. It establishes this as the primary content creation entry point.

  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?

  It mentions the 'server-side daily post quota' which provides implicit usage context (rate limiting exists), but it lacks explicit guidance on when to use this versus plurk_reply or prerequisites like required OAuth scopes.

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

• plurk_get_thread_contextA
  3.5/5.0
  Behavior3/5

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

  Discloses 'normalized replies' processing behavior and implies credential-based auth. However, lacks details on what 'normalized' means, response structure, rate limits, or pagination given zero annotations provided.

  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?

  Single sentence, front-loaded with action verb. Every phrase earns its place: 'normalized' signals processing, 'parent plurk' distinguishes from replies, 'supplied credentials' establishes auth requirement.

  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?

  Adequate basic description but insufficient given complexity: nested credential object with 4 undocumented fields, no output schema, and no annotations. Missing crucial details like what constitutes a valid plurkId or expected response format.

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

  Parameters3/5

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

  With 0% schema coverage, description compensates partially: 'supplied credentials' maps to auth object and 'specific thread' implies plurkId identifies the thread. However, fails to document the 4 required credential sub-fields (appKey, appSecret, etc.) or plurkId value format.

  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?

  Specific verb 'Return' with clear resource 'parent plurk and normalized replies' and scope 'specific thread'. Distinct from siblings: plurk_post/reply are write operations, plurk_get_alerts/mentions_context retrieve different data types.

  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 on when to use this vs plurk_get_mentions_context or other retrieval tools. No mention of prerequisites like needing a valid plurkId from a previous search.

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