Productboard MCP Server and API by Cotlet

List objectives in Productboard

productboard_list_objectives

Read-onlyIdempotent

List objectives in the user's own Productboard account from ChatGPT, Claude or any AI agent. Returns how to do it in Productboard step by step (screens, buttons, fields) and opens nothing by itself; then do it with the cotlet_browser_* tools in the user's Productboard Cloud Browser. Productboard's official API: Productboard has a full REST API v2 for notes, entities, teams, members, webhooks and analytics, and a beta MCP server at mcp.productboard.com that works on specs (checked 22 Oct 2026).

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": "productboard_list_objectives"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful context that the tool returns step-by-step instructions (screens, buttons, fields) and does not open anything by itself, which clarifies that it is non-executing. However, it does not describe the format or reliability of those instructions, and the unrelated API paragraph dilutes the behavioral message.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is bloated with irrelevant details about Productboard's official REST API, beta MCP server, and a checked date, none of which help an agent select or invoke this tool. The core message about returning instructions is buried after a misleading opening sentence, and phrases like 'from ChatGPT, Claude or any AI agent' add no actionable value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the zero-parameter schema and existing annotations, the description covers the essential non-executing nature and mentions step-by-step output. But it fails to resolve the core ambiguity of whether objectives are returned or only instructions, does not specify the output structure, and omits any prerequisite about account connection or context needed for the subsequent browser tools.

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 takes zero parameters, so the schema imposes no semantic burden. A baseline of 4 is appropriate because there are no parameters to misunderstand or document beyond what the schema already conveys.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts by saying it will 'List objectives' but then clarifies it actually 'Returns how to do it in Productboard step by step' and 'opens nothing by itself', meaning the tool does not list objectives at all. This contradicts the tool name and leaves an agent unsure whether it will receive objectives or procedural instructions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only usage direction is 'then do it with the cotlet_browser_* tools,' which implies a preparatory step but gives no explicit when-to-use versus alternatives like the official API or beta MCP server mentioned. There is no guidance on prerequisites, exclusions, or how this differs from simply reading Productboard documentation.

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

All Productboard MCP Server and API by Cotlet 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?