Tulina

http_act

Destructive

Act on a custom connector (Custom API) — ops: call, request, import, set_definition. Reads (the org's connectors, an action's input, the setup link): http.

call: an action by name (operation, args). _account is optional when only one of the org's custom connectors has this action. Arguments are checked against its input; an omitted one takes the connector's saved variable of the same name. Any verb.
request: a raw call to the custom connector of this call (_account when there are several), any verb (method, path, params, body) — for what no saved action describes. Its auth and constant headers are applied. Prefer call when an action exists.
import (admin): turns an OpenAPI/Swagger JSON document into candidate actions WITHOUT saving them (source, url | document); review, then save with set_definition.
set_definition (admin): saves the definition of the custom connector of this call (_account), reused by every member and session. Only the parts given change. operations REPLACES the action list: each name (snake_case), description, method GET|POST|PUT|PATCH|DELETE, path relative with {param}, input (JSON schema object), optional in {arg: path|query|body}. Never a secret here: the key stays on the card.

dry_run=true (call, request) returns {method, path, query, body} without sending it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "op": "<op>"
    },
    "name": "http_act"
  }
}

Input Schema

Name	Required	Description
`op`	Yes	call \| request \| import \| set_definition.
`url`	No	import, source=url only.
`_org`	No	Org (id) de CET APPEL. `oto_list_orgs()`.
`args`	No	call — its arguments, by name.
`body`	No	request — JSON body.
`path`	No	request — relative to the connector's base URL, starts with /, no query.
`label`	No	set_definition — display name of the connector (e.g. "Acme Payroll").
`_group`	No	Équipe (id) de CET APPEL, sous son org parente.
`method`	No	request — GET \| POST \| PUT \| PATCH \| DELETE.
`params`	No	request — query parameters.
`source`	No	import — doc_path (the card's doc route, same auth), url (a public JSON document, no auth sent) or inline (`document`).
`_run_id`	No	OBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
`dry_run`	No	call, request — validate and preview, send nothing.
`headers`	No	set_definition — constant NON-secret headers (e.g. an API version).
`_account`	No	Compte à OPÉRER parmi : `Cal.com` (org), `Qonto` (org). `oto_identity(op='list')`.
`_project`	No	Projet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
`document`	No	import, source=inline only — the OpenAPI JSON document.
`_instance`	No	Instance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
`operation`	No	call — name of the action.
`variables`	No	set_definition — saved values {name: {value, description}} that fill an action argument of the same name when the call omits it.
`operations`	No	set_definition — the full action list (100 max); [] clears it.
`description`	No	set_definition — what the tool is and what it holds, for the agent.
`logo_domain`	No	set_definition — brand domain for the logo (e.g. acme.test).

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds real behavior beyond the annotations: `import` produces candidates WITHOUT saving, `set_definition.operations` REPLACES the action list and is reused by every member and session, credentials stay on the card, and `dry_run` returns {method, path, query, body} without sending. No annotations are contradicted, but return shape for `call`/`request` and error/failure behavior are not described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded one-line summary followed by per-operation bullets, each scoped to its own parameters. Dense but purposeful; a few lines (op enum restatement, `_org`-style references) approach redundancy with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 23-parameter, four-mode, destructive, open-world tool this covers mode selection, argument resolution, admin side effects, and dry-run preview. The remaining gap is that no output schema exists and the successful return of `call`/`request` is never described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond it: it maps parameters to each op, explains that `_account` is optional when only one connector has the action, that omitted args fall back to the connector's saved variables, and that `path` is relative to the base URL with connector auth applied.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Act on a custom connector (Custom API)') and enumerates the four operations with their distinct purposes, so an agent can tell `call` from `request` from the admin ops. It also points to the `http` sibling for read access, though it does not explicitly distinguish itself from http_get/http_post.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit in-tool routing ('Prefer `call` when an action exists', `request` for what no saved action describes) and flags `import`/`set_definition` as admin with a review-then-save workflow. Missing only an explicit statement of when to use this tool instead of the sibling http/http_get/http_post tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Tulina tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?