WritersLogic agent-infra

chat-standard

Chat completion, standard tier (12k in, 2k out) — OpenAI-style chat completion served by the hub's provider router (mid-size general model, up to 12000 input tokens and 2048 output tokens per call), with a signed receipt that binds the provider, model, token usage and the hashes of your messages and the reply. Supports optional strict json_schema output returned both parsed and as a string. Does not stream, call tools or functions, accept images,

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": {
      "messages": "<messages>"
    },
    "name": "chat-standard"
  }
}

Input Schema

Name	Required	Description
`model`	No	Accepted and ignored: the hub routes by tier (the resource you paid for). Echoed as requested_model.
`top_p`	No	Accepted and ignored.
`messages`	Yes	Conversation, oldest first; the last message must have role user. At most 200000 characters in total. System messages are joined into the instructions.
`max_tokens`	No	Upper bound on the reply in tokens; defaults to 1024. A value above the tier cap is rejected with 400.
`temperature`	No	Accepted and ignored.
`response_format`	No	Either {"type":"text"} (default) or {"type":"json_schema","json_schema":{name,schema}}. The schema is always enforced strictly: root object, every property required, additionalProperties false, keywords limited to type, description, properties, required, additionalProperties, items, enum.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A3.6/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 substantial work: it discloses the routing/ignored-parameter behavior, the signed receipt binding provider, model, usage and message hashes, strict json_schema enforcement, and the no-stream/no-tools/no-images limits. Gaps remain on auth, rate limits, and error/latency behavior, and the text cuts off mid-list ('accept images,').

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

Conciseness3/5

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

The key facts (tier caps, router) are front-loaded, which is good, but the rest is a single long run-on parenthetical-heavy sentence that terminates mid-enumeration. Truncation and density cost it.

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 six-parameter tool with nested response_format and no output schema, the description covers the essentials: caps, routing semantics, receipt contents, and strict schema constraints. Only operational details (auth, rate limits, failure modes beyond the documented 400) are absent.

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 100%, so the schema already documents all six parameters, including that model, temperature and top_p are 'accepted and ignored'. The description adds only a little beyond that — notably that json output is returned both parsed and as a string — so the baseline 3 applies.

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 description names a specific resource and tier: 'Chat completion, standard tier (12k in, 2k out)', plus the routing mechanism ('served by the hub's provider router'). That sizing distinguishes it from larger/smaller tier siblings, though it never names chat-deep or chat-fast explicitly.

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

Usage Guidelines3/5

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

Usage is implied through the tier caps and the exclusion list ('Does not stream, call tools or functions, accept images'), which tells an agent when this tool is unfit. There is no positive routing guidance such as 'use chat-deep for longer contexts', so the agent must infer the alternative.

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

All WritersLogic agent-infra 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?