Server Quality Checklist

Tool Scores

• execute_workflowA
  3.6/5.0
  Behavior2/5

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

  Since no annotations are provided, the description carries the full burden of behavioral disclosure. It mentions that workflows are 'server-side scripts that contain business logic' and that execution will 'trigger actions,' implying side effects, but it does not disclose whether changes are reversible, what permissions are required, or any potential consequences of running arbitrary scripts. This is minimal transparency for a potentially high-impact execution 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 compact—three sentences that immediately state the core action and use case. It front-loads the essential detail and provides useful context about server-side scripts without any fluff or redundancy. Every sentence serves a distinct purpose, making it a model of concise, structured 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?

  The tool has no output schema and no annotations, but the description does not mention what the tool returns, whether errors are possible, or any safety caveats about executing arbitrary server-side scripts. It does guide the caller to inspect workflows first, which is helpful, but the lack of behavioral consequences and result information leaves the context incomplete for a tool with this level of power.

  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%, meaning all parameters are already documented in the input schema. The description adds a general note that arguments are 'key-value pairs matching the workflow's parameter names,' but this largely mirrors the schema's own description for args. There is no additional depth about workflowName or method beyond what the schema already provides, 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 opens with 'Execute a named workflow method with arguments,' clearly identifying the verb (execute), resource (workflow method), and scope (named). It then distinguishes from sibling tools by instructing to use list_workflows and get_workflow for discovery and inspection, making it unambiguous that this tool performs the actual execution. This fully clarifies its unique role among the siblings.

  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: 'to trigger actions, run calculations, or invoke custom processes.' It also provides clear prerequisites: 'Before executing, use list_workflows to discover available workflows and get_workflow to read their source code.' This is strong guidance, though it does not explicitly state when not to use it or mention alternatives for read-only operations such as fetch_query.

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

• list_entitiesA
  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 must carry the burden. It does disclose the return values and implies a non-destructive read operation, but doesn't explicitly mention authentication, rate limits, or pagination behavior. The mention that it returns 'whether they are public/customizable' adds useful context beyond a simple list.

  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 three sentences, each serving a purpose: what it does, what it returns, and how to proceed. It's front-loaded and free of fluff.

  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 list tool with two optional parameters and no output schema, the description gives enough context: what it returns, when to use it, and a next-step pointer. It could mention the default limit or any permission requirements, but these are minor 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?

  The input schema fully documents the two parameters (limit and filter) with descriptions and defaults. The description doesn't add any parameter-specific guidance, so it relies on the schema. Baseline 3 is appropriate since coverage is 100%.

  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 'List all entities' with a specific verb and resource, and enumerates the returned fields (names, display names, public/customizable). It distinguishes from siblings like get_entity_schema by framing this as discovery.

  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 a clear use case: 'Use this to discover what data is available before diving into specific entities.' It also offers a tip to use get_entity_schema afterward, which is an explicit alternative for the next step. However, it doesn't state when not to use it relative to other siblings like fetch_query or list_workflows.

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

• list_workflowsA
  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 burden. It adds useful context about workflow bindings and lifecycle events, but does not disclose potential side effects, authentication requirements, or response format details. Since this is a read-only listing, the lack of danger may be acceptable, but the description could be more explicit.

  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: the first states what the tool does, the second gives the usage rationale. No wasted words or redundant information, and the key action 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?

  Given the tool's simplicity (2 optional params, no output schema), the description covers the main purpose and includes practical context about workflow bindings. It lacks an explicit statement of what the response contains (e.g., workflow names, IDs), but the schema and straightforward nature make this a minor gap.

  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 baseline is 3. The description mentions 'optionally with their event bindings' but does not elaborate on the limit or entityFilter parameters, relying on the schema for their meaning. It adds little beyond 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 uses a specific verb ('List') with a clear resource ('all workflow definitions in the system') and adds scope ('optionally with their event bindings'). It distinguishes itself from sibling tools like get_workflow (single workflow) and execute_workflow (executes, not lists).

  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?

  Provides a clear use case: 'Use this to understand what business logic runs when data changes.' This tells the agent when to invoke the tool, though it does not explicitly mention alternatives or when not to use it. The context is enough for most selection scenarios.

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

