Skip to main content
Glama
thenavidm
by thenavidm

List bounty submissions

list_bounty_submissions
Read-onlyIdempotent

Retrieve all submissions for a specific bounty in your partner program, filterable by status, partner, or group to track review progress.

Instructions

List all submissions for a specific bounty in your partner program.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoThe page number for pagination. The first page is `1`.
statusNoThe status of the submissions to list.
accountNoExact configured private workspace profile label; not a tenant or provider account ID.
sort_byNoThe field to sort the submissions by.completedAt
group_idNoThe ID of the group to list submissions for.
bounty_idYesThe unique ID of the bounty on Dub. Can be found in the URL of the bounty page, prefixed with `bnty_`.
page_sizeNoThe number of items per page.
partner_idNoThe ID of the partner to list submissions for.
sort_orderNoThe order to sort the submissions by.asc

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the scoping constraint ('for a specific bounty in your partner program') and says nothing about pagination defaults, filtering behavior, or result ordering.

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?

A single tight sentence with zero filler and the scope stated up front. It is appropriately sized, though it errs toward being too sparse to be maximally helpful for a nine-parameter tool.

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?

With annotations covering the safety profile and a fully documented schema, the description has cover for its thinness. Still, for a tool with nine filter/sort/pagination parameters it omits any mention of the filtering capabilities or relationship to the approve/reject siblings, leaving gaps in workflow context.

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 every one of the nine parameters is already documented (page, status, account, sort_by, group_id, partner_id, etc.). The description adds no parameter meaning beyond the schema, making the baseline 3 appropriate.

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

Purpose4/5

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

States a specific verb (list) and resource (bounty submissions) scoped to a specific bounty in the partner program, so the agent knows exactly what it returns. It does not, however, explicitly distinguish itself from related siblings like approve_bounty_submission, reject_bounty_submission, or list_program_applications.

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?

There is no when-to-use or when-not-to-use guidance. The description never mentions the reviewer siblings (approve_bounty_submission, reject_bounty_submission) or when listing is preferable, leaving the agent to infer the workflow entirely.

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