XFMS — Xpansion Framework Model Source

Watch this job (XF Model Watch subscribers)

watch_job

Saves a finished job for XF Model Watch, which re-tests it as new models arrive and emails the person only when a model passes every must-have and ranks higher on their priorities. Needs a signed-in subscriber. Ask the person first: Model Watch keeps the job and its example tasks (encrypted, deletable any time). Pass consent=true only if they agree. Pass the discover session, and either test_session from a finished comparison or the tasks, plus the model they use now. The first check runs as soon as the job is saved. To re-check a job the person already watches, pass check_now with the job's id or title instead (once a day per job; the result is emailed and shown at /account).

Input Schema

Name	Required	Description
`tasks`	No	Example tasks, if no test_session.
`title`	No	A short name for the job, in the person's words.
`consent`	No	The person agreed to Model Watch keeping this job.
`session`	No	The discover session.
`check_now`	No	Check a job they already watch now: its id or title. Leave out when saving a job.
`test_session`	No	From a finished comparison; carries its tasks.
`current_model`	No	OpenRouter id of the model the job uses now.
`runs_per_month`	No	Roughly how many times a month the job runs, if known.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 21, 2026

addedInput schema / properties / check_now

Added value: +{
+  "description": "Check a job they already watch now: its id or title. Leave out when saving a job.",
+  "type": [
+    "integer",
+    "string"
+  ]
+}

changedInput schema / required

Previous value: -[
-  "session",
-  "consent"
-]New value: +[]

Changed1 schema field changedOct 16, 2026

changedInput schema / properties / consent / description

Previous value: -"The person agreed to Watch keeping this job."New value: +"The person agreed to Model Watch keeping this job."

AddedOct 15, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds substantial context beyond annotations: encryption and deletability of stored data, consent requirement, immediate first check, once-a-day rate limit for re-checks, and that results are emailed and shown at /account.

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

Conciseness5/5

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

Front-loads the purpose in the first sentence, then follows with prerequisites, required inputs, timing, and the re-check alternative. Every sentence earns its place for an 8-parameter tool with complex consent and storage behavior.

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?

Although there is no output schema, the description explains where results appear (emailed and shown at /account) and covers all prerequisites, consent handling, storage traits, and timing. Annotations carry the safety profile, and the description fills in the remaining behavioral gaps completely.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds some meaning beyond the schema, such as passing consent=true only if the person agrees and clarifying the either/or relationship between test_session and tasks. However, most parameter semantics are already in the schema descriptions, so it does not reach the highest level.

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: 'Saves a finished job for XF Model Watch' and explains the monitoring behavior (re-tests, emails when a model ranks higher). This distinguishes it from siblings like benchmark, compare, and discover. Also covers the secondary re-check mode explicitly.

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

Usage Guidelines5/5

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

Explicitly states when to use it: after a finished job, needs a signed-in subscriber, ask the person first, pass consent=true only if they agree. Gives the alternative for re-checking: 'To re-check a job the person already watches, pass check_now with the job's id or title instead.' Nothing is left to inference.

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

All XFMS — Xpansion Framework Model Source 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?