Skip to main content
Glama

TickerFacts

by com.tickerfacts
OverviewDiscussionsAdmin

Tell TickerFacts what you needed

send_feedback

Report what you needed from TickerFacts and did not get, what looked wrong, what was confusing, or what worked. Call this whenever a tool call fails or a result lacks a figure, period, company or filter your user's task needed; say what the user was trying to accomplish and exactly which fields, periods, companies or filters would have solved it. Also call it once at the end of a session that went well, naming what was useful. Reports are read by the maintainers and drive what gets added; there is no reply channel unless you give a contact. Free-text fields are bounded; nothing is published.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYesmissing_data: a company, period, metric or filter you needed is not served. wrong_data: a served figure or label looks incorrect (say which and why). confusing_response: the result or error was hard to use. feature_request: a capability that would help. works_well: what was useful. other.
toolNoThe tool or endpoint involved, e.g. get_fundamentals or /api/v1/screen.
agentNoYour client or agent and version, e.g. "claude-code 2.1" or "acme-research-bot".
tickerNoThe company or companies involved, if any.
contactNoAn email or URL for follow-up, if the person you work for wants one. Optional; not published.
detailsNoAnything else: the figure you expected and its source, the workaround you used, how often this comes up.
summaryYesOne or two sentences: what you needed and what happened. Required.
use_caseNoWhat your user is trying to accomplish overall (the task, not the call). This is the most useful field.
in_reply_toNoThe id of an earlier report you are continuing (from its reply), when answering the questions it asked.
would_solve_itNoThe exact fields, periods, companies, filters or behaviour that would have solved it.
attempted_argumentsNoThe arguments of the call that failed or fell short, as JSON text.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / in_reply_to
      Added value: +{
+  "description": "The id of an earlier report you are continuing (from its reply), when answering the questions it asked.",
+  "maxLength": 200,
+  "type": "string"
+}
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, the description discloses real behavioral facts: reports are read by maintainers, there is no reply channel unless a contact is provided, and nothing is published. It also notes that free-text fields are bounded. This gives the agent an accurate model of the side effects and privacy guarantees, and does not contradict the annotations.

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?

Every sentence earns its place: the first states purpose, the second gives call triggers, the third adds a session-completion case, and the final two cover consequences and privacy. It is front-loaded with the core reporting verb and remains compact despite covering many operational details.

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 an 11-parameter tool with no output schema, the description is complete: it explains what to report, when to report, what content to include, what happens to the report, and whether follow-up is possible. The schema handles the rest, so no critical operational context is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description paraphrases schema-level guidance already present in fields like use_case ('say what the user was trying to accomplish') and would_solve_it ('exactly which fields, periods, companies or filters would have solved it'), but it does not add significant new parameter-level meaning beyond what the schema already supplies.

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 opens with a specific verb and resource: 'Report what you needed from TickerFacts and did not get, what looked wrong, what was confusing, or what worked.' It clearly distinguishes this tool from all data-retrieval siblings by establishing it as the feedback/issue-reporting channel, not a lookup or screening tool.

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?

The description gives explicit call conditions: 'Call this whenever a tool call fails or a result lacks a figure, period, company or filter your user's task needed.' It also adds a positive trigger: 'call it once at the end of a session that went well.' This is strong when-to-use guidance, with no meaningful alternatives among the sibling tools.

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

All TickerFacts 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