Server Quality Checklist

Tool Scores

• run_queryB
  3.1/5.0
  Behavior2/5

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

  With no annotations present, the description... ...does not disclose mutation effects, whether operations can be destructive, rate limits, error behavior, or return1 result shape. Merely saying it 'requires a monday.com API key' is useful but insufficient for a tool that can execute arbitrary mutations.

  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 only two isolated sentences with no fluff. The main operation is front-loaded ('Executes a GraphQL query or mutation…') and the auth requirement is stated clearly and separately. Every sentence carries meaningful information.

  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 thin GraphQL executor, the description is minimally viable: it states the action, the target API, and the result. However, without annotations, an output schema, or any notes on mutation behavior, /error handling, or relationship to sibling tools, an agent is left with gaps before invoking it safely.

  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 each parameter (query, api_key, variables) already has a semantic description. The tool description adds almost no new parameter detail beyond saying an API key is required. This falls directly on the baseline for 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 uses a specific verb ('Executes') with a named resource ('monday.com API') and clearly indicates it handles GraphQL queries and mutations and returns a result. It is distinguishable from siblings like validate_query and get_schema, though it does not explicitly name them or explain the distinction.

  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 says when the tool will run (a GraphQL query/mutation), but gives no guidance on when to choose this tool over siblings, such as validate_query for validation get_schema for introspection, or explain_error for debugging errors. It also doesn't state conditions, prerequisites beyond an API key, or exclusions.

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

• scaffoldA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the full behavioral burden. The one useful addition is 'No API key required,' which clarifies an important prerequisite. However, the description does not disclose whether files are written, whether a project is created, or how the generated code is returned, so the behavioral picture remains incomplete.

  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, lean sentence with every word working. It front-loads the core purpose and adds the useful, non-obvious 'No API key required' detail without any waste or unnecessary preamble.

  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?

  Even though there is no output schema and no annotations, the description covers the essential facts: it generates boilerplate, targets monday.com, and needs no API key. Combined with 100% schema coverage that spells out required enums, an agent should be able to invoke the tool correctly. A description that additionally mentioned what the generated output looks like would be more complete, but nothing critical is missing for basic use.

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

  Parameters3/5

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

  Schema description coverage is 100%, and the schema already documents the purpose of each parameter. The description adds no value beyond that coverage. A score of 3 is appropriate when the schema does the heavy lifting and the description introduces no new parameter-relevant semantics.

  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 ('Generates') and a specific resource ('ready-to-use boilerplate code for monday.com integrations and apps'), making the tool's purpose unambiguous. The compact phrasing also naturally distinguishes it from sibling tools like get_schema or validate_query, which serve different query-oriented purposes.

  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?

  There is no explicit guidance about when to choose this tool over alternatives, no exclusionary cases, and no mention of prerequisites. The only hint is the tool's name and generic 'Generates...' statement, which implies scaffolding use but does not guide the agent through selection criteria.

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

• validate_queryA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description must carry the behavioral burden. It communicates the validation-only nature and the optional online schema validation, but it does not disclose what the tool returns on success or failure, whether it ever executes the query, or what side effects the optional API key usage has.

  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 focused sentences with no fluff. It front-loads the primary purpose and follows with the key operational caveat about the optional API key, making it easy for an agent to parse quickly.

  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?

  There is no output schema, and the description does not explain what the caller should expect in return-whether it emits a boolean, a report, error details, or a complexity estimate. Given the tool's purpose is validation, the agent is left unsure how to interpret the result, which is a meaningful gap in context.

  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 already 100%, so both parameters are documented in the input schema. The description adds slightly by clarifying that syntax and complexity checks work without the API key and that the key is only needed for live schema validation, but this mostly restates what the schema already says.

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

  Purpose5/5

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

  The description states a specific verb and resource: validates a monday.com GraphQL query. It also enumerates the concrete validation activities (syntax, complexity, common pitfalls) and distinguishes itself from execution tools like run_query by focusing on validation rather than running the query.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

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

  The description gives clear context for what the tool does and notes that a live schema check requires an API key. However, it does not explicitly say when to prefer this over sibling tools such as run_query or explain_error, nor does it name any alternative for actually executing a validated query.

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

