Skip to main content
Glama
Teamwork

Teamwork

Official
by Teamwork
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Remote

twdesk-list_helpdoc_sites

Read-only

List help doc sites and filter by name or subdomain to find the site ID required for help doc article tools.

Instructions

List help doc sites (knowledge bases). Filter by name or subdomain. Use this to discover the site ID required by the help doc article tools.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoThe name of the help doc site to filter by.
pageNoPage number for pagination of results (1-based).
fieldsNoSparse fieldset: field names to include (e.g. ["id","name"]). Omit to receive all fields.
orderByNoThe field to order the results by.
pageSizeNoNumber of results per page for pagination (1-100). The API silently reduces anything above 100, so a larger value returns fewer results rather than more.
subdomainNoThe subdomain of the help doc site to filter by.
orderDirectionNoThe direction to order the results by (asc, desc).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed22 schema fields changedv1.39.3
    • removedInput schema / properties / fields / anyOf
      Removed value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / fields / items
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / fields / type
      Added value: +"array"
    • removedInput schema / properties / name / anyOf
      Removed value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / name / items
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / name / type
      Added value: +"array"
    • removedInput schema / properties / orderBy / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / orderBy / type
      Added value: +"string"
    • removedInput schema / properties / orderDirection / anyOf
      Removed value: -[
-  {
-    "enum": [
-      "asc",
-      "desc"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / orderDirection / enum
      Added value: +[
+  "asc",
+  "desc"
+]
    • addedInput schema / properties / orderDirection / type
      Added value: +"string"
    • removedInput schema / properties / page / anyOf
      Removed value: -[
-  {
-    "minimum": 1,
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / page / minimum
      Added value: +1
    • addedInput schema / properties / page / type
      Added value: +"integer"
    • removedInput schema / properties / pageSize / anyOf
      Removed value: -[
-  {
-    "maximum": 100,
-    "minimum": 1,
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / pageSize / maximum
      Added value: +100
    • addedInput schema / properties / pageSize / minimum
      Added value: +1
    • addedInput schema / properties / pageSize / type
      Added value: +"integer"
    • removedInput schema / properties / subdomain / anyOf
      Removed value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / subdomain / items
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / subdomain / type
      Added value: +"array"
    • removedInput schema / required
      Removed value: -[
-  "page",
-  "pageSize",
-  "orderBy",
-  "orderDirection",
-  "fields",
-  "name",
-  "subdomain"
-]
  2. Addedv1.27.2

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=false, so the safety profile is covered. The description adds useful behavioral context by explaining the tool's role as a discovery mechanism for site IDs, and the schema enriches this with pagination details. Minor gap: the description does not explicitly state that results are paginated or that filters are optional, but the schema handles that.

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 with no fluff: the first identifies the resource and filters, the second states the primary use case. The most important guidance (site ID discovery) is front-loaded at the end of a short description. Every word 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 read-only list tool with 100% schema coverage and no output schema, the description is sufficient. The only gap is that it does not state that the response is a list of site objects, but the tool name and schema make that evident. The description handles the main contextual need: routing the agent to use this tool for site ID discovery.

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 does not add parameter-level detail beyond what the schema already provides, but it does frame 'name' and 'subdomain' as filters and 'site ID' as the key output, which adds minimal semantic value. The pagination and sparse-fieldset parameters are already well documented 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 states a specific verb ('List') and resource ('help doc sites (knowledge bases)'), and distinguishes this tool from related article tools by noting its purpose is to discover the site ID required by the help doc article tools. It is immediately clear what the tool does and how it differs from siblings like twdesk-get_helpdoc_site or twdesk-search_helpdoc_articles.

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 explicitly says 'Use this to discover the site ID required by the help doc article tools,' which tells the agent when to invoke this tool and for what downstream purpose. It does not name alternative tools to exclude, but the downstream guidance is strong and the distinction from article-level tools is clear.

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

Deploy Server

Other Tools