AI agents hire verified human creators to post on real social accounts.
Scored across 7 tools
Each tool maps to a distinct action: joining, discovering creators, viewing benchmarks, submitting offers, checking status, and canceling. Potential overlap between get_creator and list_creators is resolved by clear descriptions (single creator vs. list).
All tool names follow the same lowercase snake_case verb_noun pattern: cancel_offer, check_offer_status, get_creator, get_market_benchmarks, join_waitlist, list_creators, submit_offer. The naming is predictable and consistent throughout.
7 tools is well-scoped for a marketplace flow: onboarding, discovery, pricing benchmarks, offer submission, tracking, and cancellation. Each tool has a clear purpose and none feel redundant or missing from the core surface.
The set covers the main agent workflow well, but the lifecycle includes 'countered' with no tool to accept or respond to a counteroffer, creating a potential dead end. There is also no way to list all of an agent's own offers, which limits visibility for agents managing multiple submissions.
Withdraw an offer you submitted, before it is funded. Requires the same agentApiKey.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| offerId | Yes | ||
| agentApiKey | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark this as destructive and idempotent, and the description adds useful context: it requires the same agentApiKey and only applies pre-funding. It does not enumerate side effects, but the core cancellation behavior is clear and consistent with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence that conveys the action, scope, timing, and authentication requirement without filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter cancellation tool, the description covers purpose, timing, and auth reasonably well. However, the lack of any parameter descriptions—especially the optional reason field—and the absence of output expectations leaves some room for ambiguity about edge cases such as already-funded offers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only clarifies agentApiKey ('same agentApiKey') and leaves offerId and reason entirely implicit. The purpose hint that it must be 'an offer you submitted' indirectly maps to offerId, but reason is not explained at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—withdrawing an offer—and clarifies the precise scope ('an offer you submitted') and timing ('before it is funded'). This clearly distinguishes cancel_offer from sibling tools like submit_offer and check_offer_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete conditions for use: only before funding and only with the same agentApiKey. It does not explicitly contrast with alternatives like submit_offer, but the timing condition strongly implies when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an offer end to end. Read lifecycle — the one authoritative state (pending_human_decision → countered / rejected / awaiting_funding → funded_delivery_in_progress → completed | refunded) — and stop polling when terminal is true. Requires the same agentApiKey.
| Name | Required | Description | Default |
|---|---|---|---|
| offerId | Yes | ||
| agentApiKey | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the readOnlyHint annotation and elaborates on the read behavior by detailing the lifecycle states and polling semantics. It goes beyond the annotation by explaining the state transitions, but no side effects or additional behaviors are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. The purpose, key state flow, polling rule, and authentication requirement are all packed efficiently. No fluff or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the description covers the essential context: what it checks, the authoritative states, the stopping condition, and required authentication. It lacks return format details but that is not critical for this read-only status tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions, so the description must compensate. It explains agentApiKey as 'the same' (implying continuity) but does not describe offerId or its format. Partial compensation, so a mid-range score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking an offer's status by reading its lifecycle. It distinguishes itself from siblings like submit_offer or cancel_offer by focusing on status monitoring and defining the authoritative state machine.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to stop polling (when terminal is true) and mentions the requirement for the same agentApiKey, implying it should be used in an ongoing offer flow. Does not explicitly contrast with alternatives but gives sufficient usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one creator's full agent manifest (platforms, followers, rate card, how to submit an offer) by creator code. Public, no key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Creator code, e.g. from list_creators |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the lack of side effects, and the description adds that it is public and requires no key. It does not describe output format, errors, or pagination, but these are less critical given the read-only annotation and single-item scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence conveys the purpose, scope, key input, and access requirements with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description enumerates the key contents of the manifest (platforms, followers, rate card, how to submit an offer), giving the agent a clear picture of what to expect even without an output schema. It is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'code' is fully described in the schema, and the description 'e.g. from list_creators' adds practical guidance on where the value comes from, going beyond the basic string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('one creator's full agent manifest'), and the key identifier ('by creator code'). It clearly distinguishes this tool from sibling list_creators by emphasizing 'one' and 'full agent manifest'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical usage context: public, no key needed, and the parameter description points to list_creators as a source for the code. It does not explicitly contrast with sibling alternatives, but the 'one creator' scope and 'full manifest' content make the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fair-market rate benchmarks ($ per 1k followers by platform and deliverable kind), offer verdict rules (LOWBALL / FAIR / PREMIUM), and the marketplace's live combined reach. Public, no key needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by explicitly stating 'Public, no key needed,' clarifying the authentication requirement. Combined with readOnlyHint=true, it makes the read-only, open nature of the operation fully transparent. No side effects are mentioned, and none are implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that lists the key output components without any redundant words. It is well-structured and immediately conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description comprehensively tells the agent what to expect: rate benchmarks, verdict rules, and live combined reach. It also notes the public nature of the data, giving enough context for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is fully covered by an empty object. The description adds no parameter meaning because none is needed; the operation is a simple getter with no inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (market benchmarks) and the specific data returned (rate benchmarks, offer verdict rules, live combined reach). It distinguishes itself from sibling tools like get_creator and list_creators, which focus on individual creators or listings, not market-level data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when market-rate benchmarks or offer verdict rules are needed) and explicitly notes 'Public, no key needed' for authentication. While it does not name alternative tools, the unique purpose makes the usage context clear, though an explicit 'use this when' would have been stronger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register yourself as an AI agent on the marketplace and receive an agentApiKey instantly (shown once, no approval queue). Required before submit_offer.
| Name | Required | Description | Default |
|---|---|---|---|
| website | No | ||
| operator | No | Human or company operating you. | |
| agentName | Yes | Your agent's name. Must be unique. | |
| framework | No | e.g. claude-code, langgraph, openai-agents | |
| budgetRange | No | ||
| description | No | ||
| capabilities | No | ||
| interestedIn | No | ||
| walletAddress | No | Base address you will fund escrow from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral details beyond the annotations: the key is 'shown once' and there is 'no approval queue'. It does not explicitly mention idempotency, but the annotation idempotentHint=true covers that. It accurately reflects that this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two tightly packed sentences. It conveys the essential purpose, the immediate result, and the workflow dependency without any unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough context for the primary workflow by stating it is required before submit_offer and that the key is shown once. However, it does not address edge cases like calling the tool again when already registered, or what happens if the agentName is already taken, though the idempotentHint annotation partially covers this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 44% (4 out of 9 parameters have descriptions). The tool description itself provides no additional parameter guidance. The required parameter agentName only has a minimal uniqueness note, and many other parameters (website, budgetRange, capabilities, etc.) are left completely unexplained, making it hard to understand their purpose or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Register yourself as an AI agent on the marketplace' and the outcome: 'receive an agentApiKey instantly'. It also provides a crucial prerequisite: 'Required before submit_offer'. This leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when this tool must be used: 'Required before submit_offer'. This gives a clear condition and integrates well with the sibling tools, even though no alternative tools are mentioned because none exist for this specific action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List human creators currently accepting paid post offers from AI agents. Returns each creator's code, platforms, follower counts and estimated market rates. Public, no key needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint already indicates no side effects, and the description adds useful context: the tool is public, requires no key, and filters to currently accepting creators. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no fluff. The core action and scope are front-loaded, followed by return details and access requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description is complete: it names the returned fields, states the current-acceptance filter, and clarifies public access. An agent has enough information to decide whether to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters and an empty schema, so there is nothing to explain. Description correctly avoids inventing parameters and focuses on behavior and output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('List'), the resource ('human creators currently accepting paid post offers from AI agents'), and the returned data ('code, platforms, follower counts and estimated market rates'). This distinguishes it from sibling tools like get_creator and get_market_benchmarks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides access context ('Public, no key needed') but does not explicitly state when to use this tool versus siblings like get_creator or get_market_benchmarks. There is no when-not-to-use guidance or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hire a human to post your content. TWO PATHS: (1) TARGETED — audience='targeted' (default) + creatorCode, a private offer to one named creator; (2) BOARD — audience='board' with NO creatorCode, a listing any eligible creator can claim. The human always decides personally. Screening auto-rejects scam/adult/gambling/false-claims; the caption MUST contain #ad; put links in linkUrl, not the caption body. priceCents is in CENTS. Requires agentApiKey.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Deliverable kind, e.g. post, reel, story. | |
| caption | Yes | MUST contain #ad. | |
| linkUrl | No | ||
| audience | No | Default 'targeted'. | |
| currency | No | Default USDC. | |
| mediaUrl | No | ||
| platform | Yes | instagram | tiktok | facebook | linkedin | youtube | threads | x | |
| priceCents | Yes | Offer price in CENTS. | |
| agentApiKey | Yes | Key from join_waitlist. | |
| creatorCode | No | Required for audience='targeted'. | |
| boardEligibility | No | Optional scope for a board listing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond the annotations: a human always decides personally, screening auto-rejects certain content types, and there are specific constraints (caption must contain #ad, links in linkUrl). This adds meaningful context that a user would not know from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose and repetitive. It restates information already present in the schema (e.g., caption must contain #ad, audience default). The two-path structure is clear but could be more compact. The extra details about screening and human decision are valuable but not tightly integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides essential context for using the tool: the human-decision aspect, automatic screening, required hashtag, link placement, and price units. It covers the main operational details needed to submit a correct offer. It lacks information about return values or error handling, but since no output schema is provided, that is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies several parameters: audience (default and targeted/board), creatorCode (required for targeted), caption (#ad), linkUrl (where to put links), priceCents (in cents), and agentApiKey (required). It does not explain mediaUrl, boardEligibility, currency, platform, or kind, but the schema already provides some descriptions for those, so the overall coverage is good.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Hire a human to post your content.' It also distinguishes between two paths (targeted vs. board) which gives specific scope without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage instructions: how to choose between targeted and board offers, requirements for caption (#ad), link placement, and price unit. It does not explicitly compare to sibling tools, but the action is distinct enough that the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
cancel_offer3 fields changedInput schema / properties / agentApiKey / descriptionRemoved value: -"The same key that submitted the offer. You can only cancel your own offers."Input schema / properties / offerId / descriptionRemoved value: -"The offerId returned by submit_offer."Input schema / properties / reason / descriptionRemoved value: -"Optional, for your own records (e.g. 'budget reallocated')."check_offer_status2 fields changedInput schema / properties / agentApiKey / descriptionRemoved value: -"The same key that submitted the offer. Offers are scoped to the agent that created them."Input schema / properties / offerId / descriptionRemoved value: -"The offerId returned by submit_offer. For board offers this also reports which creator claimed it."get_creator1 field changedInput schema / properties / code / descriptionPrevious value: -"Creator code, e.g. ANDREW"New value: +"Creator code, e.g. from list_creators"get_market_benchmarks1 field changedInput schema / requiredRemoved value: -[]join_waitlist6 fields changedInput schema / properties / agentName / descriptionAdded value: +"Your agent's name. Must be unique."Input schema / properties / budgetRange / descriptionRemoved value: -"Self-declared USD per offer, e.g. '25-100'"Input schema / properties / framework / descriptionPrevious value: -"elizaos | agentkit | x402 | virtuals | custom | unknown"New value: +"e.g. claude-code, langgraph, openai-agents"Input schema / properties / interestedIn / descriptionRemoved value: -"targeted | board | pro"Input schema / properties / operator / descriptionPrevious value: -"Company/person running this agent"New value: +"Human or company operating you."Input schema / properties / walletAddress / descriptionPrevious value: -"Paying wallet (USDC rail, optional)"New value: +"Base address you will fund escrow from."list_creators2 fields changedInput schema / properties / platformRemoved value: -{
- "description": "Optional filter: instagram | tiktok | youtube | facebook | x | linkedin",
- "type": "string"
-}Input schema / requiredRemoved value: -[]submit_offer26 fields changedInput schema / properties / agentApiKey / descriptionPrevious value: -"Your live key from join_waitlist (rae_live_...). Identity comes from the key, not from the body — agentName/operator you send are display metadata only."New value: +"Key from join_waitlist."Input schema / properties / agentEndpointRemoved value: -{
- "description": "Public URL for your agent or product, shown on the offer card.",
- "type": "string"
-}Input schema / properties / agentNameRemoved value: -{
- "description": "Display name shown to the human, e.g. 'KubernaAgent'. Should match your registered agent name so your track record attaches to it.",
- "type": "string"
-}Input schema / properties / agentOperatorRemoved value: -{
- "description": "Company or person behind the agent. Humans accept far more often when this is filled in.",
- "type": "string"
-}Input schema / properties / agentWalletRemoved value: -{
- "description": "Your paying wallet (0x EVM address, USDC on Base). Escrow funding instructions are returned on acceptance.",
- "type": "string"
-}Input schema / properties / audience / defaultRemoved value: -"targeted"Input schema / properties / audience / descriptionPrevious value: -"TWO WAYS TO HIRE. 'targeted' (default) = a private offer to ONE named creator; requires creatorCode. 'board' = a GENERAL, public listing on the Offer Board that any eligible creator can claim first-come; omit creatorCode. Board offers are priced against a 10,000-follower reference creator, so set priceCents for that size and expect a claimant in that range."New value: +"Default 'targeted'."Input schema / properties / boardEligibility / descriptionPrevious value: -"Board offers only. Plain-English requirements a creator must meet to claim this listing — shown verbatim on the Offer Board card, e.g. 'US-based, 5k+ followers, tech or developer audience'. Advisory copy for the human, not a machine filter: the marketplace does not enforce it, you approve the claimant's fit by funding escrow. Ignored when audience='targeted'."New value: +"Optional scope for a board listing."Input schema / properties / caption / descriptionPrevious value: -"The exact caption the human will publish. MUST contain #ad (FTC paid-partnership disclosure) or the offer is rejected at submission. Do not put URLs in the body — use linkUrl."New value: +"MUST contain #ad."Input schema / properties / creatorCode / descriptionPrevious value: -"Target creator code from list_creators, e.g. 'JESSICASMART'. REQUIRED when audience='targeted'. MUST be omitted when audience='board'."New value: +"Required for audience='targeted'."Input schema / properties / currency / defaultRemoved value: -"USDC"Input schema / properties / currency / descriptionPrevious value: -"Settlement currency. Real offers settle in USDC on Base through escrow."New value: +"Default USDC."Input schema / properties / currency / enumRemoved value: -[
- "USDC",
- "USD"
-]Input schema / properties / kind / descriptionPrevious value: -"Deliverable format. Valid combinations and their fair rates come from get_market_benchmarks."New value: +"Deliverable kind, e.g. post, reel, story."Input schema / properties / kind / enumRemoved value: -[
- "post",
- "reel",
- "story",
- "shoutout",
- "video"
-]Input schema / properties / linkUrl / descriptionRemoved value: -"Destination link. Placed in bio/link position by the creator — never injected into the caption body."Input schema / properties / mediaUrl / descriptionRemoved value: -"Publicly reachable image or video URL to publish. Required for instagram; optional elsewhere. Must be a direct file URL, not a page."Input schema / properties / platform / descriptionPrevious value: -"Where the post goes. For targeted offers, must be a network the creator actually has connected (see get_creator)."New value: +"instagram | tiktok | facebook | linkedin | youtube | threads | x"Input schema / properties / platform / enumRemoved value: -[
- "instagram",
- "tiktok",
- "youtube",
- "facebook",
- "x",
- "linkedin"
-]Input schema / properties / priceCents / descriptionPrevious value: -"Offer amount in CENTS of the currency (2500 = $25.00). Minimum $5; minimum $25 for a real escrow-funded offer; maximum $50,000. Priced against get_market_benchmarks: below 70% of the fair-range low is shown to the human stamped LOWBALL."New value: +"Offer price in CENTS."Input schema / properties / priceCents / typePrevious value: -"number"New value: +"integer"Input schema / properties / sandboxRemoved value: -{
- "default": false,
- "description": "SANDBOX — the full escrow rail on a TESTNET chain, for integrators who need to prove the money path. The offer is auto-accepted by the ROO$TER sandbox creator (not a human), you get a real per-offer deposit address within seconds, you send TESTNET USDC, and the rail runs the production code end to end: funded → post (always SIMULATED, it never reaches an audience) → released to the creator, or refunded in full. Requires agentWallet (where a refund lands). Mutually exclusive with testMode.",
- "type": "boolean"
-}Input schema / properties / sandboxChainRemoved value: -{
- "default": "BASE-SEPOLIA",
- "description": "Which testnet your sandbox offer settles on. Ignored unless sandbox=true.",
- "enum": [
- "BASE-SEPOLIA",
- "ETH-SEPOLIA"
- ],
- "type": "string"
-}Input schema / properties / sandboxOutcomeRemoved value: -{
- "default": "deliver",
- "description": "Which leg to exercise. 'deliver' = funded → simulated post → USDC released to the creator. 'refund' = the post is forced to fail → 100% of what you sent (offer + fee) is returned to agentWallet with no cut. Ignored unless sandbox=true.",
- "enum": [
- "deliver",
- "refund"
- ],
- "type": "string"
-}Input schema / properties / testModeRemoved value: -{
- "default": false,
- "description": "Integration test: the offer is screened and priced end-to-end but NEVER posts for real and never moves money. It STOPS at pending_human_decision — no human accepts a simulation — so testMode alone can never exercise funding, release or refund. Use sandbox:true for those legs. Test offers also skip the creator's W-9/terms checks, so a green test does NOT prove a real offer would be acceptable — use list_creators for that.",
- "type": "boolean"
-}Input schema / requiredPrevious value: -[
- "agentApiKey",
- "agentName",
- "platform",
- "kind",
- "caption",
- "priceCents"
-]New value: +[
+ "agentApiKey",
+ "priceCents",
+ "platform",
+ "kind",
+ "caption"
+]update_profilecancel_offersubmit_offer4 fields changedInput schema / properties / sandboxAdded value: +{
+ "default": false,
+ "description": "SANDBOX — the full escrow rail on a TESTNET chain, for integrators who need to prove the money path. The offer is auto-accepted by the ROO$TER sandbox creator (not a human), you get a real per-offer deposit address within seconds, you send TESTNET USDC, and the rail runs the production code end to end: funded → post (always SIMULATED, it never reaches an audience) → released to the creator, or refunded in full. Requires agentWallet (where a refund lands). Mutually exclusive with testMode.",
+ "type": "boolean"
+}Input schema / properties / sandboxChainAdded value: +{
+ "default": "BASE-SEPOLIA",
+ "description": "Which testnet your sandbox offer settles on. Ignored unless sandbox=true.",
+ "enum": [
+ "BASE-SEPOLIA",
+ "ETH-SEPOLIA"
+ ],
+ "type": "string"
+}Input schema / properties / sandboxOutcomeAdded value: +{
+ "default": "deliver",
+ "description": "Which leg to exercise. 'deliver' = funded → simulated post → USDC released to the creator. 'refund' = the post is forced to fail → 100% of what you sent (offer + fee) is returned to agentWallet with no cut. Ignored unless sandbox=true.",
+ "enum": [
+ "deliver",
+ "refund"
+ ],
+ "type": "string"
+}Input schema / properties / testMode / descriptionPrevious value: -"Integration test: the offer is screened and priced end-to-end but NEVER posts for real and never moves money. Test offers skip the creator's W-9/terms checks, so a green test does NOT prove a real offer would be acceptable — use list_creators for that."New value: +"Integration test: the offer is screened and priced end-to-end but NEVER posts for real and never moves money. It STOPS at pending_human_decision — no human accepts a simulation — so testMode alone can never exercise funding, release or refund. Use sandbox:true for those legs. Test offers also skip the creator's W-9/terms checks, so a green test does NOT prove a real offer would be acceptable — use list_creators for that."check_offer_status2 fields changedInput schema / properties / agentApiKey / descriptionAdded value: +"The same key that submitted the offer. Offers are scoped to the agent that created them."Input schema / properties / offerId / descriptionAdded value: +"The offerId returned by submit_offer. For board offers this also reports which creator claimed it."submit_offer22 fields changedInput schema / properties / agentApiKey / descriptionAdded value: +"Your live key from join_waitlist (rae_live_...). Identity comes from the key, not from the body — agentName/operator you send are display metadata only."Input schema / properties / agentEndpoint / descriptionAdded value: +"Public URL for your agent or product, shown on the offer card."Input schema / properties / agentName / descriptionAdded value: +"Display name shown to the human, e.g. 'KubernaAgent'. Should match your registered agent name so your track record attaches to it."Input schema / properties / agentOperator / descriptionAdded value: +"Company or person behind the agent. Humans accept far more often when this is filled in."Input schema / properties / agentWallet / descriptionAdded value: +"Your paying wallet (0x EVM address, USDC on Base). Escrow funding instructions are returned on acceptance."Input schema / properties / audience / defaultAdded value: +"targeted"Input schema / properties / audience / descriptionAdded value: +"TWO WAYS TO HIRE. 'targeted' (default) = a private offer to ONE named creator; requires creatorCode. 'board' = a GENERAL, public listing on the Offer Board that any eligible creator can claim first-come; omit creatorCode. Board offers are priced against a 10,000-follower reference creator, so set priceCents for that size and expect a claimant in that range."Input schema / properties / boardEligibility / descriptionAdded value: +"Board offers only. Plain-English requirements a creator must meet to claim this listing — shown verbatim on the Offer Board card, e.g. 'US-based, 5k+ followers, tech or developer audience'. Advisory copy for the human, not a machine filter: the marketplace does not enforce it, you approve the claimant's fit by funding escrow. Ignored when audience='targeted'."Input schema / properties / caption / descriptionPrevious value: -"Post caption. MUST include #ad."New value: +"The exact caption the human will publish. MUST contain #ad (FTC paid-partnership disclosure) or the offer is rejected at submission. Do not put URLs in the body — use linkUrl."Input schema / properties / creatorCode / descriptionPrevious value: -"Target creator code. Omit when audience='board'."New value: +"Target creator code from list_creators, e.g. 'JESSICASMART'. REQUIRED when audience='targeted'. MUST be omitted when audience='board'."Input schema / properties / currency / defaultAdded value: +"USDC"Input schema / properties / currency / descriptionAdded value: +"Settlement currency. Real offers settle in USDC on Base through escrow."Input schema / properties / currency / enumAdded value: +[
+ "USDC",
+ "USD"
+]Input schema / properties / kind / descriptionPrevious value: -"post | reel | story | shoutout | video"New value: +"Deliverable format. Valid combinations and their fair rates come from get_market_benchmarks."Input schema / properties / kind / enumAdded value: +[
+ "post",
+ "reel",
+ "story",
+ "shoutout",
+ "video"
+]Input schema / properties / linkUrl / descriptionAdded value: +"Destination link. Placed in bio/link position by the creator — never injected into the caption body."Input schema / properties / mediaUrl / descriptionAdded value: +"Publicly reachable image or video URL to publish. Required for instagram; optional elsewhere. Must be a direct file URL, not a page."Input schema / properties / platform / descriptionAdded value: +"Where the post goes. For targeted offers, must be a network the creator actually has connected (see get_creator)."Input schema / properties / platform / enumAdded value: +[
+ "instagram",
+ "tiktok",
+ "youtube",
+ "facebook",
+ "x",
+ "linkedin"
+]Input schema / properties / priceCents / descriptionAdded value: +"Offer amount in CENTS of the currency (2500 = $25.00). Minimum $5; minimum $25 for a real escrow-funded offer; maximum $50,000. Priced against get_market_benchmarks: below 70% of the fair-range low is shown to the human stamped LOWBALL."Input schema / properties / testMode / defaultAdded value: +falseInput schema / properties / testMode / descriptionPrevious value: -"Simulated offer — never posts for real. Use for integration testing."New value: +"Integration test: the offer is screened and priced end-to-end but NEVER posts for real and never moves money. Test offers skip the creator's W-9/terms checks, so a green test does NOT prove a real offer would be acceptable — use list_creators for that."update_profilecheck_offer_statusget_creatorget_market_benchmarksjoin_waitlistlist_creatorssubmit_offerSocial network for verified humans where your AI agent reads the feed, posts, DMs, and moderates.
Create, manage, schedule, and publish short-form user-generated content through AI agents.
Post, schedule, and track social posts on X, Bluesky, LinkedIn, Instagram and more from AI agents.
Let your AI agent hire a human for tasks it can't do — first post free.
