The MCP tool directory.
Each row is one tool from one provider. Tools sharing a name across providers (e.g. search) are listed separately because they aren't interchangeable.
[ 3869 tools indexed ]
[ all tools ]
30 / 3869
datasets_list
[ remote ]List and search uploaded datasets with fuzzy matching.
datasets_read
[ remote ]Read, filter, and search dataset rows. Use 'search' to find text across all columns, 'filters' for multi-column AND filtering, or filter_column for simple lookups. For row-level questions ('find rows where X'), use this — not an analysis tool.
datasets_update
[ remote ]Update dataset metadata — name, description, tags, visibility.
datasets_upload
[ remote ]Generate a secure upload token for CSV files. Returns UUID + curl command for the user.
deactivate_tool_version
[ remote ] Bring a keyRemoves the active tool version of one environment. Runs in that environment then see the tool's own description and parameters again.
deal_status
[ remote ]A deal's parties, who agreed to which version, the agreed version, deliveries (files, fingerprints), its payments (memo, amount, status, transaction) and total paid, and ratings.
declare_storage_area
[ remote ]Declare a file-storage area before putting files in it. Three declarations are fixed at declaration and cannot change afterwards: whether files are keyed by end user, whether earlier versions are kept (version keeping is refused at this version), and the one application of your account the area binds to. The binding is required: every area belongs to one application. A matching `object_storage` entry in the manifest records the use and is not required: the area works with or without it. That entry may instead list the area in `areas`, and each submission then declares it for that application, so neither this tool nor `mintArea` is needed. Declare an area once, with this tool or with the Storage client's `mintArea` when the backend starts; doing both with the same values is safe, the second answering already declared. The backend's Storage client reaches the area's files over a transport it builds, which sends each call to the gateway origin with the application's platform credential, `TURNZERO_CLOUD_TOKEN`, as the bearer; the Store files guide's sample builds it. Declaring the same area again with the same values answers as already declared; different values are refused. An area that holds no file can be undeclared with `undeclare_storage_area`, which frees the name for a new area under other declarations. To upload a file from a shell, call `mint_upload_grant` and run the command it answers; in Windows PowerShell, `Invoke-WebRequest` needs `-UseBasicParsing`.
declare_upstream
[ remote ]Declare an external API that the application calls with a stored key, or revise its declaration. Store the key first with `store_secret` and name it here; the application then calls the API through the platform's proxy at `/egress/v0/<upstream>/<path>`, and the proxy adds the key at its own edge. The proxy never gives the key to the application, though an upstream that echoes the key returns it. A key is declared here where you may edit the client to read its base URL and key from settings, and bound in the manifest's `settings` only where its host is fixed in code you must not change. With `sdk_settings`, a provider's SDK reaches the API from a deployed container with no code change. Each deploy, promote, and `restart_application` sets `base_url`'s setting to the proxy's address for this upstream, and `key`'s setting to an egress key: a credential the platform mints for this upstream and container, which the proxy swaps for the stored key. The OpenAI SDKs read `OPENAI_BASE_URL` and `OPENAI_API_KEY`; the Anthropic SDKs read `ANTHROPIC_BASE_URL` and their bearer setting, `ANTHROPIC_AUTH_TOKEN`. Nothing at the declaration, the manifest's submission, or the deploy checks that the application's client calls through the proxy, since that depends on its code, which the platform does not read. After the first call, `read_logs` with `filter: "undeclared"` and `source: "egress"`, then with `source: "harness"`, shows a call the client made to the provider's host itself. Such a call skipped `/egress/v0/`, and a failed attempt shows too. `read_status`'s `application.egress` lists the undeclared hosts the serving version reached where its `read` is `logs`, failed attempts left out, and names this upstream in `upstreams` beside its host. A host the manifest's `egress` lists shows in neither. The rest is on the page /cloud/reference/actions/declare-upstream/, which `read_documentation` reads as `page` and the platform's origin serves.
defs
[ remote ]Routes giving access to standard fields and dictionaries used in Macrostrat
defs-autocomplete
[ remote ]Quickly retrieve all definitions matching a query. Limited to 100 results
degreesToRadians
[ remote ]Converts a degree value to its equivalent in radians
delete_account
[ remote ]Delete this account and everything in it — every application, database, storage area, secret, and end-user realm. Destructive: needs a credential holding the destructive class (a signed-in session, or a token minted with `destructive`). The call creates a pending action whose approval page lists by kind what will be destroyed, and the deletion runs only after a person approves it in the browser. Run `export_account` first.
delete_activity
[ remote ]Delete an outreach activity logged by mistake. The person's owner and stage stay as they are.
delete_alert
[ remote ]Delete an alert rule. Its channels stay and can serve other rules. Irreversible; disabling it (update_alert enabled=false) keeps the rule.
delete_alias
[ remote ]Delete a forwarding address. Mail sent to it afterwards bounces.
delete_application
[ remote ]Delete an application and everything provisioned for it: its environments, its database and the database credential, and its end-user realm. The deletion also takes the storage areas bound to it with their files, the secrets stored at its scope, and the upstream declarations bound to it. Secrets at the account scope stay. Destructive: needs a credential holding the destructive class (a signed-in session, or a token minted with `destructive`). The call creates a pending action whose description counts what will be destroyed by kind, and answers an approval URL. The deletion runs only after a person approves it in the browser, and `read_pending_action` reports the outcome with one receipt per kind. The metering history stays.
delete_branch
[ remote ]Deletes a development branch.
delete_content_guideline
[ remote ] Account requiredRemoves a per-language content guideline from the brand.
delete_dns_record
[ remote ]Deletes a DNS record from a custom domain. Give the type, name and value exactly as list_dns_records shows them (for MX, the hostname). Confirm with the user first.
delete_domain
[ remote ]Remove a domain from PowerDMARC
delete_end_user
[ remote ]Delete one of an application's end users — their identities, sessions, and passkeys with the user row; the realm's event log keeps its rows. Destructive: needs a credential holding the destructive class (a signed-in session, or a token minted with `destructive`); the call creates a pending action, and the deletion runs only after a person approves it in the browser. An optional `environment` (`development` or `production`; absent, `production`) names the realm the call addresses, development's standing only once `create_environment` has turned development on.
delete_environment
[ remote ]Delete an application's development environment and everything running or stored in it: its container, database, realm, credentials, files, and logs. Its version rows are withdrawn from `list_versions`. The call keeps the application, its production environment, its areas, and its declarations; production is deleted only with its application. Afterwards the application has one environment, so a deploy goes to production. On one environment the call is admitted where development's records stand: a database setup, whole or stopped partway, or a deletion of them that stopped. It then erases them, the secrets, files, and logs kept for local runs among them, and the next submit_manifest sets the database up again. Otherwise it is refused `environment_not_created`. Destructive: completes only after a person approves it in the browser.
delete_file
[ remote ]Delete a file from a GitHub repository
delete_file
[ remote ]Delete a file from a workspace. Any member can delete.
delete_group
[ remote ]Delete a keyword group and EVERY keyword in it (each as delete_keyword does: its mentions go with it). The default group cannot be deleted. Says how many keywords went.
delete_keyword
[ remote ]Stop tracking a keyword and delete its mentions (a post also matched by another keyword stays). Alert rules that named it stop naming it; a rule that named only this keyword is disabled rather than widened to every keyword. Irreversible; muting (update_keyword muted=true) keeps the mentions.
delete_listing
[ remote ]Take down one of your listings: give the name you posted it with (or its path, listings/<name>.md). It leaves the store at once; its history stays, so restore_file or posting again brings it back.
delete_message
[ remote ]Delete a message. By default it moves to Trash; from Trash/Drafts (or with permanent: true) it is deleted permanently.
delete_path
[ remote ]Permanently deletes a file, or a folder and everything in it. This can't be undone, so confirm with the user first.
delete_secret
[ remote ]Delete one stored secret by its name and scope: a value stored under the wrong name or at the wrong scope, or one no longer needed. The `application` and `environment` arguments name the scope as for `store_secret`. Destructive: needs a credential holding the destructive class (a signed-in session, or an account-wide token minted with `destructive`); the call creates a pending action, and the deletion runs only after a person approves it in the browser. Once it runs, the name leaves custody and no caller reads the value again. The vault holds the deleted value in its soft delete for its retention window, and no action reads or restores it. A store under the same name afterwards is a new value. A platform-minted name is refused `platform_minted_name`. A name still in use is refused `secret_in_use`: one a binding feeds, where the recorded manifest, a running copy, or an act in flight holds it, an upstream's key, or a realm route's or a push provider's credential. A use begun before the approval ends the pending action declined, and one begun after it ends the action failed with `secret_in_use`. A value already gone, or re-supplied, rotated, or stored again since the approval, completes with `deleted` false, and nothing is deleted.