Skip to main content
Glama
mapbox

Mapbox Developer MCP Server

Official
by mapbox

List Feedback Tool

list_feedback_tool
Read-onlyIdempotent

List user feedback items from Mapbox Feedback API with filtering, sorting, and pagination. Access reported issues, suggestions, and ratings about map data, routing, and POI details.

Instructions

List user feedback items from the Mapbox Feedback API with filtering, sorting, and pagination. Use this tool to access user-reported issues, suggestions, and feedback about map data, routing, and POI details. Supports comprehensive filtering by status, category, date ranges, trace IDs, and search text. Requires user-feedback:read scope on the access token.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
afterNoA cursor from a previous response. Use this to fetch the next page of results.
limitNoThe maximum number of feedback items to return (1-1000)
orderNoThe sort direction: asc (ascending, default) or desc (descending)asc
formatNoOutput format: "json_string" returns raw JSON data as a JSON string that can be parsed; "formatted_text" returns human-readable text. Both return as text content but json_string contains parseable JSON data while formatted_text is for display.formatted_text
searchNoA search phrase. Returns items where the feedback text contains the phrase.
statusNoFilter by one or more feedback statuses. Options: received, fixed, reviewed, out_of_scope
sort_byNoThe field to sort results by. Options: received_at (default), created_at, or updated_atreceived_at
categoryNoFilter by one or more feedback categories
trace_idNoFilter by one or more trace_id values. At least one must match.
feedback_idsNoFilter by one or more feedback item IDs. At least one must match.
created_afterNoReturn items created after the specified time. Use ISO 8601 format: YYYY-MM-DDTHH:mm:ss.SSSZ
updated_afterNoReturn items last updated after the specified time. Use ISO 8601 format: YYYY-MM-DDTHH:mm:ss.SSSZ
created_beforeNoReturn items created before the specified time. Use ISO 8601 format: YYYY-MM-DDTHH:mm:ss.SSSZ
received_afterNoReturn items received by Mapbox after the specified time. Use ISO 8601 format: YYYY-MM-DDTHH:mm:ss.SSSZ
updated_beforeNoReturn items last updated before the specified time. Use ISO 8601 format: YYYY-MM-DDTHH:mm:ss.SSSZ
received_beforeNoReturn items received by Mapbox before the specified time. Use ISO 8601 format: YYYY-MM-DDTHH:mm:ss.SSSZ
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds the scope requirement and the types of feedback accessible. It does not contradict annotations and builds upon them.

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 concise (4 sentences), front-loaded with the core action, and contains no redundant information. Every sentence serves a purpose.

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?

With 16 parameters and no output schema, the description covers the tool's purpose, scope, and authorization. It could be improved by explicitly noting the two output formats (json_string and formatted_text) and clarifying that the response is a list of items. Nonetheless, it is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description provides context about the API and feedback types but adds minimal value beyond the individual parameter descriptions already in the schema.

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 verb 'List', the resource 'user feedback items', and elaborates on the scope (map data, routing, POI) and capabilities (filtering, sorting, pagination). It effectively distinguishes from siblings like get_feedback_tool.

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 clearly states when to use the tool and lists filtering options. It mentions the required scope ('user-feedback:read'). However, it does not explicitly exclude cases or recommend alternatives, such as using get_feedback_tool for single items.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mapbox/mcp-devkit-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server