ClickHelp Published Docs MCP Server

List Topics

list_topics

Read-onlyIdempotent

List all topics in a project or publication. Returns metadata only (id, title, status, dates, isAutoTopic) without content for performance. If you need topic URLs, you can construct them as https://{portalDomain}/articles/{project-id}/{article-id}, e.g. https://your-portal.example.com/articles/my-project/my-topic. Use get_topic to fetch full content of a specific topic. Note: Topics marked with isAutoTopic=true are read-only and cannot be updated, deleted or used as new parents for TOC update operations. Topic IDs are unique within a project/publication scope but may duplicate across different projects. Publication topics are read-only (publications are auto-generated project copies that may be regenerated at any time).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectId": "<projectId>"
    },
    "name": "list_topics"
  }
}

Input Schema

Name	Required	Description
`pageSize`	No	Number of topics per page (default: 100). Use pagination for large projects to avoid excessive output.
`projectId`	Yes	Project or publication ID (e.g., 'my-documentation'). Project IDs are unique across the portal.
`pageNumber`	No	Page number (1-based). Default is 1.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is known. The description adds meaningful behavior beyond that: metadata-only payloads for performance, isAutoTopic=true topics being immutable and unusable as TOC parents, ID uniqueness scoped per project, and publication topics being read-only because publications are auto-generated copies. It stops short of describing ordering or total-count behavior, keeping it just under the top mark.

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?

Front-loads the core purpose and return shape before constraints and alternatives, which is the right order. It is slightly longer than needed: the full URL template plus a worked example consumes a sentence that could be compressed, though it does usefully prevent a wasted tool call.

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?

With no output schema, the description compensates by enumerating the returned fields, and it covers the read-only edge cases (auto topics, publication topics) that would otherwise cause failed mutations later. Nothing an agent needs to list topics correctly appears to be missing.

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%, so pageSize, pageNumber, and projectId are already documented, including the note to paginate large projects. The description reinforces that projectId may be a publication ID and clarifies ID uniqueness scope, but adds no new syntax or format detail for the pagination parameters. 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?

Opens with a specific verb and resource ("List all topics") plus scope (project or publication), then states exactly what is returned (metadata only: id, title, status, dates, isAutoTopic). It explicitly contrasts with get_topic for full content, so an agent can distinguish it from siblings without reading schemas.

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?

Gives explicit routing guidance: use get_topic for full content of a specific topic, and construct article URLs directly rather than calling another tool. It also flags when listing is inappropriate in effect by noting pagination for large projects, and warns that publication-scoped listings are read-only and regenerable.

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

All ClickHelp Published Docs MCP Server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?