← Home
Search by capability

Tool search 103,811 tools · 5,319 live servers

Filtersactive
Searches the tool schemas themselves, not the README. Every result is a server you can install.
9 servers with tools matching “fileBest-graded first
STRING Database MCP Serverorg.string-db/string-mcpAPublisher
  • string_interactions_query_set

    Retrieves the interactions between the query proteins. Use this method only when you specifically need to list the interactions between all proteins in your query set. If user asks for 'physical' or 'complex' use 'physical' network type. - For a **single protein**, the network includes that protein and its top 10 most likely interaction partners, plus all interactions among those partners. - For **multiple proteins**, the network includes all direct interactions between them. - If the user refers to "physical interactions", "complexes", or "binding", set the network type to "physical". - STRING does not store or report information about self-interactions/homomers; if asked, explain the limitation. If few or no interactions are returned, consider reducing the `required_score`. For large query sets (>50 proteins), consider increasing the `required_score` (e.g. ≥700) to focus on high-confidence interactions and avoid overly dense networks. - Expand the names of score sources: `nscore` (neighborhood), `fscore` (fusion), `pscore` (phylogenetic profile), `ascore` (coexpression), `escore` (experimental), `dscore` (database), `tscore` (text-mining)

  • string_all_interaction_partners

    Retrieves all interaction partners for one or more proteins from STRING. This tool returns all known interactions between your query protein(s) and **any other proteins in the STRING database**. - Use this when asking **“What does TP53 interact with?”** - It differs from the `network` tool, which only shows interactions **within the input set** or a limited extension of it. - If the user refers to "physical interactions", "complexes", or "binding", set the network type to "physical". You can filter for strong interactions using `required_score`. - Evidence scores: `nscore` (neighborhood), `fscore` (fusion), `pscore` (phylogenetic profile), `ascore` (coexpression), `escore` (experimental), `dscore` (database), `tscore` (text mining)

  • string_create_file

    Creates a downloadable file for STRING-derived results. Use this tool when the user explicitly asks to download, save, export, or receive a file containing STRING data, tables, protein lists, enrichment results, networks, etc. When a response would otherwise include a publication-style or supplementary result table, or another table clearly intended for reuse outside chat, mention that a downloadable TSV/CSV file can be generated on request. Ask whether they want the file, unless they already requested it. Do not create the file until the user asks for it. Do not store unrelated data or full conversation transcripts.

Scalix Cloudworld.scalix/cloudAPublisher
  • scalix_build_create

    Create a new container image build from a Git repository or Dockerfile.

Atlarium Habitat Database MCPbio.atlarium/habitat-databaseAPublisher
  • search_fish

    Search fish and aquatic animal profiles in the Atlarium habitat database.

  • get_fish_profile

    Get a structured fish or aquatic animal profile from the Atlarium habitat database.

  • get_plant_profile

    Get a structured aquatic plant profile.

  • get_product_profile

    Get a structured public habitat product profile.

  • search_algae

    Search public algae diagnostic profiles with symptoms, causes and treatment guidance.

  • get_algae_profile

    Get a structured public algae diagnostic profile.

