Valuein — SEC EDGAR Fundamentals & Smart-Money Data

Submit Feedback

submit_feedback

File product feedback to the Valuein team — a bug, feature request, experience note, or data-quality issue — directly from the agent surface. Available on EVERY tier including guest/sample (no token required), so an agent can report a rough edge in-band without the human leaving the conversation. Provide a category and a message (other fields optional — see params). Authenticated callers can pass an idempotency_key so a retried submission files exactly once (the same key from the same account); guest/sample callers are never deduplicated. Returns a friendly acknowledgment you can relay to the user. Do NOT use this to query data; it is a one-way report channel.

Input Schema

TableJSON Schema

Name	Required	Description
`reason`	No	Optional structured error-mode reason: 'wrong_number', 'bad_citation', 'missing_data', 'wrong_company', 'formatting', 'hallucinated_fact', 'tool_error', 'coverage_gap', or 'other'.
`context`	No	Optional free-form context object (stored as JSON), e.g. { tool: 'get_company_fundamentals', ticker: 'AAPL', request_id: 'abc123' }. Avoid secrets.
`fact_id`	No	Optional disputed `fact_id` (for wrong_number / bad_citation feedback).
`message`	Yes	The feedback body (1–4000 chars). Be specific: what you expected, what happened, and any reproduction steps. May contain the user's own words — it is stored for triage and never used for arithmetic.
`subject`	No	Optional short title (≤140 chars) summarizing the feedback.
`surface`	No	Optional product surface the feedback concerns: 'mcp', 'workspace', 'sdk', 'dashboard', or 'api'.
`category`	Yes	What kind of feedback this is: 'bug' (something broke), 'feature_request' (something missing), 'experience' (UX / clarity / docs), 'data_quality' (a wrong/missing/stale figure), or 'other'.
`severity`	No	Optional impact classification: 'low', 'medium', or 'high'.
`sentiment`	No	Optional sentiment of this feedback: 'positive' (worked well), 'negative' (something was wrong), or 'correction' (you are supplying the right value).
`target_id`	No	Optional id of the artifact this feedback targets (e.g. a report or thesis id).
`request_id`	No	Optional `_meta` request id of the turn that produced the artifact, for correlation.
`target_type`	No	Optional kind of artifact the feedback targets: 'chat_message', 'report', 'thesis', 'claim', 'tool_call', 'schema', or 'other'.
`expected_value`	No	Optional caller-asserted correct value, in your own words. Stored verbatim for triage — NEVER computed or trusted as data.
`idempotency_key`	No	Optional client-supplied key (1–64 chars). For authenticated callers, reusing the same key files the feedback exactly once — safe to retry on a network error. Ignored for guest/sample callers (no account to scope dedup to).

Output Schema

TableJSON Schema

Name	Required	Description
`_meta`	Yes	Provenance envelope — data lineage for every MCP response
`feedback`	Yes
`acknowledgment`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 18, 2026

changedOutput schema / properties / _meta / properties / fundamentals_as_of / description

Previous value: -"ISO timestamp when the FINANCIAL STATEMENTS were last rebuilt. Use THIS — not `last_updated` — when telling a user how current the fundamentals are. The snapshot is republished on every weekday price refresh while the statements are carried forward unchanged, so `last_updated` can be far more recent than the numbers it sits next to."New value: +"ISO timestamp when the FINANCIAL STATEMENTS were last rebuilt in bulk. Use THIS — not `last_updated` — when telling a user how current the cross-sectional fundamentals are. The snapshot is republished on every weekday price refresh while the statements are carried forward unchanged, so `last_updated` can be far more recent than the numbers it sits next to. It is a floor for a single filer, not a ceiling: a filer with a live partition receives its filing, facts and ratios intraday (minutes after EDGAR dissemination), so an entity-scoped read may carry a filing newer than this; cross-sectional ranks (factor scores, earnings signals) refresh with the weekly bulk export."

Changed2 schema fields changedJul 25, 2026

addedOutput schema / properties / _meta / properties / fundamentals_as_of

Added value: +{
+  "description": "ISO timestamp when the FINANCIAL STATEMENTS were last rebuilt. Use THIS — not `last_updated` — when telling a user how current the fundamentals are. The snapshot is republished on every weekday price refresh while the statements are carried forward unchanged, so `last_updated` can be far more recent than the numbers it sits next to.",
+  "type": "string"
+}

addedOutput schema / properties / _meta / properties / price_as_of

Added value: +{
+  "description": "ISO timestamp when the price surfaces were last refreshed.",
+  "type": "string"
+}

Changed2 schema fields changedJul 7, 2026

addedOutput schema / properties / _meta / properties / cost_usd

