Power your agent
URL ของผู้เผยแพร่เอง ไม่ใช่เอนด์พอยต์ของ PlugMCP
Host a copy with our keys and logs.
https://app.tin.computer/mcpปุ่ม Claude ด้านบนจะเปิด Claude พร้อมกรอกชื่อและ URL ให้แล้ว คุณยังต้องยืนยันที่นั่นเอง
claude mcp add --transport http computer.tin-tin https://app.tin.computer/mcpRun in a terminal.
{ "mcpServers": { "computer.tin-tin": { "command": "npx", "args": [ "-y", "mcp-remote", "https://app.tin.computer/mcp" ] } }}claude_desktop_config.json
URL แบบรีโมตหรือคำสั่งบนเครื่องของคุณ? การติดตั้งสองแบบต่างกันอย่างไร
รันบน PlugMCP
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
เปิดจากผู้เผยแพร่
Open-source marketing system, designed for coding agents.
Why would you invent marketing from first principles when you can use a battle-tested marketing stack in 10 minutes?
Now with 60 workflows you can use right away, across organic search, content, social, outreach, product QA, paid ads and creative work.
Open-source marketing system, designed for coding agents.
The hosted dashboard, API and MCP service use app.tin.computer. Add the MCP connection from your project directory.
Claude Code:
claude mcp add --transport http tin https://app.tin.computer/mcp
Then open Claude Code and use /mcp to authenticate Tin.
Codex:
codex mcp add tin --url https://app.tin.computer/mcp
Complete the browser login when prompted. For an existing connection that needs authentication, use codex mcp login tin.
Cursor, in .cursor/mcp.json:
{ "mcpServers": { "tin": { "url": "https://app.tin.computer/mcp" } } }
Use Cursor's MCP controls to connect and complete authentication.
Start a new agent session if Tin's tools have not appeared. To check the connection, ask it to call list_projects. Your agent can also delete a project you created when you ask it to; it confirms the exact name first, and billing history stays. Then ask:
Use Tin to grow my project like a pro!
Connect Tin over MCP in Claude Code, Codex, or Cursor. Your agent can read your local repository, ask you about the business, and use Tin's onboarding workflow to prepare a plan.
It starts with practical questions: what are you trying to achieve, how much time and budget can you put into it, and what should it avoid? The plan uses that context alongside the workflows and integrations available to your project.
For example, the setup conversation might look like this:
› Use Tin to grow my project like a pro!
I'll read the repository first, then help you choose a starting plan.
If organic growth is the priority, we can audit the site, research
buyer questions, and turn the findings into a content plan.
Search Console can add evidence from your current search traffic.
GitHub lets Tin propose site changes as pull requests.
What would a useful result look like in the next sixty days,
and how much time can you spend reviewing work each week?
You choose the plan and allow the connections it needs. After approval, Tin creates the selected configurations and starts the initial work it can run. It reports what was set up and what is still blocked.
A good skill tells an agent how to do something. Running that skill every week adds other problems: which version should it use, where does its context come from, what happens after a failure, and who approves the result?
Tin handles those parts.
These are the main areas covered by the current catalog. Availability depends on the workflow's inputs, connected services, and operator settings. Some workflows run on demand; others can be saved with a schedule.
For work that does not fit a template, project.task gives you a separate Codex task with its own conversation and controls. It can ask questions, pause, and resume. Changes to project files require approval of the proposed diff.
A content plan's dates are editorial targets, not automatic publication times. You can start generation individually; the current organic traffic system can also continue from planning into the next eligible draft, review and delivery. Tin can report that an item is already covered or needs better evidence instead of forcing out another article. With GitHub connected, approved content follows the project's delivery setting: an unmerged PR, or a commit to main; otherwise its Markdown stays in project Files. This does not schedule six months of automatic drafting or publish a website.
The live Registry is the source for each workflow's inputs and requirements. docs/architecture.md explains how the main pieces fit together.
A repository says a lot about how a product works. It says less about why customers buy it, what they misunderstand, or how you want to sound. Add the material that fills those gaps: customer interviews, support questions, research, and examples of your own writing.
Your project can also hold SKILL.md files under .agents/skills/. Workflows load the skills they declare, such as a writing-style guide. Tin can help extract that guide from samples you select, and you can edit it directly. A skill in your local repository is not automatically available to a hosted run; your agent needs to save the relevant material to the Tin project.
Public articles and planned drafts support feedback in the reader or through MCP. Tell Tin what to change, compare the revision, and approve the version you want. Generation notes stay separate from public copy. With GitHub delivery configured, an approved article follows the project's delivery setting: an unmerged pull request, or a commit to main, where Tin merges its own pull request only when it adds nothing but the page and GitHub reports it clean. Technical fixes always wait for you to merge.
Connections belong to projects. A workflow uses specific operations from each integration, and Tin checks access before running them.
Provider tokens and keys stay on the switchboard, Tin's server. Sandbox tools receive the permitted data or access through a grant tied to the run. Product QA can use a separate Tin test identity to sign into the product it is testing.
For data from Google Docs and Drive, GA4, or other advertising platforms, add relevant exports to project files.
Start with ordinary Python when you know the steps. Add managed model calls where the work needs judgment; a workflow can have several of them, with code handling the sequence, branches and validation. Use a Codex procedure when an agent needs to explore and choose the steps itself.
All three can be contributed as public workflow packages:
workflow_packages/<workflow>/
├── workflow.json
└── main.py # Python, optionally calling managed models
A procedure package uses PROMPT.md and skills/ instead of main.py. The manifest declares
typed inputs, bounded outputs, integrations and review. Maintainers review contributions and
explicitly select packages for the Registry; catalog sync publishes each selected package as
one pinned version. Existing runs and saved configurations keep their selected version.
See Adding a workflow and the deterministic and two-model-step examples. Native code and model-backed workflows can also be contributed when the bounded package runtime isn't enough.
The bounded private-workflow pilot uses the same Python contract: typed inputs, isolated execution, optional managed model calls, project API connections, durable reports, and eligible daily or weekly schedules. Your coding agent authors and tests the package; Tin runs it independently. Code-only bounded compute needs no model credentials or Tin credits. Hosted model calls use Tin credits; connected API usage belongs to that provider account.
See code workflows, managed model steps, and secure project API connections for examples, exact limits, setup, and verification. Private code schedules reuse saved workflow scheduling; paid occurrences need standing spending authority.
Private workflows live in a project's files and still require operator enablement. A coding agent writes a package, validates it, and explicitly activates it through MCP. Code workflows produce a bounded text artifact. Private Codex procedures can produce a project artifact or an unmerged GitHub PR, but remain on demand. Direct SDK credentials in author code and general one-command skill imports are not supported. See feature status for the supported-versus-experimental boundaries.
Public or private determines who can use a workflow, not whether it runs code or an agent.
Claw Messenger gives AI agents an iMessage number. The original Tin agent worked on its growth from March to July 2026. This predates the workflow engine in this repository; that experience shaped its workflows.
The reported figures come from Claw's Stripe and PostHog data, filtered to Claw plans. The work included pages answering buyer questions, site fixes, outreach, and weekly reviews. These are historical results from the earlier system, not a benchmark or a promise of results from this repository.
Tin's server coordinates the work. Temporal keeps runs alive across failures and waits. Files hold the results, and Postgres holds the state the product reads.
The web app is the interface you open in your browser. The separate browser inside E2B is controlled by the agent. Arrows show calls and work dispatch; sandbox results return to Tin's server for validation and storage.
auth.json. Provider keys and integration credentials stay on the switchboard; a sandbox is not given your GitHub or Google token.A typical artifact-producing run looks like this. Its workflow determines whether review or external delivery is part of the job:
The switchboard checks the active run's lease and the repository's expectedHeadSha before making a commit. For procedure outputs, a conflicting destination edit preserves the new result for you to resolve. Completed-step receipts let a retry reuse work that is already done.
That is the foundation: files and recorded results carry forward, while the process that produced them can be replaced. docs/architecture.md goes into more detail; AGENTS.md records the implementation boundaries and acceptance checks.
You host Tin's server on your infrastructure and connect it to Temporal Cloud, E2B, code.storage, Clerk, and Postgres through accounts you control. You pay infrastructure and model providers directly; Stripe is optional.
This is currently an engineering setup path, not a verified turnkey installer. A clean-clone
acceptance run and usable .env.example are still outstanding; see self-hosting limits.
You need Python 3.12 and uv. Clone and install:
git clone https://github.com/tin-computer/tin.git
cd tin
uv sync
Configure the database and migration roles, Temporal namespace, storage, Clerk, E2B, and model access in a local .env. The service settings and identity and integrations guide list the configuration. Keep credentials out of git.
Then apply migrations, publish the catalog, build the sandbox templates your workflows require, and start the service. It starts the Temporal worker as well:
uv run tin-lite migrate
uv run tin-lite sync-builtins
uv run python sandbox/template.py
uv run tin-lite serve
Customer billing is optional when self-hosting. With TIN_LITE_BILLING_ENABLED=false, you pay your own infrastructure and provider costs without needing Stripe or a Tin credit balance.
Self-hosted UI and portable diagrams use bundled open-source Geist fonts. Hosted Tin's licensed brand font is served separately; see font configuration and source-distribution notes.
The engineering reference covers service configuration, local checks, and deployment.
The direction is broader coverage with less setup, while keeping the work inspectable.
Tin is licensed under the Apache License 2.0. This repository contains the service and built-in workflows, including the instructions you need to inspect or change them. Third-party components retain their own licenses; see third-party notices.
See CONTRIBUTING.md for development checks and pull requests, SECURITY.md for private vulnerability reporting, and feature status and release readiness for current limits and outstanding release gates. The documentation index groups contributor and self-hosting guides.
Made by Ege Özgirin, who built AI agents at Oda and then Keke, his autonomous AI artist, and Emre Şarbak, who helped build LaunchCode, Kodluyoruz, Patika, Rise In, and SuperSense.
We have spent a lot of time building agents that can do useful work. Tin is about making that work easier to organize, repeat, and improve. We run the hosted version at app.tin.computer, and the same code is here for people who want to operate it themselves.
Also from us: with.md, Personality Machine, and Personaplex fine-tuning.
{ "mcpServers": { "computer.tin-tin": { "url": "https://app.tin.computer/mcp", "headers": {} } }}เครื่องมือ
ยังไม่มีรายการเครื่องมือ เซิร์ฟเวอร์แบบรีโมตจะได้รายการหลังการตรวจสอบสถานะครั้งแรก
FAQ
คัดลอกคอนฟิก http สำหรับ Cursor, Claude Desktop, Claude Code หรือ VS Code ได้ในหน้านี้ คอนฟิกนี้ใช้การติดตั้งของผู้เผยแพร่ ไม่ใช่พร็อกซีของ PlugMCP
ระเบียนนี้ไม่ได้ระบุตัวแปรสภาพแวดล้อมที่จำเป็น
Tin เข้าถึงได้ผ่าน HTTP
ตรวจสอบล่าสุดเมื่อ 2026-11-08 Open-source marketing system, designed for coding agents.