DevTune MCP

devtune_list_topics

Read-onlyIdempotent

Page the project's topics: each has its id, name, description, isActive and branded, true when every live prompt in the topic names the project's own brand. Pass a topic id as topicId to devtune_list_prompts, devtune_get_visibility_summary or devtune_get_competitive_position. Only active topics are listed unless includeInactive is true; deleted topics are never listed. Ordered by id, default 50 and maximum 100 per page. Pass nextCursor back as cursor with includeInactive unchanged. This is a live listing, not a snapshot: topics added or changed while you page can be missed or appear.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "devtune_list_topics"
  }
}

Input Schema

Name	Required	Description
`limit`	No	The same setting as pageSize. Send either.
`cursor`	No	nextCursor from the previous page.
`pageSize`	No	Topics per page (1-100). Defaults to 50.
`includeInactive`	No	Also list switched-off topics. Defaults to false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 25, 2026

addedInput schema / properties / limit

Added value: +{
+  "$ref": "#/properties/pageSize",
+  "description": "The same setting as pageSize. Send either."
+}

AddedOct 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent safety, and the description adds genuinely new behavioral facts: live-listing semantics ('not a snapshot: topics added or changed while you page can be missed or appear'), the invariant that includeInactive must stay unchanged across pages, ordering by id, and default/max page sizes. That is exactly the context annotations cannot convey.

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-loaded with purpose and routing, and every sentence carries information. Slightly dense — the branded-field definition is wedged into the opening sentence and could be its own clause, but nothing is wasted.

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?

No output schema exists, yet the description names the returned fields and their semantics, plus filtering, ordering, pagination and consistency caveats. An agent has everything needed to call and interpret this tool 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?

Schema coverage is 100%, so baseline is 3; the description earns more by explaining the cursor round-trip ('Pass nextCursor back as cursor with includeInactive unchanged') — a constraint not stated in the schema — plus the 50/100 page limits. It does not add meaning for the limit/pageSize alias beyond the schema, so not a 5.

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 ('Page the project's topics') and immediately enumerates the returned fields (id, name, description, isActive, branded), including a definition of the ambiguous 'branded' flag. An agent knows exactly what this tool returns versus sibling list tools like devtune_list_prompts.

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?

Explicitly routes downstream work: 'Pass a topic id as topicId to devtune_list_prompts, devtune_get_visibility_summary or devtune_get_competitive_position.' It also states the includeInactive condition and that deleted topics are never listed, so both when-to-use and scoping rules are given.

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

All DevTune MCP 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?