DevTune MCP

devtune_list_prompts

Read-onlyIdempotent

Page the project's tracked prompts, the buyer-style questions DevTune asks AI platforms. Each has its id, the exact promptText, topicId and topicName, isActive (the prompt's own switch), topicActive, namesBrand (the prompt text names the project's own brand or one of its brand terms, retired ones included), pack (navigational for a prompt in the navigational pack, which does not count toward the prompt allowance; null otherwise) and, when recorded, disabledReason (manual, plan_limit or quota_exceeded) and disabledAt. Pass a prompt id as promptId to devtune_create_prompt_action, devtune_get_prompt_actions or devtune_list_visibility_response_history. By default only prompts that are on and whose topic is on are listed; includeInactive adds the others. Deleted prompts are never listed. The plan's prompt allowance can still hold back an active prompt; devtune_get_project_usage reports active prompts. Filter by topicId from devtune_list_topics. Ordered by id, default 50 and maximum 100 per page. Pass nextCursor back as cursor with the filters unchanged. This is a live listing, not a snapshot: prompts 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_prompts"
  }
}

Input Schema

Name	Required	Description
`limit`	No	The same setting as pageSize. Send either.
`cursor`	No	nextCursor from the previous page.
`topicId`	No	Only prompts in this topic, from devtune_list_topics.
`pageSize`	No	Prompts per page (1-100). Defaults to 50.
`includeInactive`	No	Also list switched-off prompts and prompts in switched-off topics. Defaults to false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 10, 2026
- removedInput schema / properties / limit / $ref
```
Removed value: -"#/properties/pageSize"
```
- addedInput schema / properties / limit / maximum
```
Added value: +100
```
- addedInput schema / properties / limit / minimum
```
Added value: +1
```
- addedInput schema / properties / limit / type
```
Added value: +"integer"
```
- addedInput schema / properties / topicId / pattern
```
Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
```

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 a safe, idempotent read, and the description adds substantial behavior on top: deleted prompts are never listed, the plan allowance can suppress an active prompt, ordering is by id, page bounds are 50/100, and the listing is live so items can be missed or appear while paging. The drift warning is exactly the kind of caveat 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?

The scope and default behavior are front-loaded, and nearly every clause carries information (field inventory, filter semantics, paging rules). It is one long run-on block with dense parentheticals, though, which makes it harder to scan than a few short structured sentences would be.

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 (id, promptText, topicId/topicName, isActive, topicActive, namesBrand, pack, disabledReason, disabledAt) and their meanings. Combined with the filtering, paging, and sibling routing notes, an agent has everything needed to call this 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 the baseline is 3, but the description goes further by explaining what includeInactive actually includes, that topicId values come from devtune_list_topics, and that the cursor must be reused with unchanged filters. The limit/pageSize aliasing is left to the schema, which is the only real gap.

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 tracked prompts') and immediately defines what a prompt is ('buyer-style questions DevTune asks AI platforms'), so the agent knows the object model without opening a schema. It is distinguishable from siblings such as devtune_list_topics and devtune_get_prompt_actions, which are named for related but different jobs.

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 states the default listing behavior (only on-prompts in on-topics), how to broaden it ('includeInactive adds the others'), how to narrow it ('Filter by topicId from devtune_list_topics'), and which siblings to use for per-prompt data or usage counts. Pagination guidance ('Pass nextCursor back as cursor with the filters unchanged') is spelled out rather than inferred.

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?