Added value: +{
+  "additionalProperties": false,
+  "description": "Per-call cost transparency. Omitted for subscription-only tools that have no PAYG-equivalent price.",
+  "properties": {
+    "amount_usd": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "basis": {
+      "description": "payg_charge = real agent-pay charge. payg_rate_card = indicative price, not billed.",
+      "enum": [
+        "payg_charge",
+        "payg_rate_card"
+      ],
+      "type": "string"
+    },
+    "billed": {
+      "description": "true = this amount was actually charged via PAYG for this call. false = indicative PAYG-equivalent value; your plan already covers this call for free.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "amount_usd",
+    "billed",
+    "basis"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / _meta / properties / latency_ms

Added value: +{
+  "description": "Wall-clock milliseconds this tool call took, measured server-side around the handler.",
+  "minimum": 0,
+  "type": "integer"
+}

Changed7 schema fields changedJun 27, 2026

addedInput schema / properties / expected_value

Added value: +{
+  "description": "Optional caller-asserted correct value, in your own words. Stored verbatim for triage — NEVER computed or trusted as data.",
+  "maxLength": 4000,
+  "type": "string"
+}

addedInput schema / properties / fact_id

Added value: +{
+  "description": "Optional disputed `fact_id` (for wrong_number / bad_citation feedback).",
+  "maxLength": 256,
+  "type": "string"
+}

addedInput schema / properties / reason

Added value: +{
+  "description": "Optional structured error-mode reason: 'wrong_number', 'bad_citation', 'missing_data', 'wrong_company', 'formatting', 'hallucinated_fact', 'tool_error', 'coverage_gap', or 'other'.",
+  "enum": [
+    "wrong_number",
+    "bad_citation",
+    "missing_data",
+    "wrong_company",
+    "formatting",
+    "hallucinated_fact",
+    "tool_error",
+    "coverage_gap",
+    "other"
+  ],
+  "type": "string"
+}

addedInput schema / properties / request_id

Added value: +{
+  "description": "Optional `_meta` request id of the turn that produced the artifact, for correlation.",
+  "maxLength": 256,
+  "type": "string"
+}

addedInput schema / properties / sentiment

Added value: +{
+  "description": "Optional sentiment of this feedback: 'positive' (worked well), 'negative' (something was wrong), or 'correction' (you are supplying the right value).",
+  "enum": [
+    "positive",
+    "negative",
+    "correction"
+  ],
+  "type": "string"
+}

addedInput schema / properties / target_id

Added value: +{
+  "description": "Optional id of the artifact this feedback targets (e.g. a report or thesis id).",
+  "maxLength": 256,
+  "type": "string"
+}

addedInput schema / properties / target_type

Added value: +{
+  "description": "Optional kind of artifact the feedback targets: 'chat_message', 'report', 'thesis', 'claim', 'tool_call', 'schema', or 'other'.",
+  "enum": [
+    "chat_message",
+    "report",
+    "thesis",
+    "claim",
+    "tool_call",
+    "schema",
+    "other"
+  ],
+  "type": "string"
+}

Changed1 schema field changedJun 18, 2026
- addedOutput schema / properties / _meta / properties / pit_safe / description
```
Added value: +"true iff a zero-look-ahead point-in-time cut was applied to every returned figure"
```
AddedJun 17, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With all annotations false (readOnly, openWorld, idempotent, destructive all false), the description carries the full burden and does it excellently: it discloses that guest/sample callers are never deduplicated, that authenticated callers can get exactly-once via idempotency_key, that it returns an acknowledgment to relay, and that it is a one-way channel. No contradiction with annotations exists (idempotentHint=false is consistent with conditional idempotency).

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 front-loaded with the primary purpose, then flows naturally through availability, required params, idempotency nuances, return value, and a final negative. Each sentence adds distinct value, and nothing is wasted. It is longer than average but the complexity (14 params, guest vs authenticated behavior) justifies the length.

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

Completeness4/5

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

Given the tool's complexity, an output schema exists, and annotations are silent, the description covers all essential operational aspects: tier availability, idempotency behavior per caller type, return style, and the non-query nature. It omits only an explicit comparison with submit_artifact_feedbackcca, which is the one significant contextual gap for correct tool selection among siblings.

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 description coverage is 100%, so baseline is 3. The description adds value by explicitly naming the two required parameters ('Provide a `category` and a `message`') and by explaining the behavioral effect of idempotency_key beyond the schema's per-parameter text. It doesn't deeply explain every optional field, but that's unnecessary given full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'File product feedback to the Valuein team', and enumerates the accepted types (bug, feature request, experience note, data-quality issue). It also clarifies what the tool is not for ('Do NOT use this to query data'). However, it never differentiates itself from the similarly-named sibling submit_artifact_feedback, so the resource boundary is not fully explicit.

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?

The description gives strong when-to-use context: available on every tier, no token required, usable in-band without leaving the conversation, and a one-way report channel. It includes a clear exclusion ('Do NOT use this to query data'), but does not name any alternative tool for the excluded case or for artifact-specific feedback, leaving the choice versus submit_artifact_feedback to inference.

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.