@projectsolo/solo-mission-mcp 0.21.6 → 0.21.8

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (3) hide show
  1. package/dist/index.js +6 -6
  2. package/package.json +1 -1
  3. package/src/tools/missions.ts +6 -6
package/dist/index.js CHANGED
@@ -53,8 +53,8 @@ var missionTools = [
53
53
  reward_per_human: { type: "number", minimum: 0, description: "Deprecated \u2014 use base_reward instead." },
54
54
  lottery_winner_count: { type: "integer", minimum: 1, description: "Number of winners randomly selected from all qualified participants. Must be <= max_humans. Must be paired with lottery_prize_per_winner. Winners are chosen deterministically from the on-chain seed reveal \u2014 auditable by anyone." },
55
55
  lottery_prize_per_winner: { type: "number", minimum: 0, description: "Additional prize in USDC paid to each lottery winner on top of base_reward. Must be paired with lottery_winner_count." },
56
- hiring_duration_hours: { type: "number", minimum: 1, description: "How long (hours) the mission accepts applications and the agent hires/rejects. The hiring window closes at now + hiring_duration_hours. Finalize-qualification cannot be called before this." },
57
- work_duration_hours: { type: "number", minimum: 2, description: "How long (hours) hired participants have to complete the work. Agent must call settle_mission before this period ends. Minimum is 2, not 1 \u2014 the contract requires at least 1 hour of settlement window remaining when finalize_qualification is called, and finalize can only happen after the hiring window already closes, so a value of exactly 1 leaves no reachable window at all." },
56
+ hiring_duration_hours: { type: "number", minimum: 0.0166, description: "How long (hours) the mission accepts applications and the agent hires/rejects. The hiring window closes at now + hiring_duration_hours. Finalize-qualification cannot be called before this. Backend floor is 60s (0.0166h), same for every chain \u2014 see work_duration_hours for the reasoning." },
57
+ work_duration_hours: { type: "number", minimum: 0.0166, description: "How long (hours) hired participants have to complete the work. Agent must call settle_mission before this period ends. Backend floor is 60s (0.0166h) for every chain \u2014 this is a flat sanity check against a near-zero window, not a guarantee of a legal settlement window on every chain: Base's own EscrowVault contract separately enforces its own fixed 1-hour minimum regardless of what this floor allows through, so a too-short Base mission still fails downstream (at finalize_qualification, or on-chain) instead of being caught at creation." },
58
58
  auto_accept_applicants: { type: "boolean", description: "When true, applicants are automatically hired when they apply \u2014 no manual hire_participant call needed. First-come first-served up to max_humans. Face verification is still required. Ideal for open media_review missions." }
59
59
  },
60
60
  required: ["type", "title", "description"]
@@ -101,7 +101,7 @@ var missionTools = [
101
101
  },
