cURL Executor MCP Server | Admin Guide

What the cURL Executor does

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:

• calling a webhook
• sending data to an external system
• querying a REST API
• triggering an automation flow

Use a dedicated connector instead when one already exists and covers your use case.

Administrators control:

• which HTTP methods are allowed
• which domains or URLs can be called
• which credentials are added server-side

This helps you connect assistants to external services without exposing secrets in the conversation.

Enabling the cURL Executor

This is a beta feature. Contact the Theta Assist team to enable.

Add a server instance

1. Navigate to Admin > Tools > MCP Servers.
2. Click Add Theta Assist MCP Server and select cURL Executor.
3. Enter:
   • a Label for internal use
   • a Name for easier identification in admin settings

Server label best practice

The 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:

This makes it clear what each instance does when you have multiple cURL servers configured, and avoids exposing implementation details.

Note: 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.

Access restrictions

Set access restrictions

Use access restrictions to limit where the assistant can send requests.

Warning: 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.

For production use, we recommend configuring:

• only the HTTP methods you need
• either a restricted domain list or an exact URL list
• credentials server-side only

Allowed HTTP verbs

Four 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.

Leave all unchecked to allow any supported method.

Example error when blocked:

HTTP verb 'GET' is not permitted by this server's configuration. Allowed: POST

Allowed domains

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.

Only applies when no Allowed URLs are configured. If URLs are set, the domain list is ignored — see below.

Example error when blocked:

Domain 'unexpected.com' is not in the allowed domains list.

Allowed URLs

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.

Example error when blocked:

URL 'https://api.example.com/other-path' is not in the allowed URLs list.

Combining domains and URLs

You can configure both, but only one is active at a time:

• If Allowed URLs has entries → URLs are checked; domains are ignored.
• If Allowed URLs is empty → Domains are checked (if configured).

Hiding credentials from the AI

Never 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.

Additional Headers

The 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.

If the AI includes a header with the same name as an additional header, the configured value overrides what the AI provided.

Typical uses:

• x-api-key → static API key for the target service
• x-tenant-id → tenant identifier required by the API
• api-version → fixed API version header

Example:

The AI calls the API and these headers are silently included in every request.

Auth Config (OAuth)

When an Auth Config is attached to the server instance, the server automatically:

1. Obtains an OAuth access token using the configured app registration.
2. Injects it as Authorization: Bearer <token> into the request.
3. Overrides any 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:

Built-in safety (always enforced)

These rules always apply, even if you do not set access restrictions. They reduce the risk of unsafe or unintended requests.

Multiple server instances

The cURL Executor can be added as many times as needed. Create separate server instances when integrations use different destinations, credentials, or risk levels.

Example setup:

Each instance is independently available to assign to an assistant, and can be further restricted with an Access Profile.

Use cases

Outbound webhook with a static API key

An assistant submits structured data to an external ticketing or workflow system when triggered by the user.

Configuration:

• Allowed Verbs: POST only
• Allowed Domains: hooks.ticketing-system.com
• Additional Headers: x-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.

Querying a REST API with OAuth

An assistant queries an internal reporting API protected by Azure AD, fetching data on demand during a conversation.

Configuration:

• Allowed Verbs: GET
• Allowed URLs: https://reports.internal.example.com/api/v2/results
• Auth Config: OAuth app registration with appropriate scopes

The 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.

Multiple integrations via separate instances

A single assistant needs to submit support tickets to one system and log activity to another, using different credentials for each.

Configuration:

• Instance support-tickets: POST only, domain api.helpdesk.com, x-api-key header for helpdesk
• Instance activity-log: POST only, URL https://log.internal.example.com/api/events, OAuth auth config for internal API

Both 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.

Pushing batch processing results to a data lake or storage endpoint

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.

Configuration:

• Allowed Verbs: POST only
• Allowed URLs: https://prod-xx.westeurope.logic.azure.com/workflows/... (your Power Automate HTTP trigger URL)
• Additional Headers: any static headers required by the trigger (e.g. x-functions-key for Azure Functions, or a shared secret)

Typical flow:

1. The assistant runs a batch processing job (e.g. async_start_process_files) and the results file is attached to the thread.
2. The user (or the assistant proactively) calls ta_curl_execute to POST the results JSON to the Power Automate trigger URL.
3. Power Automate receives the payload and routes it into storage, a database, or a downstream pipeline.

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.

Development / exploration instance

During assistant development, you may want an unrestricted instance to test against various endpoints before locking down the configuration for production.

Configuration:

• No verb restrictions
• No domain or URL restrictions
• No credentials (or a non-production API key in additional headers)

⚠️ Do not assign unrestricted instances to production assistants or broad user groups. After testing, replace them with a restricted production instance before rollout.