Skip to main content
Glama

Silicon Floor

by com.siliconfloor
OverviewDiscussionsAdmin

Events since a date

what_changed
Read-only

Returns what was recorded since a given date (default 7 days, up to 90): SEC filings accepted, figures a company restated, technical signals logged, and ownership declarations. By default (highlights) the window is ranked by materiality — restatements, earnings, material agreements, offerings and sizeable insider purchases first, technical signals last — with repeated items grouped on one line (a company's insider filings of one kind with their total amount, a manager's 13F declarations); detail: 'events' returns the raw chronological list. Use it for a daily or weekly brief, or when the user asks what changed since a date. Price moves are not events here (see get_company). A Schedule 13D/G row carries move (crossed 5%, up, down, below 5% — no longer required to report, not a sale —, out) with previousPercent and changeVsPrevious; a 13F row carries moves, what that manager did with the tracked companies since its previous quarter. complete: false means a source had more items than were read: the summary is complete after coversFrom; narrow since or pass symbol.

Input Schema

NameRequiredDescriptionDefault
limitNoHighlights: rows to return (default 40, max 100). Events: events to return (default 50, max 200).
sinceNoISO date or timestamp to look back from (default: 7 days ago, maximum 90 days).
detailNo'highlights' (default): ranked, grouped summary of the window. 'events': the raw list, newest first.
symbolNoRestrict to one ticker. Omit for the whole universe.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover only the safety profile (readOnly, non-destructive, closed-world), yet the description discloses the window default and 90-day cap, the default materiality ranking order, line-grouping behavior for repeated filings, and the meaning of `move`/`moves`/`previousPercent`/`changeVsPrevious`. Critically, it explains the `complete: false` truncation signal and the remediation ('narrow `since` or pass `symbol`'), which no annotation or schema field conveys.

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 purpose and default behavior before drilling into field-level detail, and every sentence is informative. It is nonetheless a dense single block with heavy em-dash nesting, and the 13D/G and 13F field explanation sits close to the boundary of what belongs in a tool description versus a response schema.

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 no output schema, the description carries the full burden of return-value semantics, and it does: it defines the default vs raw modes, the ranking, the row-level `move`/`moves` fields, and the `complete`/`coversFrom` contract. An agent has everything needed to call it and interpret the result.

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, but the description adds meaning beyond the schema: it explains why `highlights` groups rows by materiality and what `detail: 'events'` yields (raw chronological list). It reiterates defaults already in the schema (7-day window, limits), which is redundant, but the mode semantics are genuinely additive.

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?

States a specific verb and resource — 'returns what was recorded since a given date' — and enumerates the exact event classes it covers (SEC filings, restatements, technical signals, ownership declarations). It sets the tool apart from siblings by declaring 'Price moves are not events here (see get_company)', so an agent can separate this cross-source digest from per-source feeds.

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?

Gives explicit use cases ('a daily or weekly brief, or when the user asks what changed since a date') and an explicit exclusion that routes the agent elsewhere ('Price moves are not events here (see get_company)'), naming the alternative tool by name. This is when/when-not guidance, not inference.

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

All Silicon Floor 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