agent-intern

Overview Schema Source Related Servers Discussions Admin

Ask Muse Code (new session) [experimental]

muse_ask

Ask Meta's Muse Code a question or task in a new session and get its final answer, with optional sandbox control and workspace context.

Instructions

Ask Meta's Muse Code (muse exec) a question or task in a NEW session. EXPERIMENTAL.

⚠️ The real model has never answered through this bridge — the author has no Muse plan. Muse's built-in offline echo provider verified everything else end to end (argv, event stream, answer, session resume), so a failure here is most likely auth or the model itself. If it misbehaves, say so plainly and please report it.

Needs a Muse Code plan (muse login) or a META_API_KEY; run muse_status first. Returns the agent's final message (the run_terminal event of muse exec --json). Point workspace at a project dir for repo context.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`model`	No	Optional model id (`--model`, e.g. "muse-spark-1.3"). Muse accepts any id, so this is not validated. Omit for muse's default.
`watch`	No	If true, open a live "watch" view of muse's task stream. Same final text is returned. Best-effort. Default false.
`prompt`	Yes	Question or instruction for Muse. Passed in a file, never argv.
`sandbox`	No	"read-only" (default — muse's write, shell and web tools switched off, so it can only read and answer; holds on every OS), "workspace-write" (shell runs inside muse's OS sandbox, network proxy-only; on Windows that sandbox needs a one-time elevated setup — see muse_status), or "danger-full-access" (`--yolo`: no approval, no sandbox — avoid).	read-only
`timeout_s`	No	Max seconds to wait for muse to complete. Default 180.
`workspace`	No	Working root (`--workspace`). Defaults to the server cwd.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.32.1Sep 30, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations declare readOnlyHint=false, openWorldHint=true and idempotentHint=false, and the description goes well beyond them: it discloses the experimental/unverified status, that failures most likely stem from auth or the model, the auth requirements, and what is returned (the run_terminal event of `muse exec --json`). This is unusually candid context that an agent cannot infer from structured fields.

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?

Purpose is front-loaded in the first sentence, followed by a clearly delineated warning block and a compact prerequisites/returns block. The multi-line warning is slightly verbose but every line (auth, failure diagnosis, report-it request) carries actionable content.

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?

Given an output schema exists, return values needn't be spelled out, yet the description even identifies which event carries the answer. Combined with the auth prerequisite and sandbox guidance, an agent has everything needed to call this correctly.

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 documents all six parameters including the sandbox modes and timeouts. The description only re-adds the workspace-for-repo-context cue and the return value, so it mostly repeats the schema. Baseline 3 is appropriate.

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 ('Ask Meta's Muse Code a question or task in a NEW session') and explicitly scopes it as a new session, which separates it from the sibling muse_continue. An agent can pick between muse_ask and muse_continue without opening either schema.

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?

Gives a clear prerequisite ('run muse_status first') and the auth condition (Muse plan via `muse login` or META_API_KEY), plus a pointer to --workspace for repo context. It stops short of naming muse_continue as the explicit alternative for resuming, though 'NEW session' strongly implies it.

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