Homespundev.homespun/homespunAPublisher
  • deploy_app

    Deploy a v2 app: an HTML document plus a capability manifest, hosted at its own URL. The manifest carries eight extension keys: app metadata; collections, with per-collection write, update, read and delete role lists, where write gates creates and also gates updates unless an update list is declared; externalHosts, a fetch allowlist; cdn, to allow CDN scripts and styles; capabilities, for Permissions-Policy opt-ins; embeds, an iframe frame-src allowlist; notify, for email-on-row rules; and webhooks, for signed HTTP POST on-row rules. The manifest grammar is documented in the Homespun guide that get_skill returns. Pass no `app_id` to create, which mints a slug and URL, or pass `app_id` to redeploy an existing app with new content. Supply the HTML inline as `html`, or as `html_path`, an absolute path read on the MCP-server host, which is the relay for a hosted connector or the CLI host for a locally-run one, and not the remote agent's machine; it avoids retransmitting a large HTML file on every deploy, only a locally-run connector can read it, and inline `html` wins if both are given. `dry_run:true` (alias `check`) validates only: it runs the full manifest and asset-shape validation, the redeploy compat gate and the schedule-timezone advisory, then returns { ok, warnings, compat?, breaks? } without creating a version or mutating anything. A redeploy is refused with manifest_incompatible_redeploy, unless force:true, when it would strand rows already written (dropping a collection, tightening a schema, flipping appendOnly), or when it would widen what the app's install screen discloses, such as a collection's read reaching further than the live manifest. The break quotes the sentence a user would now be asked to approve. Taking access away never prompts: dropping a role, or adding update:[\"creator\"] to a write:[\"anyone\"] collection, redeploys clean. A removed collection is detached rather than deleted. Images, fonts, audio, video and data files ship with the app in the same call via `assets[]`. Each is validated and stored app-scoped and served at its `path` on the app's own origin, so the HTML references it by a stable same-origin path such as `<img src=\"frames/000.jpg\">`; media and font paths support HTTP Range for seeking. A redeploy's assets replace the previous version's set. Returns { app_id, slug, url, version, visibility, created } on create, or { app_id, version, compat, breaks? } on redeploy.

  • attachments

    Binary attachments (images, PDFs, audio, video) referenced from event payloads and input_data via `format: homespun-attachment-id`. Actions: upload, fetch, presign, finalize, download, show, list, delete, mint_token, revoke_token, list_tokens. Choosing an upload path matters for cost. An inline upload with `content_base64` carries the bytes in the tool-call arguments, so they enter the model context at a token cost proportional to file size, paid again on every retry; a few-hundred-KB image is already expensive. Two paths avoid that entirely: fetch, when the bytes are reachable at a URL, and presign plus finalize, when the client can PUT the raw bytes out of band. Inline upload suits small assets and clients that have neither a URL nor an out-of-band PUT. fetch takes { source_url (https), scope } and the relay downloads the URL itself behind an SSRF guard (https only, no private, loopback or metadata hosts, DNS pinned, redirects refused, size-capped and timed out), then runs the same byte-sniff, allowlist, size, quota and scan checks as any upload. It works on any storage backend. upload takes either `content_base64` (base64 bytes, no filesystem) or `file_path` (an absolute path read on the relay host, so it only applies when the file is local to the relay). presign plus finalize is token-free: presign with { mime, size, sha256, scope } returns { put_url, attachment_id }, the caller PUTs the raw bytes to put_url over plain HTTP out of band, then finalize with the attachment_id. At finalize the relay re-reads the stored bytes, sniffs the real type, and enforces the same allowlist, size, sha256, quota and scan checks, so a presign that misstates its mime is caught and never served inline. The presigned path requires the Azure storage backend; a filesystem self-host returns a clear not-supported error and fetch or inline upload apply there instead. download writes to an absolute out_path or returns base64. An upload is scoped to agent (the default, reusable) or app. mint_token returns a /b/<token> capability URL, shown once, that a browser can GET without the caller's API key.

  • agent

    Agent identity and binding. Actions: whoami returns the resolved relay URL, the active profile and whether a key is configured, with no network call and no secrets; claim binds this agent to a human using a one-shot claim code from their Settings UI, and is one-way; logout clears the locally saved key and profile but does not revoke it on the relay, which is what the `key` tool's revoke action does.

  • publisher

    The caller's community publisher identity: the @-handle and public profile shown in the template gallery. Actions: get returns the profile, including the handle, whether it has been claimed, tenure, and the rating and template counters; claim sets the handle from a lowercase 3-to-32-character string and may be used only once, after which the handle is permanent, and it refuses a handle that is reserved or already taken; update changes display_name, bio or url at any time. claim and update require a verified email. An existing publisher may hold a provisional `maker-...` handle assigned automatically, which claim renames on its one allowed use.