102
102
  {
103
103
  name: "hire_participant",
104
- description: "Accept a human applicant for a mission. Only applied humans can be hired. Hired humans can start work via conversations. Only valid while mission is active.",
104
+ description: "Accept a human applicant for a mission. Only applied humans can be hired. Hired humans can start work via conversations. Only valid while mission is active. IMPORTANT: silence is not neutral \u2014 an applicant you never call this (or reject_participant) on is automatically hired once the hiring window closes (up to max_humans, oldest applied_at first). If you do not want someone, you must call reject_participant before the deadline.",
105
105
  inputSchema: {
106
106
  type: "object",
107
107
  properties: {
@@ -113,7 +113,7 @@ var missionTools = [
113
113
  },
114
114
  {
115
115
  name: "reject_participant",
116
- description: "Reject a human applicant or hired participant. Valid for applied or hired status, before finalize_qualification is called.",
116
+ description: "Reject a human applicant or hired participant. Valid for applied or hired status, before finalize_qualification is called. This is the ONLY way to exclude someone \u2014 the platform auto-hires overdue applicants and auto-qualifies overdue hired participants by default (silence = go), so if you do not explicitly reject someone before their deadline, they end up hired/qualified/paid.",
117
117
  inputSchema: {
118
118
  type: "object",
119
119
  properties: {
@@ -125,7 +125,7 @@ var missionTools = [
125
125
  },
126
126
  {
127
127
  name: "finalize_qualification",
128
- description: "Lock in the qualified participants after reviewing their work. For standard missions provide an explicit list of UIDs whose work was accepted. For media_review missions pass an empty body \u2014 qualified_human_uids is ignored and the backend auto-qualifies anyone who rated every track. For on-chain missions, the backend calls finalizeQualification() on EscrowVault. Mission transitions to qualifying.",
128
+ description: "Lock in the qualified participants after reviewing their work. For standard missions provide an explicit list of UIDs whose work was accepted. For media_review missions pass an empty body \u2014 qualified_human_uids is ignored and the backend auto-qualifies anyone who rated every track. For on-chain missions, the backend calls finalizeQualification() on EscrowVault. Mission transitions to qualifying. If you never call this, the platform does it for you shortly after the hiring window closes, qualifying every hired participant you did not explicitly reject_participant (silence = go) \u2014 call reject_participant first for anyone whose work should NOT be paid.",
129
129
  inputSchema: {
130
130
  type: "object",
131
131
  properties: {
@@ -141,7 +141,7 @@ var missionTools = [
141
141
  },
142
142
  {
143
143
  name: "settle_mission",
144
- description: "Settle the mission after finalize_qualification. For on-chain missions, calls settleTask() on EscrowVault only (aggregate payout numbers, no per-wallet computation); mission transitions to completed or refundable. IMPORTANT: status alone cannot tell you whether anyone was paid \u2014 a mission with 8/10 slots filled (2 slots' budget refunded) and one with 0/10 filled (the whole budget refunded) both land on 'refundable'/'refunded'. Check the settlement_outcome field on the response instead: 'completed' (fully spent, no refund), 'completed_refundable' (real participants were paid, only the unfilled slots refund), or 'no_payout_refunded' (nobody qualified, the entire budget bounces). Rewards are NOT immediately claimable \u2014 a separate batched process publishes the Merkle root that makes them claimable, gated by a review window currently defaulting to about 10 seconds (minimized pre-launch; will lengthen to an hour or more once real funds are at stake). Check GET /human/rewards for actual claimable status rather than assuming a fixed delay. For free (off-chain) missions, marks qualified participants as completed \u2014 no payment is involved; settlement_outcome is always 'completed' there.",
144
+ description: "Settle the mission after finalize_qualification. For on-chain missions, calls settleTask() on EscrowVault only (aggregate payout numbers, no per-wallet computation); mission transitions to completed or refundable. IMPORTANT: status alone cannot tell you whether anyone was paid \u2014 a mission with 8/10 slots filled (2 slots' budget refunded) and one with 0/10 filled (the whole budget refunded) both land on 'refundable'/'refunded'. Check the settlement_outcome field on the response instead: 'completed' (fully spent, no refund), 'completed_refundable' (real participants were paid, only the unfilled slots refund), or 'no_payout_refunded' (nobody qualified, the entire budget bounces). Rewards are NOT immediately claimable \u2014 a separate batched process publishes the Merkle root that makes them claimable, gated by a review window currently defaulting to about 10 seconds (minimized pre-launch; will lengthen to an hour or more once real funds are at stake). Check GET /human/rewards for actual claimable status rather than assuming a fixed delay. For free (off-chain) missions, marks qualified participants as completed \u2014 no payment is involved; settlement_outcome is always 'completed' there. If you never call this, the platform settles on your behalf shortly after finalize_qualification (auto or manual) \u2014 you do not get a second chance to change who is qualified at that point, so reject anyone unwanted before finalize, not after.",
145
145
  inputSchema: {
146
146
  type: "object",
147
147
  properties: {
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@projectsolo/solo-mission-mcp",
3
- "version": "0.21.6",
3
+ "version": "0.21.8",
4
4
  "description": "MCP server for Solo Mission Platform — lets AI agents create missions, browse humans, and chat.",
5
5
  "type": "module",
6
6
  "main": "dist/index.js",
package/src/tools/missions.ts CHANGED
@@ -39,8 +39,8 @@ export const missionTools: Tool[] = [
39
39
  reward_per_human: { type: 'number', minimum: 0, description: 'Deprecated — use base_reward instead.' },
40
40
  lottery_winner_count: { type: 'integer', minimum: 1, description: 'Number of winners randomly selected from all qualified participants. Must be <= max_humans. Must be paired with lottery_prize_per_winner. Winners are chosen deterministically from the on-chain seed reveal — auditable by anyone.' },
41
41
  lottery_prize_per_winner: { type: 'number', minimum: 0, description: 'Additional prize in USDC paid to each lottery winner on top of base_reward. Must be paired with lottery_winner_count.' },
42
- hiring_duration_hours: { type: 'number', minimum: 1, description: 'How long (hours) the mission accepts applications and the agent hires/rejects. The hiring window closes at now + hiring_duration_hours. Finalize-qualification cannot be called before this.' },
43
- work_duration_hours: { type: 'number', minimum: 2, description: 'How long (hours) hired participants have to complete the work. Agent must call settle_mission before this period ends. Minimum is 2, not 1 — the contract requires at least 1 hour of settlement window remaining when finalize_qualification is called, and finalize can only happen after the hiring window already closes, so a value of exactly 1 leaves no reachable window at all.' },
42
+ hiring_duration_hours: { type: 'number', minimum: 0.0166, description: 'How long (hours) the mission accepts applications and the agent hires/rejects. The hiring window closes at now + hiring_duration_hours. Finalize-qualification cannot be called before this. Backend floor is 60s (0.0166h), same for every chain — see work_duration_hours for the reasoning.' },
43
+ work_duration_hours: { type: 'number', minimum: 0.0166, description: 'How long (hours) hired participants have to complete the work. Agent must call settle_mission before this period ends. Backend floor is 60s (0.0166h) for every chain — this is a flat sanity check against a near-zero window, not a guarantee of a legal settlement window on every chain: Base\'s own EscrowVault contract separately enforces its own fixed 1-hour minimum regardless of what this floor allows through, so a too-short Base mission still fails downstream (at finalize_qualification, or on-chain) instead of being caught at creation.' },
44
44
  auto_accept_applicants: { type: 'boolean', description: 'When true, applicants are automatically hired when they apply — no manual hire_participant call needed. First-come first-served up to max_humans. Face verification is still required. Ideal for open media_review missions.' },
45
45
  },
46
46
  required: ['type', 'title', 'description'],
@@ -87,7 +87,7 @@ export const missionTools: Tool[] = [
87
87
  },
88
88
  {
89
89
  name: 'hire_participant',
90
- description: 'Accept a human applicant for a mission. Only applied humans can be hired. Hired humans can start work via conversations. Only valid while mission is active.',
90
+ description: 'Accept a human applicant for a mission. Only applied humans can be hired. Hired humans can start work via conversations. Only valid while mission is active. IMPORTANT: silence is not neutral — an applicant you never call this (or reject_participant) on is automatically hired once the hiring window closes (up to max_humans, oldest applied_at first). If you do not want someone, you must call reject_participant before the deadline.',
91
91
  inputSchema: {
92
92
  type: 'object',
93
93
  properties: {
@@ -99,7 +99,7 @@ export const missionTools: Tool[] = [
99
99
  },
100
100
  {
101
101
  name: 'reject_participant',
102
- description: 'Reject a human applicant or hired participant. Valid for applied or hired status, before finalize_qualification is called.',
102
+ description: 'Reject a human applicant or hired participant. Valid for applied or hired status, before finalize_qualification is called. This is the ONLY way to exclude someone — the platform auto-hires overdue applicants and auto-qualifies overdue hired participants by default (silence = go), so if you do not explicitly reject someone before their deadline, they end up hired/qualified/paid.',
103
103
  inputSchema: {
104
104
  type: 'object',
105
105
  properties: {
@@ -111,7 +111,7 @@ export const missionTools: Tool[] = [
111
111
  },
112
112
  {
113
113
  name: 'finalize_qualification',
114
- description: 'Lock in the qualified participants after reviewing their work. For standard missions provide an explicit list of UIDs whose work was accepted. For media_review missions pass an empty body — qualified_human_uids is ignored and the backend auto-qualifies anyone who rated every track. For on-chain missions, the backend calls finalizeQualification() on EscrowVault. Mission transitions to qualifying.',
114
+ description: 'Lock in the qualified participants after reviewing their work. For standard missions provide an explicit list of UIDs whose work was accepted. For media_review missions pass an empty body — qualified_human_uids is ignored and the backend auto-qualifies anyone who rated every track. For on-chain missions, the backend calls finalizeQualification() on EscrowVault. Mission transitions to qualifying. If you never call this, the platform does it for you shortly after the hiring window closes, qualifying every hired participant you did not explicitly reject_participant (silence = go) — call reject_participant first for anyone whose work should NOT be paid.',
115
115
  inputSchema: {
116
116
  type: 'object',
117
117
  properties: {
@@ -127,7 +127,7 @@ export const missionTools: Tool[] = [
127
127
  },
128
128
  {
129
129
  name: 'settle_mission',
130
- description: 'Settle the mission after finalize_qualification. For on-chain missions, calls settleTask() on EscrowVault only (aggregate payout numbers, no per-wallet computation); mission transitions to completed or refundable. IMPORTANT: status alone cannot tell you whether anyone was paid — a mission with 8/10 slots filled (2 slots\' budget refunded) and one with 0/10 filled (the whole budget refunded) both land on \'refundable\'/\'refunded\'. Check the settlement_outcome field on the response instead: \'completed\' (fully spent, no refund), \'completed_refundable\' (real participants were paid, only the unfilled slots refund), or \'no_payout_refunded\' (nobody qualified, the entire budget bounces). Rewards are NOT immediately claimable — a separate batched process publishes the Merkle root that makes them claimable, gated by a review window currently defaulting to about 10 seconds (minimized pre-launch; will lengthen to an hour or more once real funds are at stake). Check GET /human/rewards for actual claimable status rather than assuming a fixed delay. For free (off-chain) missions, marks qualified participants as completed — no payment is involved; settlement_outcome is always \'completed\' there.',
130
+ description: 'Settle the mission after finalize_qualification. For on-chain missions, calls settleTask() on EscrowVault only (aggregate payout numbers, no per-wallet computation); mission transitions to completed or refundable. IMPORTANT: status alone cannot tell you whether anyone was paid — a mission with 8/10 slots filled (2 slots\' budget refunded) and one with 0/10 filled (the whole budget refunded) both land on \'refundable\'/\'refunded\'. Check the settlement_outcome field on the response instead: \'completed\' (fully spent, no refund), \'completed_refundable\' (real participants were paid, only the unfilled slots refund), or \'no_payout_refunded\' (nobody qualified, the entire budget bounces). Rewards are NOT immediately claimable — a separate batched process publishes the Merkle root that makes them claimable, gated by a review window currently defaulting to about 10 seconds (minimized pre-launch; will lengthen to an hour or more once real funds are at stake). Check GET /human/rewards for actual claimable status rather than assuming a fixed delay. For free (off-chain) missions, marks qualified participants as completed — no payment is involved; settlement_outcome is always \'completed\' there. If you never call this, the platform settles on your behalf shortly after finalize_qualification (auto or manual) — you do not get a second chance to change who is qualified at that point, so reject anyone unwanted before finalize, not after.',
131
131
  inputSchema: {
132
132
  type: 'object',
133
133
  properties: {