Skip to main content
Glama

Send Participant Reward

send_participant_reward
DestructiveIdempotent

Send the configured incentive to a BYOP participant when the human requests it. No separate MCP App approval is required. Reuse idempotency_key on uncertain retries; the backend prevents duplicate rewards for an already-paid participant.

Input Schema

NameRequiredDescriptionDefault
participant_idYes
idempotency_keyNoReuse the same key and inputs if a prior call timed out. A different operation needs a new key.
organization_idNoOrganization for this operation and billing. Use list_organizations to choose an active membership.

Output Schema

NameRequiredDescriptionDefault
resultYesReward delivery acknowledgement.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / organization_id / description
      Previous value: -"Platform admins only: select an organization for this operation. Required when changing another organization’s study or using its wallet."New value: +"Organization for this operation and billing. Use list_organizations to choose an active membership."
  2. Changed1 schema field changed
    • addedInput schema / properties / organization_id
      Added value: +{
      +  "description": "Platform admins only: select an organization for this operation. Required when changing another organization’s study or using its wallet.",
      +  "maxLength": 128,
      +  "minLength": 1,
      +  "type": "string"
      +}
  3. Changed5 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / participant_id / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedOutput schema / properties / result / propertyNames
      Added value: +{
      +  "type": "string"
      +}
  4. First observed

TDQS

A4.2/5.0
Behavior4/5

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

With destructiveHint=true and idempotentHint=true already declared, the description still adds meaningful context: no approval gate is needed, the key must be reused on uncertain retries, and the backend itself blocks duplicate payouts for an already-paid participant. It does not disclose irreversibility, whether funds can be clawed back, or permission/billing prerequisites beyond organization_id, so not a top score.

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?

Three short sentences, front-loaded with the action and its trigger, then the approval clarification, then the retry rule. Nothing is padded and each sentence carries a distinct operational fact.

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?

For a destructive, open-world, idempotent mutation with three parameters and an output schema, this covers the essentials an agent needs to call it safely: trigger, approval posture, and retry/dedup behavior. Gaps remain around eligibility failures (unconfigured incentive, already-paid participant response) and permission/billing requirements.

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 67%, with idempotency_key and organization_id already well documented in the schema, so the baseline applies. The description's retry-sentence largely restates the schema's idempotency_key text, and participant_id remains undocumented in both places beyond its UUID format, though the 'BYOP participant' framing gives some implicit meaning.

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 ('Send the configured incentive to a BYOP participant') plus the trigger ('when the human requests it'). No sibling tool in the list handles rewards or incentives, so there is no ambiguity to resolve, and an agent can immediately tell this is a one-shot payout action rather than a participant-state read or update.

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 a clear invocation condition ('when the human requests it') and explicitly clears a workflow obstacle ('No separate MCP App approval is required'), which is real routing guidance. It stops short of stating when NOT to call (e.g., participant already paid, incentive not configured, wrong study state), even though the backend dedup implies such conditions exist.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources