Valuein — SEC EDGAR Fundamentals & Smart-Money Data

Create Rule

create_rule

Persist a trigger -> action rule and register it with the evaluator. 7 trigger types accepted (alert_fired, schedule_tick, inbox_item, price_threshold, filing_event, manual, scheduled_task_wake) x five action types (run_team, send_alert, create_report, schedule_task, post_inbox); score_thesis is retired and refused. These trigger types have a live event source and DO dispatch today: alert_fired, schedule_tick, inbox_item, filing_event and scheduled_task_wake. price_threshold and manual are accepted and persisted (forward-compatible schema) but have NO live event source wired yet, so a rule created with one of them is saved as enabled:true and simply never fires. Always read the returned rule's trigger_wiring_status field ("live" vs "not_yet_wired") — it is computed from the dispatcher's own registry, so it is authoritative even if this description is stale. condition_expr is an OPTIONAL single comparison ("field op value", op one of gt/gte/lt/lte/eq, e.g. "price_change_pct gt 5") evaluated against the trigger event's payload — omit to fire on the trigger alone. Deliberately NOT a general expression language (no AND/OR, no loops) — this is both an anti-complexity and an anti-loop guard; compose multiple rules if you need more than one comparison. filing_event timing: pro and full rules fire within minutes of a filing; sp500 (free Benchmark) rules fire once a day, for filings detected up to 20:00 America/New_York, at that cutoff (no inbox item, webhook, Slack or agent run before it). Use test_rule immediately after creating to verify it fires as expected WITHOUT spending a real dispatch. Tier: sp500+ (sample rejected).

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": {
      "name": "<name>",
      "trigger": "<trigger>",
      "action": "<action>"
    },
    "name": "create_rule"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Human-readable label.
`action`	Yes	Discriminated union — what happens when the rule fires.
`trigger`	Yes	Discriminated union — which signal fires this rule.
`condition_expr`	No	Optional single comparison against the trigger payload, e.g. "price_change_pct gt 5". Omit to fire on the trigger alone.
`replaces_rule_id`	No	Optional. The id of a signal this call REPLACES — set it when saving an edit, which is stored as create-then-delete because neither engine has an update tool. A verified live record you own is discounted from the tier cap so an edit is cap-neutral; an unknown, deleted, or foreign id is ignored and the cap applies normally.

Output Schema

Name	Required	Description
`rule`	Yes
`_meta`	Yes	Provenance envelope — data lineage for every MCP response
`warning`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes far beyond the annotations: it discloses that price_threshold and manual persist as enabled:true but never fire, that score_thesis is retired and refused, the tier-dependent filing_event latency, and that trigger_wiring_status is authoritative even if the prose goes stale. That is exactly the non-obvious post-conditions an agent needs before mutating state with a non-idempotent, non-destructive write.

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?

Front-loaded with the core action, then structured by concern (wiring, condition grammar, tier timing, test advice), with no filler sentences. It is dense—parenthetical asides and backticked field names make it heavier than ideal—but nearly every clause carries decision-relevant information.

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?

For a 5-parameter union-typed creation tool with an output schema, this covers what the output schema cannot: which configurations are silently inert, editing semantics via replaces_rule_id, and tier gating. Nothing material is missing for a correct first call.

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 already 100%, so the baseline is 3; the description earns more by explaining condition_expr's single-comparison grammar, giving a concrete example, and justifying the no-AND/OR limit as an anti-loop guard, plus flagging that the schema still lists score_thesis as an accepted variant when it is actually refused.

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?

Opens with a specific verb+resource+side effect: "Persist a trigger -> action rule and register it with the evaluator." It then enumerates the exact trigger and action vocabularies, which lets an agent distinguish it from create_signal (delivery) and update_signal without opening a 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 concrete operational guidance: call test_rule immediately after creating to verify without spending a dispatch, and states the tier requirement (sp500+, sample rejected). It omits any explicit routing against the closely-named sibling create_signal, so the agent must infer which of the two creation tools to use.

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

All Valuein — SEC EDGAR Fundamentals & Smart-Money Data 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.