agent-as-model
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| chat_completeA | Generate a chat completion from an OpenAI chat-completions-shaped request. The completion is produced by the host agent's own model: direct MCP sampling on pre-2026-07-28 connections, an MRTR InputRequiredResult carrying the request payload on 2026-07-28+. When output_schema is given, the request carries exactly one required tool whose input schema is that schema, and the validated structured completion is returned as JSON text. When tools is given, the tool definitions are forwarded to the host's model with tool_choice, but only if the host advertised the sampling.tools capability: otherwise the tools are dropped (a warning is logged server-side) and the call degrades to a plain-text completion. When the host answers by calling tools, the returned text is JSON: {"text": "...", "tool_calls": [{"id": "...", "input": {...}, "name": "..."}]} (keys sorted). A plain-text host answer returns text as before. tools and output_schema cannot be combined. An optional persona {name, input_schema, output_schema} registers a per-call contract: the request arguments are validated against input_schema before anything is sent, and the host's completion text must parse as JSON validating against output_schema. The server is stateless and keeps no persona registry. persona.output_schema and output_schema cannot be combined. Session cursors: the server keeps no session state. To continue a conversation, pass the accumulated history back in and the previous turn's cursor as previous_response_id: '' starts a cursor chain (nothing verified), 'cur_<64 hex>' continues a verified chain (checked against the history passed back; mismatch fails loud naming expected vs received), 'resp_<32 hex>' (a responses_create response id) anchors a new chain at the passed history. When previous_response_id is given, the completion returns as JSON '{"completion": "", "response_id": "cur_<...>"}' instead of plain text; when omitted the tool returns plain text exactly as before. The cursor is 'cur_' + sha256 over canonical JSON '{"model","tool","transcript"}' (sorted keys, compact separators), the transcript being the conversation through the assistant turn, so the caller can recompute it. Re-supply previous_response_id on the MRTR retry round on 2026-07-28+ connections, like persona. No API key is used or needed: the connected agent is the model. |
| messages_createA | Generate a completion from an Anthropic messages-shaped request. The completion is produced by the host agent's own model: direct MCP sampling on pre-2026-07-28 connections, an MRTR InputRequiredResult carrying the request payload on 2026-07-28+. When output_schema is given, the request carries exactly one required tool whose input schema is that schema, and the validated structured completion is returned as JSON text. When tools is given, the tool definitions are forwarded to the host's model with tool_choice, but only if the host advertised the sampling.tools capability: otherwise the tools are dropped (a warning is logged server-side) and the call degrades to a plain-text completion. When the host answers by calling tools, the returned text is JSON: {"text": "...", "tool_calls": [{"id": "...", "input": {...}, "name": "..."}]} (keys sorted). A plain-text host answer returns text as before. tools and output_schema cannot be combined. An optional persona {name, input_schema, output_schema} registers a per-call contract: the request arguments are validated against input_schema before anything is sent, and the host's completion text must parse as JSON validating against output_schema. The server is stateless and keeps no persona registry. persona.output_schema and output_schema cannot be combined. Session cursors: the server keeps no session state. To continue a conversation, pass the accumulated history back in and the previous turn's cursor as previous_response_id: '' starts a cursor chain (nothing verified), 'cur_<64 hex>' continues a verified chain (checked against the history passed back; mismatch fails loud naming expected vs received), 'resp_<32 hex>' (a responses_create response id) anchors a new chain at the passed history. When previous_response_id is given, the completion returns as JSON '{"completion": "", "response_id": "cur_<...>"}' instead of plain text; when omitted the tool returns plain text exactly as before. The cursor is 'cur_' + sha256 over canonical JSON '{"model","tool","transcript"}' (sorted keys, compact separators), the transcript being the conversation through the assistant turn, so the caller can recompute it. Re-supply previous_response_id on the MRTR retry round on 2026-07-28+ connections, like persona. No API key is used or needed: the connected agent is the model. |
| responses_createA | Generate a completion from an OpenAI Responses-shaped request, returning the Responses API response object. The completion is produced by the host agent's own model: direct MCP sampling on pre-2026-07-28 connections, an MRTR InputRequiredResult carrying the request payload on 2026-07-28+. |
| generateA | Generate a raw text completion from a plain prompt string. The prompt is sent as a single user sampling message with no system prompt and no chat formatting: raw prompt in, completion text out, produced by the host agent's own model. Same model hint and parameters as the other completion tools, minus any chat or tool features: no tools, no output_schema, no tool_choice. It does accept the optional persona contract ({name, input_schema, output_schema}): request/response validation only, never a sampling feature, so the thin path stays zero overhead. Session cursors: the server keeps no session state. previous_response_id '' mints a cursor over the current prompt and completion, returned as JSON '{"completion": "", "response_id": "cur_<...>"}' instead of plain text; when omitted the tool returns plain text exactly as before. generate has no structured history channel (the prompt is the only input), so a 'cur_' cursor can never be verified here: passing one fails loud instead of silently skipping the check. The cursor is 'cur_' + sha256 over canonical JSON '{"model","tool","transcript"}' (sorted keys, compact separators) with the transcript [{"role": "user", "content": }, {"role": "assistant", "content": }], so the caller can recompute it. No API key is used or needed: the connected agent is the model. |
| list_modelsA | List the models this server offers. There is exactly one: agent-default, an alias for the host agent's own model. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
chat_complete, messages_create, and responses_create perform essentially the same operation—sampling the host model—and differ only in request/response schema. The long descriptions explain the shapes, but an agent must know which external API format is intended, so boundaries are inferable yet easy to confuse.
All names use snake_case, but ordering is mixed: list_models and generate are verb-first, while chat_complete, messages_create, and responses_create are noun-first. 'generate' is also vaguer than the other completion tools, so the pattern is readable but not predictable.
Five tools is a healthy, well-scoped count for a model-proxy server. The only slight issue is that three of the five are near-duplicate completion endpoints that could arguably be consolidated.
The surface covers the main completion shapes (chat, messages, responses, raw text) plus model discovery, which is solid for a model-sampling proxy. It lacks embeddings, streaming controls, and other peripheral model operations, but core completion workflows are covered.