• get_workflowA
  4.2/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 the output contents (workflow name, source module, source code) but does not mention error behavior, auth requirements, or explicitly confirm this is a read-only operation. For a simple get, this is minimally adequate but lacks deeper behavioral context.

  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: the first states the primary action and target, the second explains the prerequisite and return value. No filler, front-loaded, and efficient.

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

  Completeness4/5

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

  For a one-parameter retrieval tool with no output schema, the description covers the key input, how to obtain it, and what the response includes. It omits edge cases like not-found behavior, but given the tool's simplicity, it is reasonably 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?

  Schema coverage is 100% for the key parameter, but the description adds value by explaining the key is the workflow's primary key and advising to get it from list_workflows. This goes beyond the schema's property description, clarifying both meaning and acquisition of the parameter.

  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 gets the full source code and metadata of a workflow by its primary key. It distinguishes from sibling tools by specifying 'full source code' and directing users to list_workflows first, which differentiates it from listing or executing workflows.

  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 gives clear context: use list_workflows first to find the key, then use this tool to retrieve details. It implies this is for fetching a specific workflow rather than listing all, but doesn't explicitly state when not to use it or mention alternative tools like execute_workflow.

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

• fetch_queryA
  4.3/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 for behavioral disclosure. It provides valuable context by stating that queries always run under the authenticated user's security privileges and focusing on read-style operations. However, it does not describe the response format, pagination, error behavior, or potential performance implications, leaving notable 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?

  The description is well-structured and front-loaded: purpose first, then concrete use cases, syntax examples, and a security note. Every sentence earns its place, and the example block is dense with necessary information for a custom query language.

  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 complex custom-language tool, the description covers purpose, when to use, syntax, and security thoroughly. However, with no output schema, it does not specify the result shape, which is a moderate gap. Overall, it is complete enough for an agent to select and invoke the tool confidently.

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

  Parameters5/5

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

  The schema covers the single query parameter at 100% baseline, but the description adds significant meaning through syntax examples and an explanation of what FETCH can do. This is essential for correctly constructing a query, going far beyond the schema's terse 'Must start with FETCH' requirement.

  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 it executes a FETCH query against the ONE Framework instance and defines the query language's capabilities: retrieving, filtering, and aggregating data. This distinguishes it from sibling tools like list_entities and get_entity_record by emphasizing a custom, flexible query language.

  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 lists use cases: explore data, discover relationships, run reports, and understand the data model. It does not explicitly name alternatives or exclusion conditions, but the purpose and syntax examples make it obvious when to use this tool versus the simpler sibling tools.

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

• get_entity_schemaA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of disclosing behavior. It details the return structure (properties and relationships) and implies a read-only operation via 'Get.' It does not discuss permissions or error scenarios, but for a read-only schema tool this is 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 concise, front-loaded with the primary purpose, and uses a bulleted 'Returns' section to clearly list output fields without unnecessary prose. Every sentence contributes to understanding.

  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 single-parameter schema retrieval tool with no output schema, the description fully explains the return values and the tool's purpose. It covers both the properties and relationships aspects, making it self-contained and complete.

  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% (the 'entityName' parameter already includes an example and clarification). The description adds no extra parameter-specific detail, so the baseline of 3 applies.

  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 starts with a specific verb and resource: 'Get the full schema of an entity.' It clearly distinguishes itself from siblings like get_entity_record (which gets data) and list_entities (which lists names) by focusing on properties and relationships.

  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?

  Provides clear usage context: 'Use this to understand what data an entity holds and how it connects to other entities.' It does not explicitly name alternative tools or exclusion conditions, but the context is unambiguous for a schema query.

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

