Creator Sponsor MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HOST | No | HTTP bind host. | 127.0.0.1 |
| PORT | No | HTTP bind port. | 3000 |
| MCP_AUTH_TOKEN | No | HTTP only: require `Authorization: Bearer <token>`. | |
| X_BEARER_TOKEN | No | Optional. An X API v2 app-only bearer token (read-only: user lookup, user posts, post lookup). If unset, the server makes no network calls and you use manual input. | |
| CREATOR_SPONSOR_PATH | No | Data file. Must end in .json. Created on the first confirmed write with mode 0600. | ~/.creator-sponsor/data.json |
| CREATOR_SPONSOR_FIXTURES | No | Optional. A local JSON file of demo users and posts, used instead of the API when there's no token. `fixtures/demo.json` ships with the repo. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| data_source_statusA | Which X data source is active (x_api when X_BEARER_TOKEN is set, fixture, or none = manual input only), the data file path, and pricing assumptions. Never reveals the token. |
| analyze_creatorA | Builds a structured sponsor profile for an X creator: niches, audience, content style, engagement metrics (avg likes/reposts/replies, engagement rate) and an estimated price-per-post range with the exact formula and assumptions. Source: X API (needs X_BEARER_TOKEN) or |
| list_creatorsC | Saved creator profiles with niches, followers, engagement rate and price range. Optional niche filter. |
| get_creatorB | Full saved creator profile and analysis, plus their deals. |
| match_creatorsA | Ranks saved creators for a product brief by niche fit, audience fit and budget fit, with per-component scores, reasons and a suggested offer. Deterministic and explainable. Saves nothing. |
| list_dealsC | Deals with status, filterable by status or creator. |
| get_dealB | Full deal: requirement, status history, verification checks and payout record. |
| list_payout_providersB | Payout providers and whether they are available. This server never moves money. |
| list_payoutsB | All recorded payouts with totals per currency. |
| save_creator_profileA | Analyses a creator (X API or |
| delete_creatorA | Permanently removes a saved creator. Refused while they have open deals (offered, accepted or verified-but-unpaid). TWO-STEP: the first call (no confirm_token) only returns a preview and a confirm_token; nothing is written. Show the preview to the user, and only after they approve call again with the same arguments plus confirm_token. |
| create_offerA | Brand creates an offer to a saved creator: amount, product, post requirements (phrases, link) and required disclosure markers. Starts in status |
| respond_to_offerA | Records the creator's decision on an |
| cancel_dealA | Cancels an |
| verify_deal_postA | Fetches the creator's post (URL or id) from X and checks author, required phrases/link, disclosure, and that it was posted after acceptance. The preview shows every check; it can only be confirmed if all pass, which marks the deal |
| record_payoutA | Records that a verified deal was paid, via a payout provider. Default provider |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 16 tools
Most tools target clearly distinct resources and actions (creators, deals, payouts). The one overlap is analyze_creator vs save_creator_profile, which both analyze a creator; the descriptions explicitly clarify that analyze saves nothing and directs users to save_creator_profile, which mitigates the risk.
Almost every tool follows a clean verb_noun snake_case pattern (list_creators, create_offer, verify_deal_post, record_payout). The only deviation is data_source_status, a noun-phrase status tool, which is a minor inconsistency rather than a broken convention.
16 tools is at the upper edge of comfortable scope but justified by the domain, which spans creators, deals, verification, and payouts. Each tool earns its place with a distinct lifecycle role, though it leans slightly heavy.
The surface covers the full lifecycle: creator discovery/analysis/saving/deletion, offer creation and response, verification, cancellation, and payout recording/listing. Minor gaps like a generic deal-update or edit-offer operation exist but core workflows have no dead ends.