@projectsolo/solo-mission-mcp 0.21.5 → 0.21.7

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.
package/dist/index.js CHANGED
@@ -78,7 +78,7 @@ var missionTools = [
78
78
  },
79
79
  {
80
80
  name: "get_mission",
81
- description: 'Get details of a specific mission by ID, including all participants. Each participant includes a conversation_id once the human has tapped "Say Hi" \u2014 use it directly with watch_conversation or send_message. Each participant also includes an agent_rating field ({ rating: 1\u20135, comment?: string, updated_at }) if that human has rated the agent; null if not rated or if the 7-day rating window after mission completion has closed.',
81
+ description: `Get details of a specific mission by ID, including all participants. Each participant includes a conversation_id once the human has tapped "Say Hi" \u2014 use it directly with watch_conversation or send_message. Each participant also includes an agent_rating field ({ rating: 1\u20135, comment?: string, updated_at }) if that human has rated the agent; null if not rated or if the 7-day rating window after mission completion has closed. Once settled, a settlement_outcome field ('completed' / 'completed_refundable' / 'no_payout_refunded') tells you whether anyone was actually paid \u2014 see settle_mission's description; don't infer that from status alone.`,
82
82
  inputSchema: {
83
83
  type: "object",
84
84
  properties: {
@@ -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. 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.",
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.5",
3
+ "version": "0.21.7",
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",
@@ -64,7 +64,7 @@ export const missionTools: Tool[] = [
64
64
  },
65
65
  {
66
66
  name: 'get_mission',
67
- description: 'Get details of a specific mission by ID, including all participants. Each participant includes a conversation_id once the human has tapped "Say Hi" — use it directly with watch_conversation or send_message. Each participant also includes an agent_rating field ({ rating: 1–5, comment?: string, updated_at }) if that human has rated the agent; null if not rated or if the 7-day rating window after mission completion has closed.',
67
+ description: 'Get details of a specific mission by ID, including all participants. Each participant includes a conversation_id once the human has tapped "Say Hi" — use it directly with watch_conversation or send_message. Each participant also includes an agent_rating field ({ rating: 1–5, comment?: string, updated_at }) if that human has rated the agent; null if not rated or if the 7-day rating window after mission completion has closed. Once settled, a settlement_outcome field (\'completed\' / \'completed_refundable\' / \'no_payout_refunded\') tells you whether anyone was actually paid — see settle_mission\'s description; don\'t infer that from status alone.',
68
68
  inputSchema: {
69
69
  type: 'object',
70
70
  properties: {
@@ -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. 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.',
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: {