Skip to main content
Glama
drmaxbdc

@drmaxbdc/productboard-mcp

by drmaxbdc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

search_notes

Find Productboard notes (insights) by full-text, tags, dates, company, feature, or update window; archived notes are hidden by default.

Instructions

Search Productboard notes (insights). Routes to V2 POST /notes/search by default; falls back to V1 GET /notes only when term (fulltext) is set or allTags has 2+ values (V2 supports neither). The last relative time window (e.g. '6m', '10d') is translated to V2 updatedAt.from automatically, so last alone no longer forces V1. V1 fallback path will break on 2026-07-08 (V1 sunset). The response shape differs by path: V1 returns rich objects with top-level displayUrl, followers, features; V2 returns {id, type, links{self,html}, fields{...}, relationships{...}}. Check the apiVersion field in the result, or whether returned notes have top-level displayUrl (v1) vs links.html (v2). DEFAULT: hides archived notes — set archived=true to include.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lastNoRelative time window: '6m', '10d', '24h', '1h'. Translated to V2 updatedAt.from automatically. If you also pass updatedFrom, the explicit updatedFrom wins.
termNoFulltext search across note title and content. V1 ONLY — forces V1 fallback path (breaks 2026-07-08).
limitNoMax results (default 25, max 2000)
anyTagNoNotes matching ANY of these tags (OR logic, works in both V1 and V2)
sourceNoFilter by source system (v1 source.origin / v2 metadata.source.system)
allTagsNoNotes matching ALL of these tags (AND logic). V1 ONLY when 2+ tags — V2 has only OR; multi-tag AND forces V1 fallback path (breaks 2026-07-08).
archivedNoFilter by archived status. Default: false (archived notes hidden). Only honored on V2 path; ignored on V1 fallback.
companyIdNoNotes linked to this company (user/company) UUID
createdToNoISO 8601 date-time — notes created on/before
featureIdNoNotes linked to this feature UUID
processedNoFilter by processed status. Only honored on V2 path; on V1 fallback use the underlying note state.
updatedToNoISO 8601 date-time — notes updated on/before
ownerEmailNoFilter by owner email. Requires members:pii:read scope.
pageCursorNoPagination cursor from previous response (path-specific — do not mix V1 and V2 cursors)
createdFromNoISO 8601 date-time — notes created on/after
updatedFromNoISO 8601 date-time — notes updated on/after

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.1

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses the V2/V1 routing logic, the sunset date for the V1 path, how to distinguish response shapes (apiVersion, displayUrl vs links.html), and that archived is hidden by default and only honored on V2. This is unusually rich behavioral context beyond any structured field.

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?

Dense but front-loaded: purpose first, then routing, then response-shape divergence, then the archived default. Every sentence carries load, though the response-shape sentence is somewhat cramped and could be tightened.

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 16-parameter tool with no output schema and no annotations, the description compensates by explaining the two possible return shapes and the routing that determines them, plus the key default behavior. Nothing critical to correct invocation is missing.

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 adds real meaning: it clarifies that `last` is auto-translated to V2 updatedAt.from and no longer forces V1, and that `term`/multi-`allTags` force the fallback path. These are semantic consequences the schema descriptions only partially capture.

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?

States a specific verb and resource ('Search Productboard notes (insights)') and immediately scopes it against siblings by describing search semantics rather than listing. An agent can tell this apart from list_notes/get_note without opening the schema.

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?

Gives clear conditional guidance for internal routing (V2 default; V1 fallback only when term is set or allTags has 2+ values) and states the archived default with how to override it. It stops short of naming when to prefer this over siblings like list_notes or list_all_notes, so it is clear context without explicit alternative routing.

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