Holdings of great value investors: 13Fs, overseas stakes a 13F misses, 5% stakes, insider buys
Scored across 8 tools
Most tools map to distinct questions: search resolves names to slugs/ids, get_manager and get_company drill into one entity, quarter_roundup and latest_filings aggregate across managers, and filing_forecast is purely about deadlines. The main friction is fetch vs get_manager/get_company (id vs slug lookups returning overlapping data) and latest_filings vs quarter_roundup, which both surface buys and sells but differ in scope and time window.
Only the get_company/get_manager pair follows a verb_noun pattern; the rest mix bare verbs (fetch, search) with noun-phrase names (filing_forecast, insider_buying, latest_filings, quarter_roundup). The names are readable and descriptive, but there is no single predictable convention an agent can rely on.
Eight tools is well-scoped for a niche 13F/value-investor analytics server. Each tool covers a distinct slice (lookup, entity detail, aggregations, deadlines, insider activity) without obvious filler.
The surface covers the core lifecycle: discovery (search), entity resolution (fetch), per-manager and per-company views, quarterly and latest 13F aggregation, filing-timing forecasts, and insider Form 4 buying. Minor gaps remain, such as direct manager-to-manager comparison or a cross-quarter time series for a single holding beyond the quarter_roundup window.
The full record for one id from search (e.g. 'manager:berkshire-hathaway' or 'company:ko'), as text with its moatshark url.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | An id from search results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds the return format ('as text with its moatshark url'), which is useful beyond the annotations, but says nothing about record contents, error behavior, or size of the payload.
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?
A single compact sentence, front-loaded with the resource and followed by the id examples; nothing is redundant. It reads as a sentence fragment, but every clause carries information.
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?
With no output schema, the description carries the burden of explaining the return value and does so only loosely ('full record ... as text with its moatshark url'). Combined with the unexplained overlap with get_company/get_manager, an agent still has open questions before calling it.
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?
Schema coverage is 100% and the single param is documented, so the baseline is already met. The description goes further by showing the id syntax with two real examples ('manager:berkshire-hathaway', 'company:ko'), which the schema's generic 'An id from search results' does not convey.
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?
Names the resource ('the full record for one id') and its origin ('from search'), with concrete id examples that make the shape of the input obvious. It does not, however, distinguish itself from siblings get_company and get_manager, which appear to retrieve similar entity records.
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?
'one id from search' implies the intended workflow (search first, then fetch by id), so usage is inferable. There is no explicit when-to-use versus get_company/get_manager, and no statement about what happens with an unknown id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
When the managers file their 13Fs: the deadline for the quarter being filed, who has filed so far, who is expected on each remaining day (from each manager's last eight quarters), and who is later than usual. Give a slug for one manager's habit and history.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Optional manager slug, e.g. 'pershing-square' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile needs no repetition. The description adds genuinely useful methodology beyond that: expectations are derived from each manager's last eight quarters, and lateness is flagged relative to habit. It does not state how current the underlying filing data is, which would matter for a forecasting tool.
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 core purpose and its four output components are front-loaded in the first sentence, with the optional manager variant as a short follow-up. The opening relative clause is slightly awkward but no sentence is wasted.
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?
For a single optional-parameter, read-only tool with no output schema, the description carries the full burden well: it lists the categories of information returned, the eight-quarter basis for the forecast, and the meaning of the optional slug. An agent can decide whether to call it and what to expect without further context.
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?
Schema coverage is 100% and the schema already gives an example slug, so baseline would be 3. The description goes further by explaining what supplying the slug changes: it shifts the response to one manager's habit and history rather than the market-wide calendar, which the schema does not say.
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 names a specific resource and enumerates the concrete contents: the filing deadline, who has filed, who is expected per remaining day, and who is late. That is far more specific than the title. It does not explicitly contrast with the nearest sibling, latest_filings, which also reports who has filed, so an agent must infer the split between 'actual filings' and 'forecast'.
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?
Usage is implied by the content (use it to know the deadline and expected filing dates), and 'Give a slug for one manager's habit and history' hints at the single-manager variant. But there is no explicit when-to-use statement and no named alternative such as latest_filings or quarter_roundup, which overlap with the 'who has filed so far' portion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which value investors hold a company, how their holdings changed, its directors' recent share purchases and sales (Form 4), and basic SEC company facts.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Company slug from search, usually the lower-case ticker, e.g. 'ko' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorldHint=false, so the safety profile is fully covered. The description adds the scope of data returned (holdings deltas, Form 4 activity, SEC facts), but says nothing about time windows ('how their holdings changed' over what period, how 'recent' is defined), result size, or coverage limits.
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?
One compact sentence with no filler, and the primary payload (ownership) is front-loaded before insider filings and company facts. It is a noun-phrase fragment rather than a structured sentence, but nothing in it is wasted.
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?
For a read-only, single-parameter lookup with no output schema, the description covers the main content categories reasonably well. However, temporal scope for 'how their holdings changed' and 'recent' share purchases is undefined, and an agent cannot tell how much data to expect or how the sections are combined in the response.
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?
There is a single parameter with 100% schema description coverage, including a concrete example ('ko'), so the schema carries the semantics. The description adds no extra meaning about the slug or about resolving it from search, leaving this at the baseline.
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 names concrete content domains: value-investor holders, how holdings changed, directors' Form 4 purchases/sales, and basic SEC company facts, which is far more specific than the bare name 'get_company'. It lacks an explicit verb and never distinguishes itself from overlapping siblings like get_manager or insider_buying, so it stops short of a 5.
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?
Usage is only implied: by enumerating ownership, insider activity, and company facts, it signals 'use this for a company-level overview.' There is no explicit when-to-use, no exclusions, and no routing guidance against get_manager, insider_buying, or latest_filings, which cover adjacent ground.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything moatshark has on one value investor: its latest 13F (holdings, weights, change from the previous quarter), the overseas stakes a 13F never shows (from regulators in Japan, the UK, the Netherlands, France, Germany and Spain, with estimated values), its US funds' non-US holdings (N-PORT), 5% stake filings, Form 4 purchases since the 13F, and when it usually files.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Manager slug from search, e.g. 'berkshire-hathaway' | |
| limit | No | Holdings to return (default 25, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds some genuine behavioral context beyond them — the 13F lag ('change from the previous quarter', 'Form 4 purchases since the 13F') and the fact that overseas values are estimated rather than reported — but says nothing about cost/latency of this composite call, invalid-slug behavior, or how limit interacts with the result set.
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?
A single front-loaded sentence that leads with the broad claim and then itemizes sources, with no filler or restatement of the name. It is dense to the point of being a run-on list, but every clause names a distinct data source rather than padding.
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?
With no output schema, the description must describe what comes back, and it does so thoroughly by naming each source family (13F, overseas regulator filings, N-PORT, 5% stakes, Form 4, filing cadence). The remaining gaps — result shape, ordering, truncation under limit — are modest for a read-only lookup whose annotations already convey safety.
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?
Schema description coverage is 100%, including the slug example and the limit default/max, so the schema does the heavy lifting. The description adds no parameter-level meaning at all — it never mentions slug or limit — which is acceptable at full coverage but earns only the baseline.
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 opening clause ('Everything moatshark has on one value investor') plus the enumerated content makes clear this is a comprehensive per-manager holdings retrieval, distinguishable from get_company and the filing-oriented siblings by scope. It never explicitly contrasts itself with search or insider_buying, so the sibling differentiation is inferred from the data inventory rather than stated.
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?
Usage is only implied: an agent can infer 'use this when you want the full picture on a known manager,' but there is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as search (to find the slug) or insider_buying for a narrower view. The schema's 'slug from search' note carries the only workflow hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open-market share purchases reported on Form 4 in the last 90 days: by the value investors themselves (as 10% owners) and by companies' own directors and officers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, non-destructive, closed-world). The description adds useful behavioral scope: the 90-day lookback and the specific insider categories (10% owners, directors, officers), which affect interpretation of results.
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?
It is a single, front-loaded sentence with no filler. The parenthetical clarification is useful, though the phrasing is slightly dense.
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?
For a zero-parameter feed with no output schema, the description explains the data scope but not the return shape, result count, ordering, or whether results are global versus company-scoped. These omissions leave an agent unsure what to expect from the response.
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?
The tool takes zero parameters, so there is no parameter semantics to clarify; the baseline score of 4 applies. The description does not need to explain input fields.
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 states a specific dataset (open-market share purchases on Form 4 within 90 days) and the insider populations included, which distinguishes it from generic filing tools. However, it does not explicitly contrast itself with siblings like latest_filings or search.
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?
It describes what data the tool surfaces but gives no explicit when-to-use guidance, prerequisites, or alternatives. An agent must infer that this is the right tool for insider-buying analysis rather than a filing list or search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The newest 13F filings from the managers on moatshark, with each one's biggest buys and sales.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Filings to return (default 15, max 60) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a read-only, idempotent, closed-world operation, so the safety profile is covered. The one piece of added behavior is that each returned filing carries its biggest buys and sales, which is useful given there is no output schema. It does not mention ordering guarantees, pagination, or what a filing record otherwise contains.
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?
One sentence, no filler, and the defining scope ('newest') is front-loaded. Nothing could be cut without losing information.
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?
For a zero-required-parameter listing tool with full schema coverage and annotations covering safety, this is nearly complete, and the mention of buys/sales partially compensates for the absent output schema. It stops short of stating whether results are chronological or how the list behaves at the 60-item cap.
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?
Schema coverage is 100% and the single parameter already documents its default and max, so the description need not repeat it. The description adds nothing about the limit parameter, which is acceptable at this coverage level but earns only the baseline.
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 names a specific resource (13F filings), a specific scope (the newest ones from managers on moatshark), and the payload content (each filing's biggest buys and sales). An agent can tell this is a browse-latest tool rather than a search or forecast tool, though it never names the siblings that compete with it (filing_forecast, quarter_roundup).
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?
There is no guidance on when to reach for this versus filing_forecast or quarter_roundup, and no mention of when a limited, unfiltered latest-listing is or isn't appropriate. The only usage signal is the word 'newest', which is inference rather than instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What the managers owned, bought and sold in one quarter (from 2013 Q1). Omit the quarter for the latest one being filed.
| Name | Required | Description | Default |
|---|---|---|---|
| quarter | No | e.g. '2026-q2' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, read-only, idempotent, closed-world operation. Beyond that, the description adds useful behavioral context by specifying the data subject, the historical range from 2013 Q1, and the default behavior when quarter is omitted. It does not describe result format or pagination, but the annotations carry the safety profile.
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?
Two short sentences, front-loaded with the scope and followed by the key default behavior. Every phrase contributes useful information, with no redundant restatement of the name or annotations.
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?
For a simple one-parameter, read-only tool without an output schema, the description provides enough context to call it correctly: what it covers, the starting period, and how to omit the quarter. It could be slightly more complete by clarifying the relationship to similar insider-activity tools, but nothing essential is missing.
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?
Schema coverage is 100%, so the quarter parameter's format is already documented via its example. The description adds meaningful semantics beyond the schema by explaining that omitting quarter returns the latest quarter being filed, which is not inferable from the schema alone.
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 states the content and temporal scope: managers' holdings and buy/sell activity for a quarter, starting from 2013 Q1. It does not explicitly differentiate this comprehensive round-up from siblings like insider_buying or latest_filings, so it falls short of a 5.
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 gives one concrete usage instruction: omit the quarter to get the latest filed quarter. It does not explain when to choose this tool over alternatives such as insider_buying, latest_filings, or search, so usage guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find value investors (managers) and companies on moatshark by name, person or ticker. Returns slugs for get_manager and get_company, and results with ids for fetch.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Name, person or ticker, e.g. 'Buffett', 'Fundsmith', 'KO' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive/closed-world, so safety is covered. The description adds genuinely new behavior by disclosing what comes back — slugs usable by get_manager/get_company and ids usable by fetch — which matters because no output schema exists. Minor gaps remain (no mention of result limits or empty-result behavior).
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?
Two tight sentences with the core purpose first and the return-value routing second. Nothing is redundant or padded.
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?
For a one-parameter lookup with full annotations and no output schema, the definition covers purpose, input, and rough return shape adequately. Only edge-case behavior (no matches, result caps) is left out, which is a small gap given the tool's simplicity.
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?
Schema description coverage is 100% and the single 'query' parameter is already documented with examples. The description's 'by name, person or ticker' largely restates that, adding no new syntax or formatting guidance, so the baseline of 3 applies.
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?
States a specific verb and resource ('Find value investors (managers) and companies'), plus the matching keys (name, person, ticker). It also implicitly separates itself from siblings by noting it returns slugs for get_manager/get_company and ids for fetch, so an agent can tell it is a lookup step rather than a data-retrieval step.
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 mention that results feed get_manager, get_company, and fetch gives clear context for when to reach for this tool — before those detail tools. It stops short of naming an exclusion or a case where a sibling should be used instead, so it is strong context but not full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
fetchfiling_forecastget_companyget_managerinsider_buyinglatest_filingsquarter_roundupsearchSEC filings as tools: 13F superinvestor portfolios, Form 4 insider trades, XBRL and filing text
Value-investing research: fair values, valuation verdicts, quality scores and 13F portfolios
13F ownership behavior for 96 managers: signals, estimated cost basis, daily watchlist events.
Primary-source equity research: scores, screens, filings, insider trades and 13F holdings.
Add one secure layer between your agents and this server.