Skip to main content
Glama

Noemic

by app.noemic
OverviewDiscussionsAdmin

Fill in a wager for the member to publish

propose_wager

Fill in a wager exactly as the member would on the New wager form, when the user wants to formalize a concrete falsifiable forecast or disagreement. A wager is a title, an optional subtitle, the member's side, and the resolve time. Noemic writes the resolution terms itself and they are the same for every wager, so never ask the user for a decision rule, an evidence source, or void rules, and never put any of them in the title or the subtitle. The result is a private draft plus a publishUrl: the member opens it, sees the completed form, and publishes with one click. The model may suggest this naturally, but must not silently persist a passing remark. An exact source must be linked by an existing sourceRecordId, and an ID, a quote, or provenance must never be invented. This tool never publishes, invites, accepts, charges, escrows, or binds anyone.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sideYesWhether the signed-in user takes Yes or No on the title.
titleYesThe wager as a question or claim a reader takes in at a glance. Nine words or fewer; Noemic refuses longer titles.
subtitleNoOne line under the title saying what the title means, in the user's words. Optional. Not a decision rule, evidence source, or void rule: Noemic writes those.
resolutionAtYesThe resolve time as ISO 8601 with a timezone offset.
sessionTokenYesThe private session token returned by finish_sign_in. Reuse it privately and never show it to the user.
stakeDollarsNoOptional proposed stake in US dollars. It is draft text only; Noemic does not charge or hold it.
sourceRecordIdNoAn existing Noemic source record containing the literal source and provenance. Omit when none exists; never fabricate it or substitute a paraphrase.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changed
    • removedInput schema / properties / proposition
      Removed value: -{
-  "description": "The concrete proposition that will be resolved.",
-  "minLength": 15,
-  "type": "string"
-}
    • changedInput schema / properties / resolutionAt / description
      Previous value: -"The resolution time as ISO 8601 with a timezone offset."New value: +"The resolve time as ISO 8601 with a timezone offset."
    • removedInput schema / properties / resolutionRules
      Removed value: -{
-  "description": "The exact rule for deciding the outcome.",
-  "minLength": 15,
-  "type": "string"
-}
    • removedInput schema / properties / resolutionSource
      Removed value: -{
-  "description": "The authoritative source used to determine the outcome.",
-  "minLength": 3,
-  "type": "string"
-}
    • removedInput schema / properties / resolverAdapter
      Removed value: -{
-  "description": "The resolver class selected before approval. Defaults to Noemic house review; naming a class does not connect an external service.",
-  "enum": [
-    "house",
-    "objective_source",
-    "external_oracle",
-    "named_arbitrator"
-  ],
-  "type": "string"
-}
    • changedInput schema / properties / side / description
      Previous value: -"Whether the signed-in user takes Yes or No on the proposition."New value: +"Whether the signed-in user takes Yes or No on the title."
    • addedInput schema / properties / subtitle
      Added value: +{
+  "description": "One line under the title saying what the title means, in the user's words. Optional. Not a decision rule, evidence source, or void rule: Noemic writes those.",
+  "maxLength": 200,
+  "type": "string"
+}
    • addedInput schema / properties / title / description
      Added value: +"The wager as a question or claim a reader takes in at a glance. Nine words or fewer; Noemic refuses longer titles."
    • changedInput schema / properties / title / minLength
      Previous value: -5New value: +3
    • removedInput schema / properties / voidRules
      Removed value: -{
-  "description": "The exact conditions under which the offer is void.",
-  "minLength": 5,
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "sessionToken",
-  "title",
-  "proposition",
-  "side",
-  "resolutionAt",
-  "resolutionSource",
-  "resolutionRules",
-  "voidRules"
-]New value: +[
+  "sessionToken",
+  "title",
+  "side",
+  "resolutionAt"
+]
  2. Changed5 schema fields changed
    • removedInput schema / properties / counterSide
      Removed value: -{
-  "description": "The compatible opposing side offered to a counterparty.",
-  "minLength": 1,
-  "type": "string"
-}
    • changedInput schema / properties / side / description
      Previous value: -"The outcome or side the signed-in user proposes to take."New value: +"Whether the signed-in user takes Yes or No on the proposition."
    • addedInput schema / properties / side / enum
      Added value: +[
+  "yes",
+  "no"
+]
    • removedInput schema / properties / side / minLength
      Removed value: -1
    • changedInput schema / required
      Previous value: -[
-  "sessionToken",
-  "title",
-  "proposition",
-  "side",
-  "counterSide",
-  "resolutionAt",
-  "resolutionSource",
-  "resolutionRules",
-  "voidRules"
-]New value: +[
+  "sessionToken",
+  "title",
+  "proposition",
+  "side",
+  "resolutionAt",
+  "resolutionSource",
+  "resolutionRules",
+  "voidRules"
+]
  3. Added

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that the result is a private draft plus publishUrl, that the tool never publishes/invites/accepts/charges/escrows/binds anyone, and that sourceRecordId must reference an existing source with no invented IDs, quotes, or provenance. This meaningfully supplements the sparse annotation booleans and aligns with readOnlyHint=false.

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?

The description is dense but every sentence earns its place: purpose, definition, constraints, result shape, non-persistence caveat, source-provenance rule, and side-effect disclaimer. The core verb and trigger are front-loaded, and there is no filler.

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?

With 7 parameters and no output schema, the description still conveys what an agent needs to know: what the tool produces, what the user will do with the publishUrl, what must never be invented, and what side effects it does not have. The schema already covers the per-field input details.

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 useful cross-parameter constraints: title and subtitle must not contain resolution terms, sourceRecordId must be an existing source, and stakeDollars is draft-only. It does not redefine per-field syntax but does clarify intent beyond the schema.

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?

The description uses a specific verb and resource: 'Fill in a wager exactly as the member would on the New wager form.' It also states the precise trigger ('formalize a concrete falsifiable forecast or disagreement'), making it unmistakable from siblings like explain_noemic or find_relevant_wagers.

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?

It explicitly says when to use the tool and when not to: use it when the user wants to formalize a forecast or disagreement, 'must not silently persist a passing remark,' and must never ask for decision rules, evidence sources, or void rules. This gives an agent clear selection and rejection criteria.

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

All Noemic toolsInspect
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