Skip to main content
Glama

netintel_openai_gpt_5_6_luna

Generate chat completions by calling OpenAI's gpt-5.6-luna through a pay-per-call x402 endpoint; no OpenAI account or API key needed, pay $0.06 per request in USDC.

Instructions

Call OpenAI's gpt-5.6-luna via a single pay-per-call x402 endpoint — no OpenAI account or API key needed, pay $0.06 per request in USDC. Standard OpenAI chat.completions request/response shape, capped input and output. Search terms:…

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
messagesYes
max_completion_tokensNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.61

TDQS

B3.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does meaningful work: it discloses the auth model (no OpenAI account/API key), the billing side effect ($0.06 per request in USDC), and the response shape (standard chat.completions). It underspecifies what 'capped input and output' concretely means and omits rate limits.

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 with the core operation and cost, tightly worded. The trailing truncated 'Search terms:…' fragment is dead weight/artifact but overall the payload is compact.

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 2-param, no-output-schema, no-annotation tool the description covers auth, cost, and request shape adequately. But it omits the single most important disambiguator given 14 model siblings—what this model is for relative to them—leaving a real gap in call correctness.

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 coverage is 0% and there are 2 undocumented params, so the description must compensate. 'Standard OpenAI chat.completions request/response shape' implicitly documents the messages structure, but max_completion_tokens is only hinted at by 'capped output' and the 'capped input' limit is never quantified.

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 and resource (call OpenAI's gpt-5.6-luna) and notes the transport (x402 pay-per-call endpoint). However, it does not differentiate this model from the ~14 sibling netintel_openai_gpt_* tools (sol, terra, 5.5, 5.4, etc.), so an agent cannot tell why 'luna' is the right choice.

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

Usage Guidelines2/5

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

Gives payment/logistics context (no API key, $0.06 in USDC) but no when-to-use guidance, no conditions distinguishing it from the other gpt model siblings, and no exclusions. The agent is left to infer model-selection criteria entirely.

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

Deploy Server

Other Tools