Server data from the Official MCP Registry
Unofficial CLI and MCP server for the Toptal Talent platform — personal-productivity tool
Unofficial CLI and MCP server for the Toptal Talent platform — personal-productivity tool
Valid MCP server (1 strong, 1 medium validity signals). No known CVEs in dependencies. ⚠️ Package registry links to a different repository than scanned source. Imported from the Official MCP Registry. 1 finding(s) downgraded by scanner intelligence.
7 files analyzed · 1 issue found
Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.
Set these up before or after installing:
Add this to your MCP configuration file:
{
"mcpServers": {
"io-github-alexey-pelykh-ttctl": {
"args": [
"-y",
"ttctl"
],
"command": "npx"
}
}
}From the project's GitHub README.
Personal-productivity CLI and MCP server for your own Toptal Talent profile.
TTCtl is NOT affiliated with, endorsed by, or supported by Toptal LLC. It is a personal-productivity tool that interacts with Toptal Talent's web/mobile interfaces using your own session, exclusively for your own profile's data.
This tool is built for fair use and shared in case it's useful to other Toptal talents who want similar tooling for their own profiles. It is NOT to be used for:
If you encounter misuse of TTCtl, please see Abuse reporting in SECURITY.md.
Architectural friction in the codebase (sequential rate limits, single-credential design, no batch parallelism on automation-prone endpoints) is intentional. Don't remove it.
"Toptal" is a trademark of Toptal LLC. The name appears in this project's description as nominative fair use only — TTCtl is not a Toptal brand.
TTCtl gives you (and your AI assistants, via MCP) programmatic access to your own Toptal Talent profile:
applications stats; confirm / reject open Interest Requests via applications confirm / applications reject; fetch interview detail (interviewer with TopChat thread handle, client-side contact, scheduled slot, agenda link, prep-guide ref) via applications interview show <id>; read your interview prep notes via applications interview notes show <jobId>; fetch availability-request detail (status, kind, recruiter Fixed rate, comment, lifecycle timestamps, job) via applications availability-request show <id>engagements statsjobs recommended feed, the per-job jobs match-quality match-score breakdown, and the per-job jobs rate-insight rate-intelligence panel); manage saved / viewed / not-interested signals; configure search subscription; direct-apply via jobs apply <id> --consent (legal-compliance gate is mandatory). Add --suggest-answers to fetch your own historical answers to similar prior questions as advisory autocomplete suggestions (opt-in, off the critical apply path; failures degrade gracefully). The MCP tool ttctl_jobs_apply_similar_answers exposes the same surface to agents.payments summary), and payment methods; show current hourly rate via payments rate current (lightweight) or the unified payments rate show projection; submit rate-change requestsSurfaces are gated to read-heavy / personal use. Operations that would enable mass automation against the platform are deliberately not exposed.
The following Toptal Talent surfaces are out of scope by design — they enable abuse (mass-automation or spam vectors), require third-party SDKs TTCtl doesn't depend on, target client-onboarding rather than the talent-side workflow, belong to staff- or sourcing-side workflows, or are one-time / mobile-only UI affordances with no recurring CLI value:
UpdateJobAlertSettings, UpdateSmsNotificationsSettings, UpdateTimesheetReminderSettings, UpdateNotificationSetting (abuse-prevention — silencing alerts is a precursor to other abuse)applications interview show (full surface tracked in #23)SEND_CONTRACTS, testimonial publishing, snapshot history (staff-side — Toptal-staff surfaces, not talent-side)CreateTalentSignal, GetTalentSignalSetup (sourcing-side — recruiter / staff identifying talent, not talent-side)Note: The
scheduler.toptal.comsurface (interview scheduling) is currently absent rather than out by design — deferred until reverse-engineering research closes.
See What It Does above for the positive scope.
op) for credential resolutionTTCtl uses node-wreq for Chrome
TLS-fingerprint impersonation on the Cloudflare-protected surfaces (profile
editing). That transport ships as a prebuilt native binary, available for:
| OS | Architecture | libc | Supported |
|---|---|---|---|
| macOS | x64 (Intel) | — | ✅ |
| macOS | arm64 (Apple Silicon) | — | ✅ |
| Linux | x64 | glibc | ✅ |
| Linux | x64 | musl (Alpine) | ✅ |
| Linux | arm64 | glibc | ✅ |
| Linux | arm64 | musl (Alpine) | ❌ not yet |
| Windows | x64 | — | ✅ |
| Windows | arm64 (Windows on ARM) | — | ❌ not yet |
On an unsupported platform, npm install -g ttctl still succeeds (the
native binary is an optional dependency) and mobile-gateway commands keep
working — but any Cloudflare-protected command (anything that edits your
profile) fails with a clear NATIVE_MODULE_UNAVAILABLE error naming your
platform and this supported set. If you need one of the two not-yet-supported
targets, please open an issue.
npm install -g ttctl
Or run directly with npx:
npx ttctl --help
For maximum supply-chain safety, install with postinstall hooks disabled:
npm install -g --ignore-scripts ttctl
--ignore-scripts blocks preinstall / postinstall / prepare hooks
across the entire dependency tree at install time. This prevents a
compromised transitive dep (PhantomRaven, Shai-Hulud, etc.) from
executing code on your machine during install — closing the
most-exploited supply-chain attack vector against package-manager users.
TTCtl itself ships no install-time hooks. Disabling them is purely a defense against malicious behavior in dependencies you don't directly control. See SECURITY § User-install supply-chain hardening.
# 1. Install
npm install -g ttctl
# 2. Bootstrap a config interactively (recommended)
# Walks you through Form A (1Password reference; vault + item picker
# when the `op` CLI is installed) or Form B (literal credentials,
# explicit warning). Output: ~/.ttctl.yaml at mode 0600.
ttctl auth init
# 3. Sign in (captures the bearer back into ~/.ttctl.yaml under auth.token)
ttctl auth signin
# 4. Verify
ttctl auth status
# 5. View your profile
ttctl profile show
ttctl auth initscaffolds a fresh~/.ttctl.yamlinteractively. Choose Form A (1Password reference, recommended) or Form B (literal credentials, discouraged — guarded by an explicit warning). On Form A with theopCLI installed, a vault picker and a LOGIN-category item picker run. Withoutopor on JSON-shape failure, the prompt falls back to a freeformop://VAULT/ITEMreference. The output file is written atomically at mode0600and refuses to overwrite an existing file unless--forceis passed. The command is interactive only — pipe stdin or a non-TTY context exits non-zero with a clear message.
ttctl auth signinruns theEmailPasswordSignInGraphQL mutation, captures the session bearer, and writes it BACK into the same~/.ttctl.yamlfile underauth.token(atomic write; comments preserved; mode0600). All subsequent commands replay it asAuthorization: Token token=<X>on every GraphQL request. TheopCLI is invoked only at signin time to resolve your credentials. There is no separate token file — your config and your live session live in one YAML.
Hand-authoring the config also works (drop a YAML file at
~/.ttctl.yaml,chmod 600); see the Configuration section below for the four validauthshapes.ttctl auth initis the recommended starting point.
TTCtl uses a single config file — no profiles. The config-file path is resolved deterministically (highest precedence wins):
--config <path> flag — explicit override (per-invocation).TTCTL_CONFIG_FILE env var — process-scoped (CI, direnv).~/.ttctl.yaml — POSIX home dotfile (only fallback).XDG paths ($XDG_CONFIG_HOME/ttctl/config.yaml, ~/.config/ttctl/config.yaml) and the current-working-directory ./.ttctl.yaml are not auto-discovered. To use a project-local config, point TTCTL_CONFIG_FILE at it via direnv:
# .envrc in your project root (requires `direnv` installed and `direnv allow` run)
export TTCTL_CONFIG_FILE="$PWD/.ttctl.yaml"
TTCtl refuses to persist the captured bearer when the config file lives under a known cloud-sync prefix:
| Path prefix | Service |
|---|---|
~/Library/Mobile Documents/ | macOS iCloud Drive |
~/Dropbox/ | Dropbox |
~/iCloud Drive/ | iCloud (alt name) |
~/OneDrive/ | OneDrive |
~/Google Drive/ | Google Drive |
~/Box/, ~/Box Sync/ | Box |
Persisting a bearer under any of these would silently replicate it off-host. If you need a project-local config, keep it OUTSIDE these directories and route via TTCTL_CONFIG_FILE (direnv recipe above). The sibling-name guard prevents false positives — ~/DropboxOther/ is fine.
auth — four valid lifecycle statesThe auth block is structured with optional credentials and token fields. Four valid shapes correspond to the lifecycle states:
auth.token)# Single 1Password account (or relying on `OP_ACCOUNT` env / op default)
auth:
credentials: "op://Personal/ttctl"
# Multiple 1Password accounts — pin one explicitly
auth:
credentials: "op://my-account/Personal/ttctl"
TTCtl parses op://[ACCOUNT/]VAULT/ITEM and runs op item get ITEM --vault VAULT [--account ACCOUNT] --format json, then resolves credentials by matching fields with purpose: USERNAME and purpose: PASSWORD — the canonical semantic identifiers 1Password sets automatically for LOGIN-category items (including browser-autosaved logins where the field labels are the HTML form input names like user[email]).
The optional ACCOUNT segment is required only when you have multiple op accounts configured (op account list); single-account setups can omit it. ACCOUNT may be the account UUID, the shorthand set via op account add, or the sign-in email — TTCtl forwards the value verbatim to op for validation.
auth:
credentials:
username: "you@example.com" # value is your Toptal email; field name matches 1P USERNAME purpose
password: "hunter2"
Discouraged for daily use. Plaintext credentials in config files leak through backups, sync clients, and accidental commits. Form A is what you want.
Per-field references (4+ segments, e.g.
op://Personal/ttctl/Section/username) are NOT supported. The schema rejects them. Use Form A (item-level reference) — TTCtl always reads both USERNAME and PASSWORD fields from a single LOGIN item.
auth:
token: "user_<24hex>_<20alnum>"
The bearer is supplied directly. ttctl auth signin is not applicable (refused with NO_CREDENTIALS). Useful for the E2E sandbox and for deployments that bootstrap a token via a side-channel.
auth:
credentials: "op://Personal/ttctl"
token: "user_<24hex>_<20alnum>"
The on-disk shape after a successful ttctl auth signin against a Form A or B config. Both fields coexist; signout removes the token field (returning to Form A or B) without touching credentials.
TTCtl exposes the wire's actual pagination model per service. The Toptal Talent platform uses multiple coexisting pagination idioms — there is no single uniform shape — and the wire rejects requests that mix idioms (PR #383 empirically proved this: an attempt to add offset to a limit-only field was rejected with HTTP 400 across 8 E2E test failures).
Rather than invent a uniform translation layer that would lie about what the wire accepts, ttctl flags name what the wire arg names; their types match what the wire arg accepts. This keeps AI / script callers honest: a flag name maps 1:1 to a wire argument (with one documented translation — see row 2).
| Service | CLI flags | MCP keys | Wire idiom |
|---|---|---|---|
jobs list, applications list, engagements list | --page / --per-page | {page, perPage} | Offset-list (page, pageSize) |
payments payouts list | --page / --per-page (translated) | {page, perPage} (translated) | Offset-pagination wrapper (offsetPagination: {offset, limit}) |
timesheet pending (post-#374 re-spike) | --limit | {limit} | Limit-only wrapper (pagination: {limit}) |
| (future engagements-payments) | --limit + --after <id> | {limit, after} | Limit+forward-cursor wrapper (pagination: {limit, after}) |
| (future performed-actions) | --before / --after / --limit | {before, after, limit} | Bare bidirectional cursor (before, after, limit) |
Heterogeneity is the deliberate Sage move: a uniform --cursor <token> layer would forfeit scriptability for offset services (no integer-composable pages); verb decomposition (show-all vs list) would double the command tree without buying disambiguation the flag types already provide. Per-service --help is the canonical recovery surface for the specific flag shape.
The 5-row grammar is locked in ADR-007 — Pagination flag grammar.
TTCtl can apply to a job opportunity directly via ttctl jobs apply <job-id>. This is a destructive wire operation — it creates a JobApplication record on Toptal's side and there is no withdraw operation in TTCtl (see ADR-008 § What We're NOT Solving). Prefer --dry-run to preview the wire payload first.
--consent is required — it represents your explicit acceptance of Toptal's apply terms (a legal-compliance attestation). The flag has no default; auto-filling on your behalf is forbidden per ADR-008 § Decision Part 4. Absence raises CONSENT_REQUIRED with no wire call issued.
ttctl jobs apply <job-id> --consent
Most jobs require answering matcher / expertise questions before the apply mutation accepts the request. --show-questions fetches the inventory WITHOUT issuing the apply mutation (read-only path; does not require --consent):
ttctl jobs apply <job-id> --show-questions
The output lists each question's identifier, prompt text, and the pre-apply context (canApply, suggestedRate, rateValidation). Per the recovered SDL (#438), the identifier maps differently across the two answer arrays: matcher answers use it as id; expertise answers use it as questionId (see the JSON shape below). ttctl jobs show <job-id> --with-questions is a related read that inlines the same question inventory into the job's full detail view.
--answers-filePass a JSON file containing per-question answers. The file shape follows the ADR-008 § Decision Part 2 grammar (the same shape applications confirm uses for Interest Requests). Matcher answers and expertise answers use different key shapes per the recovered SDL (#438): matcher answers carry the question identifier at id; expertise answers carry it at questionId and also accept other / subjectId (both nullable):
{
"matcherAnswers": [
{ "id": "<matcher-question-id>", "answer": "<your-answer>" },
{ "id": "<matcher-question-id>", "answer": "<your-answer>" }
],
"expertiseAnswers": [
{ "questionId": "<expertise-question-id>", "other": null, "subjectId": null },
{ "questionId": "<expertise-question-id>", "other": "free-text-context", "subjectId": "<subject-id>" }
]
}
Then:
ttctl jobs apply <job-id> --consent --answers-file ./apply.json
Pass - instead of a path to read the JSON from stdin. The wrapper shape AND inner items are validated against the recovered Zod schemas (per #438) BEFORE any wire call — malformed JSON or an unknown key refuses with a VALIDATION_ERROR envelope and no mutation is issued.
--pitch-file <path> (or - for stdin) attaches a PitchInput payload alongside the answers; only one flag may claim stdin per invocation.
--dry-run emits the full apply preview envelope (operation name, surface, transport, GraphQL variables) without issuing the wire mutation. Use it to verify the payload shape before committing to the destructive call:
ttctl jobs apply <job-id> --consent --dry-run
The --consent gate still applies under --dry-run — the legal-compliance attestation is required even for previews (the gate is a CLI-level refusal, not a wire-level one).
When a recruiter expresses interest in your profile via Toptal's Availability Request (AR) flow, you respond via applications confirm / applications reject. Confirming an AR is destructive — it transitions the AR to AVAILABILITY_REQUEST_CONFIRMED and creates a JobApplication. There is no withdraw operation; prefer --dry-run to preview the wire payload first.
The <id> argument is the AvailabilityRequest id, NOT the activity-item id. Discover it by inspecting the activity row:
ttctl applications show <activityId>
…and look for the Availability request: <id> line in the output.
ttctl applications confirm <ar-id>
When both --rate and --kind are omitted, the service pre-fetches the AR metadata and auto-fills:
kind from metadata.__typenamerate from metadata.offeredHourlyRate (Fixed-kind only)Flexible-kind ARs have no recruiter-pinned rate; callers MUST pass --rate <decimal> for FLEXIBLE / MARKETPLACE_FLEXIBLE ARs.
--answers-file / --pitch-fileWhen the AR carries matcher / expertise questions or a pitch prompt, supply answers via the same JSON-file grammar as jobs apply:
ttctl applications confirm <ar-id> \
--answers-file ./answers.json \
--pitch-file ./pitch.json
Both flags accept - to read from stdin (at most one stdin claim per invocation). The answers file shape is identical to the one shown in Applying to jobs above. Pitch payloads are validated against the recovered PitchInput Zod schema (per #438); extra unknown keys reject with a field-path error.
ttctl applications reject <ar-id> --reason <key>
The <key> comes from the server-localised inventory at ttctl applications reject-reasons. Some keys require an accompanying --comment <text> — the reject-reasons inventory marks which.
TTCtl implements the Model Context Protocol (MCP) so AI assistants can interact with your Toptal Talent profile through natural language. Run ttctl mcp to start an MCP server on stdio.
Add to claude_desktop_config.json:
{
"mcpServers": {
"ttctl": {
"command": "npx",
"args": ["ttctl", "mcp"]
}
}
}
claude mcp add ttctl -- npx ttctl mcp
Add to .cursor/mcp.json in your project root:
{
"mcpServers": {
"ttctl": {
"command": "npx",
"args": ["ttctl", "mcp"]
}
}
}
Trust model: any process that can spawn
ttctl mcpgets full access to your Toptal Talent profile through your saved auth token. Don't grant MCP access to untrusted AI agents. See SECURITY.md.
When an AI assistant calls a TTCtl MCP tool, the tool's response payload — your profile, your engagements, your payouts, your contracts — enters the assistant's context window. From that point, your AI-assistant host decides what happens to that data: whether it's persisted to chat history, indexed into a vector database, surfaced to other tools loaded in the same session, or uploaded as part of telemetry.
TTCtl cannot pin host behaviour. The defenses live in your operator choices. Three concrete recommendations:
dryRun gate. The mitigation is session-level — keep TTCtl in sessions where the loaded tools are operator-trusted.The full threat model — including the per-tool audit, severity rubric, mitigation trade-off analysis, and residual risk register — is in docs/security/mcp-leakage-threat-model.md. The companion section in SECURITY.md § MCP Trust Model covers the input-side defenses (state-change mitigation via dryRun, file-upload sandbox).
auth signin / auth signoutWhen the post-signin write-back to ~/.ttctl.yaml does something unexpected — silent overwrite, mtime-drift refusal, lock contention, mysterious "Refusing to write" message — turn on the structured debug log to see exactly which invariant fired and what the file's state was at each step:
TTCTL_DEBUG_CONFIG=1 ttctl auth signin
Output is one JSON object per line on stderr (so -o json mode on stdout stays clean). The bearer token is never logged. Pipe through jq to inspect:
TTCTL_DEBUG_CONFIG=1 ttctl auth signin 2> debug.log
jq -c '.' debug.log
Each record carries ts (ISO-8601), op (persist or clear), path, and event. Event-specific fields tell you what happened:
| Event | Meaning | Useful fields |
|---|---|---|
prewrite_checks | Symlink/sync-root gates passed | symlink_ok, syncroot_ok, perm_ok |
lock_acquired | Got the cross-process write lock | wait_ms (was there contention?) |
stat_baseline | Captured pre-write file state | mtime_ms, mode_octal |
tempfile_written | Temp file flushed to disk | temp_path, size_bytes |
final_state | Mode applied to temp before rename | mode_applied |
mtime_drift_check | Concurrency re-check vs baseline | delta_ms, pass (false ⇒ another writer raced you) |
rename_completed | Atomic rename to canonical path | — |
lock_released | Lock released in finally | duration_ms (total hold) |
error | Something threw inside the locked region | error_class, error_message, lock_held_at_error |
If you ever see an error event without a following lock_released, that would be a leaked lock — file an issue. The error path always emits lock_released (the release lives in the finally, runs regardless of which invariant fired).
When TTCTL_DEBUG_CONFIG is unset (or set to anything other than literal 1 — 0, true, empty string all count as "off"), the logger is silent and pays zero per-call overhead.
TTCtl is reverse-engineered from Toptal's APK; the wire format can change without notice. As a defense-in-depth signal, the CLI fetches a small JSON manifest at startup from https://raw.githubusercontent.com/alexey-pelykh/ttctl/main/status/known-broken.json and emits a warning (or refuses to run) when the running version is listed as known-broken. The MCP server does the same at buildServer time, plus a recurring ~24h refetch — but always warns, never refuses (refusing a long-lived server interrupts in-flight tool calls).
Latency cost: synchronous fetch with a 3 s timeout. Typical latency 50–200 ms against raw.githubusercontent.com; worst-case 3 s before the action runs.
Privacy: the fetch sends only the default Node fetch headers — no version, no account identifier, no telemetry. Install-count tracking is intentionally deferred.
Fail-silent: every error path (network, timeout, 404, malformed manifest) is swallowed. The kill-switch can NEVER itself cause a denial-of-service when the maintainer's repo is briefly unreachable.
Override — disable the check entirely with:
export TTCTL_DISABLE_KILL_SWITCH=1
Captured at module load (matches the TTCTL_DEBUG_CONFIG / TTCTL_DEBUG_MCP / TTCTL_MCP_FILE_UPLOAD_ALLOW_ANY conventions). Any other value (empty string, 0, true) keeps the check enabled.
The detection sources, severity tiers, response cadence, and C&D / legal posture are documented in docs/operations/wire-breakage-runbook.md. The manifest schema and update procedure live in status/README.md.
The Toptal Talent platform exposes three GraphQL endpoints:
https://www.toptal.com/gateway/graphql/talent/graphql — used by the mobile app; accepts plain HTTPS + session cookieshttps://www.toptal.com/api/talent_profile/graphql — used by the web profile editor; Cloudflare-protected (requires browser TLS fingerprint impersonation)https://scheduler.toptal.com/api/graphql — used by the scheduler; separate Cloudflare zoneTTCtl uses two transports:
undici) for the mobile gateway endpointnode-wreq with the chrome_147 profile) for the Cloudflare-protected endpointsAuthentication is bearer-token based (per ADR-005 in the private ttctl/research repo): TTCtl POSTs EmailPasswordSignIn in persisted-query mode (SHA-256 hash from a captured operations catalog), captures the returned session token, persists it back into the same ~/.ttctl.yaml config under auth.token (atomic write, mode 0600), and replays it as Authorization: Token token=<X> on every subsequent GraphQL request. Cookies are NOT used; Chrome TLS impersonation alone passes Cloudflare on the protected surfaces.
The reverse-engineering artifacts (APK decoded, GraphQL operations catalog, schema synthesis, ADRs) live in a separate private repository (ttctl/research). They are not redistributable.
TTCtl is an independent personal-productivity project not affiliated with, endorsed by, or officially connected to Toptal, Toptal LLC, or any Toptal entity.
This software is provided to you, the Toptal talent, as a tool for managing your own profile data more efficiently. Using it to interact with profiles other than your own, to scale outreach beyond what a human can do manually, to manipulate platform-side metrics, or to extract data about other parties violates the spirit of fair use and Toptal's Terms of Service.
The maintainer disclaims any warranty and accepts no liability for use that violates platform terms. If Toptal LLC objects to TTCtl's existence and reaches out in good faith, the maintainer will work with them to address the concern.
"Toptal" is a trademark of Toptal LLC. Use of the name in this project's description is nominative fair use only — to identify the third-party platform that TTCtl interacts with.
For a longer write-up of the project's posture on trademark use, Terms of Service, the AGPL choice, and the fair-use tradition this kind of tool sits in, see docs/legitimacy.md.
TTCtl is reverse-engineered from Toptal's APK; the wire format can change without notice, and the maintainer's only signal that something has shifted is your report. There is no telemetry, no error-reporting endpoint, no install-count tracking — the channels below are the entire return path.
ttctl <command> failingIf a TTCtl command errors or returns an unexpected response (404, cryptic GraphQL error, WIRE_SHAPE_ERROR envelope, etc.), open a Wire broke for me issue. The template captures ttctl --version, the failing command, the error text, and whether ttctl auth status still succeeds — enough for the maintainer to triage against the kill-switch manifest at status/known-broken.json and the wire-breakage runbook.
Before filing, check the kill-switch manifest at https://raw.githubusercontent.com/alexey-pelykh/ttctl/main/status/known-broken.json — if your version is listed, the maintainer is already aware.
If an MCP host (Claude Desktop, Claude Code, Cursor, Windsurf, etc.) could not surface or invoke a TTCtl tool — the failure is at the host ↔ server boundary, not the Toptal wire — open an MCP host failed to invoke a tool issue. The template captures host product + version, the failing tool name, the host's surfacing of the error, and the optional TTCTL_DEBUG_MCP=1 server-side trace.
Use Discussions for questions, usage help, ideas, or "did anyone else see this?" — the issue tracker is reserved for confirmed breakages and feature requests.
Do not open a public issue for security vulnerabilities. See SECURITY.md § Reporting a Vulnerability for the coordinated-disclosure channel.
See SECURITY.md § Abuse reporting if you've observed TTCtl being used in ways that violate Toptal's Terms of Service (mass automation, recruiter scraping, engagement-signal manipulation, etc.).
~/.ttctl.yaml carries your captured bearer token (auth.token, shape user_<24hex>_<20alnum>). Never paste it in a public issue or Discussions thread. TTCtl's debug emitters (TTCTL_DEBUG_CONFIG, TTCTL_DEBUG_MCP) are designed to never print bearer values, but transcripts from your shell may include them — scan before pasting and redact as <REDACTED>.
This project adopts the Contributor Covenant Code of Conduct (version 3.0). The Code applies to all project spaces and to anyone interacting with the project — issue tracker, pull requests, MCP server interactions, and any other channel.
To report a concern, email alexey.pelykh@gmail.com. Pseudonymous reports are accepted; truly anonymous reports are not feasible (the maintainer reads the inbox directly). Best-effort response within 7 days.
ttctl as a CLI tool or MCP server does not make your code AGPL-licensed. Running the tool, scripting around it, or connecting it to your applications is normal use — no license obligations arise.@ttctl/core as a library (importing it into your code) means your combined work is covered by AGPL-3.0. If you distribute that combined work, you must make its source available under AGPL-compatible terms.Be the first to review this server!
by Modelcontextprotocol · Developer Tools
Web content fetching and conversion for efficient LLM usage
by Toleno · Developer Tools
Toleno Network MCP Server — Manage your Toleno mining account with Claude AI using natural language.
by mcp-marketplace · Developer Tools
Create, build, and publish Python MCP servers to PyPI — conversationally.