Skip to main content
Glama
Sign In
TradingView-MCP

TradingView-MCP

by tedorigawa001
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

register_event_study_hypothesis

Prevent research bias by registering event-study hypotheses and outcome contracts in an append-only journal, then record evidence from market runs without copying results.

Instructions

Register one immutable event-study or observational feature-study hypothesis and its outcome contract in the local append-only research journal. Use the optional journal field of run_market_event_study or compute_feature_outcome_relationships to record evidence without copying results by hand.

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": {
      "hypothesis_id": "<hypothesis_id>",
      "title": "<title>",
      "thesis": "<thesis>",
      "audit_definition": "<audit_definition>",
      "evaluation_contract": "<evaluation_contract>"
    },
    "name": "register_event_study_hypothesis"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleYes
thesisYes
hypothesis_idYes
audit_definitionYesExact standard falsification-audit CLI input. It is canonicalized and hash-bound in the immutable journal entry.
evaluation_contractYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.10

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the behavioral burden and does disclose important traits: the entry is immutable, the journal is append-only, and the journal is local. However, it omits duplicate-ID behavior, error handling, required permissions, and what the function returns, leaving meaningful ambiguity for a mutation/registration operation.

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?

Two sentences, no filler, with the core purpose and behavioral constraints front-loaded and the alternative usage placed second. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex tool with five required parameters, nested objects, no output schema, and no annotations. The description covers the high-level purpose but leaves out return values, duplicate handling, validation behavior, and most parameter semantics, so an agent still faces significant ambiguity before invoking it correctly.

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

Parameters2/5

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

Schema description coverage is only 20%, yet the description adds little parameter-level meaning beyond referring to an 'outcome contract,' which loosely maps to evaluation_contract. It does not explain hypothesis_id, title, thesis, audit_definition, or how the evaluation_contract fields relate to the hypothesis, so the description fails to compensate for the low schema coverage.

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 states a specific verb ('Register'), a specific resource ('immutable event-study or observational feature-study hypothesis and its outcome contract'), and a specific destination ('local append-only research journal'). It also distinguishes itself from siblings like register_strategy_hypothesis and the run_* study tools by clearly naming the domain of hypotheses it handles.

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?

It gives concrete routing guidance by telling users to use the optional journal field of run_market_event_study or compute_feature_outcome_relationships for recording evidence instead of copying results manually. It does not explicitly say when not to use this tool or mention protocol validation, but the intended workflow is reasonably clear.

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

Deploy Server

Other Tools