• explain_errorA
  4/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 behavioral transparency burden. It clearly states that the tool requires no API key, accepts either JSON or a message, and provides an explanation plus a suggested fix. It does not mention potential limitations, such as inability to handle malformed errors, but it is honest about what the tool does.

  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 compact sentences deliver the core purpose, the required input format, and a key constraint ('No API key required'). There is no filler and the most important 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?

  For a low-complexity helper tool, the description covers the input required, the optional improvement path, and the expected behavior. There is no output schema, but the promised 'plain language' explanation and fix is enough context for an agent to understand what will come back. It does not document edge cases, but none are essential to call the tool correctly.

  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 well. The description adds useful context with 'Paste the error JSON or message' and notes the optional query 'improves the analysis', but this supplements rather than substantially extends the schema. Baseline 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 states a specific verb ('Explains') with a precise resource ('monday.com API error response') and an outcome ('suggests a fix'). This makes it clearly distinguishable from siblings like validate_query or run_query, which operate on the query side rather than explaining errors.

  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 the right moment to use the tool: when you have a monday.com API error response to interpret. It also clarifies that no API key is required and that pasteing the error is the entry point. However, it does not explicitly compare against alternatives like validate_query or run_query, so an agent must infer the boundary.

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

• get_schemaA
  4/5.0
  Behavior4/5

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

  There are no annotations, so the description carries the full behavioral burden. It discloses the 'live' network-backed fetch, the API key requirement, and the return content, which covers the key operational expectations. It does not discuss failure modes, rate limits, or response size, but for a straightforward schema-fetch operation the disclosed behavior is solid.

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

  Conciseness5/5

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

  The description is two sentences with no filler. It front-loads the primary purpose and packs the credential requirement into the second sentence, so it is both minimal and effective.

  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 read-only schema-fetching tool with no output schema, the description covers the main call behavior, success return contents, and the authentication need. It is not fully complete because it doesn't mention that a full schema dump could be large or that the filter parameter shapes the output, but the schema already documents filtering adequately.

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

  Parameters3/5

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

  Schema description coverage is 100%, and both filter and api_key have detailed descriptions in the input schema itself. The tool description adds no special parameter semantics beyond reaffirming the API key requirement, so baseline 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 and resource: 'Fetches the live monday.com GraphQL schema and returns type definitions, available queries, and mutations.' This clearly distinguishes it from sibling tools like run_query, validate_query, and explain_error.

  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 an agent needs to inspect or work with the monday.com GraphQL schema, but it never explicitly says when to choose this tool over alternatives, nor does it mention exclusions. Since the tool's purpose is inherently clear, it earns a 3 rather than a 2, but explicit guidance would be better.

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

• column_value_formatA
  4.2/5.0
  Behavior4/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 discloses useful behavioral facts: it returns exact JSON formats and requires no API key. It does not describe behavior for invalid column types, but for a simple lookup this is a minor 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 three short sentences with no fluff. It front-loads the core behavior, then the auth note, then the clear usage condition. Every sentence 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 one-parameter reference/lookup tool, the description is nearly complete: it defines the input scope, the kind of output, and the intended use case. It lacks an explicit response structure or error behavior, but no output schema exists and the general output type is clear.

  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 already documents the single parameter with examples and 100% coverage. The description adds 'any monday.com column type' but does not meaningfully add parameter semantics beyond what the input schema already provides.

  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 ('Returns') and names the exact resource ('read and write JSON format for any monday.com column type'). This clearly distinguishes the tool from siblings like run_query or get_schema.

  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 'Use this whenever you need to know how to read or write a column value,' which gives a clear condition for choosing the tool. It does not mention when-not-to-use it or name alternatives, so it stops short of full alternative routing.

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