Server Quality Checklist

Tool Scores

• get_project_fieldsA
  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 must disclose behavioral traits. It adds useful context about public access and user-owned project support, and references the same data source as list_project_items. However, it does not explicitly state the operation is read-only or describe return format/pagination, leaving gaps in the behavioral disclosure.

  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 reasonably sized with a clear front-loaded purpose. The additional details about use case and limitation are valuable and each sentence earns its place, though it could be slightly tightened.

  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 two-parameter getter with no annotations or output schema, the description covers purpose, return contents (field definitions, option colors, saved views), a use case, and limitations. It doesn't explain response structure or failure modes, but the current information is sufficient for most invocation scenarios.

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

  Parameters3/5

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

  The input schema already fully describes both parameters (owner and projectNumber) with 100% coverage. The description adds an extra constraint (user-owned, public) but doesn't elaborate on parameter formats or semantics beyond the schema, so it meets but doesn't exceed 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 opens with a specific verb and resource: 'Get a public GitHub Projects (v2) board's field definitions.' It also details what's included (single-select options, saved views) and a concrete use case (resolving option IDs), distinguishing it from sibling tools like get_project_metadata.

  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 clear usage context: it's useful for resolving option IDs from list_project_items, and it notes a limitation (user-owned projects only). However, it doesn't explicitly name alternative tools or state when not to use it, so it falls short of explicit exclusions.

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

• get_project_metadataA
  4.2/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 for behavioral disclosure. It explicitly states unauthenticated access and that it applies only to public projects, which are key constraints. It does not mention error handling or response structure, but these are less critical for a read-only metadata fetch.

  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 purpose and packs the access scope into the second sentence, making every word useful.

  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 description conveys what the tool returns (metadata fields), its scope (public, user/org owned), and auth requirement (unauthenticated), covering the essentials. The lack of an output schema is mitigated by the explicit list of metadata fields, though error behavior is not addressed.

  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 provides complete descriptions for all three parameters (coverage 100%), so the description does not need to add parameter-level detail. The description only adds context about the return fields, not about the parameters themselves, fitting the baseline of 3.

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

  Purpose5/5

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

  The description uses a specific verb 'Get' and clearly identifies the resource as metadata for a GitHub Projects v2 board. It enumerates the metadata fields (title, description, state, dates) and distinguishes itself from sibling tools like get_project_fields (fields) and get_project_item (single item).

  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 specifies that it works unauthenticated for public projects, which gives clear context on when it can be used. However, it does not explicitly contrast it with sibling tools or state when not to use it, so it stops short of a 5.

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

• list_user_projectsA
  4.2/5.0
  Behavior4/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. It discloses that the tool reads the same project list from the user's profile page, and explains the limitation of the official APIs. This is useful behavioral context beyond the schema, though it does not discuss authentication, rate limits, or output format.

  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 composed of two concise sentences. The first states the primary purpose; the second adds essential context about the API limitation. Every word earns its place, with no redundant information.

  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 tool with no output schema, the description is sufficiently complete. It explains what the tool does, the source it reads from, and why it exists. A minor omission is the lack of an explicit note on the return format, but that is not critical for this use case.

  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 provides 100% coverage with the parameter 'username' described as 'GitHub username'. The description does not add additional semantics beyond that, but none are needed for such a simple parameter. 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 clearly states the action ('List') and the specific resource ('public GitHub Projects (v2) boards owned by a user account'). It also distinguishes from sibling tools by focusing on the user-level listing, which is the entry point to other project-related tools.

  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 implicitly explains when to use this tool: when you need to list a user's projects without knowing a project number. It also provides helpful context about the lack of an official API, which justifies the tool's existence. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to decide.

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

• list_project_itemsA
  4.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 full burden of behavioral disclosure. It explicitly reveals that for user-owned projects it falls back to an unofficial page-scraping method that 'could break if GitHub changes its page structure'—a critical risk that an agent must know. It does not mention pagination or return format, but the core behavioral trait is well exposed.

  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 consists of two sentences: the first states the core purpose and result content, and the second provides the essential implementation caveat. Every sentence earns its place with no redundant or filler phrasing.

  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?

  With no output schema and no annotations, the description must convey enough context for safe invocation. It covers the purpose, result contents, and a major behavioral difference between owner types. Gaps include pagination behavior and error conditions for private/non-existent projects, but for a listing tool with fully documented parameters this is acceptably 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?

  The schema already covers all 3 parameters at 100%, so baseline is 3. The description adds meaning to the 'ownerType' parameter by explaining that 'user' triggers the unofficial fallback while 'org' uses the official REST API, which is not obvious from the schema alone. This extra context helps the agent predict behavior per owner type.

  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 the specific verb 'List' with a clear resource: 'all items (issues/PRs/draft issues) in a public GitHub Projects (v2) board'. It enumerates the output contents (status, custom field values, metadata), which distinguishes it from siblings like get_project_item (single item) and get_project_fields (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 clearly implies this is the tool for listing all items in a public project board, and it provides contextual guidance on the behavioral split between org-owned and user-owned projects. However, it does not explicitly state 'when not to use this' or name alternative tools, though siblings are obvious.

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

• get_project_itemA
  4.8/5.0
  Behavior5/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 that the tool uses an 'unofficial, undocumented GitHub endpoint' and that it 'works today for public projects but is not a published API contract,' setting clear expectations about reliability. It also mentions the nodeId incompatibility and the ID-resolution behavior, adding significant transparency beyond the annotation baseline.

  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?

  Though long, every sentence contributes: purpose, differentiation, required IDs, optional parameter behavior, and reliability caveat. The structure front-loads the core action, then explains dependencies and trade-offs, ending with a crucial warning. No superfluous content.

  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 description explains what the tool does, how it differs from siblings, ID requirements, and optional parameter effects, which is substantial without an output schema. However, it does not explicitly describe the shape of the returned data (e.g., whether it returns a flat object or nested fields), leaving a minor gap for a 'get' operation. Still, given the complexity and the tool's nature, it's nearly 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 covers 100% of parameters, so baseline is 3. The description adds important context: projectId must come from get_project_metadata's `id` field and not nodeId, itemId from list_project_items, and owner/projectNumber are only needed for resolving custom field/option names (omit to get raw IDs). This clarifies parameter relationships and usage, going beyond schema 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?

  Description clearly identifies the verb ('Get') and specific resource ('full field data for a single item in a public GitHub Projects (v2) board'), and explicitly distinguishes itself from list_project_items by noting it returns every field defined on the project instead of only default-view columns. The mention of custom fields like Priority/Story Points provides concrete examples.

  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?

  The description states when to use this tool: when needing full field data including custom fields, and contrasts with list_project_items which only returns default-view columns. It also gives explicit instructions on required IDs (numeric, not nodeId) and optional parameters (owner/projectNumber) with clarifications on what happens if omitted. This effectively guides selection among the sibling tools.

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