watch_companyFollow a company's SEC filings: returns feed links to read whenever needed — the SEC's own Atom feed of every filing, plus Edgar & Edgarette's card and its JSON. Argument: company (name, ticker) or cik. No email is sent and nothing is stored.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | optional SEC CIK, exact match | |
| company | No | company name as it files, or ticker |
Changes observed during successful MCP inspections.
Input schema / properties / boardRemoved value: -{
- "enum": [
- "breaches",
- "charter-amendments",
- "mergers",
- "agreements",
- "restructuring",
- "cmo-moves",
- "ipo-watch",
- "annual-meetings",
- "auditor-watch"
- ],
- "type": "string"
-}Input schema / properties / company / descriptionAdded value: +"company name as it files, or ticker"Input schema / properties / emailRemoved value: -{
- "type": "string"
-}Input schema / requiredRemoved value: -[
- "company",
- "email"
-]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Crucial behavioral constraints not covered by annotations are highlighted: 'No email is sent' and 'nothing is stored'. This provides strong operational guarantees that prevent misuse or unexpected side effects, making it highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is concise and front-loaded, immediately stating the function. It provides necessary behavioral constraints in a tight package without excessive verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool returns simple feed links (not complex data requiring an output schema), the definition is complete. It covers input variability, the return type (links), and critical behavioral boundaries (no storage/no email).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the schema already clearly defines the parameters (cik and company) and their accepted formats. The description reinforces this by noting that the 'company' argument can accept a name, ticker, or CIK, which is baseline supplemental information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the purpose: 'Follow a company's SEC filings' and explicitly states the output is 'feed links'. This function is clearly scoped to SEC filings, distinguishing it from tools dealing with performance or mergers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description defines the operational scope and flexibility of inputs (name, ticker, CIK), which guides usage. While it doesn't list explicit alternatives, it clarifies the purpose of the tool (getting links vs detailed data), which implies appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.