Server Quality Checklist

Tool Scores

• list_databasesB
  3.2/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 states it retrieves a list of database names, implying a read-only operation, but doesn't mention potential constraints like permissions needed, rate limits, or what happens if no databases exist. This leaves significant gaps for a tool with zero annotation coverage.

  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, efficient sentence that front-loads the core purpose ('Get list of all databases') without any wasted words. It's appropriately sized for a simple tool with no parameters, 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.

  Completeness3/5

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

  Given the tool's simplicity (0 parameters, no output schema), the description is adequate but has clear gaps. It explains what the tool does but lacks behavioral context (e.g., permissions, error handling) and doesn't differentiate from siblings, making it minimally viable but not fully complete for informed use.

  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 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, aligning with the schema. A baseline of 4 is applied since no parameters exist, and the description doesn't add unnecessary details.

  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 action ('Get list') and resource ('all databases in user's Fibery workspace'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'describe_database' or 'query_database', which prevents a perfect score.

  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 such as 'describe_database' for detailed info or 'query_database' for querying data. It lacks explicit when-to-use or when-not-to-use instructions, leaving usage context implied at best.

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

• create_entityB
  3.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. It discloses that successful execution returns a link to the created entity, which is useful behavioral context. However, it doesn't mention permission requirements, error conditions, rate limits, or whether the operation is idempotent, leaving gaps for a mutation tool.

  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 front-loaded with the core purpose, but includes verbose examples and implementation details that could be streamlined. The warning about non-existent databases is necessary but lengthy, and the example could be more concise while still being helpful.

  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 mutation tool with no annotations and no output schema, the description provides basic context about the return value (a link) and includes examples. However, it lacks information about error handling, authentication needs, and doesn't fully compensate for the absence of structured behavioral annotations.

  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%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema by providing examples of parameter usage, but doesn't explain semantics like field name formatting or value constraints beyond what's in the schema descriptions.

  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 verb 'Create' and resource 'Fibery entity with specified fields', which is specific and actionable. It distinguishes from siblings like 'update_entity' by focusing on creation rather than modification. However, it doesn't explicitly differentiate from 'create_entities_batch', which handles batch creation.

  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 implied usage through examples and warnings about using only databases from the user's schema, but lacks explicit guidance on when to use this tool versus alternatives like 'create_entities_batch' for multiple entities or 'update_entity' for modifications. No explicit when-not-to-use or prerequisite information is given.

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

• describe_databaseA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states what the tool returns, not behavioral traits like whether it's read-only, requires permissions, has rate limits, or error handling. It doesn't disclose if it's safe or has 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the purpose and includes key details like output format and scope. There's zero wasted verbiage, 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.

  Completeness3/5

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

  For a simple read operation with one parameter and no output schema, the description is adequate but lacks context on permissions, errors, or return structure beyond format hints. It doesn't fully compensate for missing annotations, leaving behavioral gaps.

  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%, so the schema already documents the single parameter 'database_name'. The description adds no additional meaning beyond implying it selects a database, matching the baseline for high schema coverage.

  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 specific action ('Get list of all fields') and the resource ('selected Fibery database and for all related databases'), with precise output format details. It distinguishes itself from siblings like 'list_databases' (which lists databases) and 'query_database' (which queries data).

  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 usage when needing field metadata for a specific database and its relations, but doesn't explicitly state when to use this vs. alternatives like 'list_databases' or 'query_database'. No exclusions or prerequisites are mentioned.

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

• query_databaseA
  3.5/5.0
  Behavior4/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 discloses key behavioral traits: it returns a list of records on success or detailed error messages on failure, includes examples showing complex query capabilities, and mentions constraints like 'use databases only from user's schema'. However, it doesn't cover rate limits, authentication needs, or pagination details beyond limit/offset.

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

  Conciseness2/5

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

  The description is overly long and not front-loaded. The first two sentences state the purpose, but then it includes four detailed examples that dominate the text. While examples are helpful, they make the description verbose and could be summarized or moved to documentation. The structure lacks efficiency, with repetitive query patterns.

  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 complexity (7 parameters, nested objects, no output schema) and lack of annotations, the description does a good job of completeness. It explains success/failure outcomes, provides multiple examples covering various use cases, and includes important warnings (e.g., about database usage). However, it could better address error handling or advanced query patterns to be fully comprehensive.

  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%, so the schema already documents all 7 parameters thoroughly. The description adds value through extensive examples that illustrate parameter usage in context (e.g., showing how q_where and q_params interact), but doesn't provide additional semantic meaning beyond what the schema descriptions offer. Baseline 3 is appropriate given high schema coverage.

  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 purpose: 'Run any Fibery API command.' It specifies the verb ('Run') and resource ('Fibery API command'), and mentions flexibility and required experience. However, it doesn't explicitly differentiate from sibling tools like 'describe_database' or 'list_databases' beyond being a general query tool.

  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 usage by stating it 'requires a bit of experience with the low-level Fibery API' and provides examples, but doesn't explicitly say when to use this tool vs. alternatives like 'create_entity' or 'update_entity'. It gives context (e.g., 'use databases only from user's schema!') but lacks clear when/when-not guidance.

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