• update_entity_recordA
  4.4/5.0
  Behavior5/5

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

  With no annotations provided, the description fully carries the burden. It discloses the required Update permission, the fact that only included properties change, the full-replacement semantics for children, and the irreversible nature of the operation. This goes far beyond a simple 'update' statement.

  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 and well-structured: a clear purpose line, a usage summary, and a prominent warning. Each sentence provides essential information without redundancy or fluff.

  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?

  The tool is a mutation with nested objects and no output schema. The description covers permissions, partial updates, children replacement, and read-before-update. It doesn't mention what the tool returns (e.g., updated record or success message), which would normally be needed without an output schema, but it is otherwise quite complete.

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

  Parameters3/5

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

  Schema coverage is 100% and the schema already describes each parameter. The description adds minimal parameter-specific value, mostly restating what the schema says. It does clarify the partial-update semantics for 'properties' but the schema already conveys that.

  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 and resource: 'Update an existing entity record.' This distinguishes it from sibling tools like create_entity_record and get_entity_record by explicitly stating that it modifies an already-existing record.

  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 advises using get_entity_record before updating and warns that there is no undo. While it doesn't explicitly say when not to use this tool, it provides clear context for safe usage and a concrete alternative for inspection.

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

• get_instance_infoA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses the read-only nature through 'Get information' and 'verify the connection', and explicitly mentions the authenticated user, adding useful context about what to expect. It does not explicitly state side-effect absence, but the 'get' semantics fully imply it.

  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, front-loaded with the primary action and key return values, followed by a practical use case. 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?

  For a zero-parameter, no-output-schema tool, the description fully covers what the tool does, what it returns, and when to use it. There is no missing critical context for an agent to invoke it 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?

  The tool has zero parameters, so the description correctly omits any parameter details. The baseline for no parameters is 4, and the description adds no unnecessary filler.

  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 verb 'Get information' and the specific resource 'connected ONE Framework instance', listing the returned details (server version and authenticated user). This distinguishes it from sibling tools that focus on queries, workflows, or entities.

  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 explicit usage context: 'Use this to verify the connection is working and to see who you are authenticated as.' It gives a clear when-to-use but does not mention alternatives or exclusions relative to sibling tools.

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

• create_entity_recordA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It warns about requiring permission, creating real data, and having no delete functionality, which are critical operational traits.

  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 compact and well-structured, with a warning, step-by-step guidance, an example, and a final caution. Every sentence contributes meaningful information with no redundancy.

  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 create tool with nested objects, the description covers prerequisites, usage, side effects, and a warning about irreversibility. It is sufficiently complete given the schema coverage and lack of an output schema.

  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 already documents all three parameters 100%, so the baseline is 3. The description adds a concrete example and clarifies nested child record creation, enhancing understanding beyond the schema alone.

  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 'Create a new entity record' with a specific verb and resource, distinguishing it from sibling tools like get_entity_record and update_entity_record. It also highlights nested creation as a unique feature.

  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 usage instructions, including an example and the requirement for Create permission. It does not explicitly name alternatives or exclusion scenarios, but the context strongly implies when this tool should be used.

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

• get_entity_recordA
  4.7/5.0
  Behavior4/5

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

  With no annotations, the description discloses the return content ('full record with all properties and child entities'), which helps set expectations. However, it doesn't mention error behavior or access requirements, but for a read operation this level is sufficient.

  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?

  Concise two-sentence paragraph, with the core action front-loaded and a relevant example. The alternative tool mention is integrated without clutter. Every sentence contributes value.

  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 retrieval tool with no output schema, the description covers the full return shape ('all properties and child entities') and use-case context. Sibling tools like fetch_query are referenced appropriately. No critical gaps remain.

  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 the baseline is 3. The description adds a concrete example ('entity 'user' with key 1') and clarifies the key is a primary key, going slightly beyond the schema's own 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 clearly states the tool retrieves a single entity record using entity name and key, with explicit scope ('exactly which record you need'). It distinguishes itself by naming the alternative fetch_query for discovery, making its 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 Guidelines5/5

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

  Provides direct usage criteria: 'Use this when you know exactly which record you need' and explicitly points to fetch_query as the alternative for discovery. This gives the agent clear decision rules.

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