Skip to main content
Glama

Native responses

native_responses

Call Responses through the organization's private OpenAI connection. Requires an organization API key and recorded native consent. Sends the original input without the privacy barrier. A required organization privacy barrier blocks this tool before dispatch. Use protected chat instead. Provider charges use the connected account. Supply an available native model identifier. Requires an organization API key, an active provider connection and a configured RN contract. Uses the organization's pool first. An inherited pool requires native consent from the consumer and supplier. The original provider body and model are preserved. Personal data is sent without the privacy barrier. An organization can set privacy_barrier_required in its inference settings. That requirement overrides key consent: native requests return 403 organization_privacy_barrier_required before body processing, billing or provider dispatch. The requirement also applies when the supplying organization's pool requires the barrier. Use /v1/chat/completions and the protected rota/* catalog when the request requires that barrier. Resources remain scoped to the organization and the connection that created them. A submitted request is not retried by the gateway. Provider charges remain on the connected provider account. Provider HTTP errors retain their status and original body; a provider 400 is not replaced with a gateway 502. Unsupported model parameters are not removed or translated. Omit X-RN-Connection-Id to select from the authorized pool. RN reserves its contracted fee before dispatch. Provider charges for an owned key remain on that provider account. Token tariffs and positive reference percentages require verified usage limits and provider counters. For OpenAI-compatible streaming under these tariffs, send stream_options.include_usage=true. Positive charges for opaque or batch creation calls require a per-request tariff when usage cannot be reconciled in that response. Unknown execution remains pending; the gateway does not invent zero usage or repeat the paid request.

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": {
      "model": "<model>",
      "input": "<input>"
    },
    "name": "native_responses"
  }
}

Input Schema

NameRequiredDescriptionDefault
inputYesOriginal text or input item array for the native Responses request. Requires recorded native consent.
modelYesAvailable native OpenAI model identifier in the connected account.
storeNoNative provider response storage option. Default: false.
max_output_tokensNoMaximum output tokens for this request.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations only declare non-read-only, non-idempotent, non-destructive, so the description carries real weight and delivers: no gateway retry on submitted requests, provider charges land on the connected account, RN reserves its fee before dispatch, provider HTTP errors keep their original status (a provider 400 is not rewritten as 502), and unsupported model parameters are not stripped. That is substantial context beyond the annotations. It loses a point because several disclosures are opaque jargon ("positive reference percentages", "opaque or batch creation calls") that an agent cannot act on, and the no-retry/pending semantics are stated twice with slight variation.

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

Conciseness2/5

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

The definition is heavily padded and repetitive: the API-key requirement appears twice, provider charges remaining on the provider account appears three times, and the privacy-barrier rule is restated across several sentences. It is front-loaded with the core purpose, which helps, but most readers must sift a long block to find the actionable rules.

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

Completeness3/5

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

For a high-complexity paid inference proxy, the description covers auth, consent, blocking error codes, billing behavior and error passthrough, which is broadly complete. However, it never explains what a successful call returns (no output schema exists to carry that), and the tariff/usage-limit sentences presume concepts the description never defines. An agent knows the preconditions but not the result shape.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already explains model, input, store and max_output_tokens, and the 3 baseline applies. The description adds only marginal meaning — that model must be an available native identifier in the connected account, and that omitting X-RN-Connection-Id selects from the authorized pool, though that header is not a schema parameter. No format or syntax detail is added for input.

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?

The opening sentence states a specific verb and resource: it calls Responses through the organization's private OpenAI connection, forwarding the original input. It also names what it is not ("Use protected chat instead", "/v1/chat/completions"), so an agent can separate it from the protected path. The clarity is diluted by the volume of surrounding prose, but the core purpose is unambiguous.

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?

The description gives an explicit exclusion rule: if the organization sets privacy_barrier_required, this tool returns 403 before dispatch and the agent should use /v1/chat/completions and the protected rota/* catalog instead. It also conditions use on an API key, an active provider connection and a configured RN contract. What is missing is any positive guidance on when this tool is the right choice versus other listed siblings; the guidance is mostly framed as a warning.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources