Skip to main content
Glama
olgasafonova

productplan-mcp-server

by olgasafonova
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

list_idea_forms

Read-only

List all idea submission forms, returning each form's ID and name for easy reference and management.

Instructions

List idea submission forms.

USE WHEN: "Show feedback forms", "What forms exist?" Returns array of forms with ID and name. FAILS WHEN: API token invalid.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesThe ProductPlan payload (object or array) returned by the API, passed through verbatim
summaryYesHuman-readable summary of the result (e.g. "Found 3 roadmaps")

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv6.0.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "data": {
+      "description": "The ProductPlan payload (object or array) returned by the API, passed through verbatim",
+      "type": "object"
+    },
+    "summary": {
+      "description": "Human-readable summary of the result (e.g. \"Found 3 roadmaps\")",
+      "type": "string"
+    }
+  },
+  "required": [
+    "summary",
+    "data"
+  ],
+  "type": "object"
+}
  2. First observedv5.0.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true, and the description adds return format (array with ID and name) and a failure condition (invalid API token). This goes beyond annotations, though it doesn't disclose other traits like pagination or ordering, which are likely unnecessary for a simple list.

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?

Three short lines: main action, when to use, failure condition. No fluff, and the primary action is front-loaded. Every sentence serves a purpose.

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?

For a parameterless list tool with an output schema and read-only annotation, the description covers the essential usage triggers and failure mode. Nothing critical is missing for an agent to decide and call 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?

The tool has zero parameters, so the description correctly omits parameter details. With schema coverage at 100% (no params), the baseline of 4 applies and the description adds no unnecessary param info.

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 'List idea submission forms' with a specific verb and resource. It also specifies the return type (array with ID and name) and is easily distinguishable from siblings like get_idea_form (singular) and list_ideas (different resource).

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 explicit USE WHEN examples ('Show feedback forms', 'What forms exist?') that trigger this tool, giving clear context. It doesn't explicitly exclude alternatives, but sibling tools are distinct resources, so the intended usage is unambiguous.

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