Skip to main content
Glama

Sec Form D

by io.github.pipeworx-io

Recent Changes

recent_changes
Read-onlyIdempotent

"What's new with X" / "latest on Y" / "what happened to Z this week / month / quarter" / "updates on Acme" / "news on Tesla recently" / "what's happening with Apple" — change feed for a company in the last N days/weeks/months in ONE parallel call. Fans out to SEC EDGAR (filings since since), GDELT→GNews fallback (news mentions in window — GDELT preferred, GNews when rate-limited or 5xx), USPTO (patents granted; PatentsView API sunset May 2025 so this soft-fails until reactivated). since accepts ISO date ("2026-04-01") or relative shorthand ("7d", "30d", "3m", "1y"). Returns structured changes[] grouped by source + total_changes count + pipeworx:// citation URIs. Use entity_profile instead when you want the static profile (filings + fundamentals + LEI + patents) regardless of window.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYesEntity type. Only "company" supported today.
sinceYesWindow start — ISO date ("2026-04-01") or relative ("7d", "30d", "3m", "1y"). Use "30d" or "1m" for typical monitoring.
valueYesTicker (e.g., "AAPL") or zero-padded CIK (e.g., "0000320193").

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already indicate read-only, idempotent behavior. The description adds crucial details: fan-out to multiple sources (SEC, GDELT, GNews, USPTO), fallback logic, and soft-failure for USPTO. No contradiction with annotations.

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?

Description is moderately long but every sentence is informative and contributes to understanding. Front-loaded with usage examples. Could be slightly more concise but well-structured.

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?

Despite no output schema, the description explains the return structure (changes[], total_changes, citation URIs) and covers edge cases like USPTO soft-fail and GDELT/GNews fallback. Complete for the tool's complexity.

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 describes all parameters with 100% coverage. Description adds semantic value beyond schema: explains 'since' shorthand formats and 'value' formats (ticker/CIK), and reiterates 'type' constraint.

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 clearly identifies the tool's purpose: providing a change feed for a company over a recent time window. It distinguishes itself from the sibling tool 'entity_profile', which is for static profiles.

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?

Description gives explicit guidance on when to use this tool versus 'entity_profile', and provides query examples. It also explains the fallback behavior between GDELT and GNews, aiding appropriate usage.

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

All Sec Form D toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation2/5

Many tools have overlapping purposes, e.g., ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded all route questions to data sources with minor differences. Form D tools and meta-tools (discover_tools, suggest_questions) further blur boundaries, making it hard for an agent to select the right tool.

Naming Consistency4/5

Most tools follow a consistent snake_case verb_noun pattern (e.g., resolve_entity, validate_claim, subscribe). However, there are minor deviations like bet_research and deep_research without clear verbs, and the ask_pipeworx variants use irregular suffixes.

Tool Count2/5

With 39 tools, the server is over-scoped, including many utility and meta-tools (remember, recall, forget, list_subscriptions) that inflate the count beyond the core domain (SEC Form D and data lookups). A more focused set of 10-15 tools would be more coherent.

Completeness4/5

The tool set covers a very broad range of data sources and actions, including SEC filings, prediction markets, entity profiling, and AI visibility. However, the completeness is uneven; for example, there are many Form D tools but few for other SEC forms, and some areas like weather or clinical trials are only accessible via ask_pipeworx.

Resources