• update_entityA
  3.5/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 behavioral disclosure. It adds some context: it mentions that successful execution returns a link to the updated entity, which is useful for understanding output behavior. However, it does not cover critical aspects like authentication requirements, error handling, rate limits, or whether the update is reversible, leaving gaps in transparency for a mutation tool.

  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 appropriately sized and front-loaded, starting with the core purpose followed by examples and additional notes. The examples are detailed but necessary for clarity, and the text avoids redundancy. However, the warning about non-existent databases could be more concise, slightly affecting efficiency.

  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?

  Given the complexity of a mutation tool with no annotations and no output schema, the description is moderately complete. It covers the basic operation, parameter examples, and output behavior (returning a link), but lacks details on error cases, permissions, or side effects, which are important for full contextual understanding.

  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 input schema has 100% description coverage, so the baseline is 3. The description adds value by providing concrete examples that clarify parameter usage, such as the format for entity fields and special handling for document fields with 'append' and 'content'. This enhances understanding beyond the schema, justifying a higher score.

  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 purpose: 'Update Fibery entity with specified fields.' It specifies the verb ('Update'), resource ('Fibery entity'), and scope ('with specified fields'), making it easy to understand what the tool does. However, it does not explicitly differentiate from sibling tools like 'create_entity' or 'create_entities_batch', which would require a more specific comparison.

  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 implied usage guidance through examples, such as noting to use databases from the user's schema and showing how to handle document fields. However, it lacks explicit when-to-use instructions compared to alternatives like 'create_entity' or 'query_database', and does not mention prerequisites or exclusions, leaving some ambiguity for the agent.

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

• create_entities_batchA
  3.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 burden of behavioral disclosure. It reveals that successful execution returns links to created entities and mentions that workflow fields require string literals. However, it doesn't disclose important behavioral aspects like authentication requirements, error handling, rate limits, or whether the operation is idempotent, which are significant gaps for a batch creation tool.

  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 appropriately sized but not optimally structured. The purpose statement is clear upfront, but the example dominates the text and includes implementation details that might be better in documentation. The final sentence about giving links to users is useful but could be integrated more smoothly. Some sentences could be more concise.

  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 batch creation tool with no annotations and no output schema, the description provides adequate basic information but has significant gaps. It explains the core functionality and parameter usage well through examples, but lacks details about error conditions, performance characteristics, permissions required, and what exactly the returned links contain. The example helps but doesn't fully compensate for missing structural information.

  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 100% schema description coverage, the baseline is 3. The description adds substantial value through the detailed example showing exactly how to structure the 'entities' parameter with field-value pairs, including the specific syntax for workflow fields. This goes well beyond what the schema provides, though it doesn't explain the 'database' parameter beyond what's in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action ('Create multiple Fibery entities at once') and resource ('Fibery entities'), distinguishing it from the sibling 'create_entity' tool which presumably creates single entities. The description explicitly mentions batch creation with specified fields, making the purpose unambiguous and differentiated.

  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 provides clear context for when to use this tool (creating multiple entities at once with specified fields) and includes a warning about using only databases from the user's schema. However, it doesn't explicitly state when NOT to use it or mention the 'create_entity' sibling as an alternative for single-entity creation scenarios.

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

• current_dateA
  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 full burden. It discloses the output format and that it returns current date, but lacks details on behavioral traits like timezone handling, freshness guarantees, or error conditions. However, for a simple read-only tool with no parameters, this is minimally adequate.

  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 with zero waste—it directly states the tool's purpose and output format. Every word earns its place, making it highly efficient and easy to parse.

  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 (0 parameters, no annotations, no output schema), the description is complete enough for a basic date retrieval function. It specifies the exact format, which compensates for the lack of output schema. However, it could slightly improve by mentioning timezone or freshness aspects.

  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 0 parameters, and schema description coverage is 100%. The description does not need to add parameter semantics, so it appropriately focuses on output. Baseline for 0 params is 4, as it efficiently describes the tool's function without unnecessary parameter details.

  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 specific verb ('Get') and resource ('today's date'), with precise format details ('ISO 8601 format (YYYY-mm-dd.HH:MM:SS.000Z)'). It distinguishes from sibling tools (like create_entities_batch or query_database) by focusing solely on retrieving current date information.

  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 usage context (when you need today's date in a specific format), but does not explicitly state when to use this tool versus alternatives or any exclusions. No guidance on prerequisites or comparisons with other date/time tools is provided.

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