Skip to main content
Glama

Create Idea

create_idea

Add an idea to the backlog with zero votes and 'new' status. Attach customer insights for evidence, then grow votes and promote the winner to a roadmap feature.

Instructions

Create an idea in the backlog and return it (starts with 0 votes, status 'new'). Link the evidence it came from with insight_id (from list_insights). product_id defaults to the primary product. Only title is required. Grow it with vote_idea, then promote_idea turns the winner into a roadmap feature.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNoThe idea in more detail (optional).
titleYesIdea title (the only required field), e.g. 'Bulk-edit tasks'.
insight_idNoCustomer insight this idea came from, from list_insights (optional; welds evidence to the idea).
product_idNoProduct to scope it to, from whoami (optional; the primary product when omitted).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.14

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already indicate this is a mutating operation (readOnlyHint false). The description adds value by disclosing the initial vote count and status, the return behavior, and the default product_id, which are behavioral traits beyond the structured annotation fields.

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?

The description is compact and well-structured: two sentences with the core action upfront, followed by key parameter context and workflow. Every sentence adds necessary information without redundancy, making it easy for an agent to parse quickly.

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?

Given the 4 parameters and no output schema, the description covers the essential context: what the tool does, initial state, parameter defaults, and subsequent actions. It could provide more detail on the exact return structure, but 'return it' plus the initial field values is reasonably complete for a create tool.

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 input schema already covers all parameters (100% coverage), but the description enriches semantics by explaining that insight_id links evidence from list_insights and that product_id defaults to the primary product. It also clarifies that only title is required, reinforcing the schema's required field.

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 the tool's function with a specific verb and resource: 'Create an idea in the backlog and return it.' It also distinguishes from siblings by specifying the initial state ('starts with 0 votes, status 'new'') and the workflow with vote_idea and promote_idea, making it unmistakably about ideas rather than other entities.

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?

The description provides clear context on how to use the tool: linking with insight_id from list_insights, product_id defaulting to the primary product, and only title being required. It also hints at the lifecycle ('Grow it with vote_idea, then promote_idea...') but does not explicitly state when not to use it versus alternatives like create_feature.

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