mcpio.sota/mcpBPublisher
  • create-project

    Create a new project on sota.io. Each project automatically provisions: (1) a managed PostgreSQL 17 database accessible via the DATABASE_URL environment variable (auto-injected, no configuration needed), (2) PgBouncer connection pooling (pool size 20, max 100 clients), (3) automatic daily database backups with 7-day retention, (4) a live URL at https://{slug}.sota.io with automatic HTTPS via Let's Encrypt. The project slug is auto-generated from the name (lowercase, hyphens, max 63 chars) and is immutable after creation. Supported frameworks: Next.js, Node.js (Express/Fastify/Koa), Python (Flask/FastAPI/Django), or any language via custom Dockerfile. You can also add up to 5 custom domains per project with automatic HTTPS (via API: POST /v1/projects/:id/domains with {domain: "yourdomain.com"}). DNS: A record to 23.88.45.28 for apex domains, CNAME to {slug}.sota.io for subdomains. Optionally associate the project with a public git repository at create-time by passing `git_url` (and optional `git_branch`). The association is informational — it shows up in the dashboard and the `sota deploy --git` CLI flag can default to it — but does NOT enable auto-deploy-on-push yet.

  • deploy

    Deploy an application to sota.io. The platform auto-detects your framework and builds a Docker image automatically: - Next.js: Detected via next.config.js/ts. Add output: 'standalone' to next.config for optimal builds. - Node.js: Detected via package.json with a "start" script. Works with Express, Fastify, Koa, Hapi, etc. - Python: Detected via requirements.txt or pyproject.toml. Works with Flask, FastAPI, Django. - Custom Dockerfile: If a Dockerfile exists in the project root, it takes priority over auto-detection. Use this for Go, Rust, Java, or any other language. The EXPOSE directive in the Dockerfile is used to detect the app port automatically. THREE WAYS to supply the source code — pick EXACTLY ONE: 1. **files** (inline source from AI): Pass a map of relative paths to UTF-8 text content. Best when you've just generated a small app in this conversation and want to deploy it without any filesystem step. Up to 200 files, 10 MB total. Include the framework manifest (package.json, requirements.txt, or Dockerfile) so auto-detection works. 2. **git_url** (clone a public repo): Pass an https://, git://, ssh://, or git@host:path URL. We shallow-clone it (--depth=1 --single-branch) on the server and deploy. Optional git_branch picks a non-default branch. Only public repos are supported in v1. Max 200 MB after clone. 3. **directory** (local filesystem): Pass an absolute path. Only works when the MCP client has filesystem access (Claude Code / CLI; not Claude.ai web). Defaults to the current working directory when omitted. IMPORTANT: Your app MUST listen on the PORT environment variable. For auto-detected frameworks (Next.js, Node.js, Python) PORT is 8080. For custom Dockerfiles, the port is auto-detected from the EXPOSE directive (e.g. EXPOSE 3000 sets PORT=3000). If no EXPOSE is found, it defaults to 8080. Every project includes a managed PostgreSQL 17 database. Six environment variables are auto-injected into your container — no manual database configuration needed: DATABASE_URL (full connection string), PGHOST, PGPORT, PGUSER, PGPASSWORD, and PGDATABASE. Libraries that follow libpq conventions (node-postgres, pgx, psycopg2, Django) pick up the PG* variables automatically with no configuration. If your app needs database migrations, run them on startup. Deployments use blue-green strategy for zero downtime. The old container keeps running until the new one passes health checks (60s timeout). Use get-logs to monitor build progress. Files matching .gitignore, .git/, node_modules/, .env, and .DS_Store are excluded from the archive.

  • get-logs

    Get build and runtime logs for a deployment. If no deployment_id is provided, returns logs for the latest deployment. Use this after calling deploy to monitor build progress and diagnose failures. Logs include: framework detection output, dependency installation, build steps, container startup, and health check results. If a deployment fails, check the logs for error details — common issues include missing dependencies, build errors, or the app not listening on the correct PORT (check the PORT env var — 8080 for auto-detected frameworks, or the EXPOSE value from Dockerfile).

  • set-env

    Set an environment variable for a project. Variables are encrypted at rest (AES-256-GCM) and injected at container runtime. NOTE: DATABASE_URL, PGHOST, PGPORT, PGUSER, PGPASSWORD, and PGDATABASE are all auto-injected for the managed PostgreSQL database — you do NOT need to set any of them manually. The PORT variable is auto-managed: 8080 for auto-detected frameworks (Next.js, Node.js, Python), or auto-detected from the Dockerfile EXPOSE directive for custom Dockerfile builds. IMPORTANT: Changing env vars does NOT auto-redeploy. You must call deploy or use the redeploy API endpoint to apply changes. For Next.js apps, NEXT_PUBLIC_* variables must be set BEFORE deploying since they are embedded at build time.

