The cURL Executor is an MCP server with one tool, ta_curl_execute. It lets an assistant send HTTP requests to approved external endpoints.
Use it for lightweight integrations such as:
\nUse a dedicated connector instead when one already exists and covers your use case.
\nAdministrators control:
\nThis helps you connect assistants to external services without exposing secrets in the conversation.
\nThis is a beta feature. Contact the Theta Assist team to enable.
\nThe server label is an internal identifier (lowercase, alphanumeric, hyphens and underscores only). It appears in logs and configuration but is not directly shown to users. Use a label that describes the integration, not the technology — for example:
\n| Label | \nName | \n
|---|---|
crm-webhooks | \nCRM Webhooks | \n
reporting-api | \nReporting API | \n
notification-service | \nNotification Service | \n
This makes it clear what each instance does when you have multiple cURL servers configured, and avoids exposing implementation details.
\n\n\nNote: All cURL Executor instances point to the same MCP server URL — the label does not change the URL. You do not need to (and should not) modify the server URL when adding additional instances.
\n
Use access restrictions to limit where the assistant can send requests.
\n\n\nWarning: If you leave all restriction fields empty, the cURL Executor can call any HTTPS URL allowed by the built-in safety rules. Do not use this setup in production.
\n
For production use, we recommend configuring:
\nFour checkboxes: GET, POST, PUT, DELETE. When one or more are checked, only those methods are permitted. All other methods return an error to the AI.
\nLeave all unchecked to allow any supported method.
\nExample error when blocked:
\n\n\n\n
HTTP verb 'GET' is not permitted by this server's configuration. Allowed: POST
A list of hostnames (e.g. api.example.com). Subdomains are automatically included — adding example.com also permits api.example.com and subdomain.example.com.
When set, any request to a domain not on the list is blocked.
\nOnly applies when no Allowed URLs are configured. If URLs are set, the domain list is ignored — see below.
\nExample error when blocked:
\n\n\n\n
Domain 'unexpected.com' is not in the allowed domains list.
A list of exact URL paths (e.g. https://api.example.com/webhook). The query string is not matched — only the scheme, host, and path are compared. This means the AI can still append query parameters freely to a whitelisted path.
When set, Allowed URLs take precedence over Allowed Domains — the domain list is not evaluated.
\nExample error when blocked:
\n\n\n\n
URL 'https://api.example.com/other-path' is not in the allowed URLs list.
You can configure both, but only one is active at a time:
\nNever ask the assistant to include API keys, bearer tokens, or other secrets in the prompt or tool call. Store credentials in Additional Headers or an attached Auth Config instead.
\nThe Additional Headers section lets you define key/value pairs that are injected into every request at execution time. The AI never sees these headers — they are not included in the tool's instructions and are applied server-side after the AI submits its curl command.
\nIf the AI includes a header with the same name as an additional header, the configured value overrides what the AI provided.
\nTypical uses:
\nx-api-key → static API key for the target servicex-tenant-id → tenant identifier required by the APIapi-version → fixed API version headerExample:
\n| Header Name | \nValue | \n
|---|---|
x-api-key | \nexample-api-key-value | \n
x-tenant-id | \nmy-org | \n
The AI calls the API and these headers are silently included in every request.
\nWhen an Auth Config is attached to the server instance, the server automatically:
\nAuthorization: Bearer <token> into the request.Authorization header the AI may have included.The AI is instructed not to include an Authorization header when an auth config is attached — the token is handled entirely server-side.
When to use each:
\n| Scenario | \nRecommended approach | \n
|---|---|
Static API key (x-api-key, Authorization: ApiKey ...) | \nAdditional Headers | \n
| OAuth / Azure AD-protected API | \nAuth Config | \n
| OAuth token + additional non-auth headers (e.g. tenant ID) | \nAuth Config + Additional Headers | \n
These rules always apply, even if you do not set access restrictions. They reduce the risk of unsafe or unintended requests.
\n| Constraint | \nDetail | \n
|---|---|
| HTTPS only | \nRequests to http:// URLs are rejected. This prevents the AI from probing internal services or making unencrypted calls. | \n
| Supported methods | \nGET, POST, PUT, DELETE only. Other HTTP methods are not supported. | \n
| Content-Type handling | \nAny Content-Type value is permitted. application/x-www-form-urlencoded receives special form-encoding handling; all other content types are passed through as-is. | \n
The cURL Executor can be added as many times as needed. Create separate server instances when integrations use different destinations, credentials, or risk levels.
\nExample setup:
\n| Instance label | \nVerbs | \nRestriction | \nCredentials | \n
|---|---|---|---|
crm-webhooks | \nPOST | \nDomain: crm.example.com | \nAdditional header: x-api-key | \n
reporting-api | \nGET, POST | \nURLs: https://reports.example.com/api/v2/query | \nAuth Config (OAuth) | \n
notification-service | \nPOST | \nDomain: notify.example.com | \nAdditional headers: x-api-key, x-tenant-id | \n
Each instance is independently available to assign to an assistant, and can be further restricted with an Access Profile.
\nAn assistant submits structured data to an external ticketing or workflow system when triggered by the user.
\nConfiguration:
\nPOST onlyhooks.ticketing-system.comx-api-key = <your key>The AI constructs the payload and POSTs it to the webhook URL. The API key is injected silently — the AI never handles it.
\nAn assistant queries an internal reporting API protected by Azure AD, fetching data on demand during a conversation.
\nConfiguration:
\nGEThttps://reports.internal.example.com/api/v2/resultsThe AI calls the endpoint and the access token is fetched and injected automatically. The querystring is not matched, so the AI can freely append filters and pagination parameters.
\nA single assistant needs to submit support tickets to one system and log activity to another, using different credentials for each.
\nConfiguration:
\nsupport-tickets: POST only, domain api.helpdesk.com, x-api-key header for helpdeskactivity-log: POST only, URL https://log.internal.example.com/api/events, OAuth auth config for internal APIBoth instances are enabled on the same assistant. The AI calls ta_curl_execute for each integration — the server enforces the restrictions per-instance, and credentials remain hidden.
After a batch processing job completes, an assistant can POST the results to a Power Automate endpoint (or similar HTTP trigger) for ingestion into a data lake, blob storage, or downstream system — without requiring the user to manually export and upload the file.
\nConfiguration:
\nPOST onlyhttps://prod-xx.westeurope.logic.azure.com/workflows/... (your Power Automate HTTP trigger URL)x-functions-key for Azure Functions, or a shared secret)Typical flow:
\nasync_start_process_files) and the results file is attached to the thread.ta_curl_execute to POST the results JSON to the Power Automate trigger URL.This pattern works well for scheduled or recurring extractions where the output needs to land in a centralised store rather than staying in the conversation.
\nDuring assistant development, you may want an unrestricted instance to test against various endpoints before locking down the configuration for production.
\nConfiguration:
\n⚠️ Do not assign unrestricted instances to production assistants or broad user groups. After testing, replace them with a restricted production instance before rollout.
","description":"This guide explains how to set up the cURL Executor MCP server in Theta Assist. Use it when you want an assistant to send controlled HTTP requests to external APIs, webhooks, or automation endpoints without exposing credentials in the conversation.","isMarkdown":false,"publishedOnUtc":"2026-03-29T22:38:45.9375417","modifiedOnUtc":"2026-03-27T02:34:56.88479"}