Skip to main content
Glama
Sign In

Tulina

by ai.tulina.mcp
OverviewDiscussionsAdmin

oto_call

Call ANY oto tool by name — including one that is NOT listed (hidden by default, connector not installed, FOD…), for a single call, WITHOUT adding it durably to your toolbox.

Use this when you need a tool that does not appear in your tool list. If the tool IS already visible, call it directly — don't wrap it in oto_call. Discover names and schemas with oto_list_my_tools / oto_tool_schema. META/SPINE tools (oto_*, data_*, run_*, feedback) are NOT routable here — they are always visible: call them directly.

This bypasses only the DISPLAY filter, never access control: the target's call-time gates (connector activation for the org/team the call resolves under — refused connector_disabled —, credential, connector RBAC, admin authz) and the org field-redaction policy apply exactly as for a direct call (ADR 0036).

Call-context tokens (ADR 0038) are PREFIXED _ — _group, _project, _instance, _account, _run_id — and may be included INSIDE arguments: they route the CALL CONTEXT (which org/team/credential-instance the target resolves under), are guarded exactly like on a listed tool, and are stripped before the target sees them. E.g. reach a team-scoped connector via arguments={..., "_group": 3}, or pin an instance via "_instance": "<ref from oto_instance>".

The prefix keeps them out of the tools' own argument space: an unprefixed account/org/project in arguments is a BUSINESS argument of the target (e.g. aiark_company_search(account=…) is AI Ark's company filter) and is passed through untouched.

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": {
      "name": "<name>"
    },
    "name": "oto_call"
  }
}

Input Schema

NameRequiredDescriptionDefault
_orgNorun the target tool under THIS organization (id) — resolves its credentials/visibility/data for that org (ADR 0038 call token, same membership guard as the flat `_org=` axis). Omit for your current org.
nameYesExact target tool name (e.g. `fr_ccn_search`).
fieldsNokeep ONLY these top-level keys of each result row (or of the single object); `selection` names what was dropped. `["*"]` = all. A target's own `fields` goes in `arguments`.
_run_idNocorrelate this call to an open run, exactly like `_run_id` on a listed tool. Accepted here as well as inside `arguments` — same token, same effect — so the instruction « pass it on every call » never costs a call.
argumentsNoArgument object passed to the target tool. `{}` if none.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full burden and does so: it discloses that the bypass is display-only, that connector activation, credential, connector RBAC, admin authz and org field-redaction still apply (naming the connector_disabled refusal), and that _-prefixed call-context tokens are stripped before the target sees them. That is material behavior an agent could not infer from the schema.

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 correctly: the first sentence states the whole point before any caveats. It is long and parenthetical-heavy (ADR citations, multiple em-dash asides), but for a meta-tool with this many gotchas nearly every sentence carries load; the token-prefix example could be tightened.

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

Completeness5/5

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

For a five-parameter routing tool with no annotations and no output schema, the description covers the decisions an agent must make: whether to wrap or call directly, which tools are unroutable, how context tokens work, and what access-control failures look like. Return shape is left to the target's own schema, which is reasonable for a pass-through.

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 schema already documents name, fields, _org, _run_id and arguments, and the baseline would be 3. The description nonetheless adds real semantics the schema does not state: that _-prefixed tokens may be nested INSIDE `arguments`, that they route call context and are stripped, and that an unprefixed account/org/project in `arguments` is a business argument passed through untouched. It does not explain `fields`/`selection`, which keeps it from a 5.

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

Purpose5/5

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

States a specific verb and resource — 'Call ANY oto tool by name' — plus the two defining properties that separate it from every sibling: works for tools not in the visible list, and does not add the tool durably to the toolbox. It also explicitly excludes the meta/spine families (oto_*, data_*, run_*, feedback) that look like valid targets.

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

Usage Guidelines5/5

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

Gives an explicit when ('a tool that does not appear in your tool list'), an explicit when-not ('If the tool IS already visible, call it directly — don't wrap it in oto_call'), and names the discovery alternatives (oto_list_my_tools, oto_tool_schema) with the condition that selects them. A third exclusion covers meta/spine tools.

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

All Tulina toolsInspect
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