String Dbio.github.pipeworx-io/string-dbBVerified
  • entity_profile

    "Tell me about X" / "research Acme" / "brief me on Tesla" / "what does Apple do" / "company profile for Microsoft" / "give me the rundown on NVDA" / "everything you know about $TICKER" — full cross-source profile of a US public company in ONE parallel call. ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view. Fans out across SEC EDGAR, XBRL, USPTO, news, GLEIF and returns: cik + company_name; recent_filings (up to 5 with pipeworx://edgar/company/{cik}/filings/{accession} URIs); fundamentals (LATEST 10-K Revenues + NetIncomeLoss + Cash, sorted period_end DESC); patents (USPTO PatentsView API sunset May 2025 — soft-fails until reactivated); recent news mentions via GDELT→GNews fallback; LEI via GLEIF. Pass ticker "AAPL" or zero-padded CIK "0000320193" — names not supported (use resolve_entity first if you only have a name).

  • recent_changes

    "What's new with X" / "latest on Y" / "what happened to Z this week / month / quarter" / "updates on Acme" / "news on Tesla recently" / "what's happening with Apple" — change feed for a company in the last N days/weeks/months in ONE parallel call. Fans out to SEC EDGAR (filings since `since`), GDELT→GNews fallback (news mentions in window — GDELT preferred, GNews when rate-limited or 5xx), USPTO (patents granted; PatentsView API sunset May 2025 so this soft-fails until reactivated). `since` accepts ISO date ("2026-04-01") or relative shorthand ("7d", "30d", "3m", "1y"). Returns structured changes[] grouped by source + total_changes count + pipeworx:// citation URIs. Use entity_profile instead when you want the static profile (filings + fundamentals + LEI + patents) regardless of window.

  • suggest_questions

    What can I ask Pipeworx? / what is Pipeworx good for? / what can you do? / give me ideas / show me examples / getting started / what data do you have? — the onboarding entry point for an agent that just connected and wants to know what is worth asking. Returns category-bucketed example questions (company financials, drugs & clinical trials, economics, real estate, prediction markets, weather, government & patents, science & academia, news) — each with the exact tool + argument shape that answers it, drawn from the live catalog of thousands of tools. Call with no arguments for the full spread, or pass `topic` (e.g. "finance", "pharma", "betting") to focus. Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools (ask_pipeworx, entity_profile, compare_entities, etc.).

  • generate_llms_txt

    Generate a production-ready llms.txt file for any URL so AI crawlers (ChatGPT, Claude, Perplexity) can index the site cleanly. Fetches the page, extracts title/description/key links, and emits the standard llms.txt markdown format. Output is a single text blob ready to drop at site-root/llms.txt. Useful for: getting a client's site indexed by AI, drafting llms.txt for your own project, or auditing how an AI crawler would see a competitor.

Workspace Toolscom.vandorla/workspace-toolsBPublisher
  • read_file

    Read a file from the agent workspace by path (e.g. ./notes.md, /etc/...).

Shiplynow.shiply/shiplyBPublisher
  • publish_site

    Publish files to the web → live URL at <slug>.shiply.now. UPDATING: never create a new site for changes — re-call with claimToken (anonymous sites) or slug (sites you own with a Bearer key) and the SAME URL gets the new version. Unchanged files are hash-skipped server-side, so re-publishing (including retrying a failed publish) is cheap — always update the same site rather than creating a new one. Works WITHOUT auth (anonymous: 24h lifetime, returns claimToken/claimUrl — SAVE THEM). With a Bearer shp_ key sites are permanent. ≤50 files / 2 MB inline; bigger: REST flow per https://shiply.now/llms.txt. index.html serves at /. spaMode for client-side routing.

  • delete_site

    PERMANENTLY delete a site and all stored files. Irreversible — confirm with the user first.

  • list_versions

    List a site's finalized deploys newest-first (id, createdAt, isLive, fileCount, bytes), capped at 20. Pair with rollback_site: pick a version id from here and re-point the site to it.

  • pull_site

    Download the current files of a site you own (or created via a platform connection) so you can edit and republish to the same slug with publish_site. Static sites return editable source; framework/SSR sites return the built bundle (`.shiply/bundle/*`), not original source.

  • set_handle

    Give ONE site a vanity URL: rename it to <handle>.shiply.now (3-30 chars, a-z 0-9 -). The old address 301-redirects for 30 days. (For a portfolio page listing all your sites, use set_profile instead — that lives at shiply.now/@<handle>.)

  • duplicate_site

    Server-side copy of an owned site under a new slug — instantly live. Copies files + title; does NOT copy access settings, domains, or data. Great for iterating on variants.

stagenth · 数据工具箱com.stagenth/data-kitBPublisher
  • data_profile

    数据画像:每列类型/去重近似数/空值率 + 数值列 min/max/avg/std/分位数(1 credit/次)。 相当于 pandas df.describe()——AI 拿它一眼看清整份数据的分布与质量。失败自动退款。 返回 {ok, format, n_rows, n_cols, profile[]}。