the13f를 위한 Model Context Protocol 서버입니다. Claude Desktop, Cursor, VS Code + Continue 및 모든 MCP 호환 호스트에서 기관 13F 인텔리전스를 사용할 수 있게 해주며, 별도의 HTTP 코드를 작성할 필요가 없습니다.
연구 데이터 전용입니다. 분기 말로부터 최대 45일 지연되는 공개된 SEC Form 13F 공시 자료를 기반으로 합니다. 과거 기관의 포지션이 미래의 성과를 예측하지는 않습니다. 이 내용은 투자 조언을 구성하지 않습니다. 모든 도구의 응답에는 disclaimer 필드가 포함되어 있으며, 호스트 LLM은 분석 결과와 함께 이를 반드시 표시해야 합니다.
Related MCP server: earningsprism-mcp
uvx the13f-mcp또는 직접 Python 환경을 관리하고 싶다면 pip install the13f-mcp를 사용하세요. Python 3.11 이상이 필요합니다.
결제나 신용카드 없이 무료로 이용 가능합니다:
이메일 입력 및 Cloudflare Turnstile 챌린지 해결
pf13f_ 키 복사 — 한 번만 표시됨
MCP 호스트 설정에 THE13F_API_KEY로 붙여넣기 (아래 참조)
호스트 재시작
무료 티어: 일일 100회 읽기 호출 가능; 쿼터는 UTC 자정에 초기화됩니다. 신호 및 보고서 도구는 유료 티어 출시 후 향후 마이너 버전에서 제공될 예정입니다.
~/Library/Application Support/Claude/claude_desktop_config.json (macOS) 또는 %APPDATA%/Claude/claude_desktop_config.json (Windows)을 편집하세요:
{
"mcpServers": {
"the13f": {
"command": "uvx",
"args": ["the13f-mcp"],
"env": {
"THE13F_API_KEY": "pf13f_..."
}
}
}
}Claude Desktop을 재시작하세요. MCP 도구 목록에 The13f 도구가 나타나야 합니다.
설정 → MCP → 서버 추가. 동일한 JSON 블록을 "Custom" 필드에 붙여넣으세요.
설정 → experimental.modelContextProtocolServers → THE13F_API_KEY를 환경 변수로 포함하여 uvx the13f-mcp를 실행하는 stdio 전송을 추가하세요. https://the13f.com/developers/signup-success의 키 확인 페이지에서 키가 이미 채워진 복사-붙여넣기용 스니펫을 확인할 수 있습니다.
도구 | 기능 |
| 보유 데이터가 있는 모든 분기 + 최신 분기 |
| 이름으로 13F 보고자 자동 완성 |
| 특정 CIK + 분기에 대한 전체 포지션 |
| 한 번의 호출로 최대 25개의 |
| 매니저별 요약 통계를 포함한 8,600명 이상의 보고자 전체 목록 |
| 전체 목록에서 포트폴리오 매칭 |
| 분기별 가장 많이 보유된 증권 |
| 기관 체제 스냅샷 (IIOI 복합 지수, 상태, 전환) |
| 섹터별 자금 흐름 및 위험 포지션 |
버전 | 도구 | 요구 사항 |
v0.2.0 |
| 스탠다드 티어 구독 |
v0.3.0 |
| 스탠다드 티어 + 저장된 카드; 2단계 확인 |
무료 티어 읽기 도구는 데이터를 탐색하고 프롬프트를 작성하기에 충분합니다. 신호 및 보고서 도구는 유료 티어 결제 시스템이 준비된 후 제공될 예정입니다.
"2025년 4분기 기준 버크셔 해서웨이의 상위 20개 포지션을 가져와서 전 분기 대비 가장 많이 증가한 종목을 요약해줘."
"나는 AAPL, MSFT, NVDA를 동일 비중으로 보유하고 있어. 내 포트폴리오와 가장 유사한 포트폴리오를 가진 기관 매니저 5명을 찾아줘."
"지난 분기에 13F 보고자들이 가장 공격적으로 비중을 줄인 섹터는 어디야? 그 감소를 주도한 상위 3명의 매니저를 보여줘."
MCP 호스트의 LLM이 적절한 도구를 선택하고, 인자를 채우며, disclaimer를 표시하고, 결과를 구조화된 JSON으로 반환합니다.
변수 | 기본값 | 제어 항목 |
| (없음) |
|
|
| the13f의 |
|
| 요청당 HTTP 타임아웃(초). 최소 5초. |
공개 소스: https://github.com/pickelfintech/the13f-mcp. 이는 PyPI, Glama.ai 및 MCP 커뮤니티 목록이 가리키는 스냅샷입니다. GitHub 저장소는 gitlab.com/pickel-fintech/the13f-mcp의 푸시 미러이며, GitLab이 기본 저장소로서 릴리스 CI를 수행합니다. 버그 리포트와 PR은 양쪽 모두에서 허용됩니다.
MIT — LICENSE 참조. 이 클라이언트가 호출하는 호스팅된 api.the13f.com API는 별도의 서비스입니다. 무료 API 키(일일 100회 호출)가 필요하며, https://the13f.com/developers/에서 가입하세요.
tom@pickelfintech.com — 도구 호출 실패 시 반환되는 request_id 필드를 인용하면 가장 빠르게 처리됩니다.
MIT. LICENSE 참조. MCP 서버 소스는 MIT 라이선스를 따르며, the13f API 자체의 사용은 https://the13f.com/terms.html의 서비스 약관을 따릅니다.
Research data only. Returns disclosed institutional positions; do not infer manager intent or future direction. Match a portfolio against the 13F universe and return the closest (or deliberately-different) managers.
Args: holdings: list of {"ticker": "AAPL", "weight": 0.05}; weight optional (equal weights default). quarter: defaults to latest quarter if None. top_n: 1-50, default 10. direction: "similar" (closest matches) or "unlike" (most different).
Returns: {"quarter": "...", "matches": [{"cik": ..., "similarity_score": ..., ...}, ...], "disclaimer": "..."}
| Name | Required | Description | Default |
|---|---|---|---|
| holdings | Yes | ||
| quarter | No | ||
| top_n | No | ||
| direction | No | similar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It clearly explains that returns are disclosed institutional positions, not manager intent, and that direction ('similar' or 'unlike') controls behavior. Lacks details on edge cases or performance, but is adequate for 4 params.
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?
Description is concise with clear sections: research warning, purpose, args in bullet-like format, and returns. No unnecessary words, front-loaded with important caveat.
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 4 params, no output schema, and no annotations, the description adequately covers inputs and output structure. Returns object described with fields and disclaimer. A minor gap: no mention of error handling or data source limitations beyond the explicit warning.
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 has 0% description coverage, but description explains each parameter: holdings with example format (ticker and weight), quarter defaults to latest, top_n range, direction enum with meanings. Adds value by clarifying weight optional and defaults.
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 tool matches a portfolio against the 13F universe and returns closest or deliberately-different managers, specifying verb (match) and resource (13F universe). It also distinguishes from siblings like get_manager_holdings by focusing on similarity search, not individual holdings.
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 explicitly states 'Research data only' and warns about inferring manager intent, indicating when to use. However, it does not explicitly contrast with alternatives like search_managers or get_consensus_portfolio, though the unique purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Research data only. Returns disclosed institutional positions; do not infer manager intent or future direction. Return the top-N consensus portfolio - securities held by the most institutional managers.
Args: quarter: quarter code (e.g. "q4y2025").
Returns: {"quarter": "...", "count": 50, "securities": [{"ticker": ..., "weight_pct": ..., ...}, ...]}
| Name | Required | Description | Default |
|---|---|---|---|
| quarter | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries the full burden. It clearly states the tool is for research only, returns historical positions without inference of intent. It also specifies the output includes top-N securities with weight percentages.
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 description is concise: two sentences plus an args/returns block. It front-loads the key caveat 'Research data only'. Every sentence adds value, though the returns example could be slightly more terse.
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 there is no output schema and only one parameter, the description adequately explains the tool: what it returns (securities, ticker, weight), the quarter format, and the top-N nature. The research caveat adds needed context. Not perfect, but sufficient for this complexity.
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 has 0% coverage but only one parameter quarter, and the description includes an example format 'q4y2025'. This adds semantic meaning beyond the schema's type: string. The return value example also clarifies the format.
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 uses specific verb+resource: 'Return the top-N consensus portfolio - securities held by the most institutional managers'. It clearly distinguishes from siblings by stating 'Research data only' and listing sibling tools like get_manager_holdings which focus on individual managers.
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 includes a clear disclaimer: 'Research data only. Returns disclosed institutional positions; do not infer manager intent or future direction.' This guides the agent on limitations. However, it does not explicitly state when to use this vs alternatives, though the sibling context implies use for broad consensus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Research data only. Returns disclosed institutional positions; do not infer manager intent or future direction. Return all positions held by a 13F filer in a given quarter.
Args: cik: zero-padded 10-digit SEC CIK (e.g. "0001037389"). quarter: quarter code like "q4y2025".
Returns: { "cik": "...", "quarter": "...", "n_positions": 3185, "total_value_thousands": 64461244358.0, "holdings": [{"CUSIP": ..., "TICKER": ..., "VALUE": ..., ...}, ...], "disclaimer": "..." }
| Name | Required | Description | Default |
|---|---|---|---|
| cik | Yes | Zero-padded 10-digit SEC CIK. | |
| quarter | Yes | e.g. q4y2025 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It highlights that this is research-only data and warns about intent inference, which adds useful context, but does not discuss mutation side effects, rate limits, or data freshness implications.
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 description is well-structured with clear Args and Returns sections, and is moderately concise. The first sentence adds critical context about the tool's limitations, though the return example is somewhat verbose.
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 the low complexity (2 params, 100% schema coverage, no nested objects), the description provides sufficient context including a clear return example and usage caveats. No output schema exists, so the return format description is valuable.
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 schema already documents both parameters. The description provides the exact format for cik (zero-padded 10-digit) and a quarter example, but adds little beyond what the schema already states.
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 tool returns disclosed institutional positions for a 13F filer in a given quarter, distinguishing it from siblings like find_similar_managers and get_consensus_portfolio.
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 notes 'Research data only' and warns against inferring intent, but does not explicitly state when to use this tool versus alternatives like get_manager_holdings_bulk or get_consensus_portfolio.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Research data only. Returns disclosed institutional positions; do not infer manager intent or future direction. Look up holdings for many (cik, quarter) pairs in one call (Tier 3).
More efficient than calling get_manager_holdings repeatedly: groups by quarter so each parquet file is read at most once. Single billing event regardless of how many pairs you supply (up to 25 per call).
Args: pairs: list of {"cik": "...", "quarter": "..."} dicts. Min 1, max 25.
Returns: { "results": [ {"cik": "0001067983", "quarter": "q4y2025", "status": "ok", "n_positions": 42, "total_value_thousands": ..., "holdings": [...]}, {"cik": "0001234567", "quarter": "q4y2025", "status": "not_found", "error": "..."}, ... ], "n_requested": 5, "n_ok": 4, "n_failed": 1 }
Per-pair errors do NOT raise; check status field on each result. Use this when you need holdings for multiple managers/quarters at once (e.g. comparing a portfolio across periods or surveying peer institutions).
| Name | Required | Description | Default |
|---|---|---|---|
| pairs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly discloses that this is a Tier 3 call, groups by quarter for efficiency, and results include both success and failure statuses per pair without raising errors. A thorough picture is given, though slightly more detail on rate limits or data freshness could push to 5.
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 description begins with a short, direct summary, followed by efficiency rationale, parameter explanation, and return format. Each sentence adds value; no filler.
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?
Despite lack of output schema, the description covers input, output, behavior, error handling, and usage context. It is complete for a bulk lookup tool of moderate complexity.
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 detailed docstring explains the pairs parameter format, constraints (min/max), and expected structure. It also describes the return format, including the per-item response with fields like status, n_positions, total_value_thousands, and holdings. Since schema coverage is 0%, the description compensates fully.
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 tool retrieves disclosed institutional holdings for multiple (cik, quarter) pairs at once, distinguishing it from the single-pair sibling get_manager_holdings. It specifies research-only data and cautions against inferring intent, making the purpose precise and differentiated.
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 explicitly says when to use this tool: when you need multiple holdings, comparing portfolios across periods, or surveying peer institutions, as it is more efficient than repeated single calls. It also sets expectations by noting per-pair errors do not raise exceptions, so the consumer must check the status field.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Research data only. Returns disclosed institutional positions; do not infer manager intent or future direction. Return the institutional regime snapshot for a quarter (IIOI composite, regime state, transition).
Args: quarter: quarter code.
Returns: {"quarter": "...", "iioi_composite": 62.4, "regime_state": "High Optimism", ...}
| Name | Required | Description | Default |
|---|---|---|---|
| quarter | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that data reflects institutional positions and should not be interpreted as intent, which is helpful behavioral context beyond mere operation. No annotations exist, so description compensates well.
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?
Description is concise: two sentences plus an Args/Returns section. No wasted words, clearly front-loaded with key purpose and caveat.
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 simple schema (1 param, no output schema, no enums), the description provides enough context: purpose, caveat, and return example. However, lacks details on quarter format or sources but sufficient for a straightforward tool.
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 description mentions 'quarter: quarter code' which adds minimal meaning beyond the schema (which has no description). With 0% schema coverage, the description partially compensates but lacks detail on format or valid quarter codes.
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?
Description states tool returns institutional regime snapshot for a quarter, with clear verb 'Return' and resource 'institutional regime snapshot'. It distinguishes itself from siblings like list_quarters or search_managers by focusing on regime state data.
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?
Description explicitly says 'Research data only' and warns against inferring manager intent, which guides appropriate use. However, it does not explicitly state when to use this vs alternatives or exclude cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Research data only. Returns disclosed institutional positions; do not infer manager intent or future direction. Return per-sector institutional capital flow intelligence for a quarter.
Args: quarter: quarter code. sector: optional GICS sector to filter (e.g. "Information Technology").
Returns: {"quarter": "...", "sectors": [{"gics_sector": ..., "net_capital_flow_thousands": ..., "risk_posture": ..., ...}, ...]}
| Name | Required | Description | Default |
|---|---|---|---|
| quarter | Yes | ||
| sector | No | GICS sector name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, making the description the sole source for behavioral disclosure. It appropriately identifies the data as research-only, returns institutional positions, and cautions against inferring intent. However, it does not mention whether the tool is a simple read operation or has any side effects, rate limits, or pagination behavior. With no annotations, the description provides adequate transparency but could be more comprehensive.
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 description is well-structured with a brief introduction, argument descriptions in a list, and a return format example. It is concise and front-loaded with the critical warning about data limitations. The only improvements would be to remove the redundant 'Research data only' phrase if the same information is already in the tool title (but title is null), so it earns its place.
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 the tool's complexity (2 parameters, no output schema), the description covers the purpose, the data nature, and the return format with an example. It is largely complete for a straightforward query tool. However, it does not explain what 'risk_posture' means in the output, which would be helpful. Sibling tools are not explicitly differentiated, but the purpose is distinct enough.
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 description adds meaning beyond the input schema by explaining that 'quarter' is a quarter code and 'sector' is an optional GICS sector filter with an example. Schema coverage is 50% (only sector has a description), but the description compensates by providing context for both parameters. It does not list valid quarter codes or explain the format, which would be helpful, but the combination of schema and description is sufficient.
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 it returns per-sector institutional capital flow intelligence for a quarter, specifying the data is research-only and should not be used to infer manager intent. The verb 'get' combined with 'sector flows' makes the tool's purpose unambiguous and distinguishes it from sibling tools like 'get_manager_holdings' which focus on individual managers.
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 explicitly warns about data limitations ('do not infer manager intent or future direction') and indicates this is for research purposes. It mentions an optional GICS sector filter, but does not explicitly contrast with sibling tools or specify when to use alternatives like 'get_consensus_portfolio'. The usage context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Research data only. Returns disclosed institutional positions; do not infer manager intent or future direction. Return the full universe of 13F filers with per-manager AUM.
Args: active_only: if true (default), only managers present in the latest quarter.
Returns: { "count": 8625, "active_only": true, "managers": [{"cik": "...", "name": "...", "latest_aum": ..., ...}, ...], "disclaimer": "..." }
NOTE: response can be ~6 MB JSON; consider filtering client-side.
| Name | Required | Description | Default |
|---|---|---|---|
| active_only | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description warns about response size (~6 MB) and includes a disclaimer. No annotations exist, so the description partially fulfills behavioral transparency, but it does not detail any destructive behavior or authorization needs.
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?
Description is well-structured with clear sections for description, args, returns, and a note. Each sentence serves a purpose, but the format could be slightly more concise.
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 one parameter, no output schema, and no annotations, the description is complete: it explains purpose, parameter, return format, and a size warning. Enough for an agent to use correctly.
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 0%, so description must compensate. It explains the single parameter 'active_only' and its default behavior clearly, adding value beyond schema. The Returns section also adds clarity.
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?
Description clearly states the tool returns 'the full universe of 13F filers with per-manager AUM', a specific verb+resource. It distinguishes from sibling tools like 'search_managers' by offering a complete list rather than filtered 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?
The description clarifies that data is for research only and cautions against inferring intent. It provides a note on response size, suggesting client-side filtering. However, it does not explicitly contrast with sibling tools or state when to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Research data only. Returns disclosed institutional positions; do not infer manager intent or future direction. Return all quarter codes with available data.
Returns: {"quarters": ["q1y2013", ..., "q4y2025"], "latest": "q4y2025"}
Use the latest quarter by default unless the user specifies one.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the burden and does well: it warns the data is research-only and not to infer manager intent, which is crucial behavioral context that goes beyond the simple listing function.
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 description is extremely concise with three short sentences, each serving a distinct purpose: data caveat, output format, and usage instruction. No wasted words.
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 parameterless tool with no output schema, the description fully covers purpose, behavioral caveats, output format, and default usage. It is complete for its 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?
The tool has no parameters, so the description explains the output format and default behavior, adding value beyond the empty schema. The baseline is 4 for zero parameters.
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 it returns quarter codes with available data, specifying the exact output format and default behavior. It distinguishes itself from siblings by being a simple listing tool with no input parameters, unlike other tools that require manager names or filters.
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 explicitly advises to use the latest quarter by default unless the user specifies one, which provides clear usage guidance. However, it does not explicitly mention when not to use this tool or alternatives, though its purpose is distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Research data only. Returns disclosed institutional positions; do not infer manager intent or future direction. Find institutional 13F filers by name (case-insensitive substring, min 2 chars).
Args: query: substring of the manager's name (e.g. "renaissance", "berkshire"). limit: max results to return, 1-50, default 10.
Returns: { "query": "...", "results": [ {"cik": "0001037389", "name": "Renaissance Technologies Llc", "latest_aum": 64461244358, "available_quarters": [...]}, ... ], "disclaimer": "Research data only..." }
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Substring of the manager's name. | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly states the data limitation (research data only) and the constraint that positions are disclosed, not reflecting intent. This is a strong disclosure for a search 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?
Description is brief but front-loaded with the critical caveat. It uses clear sections for args and returns. Slightly more verbose than necessary but still efficient.
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 search tool with only 2 parameters and no output schema, the description covers the data disclaimer, parameter semantics, and return structure adequately. No output schema is needed as description details the response format.
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 50% (one described, one not). Description adds examples for 'query' and explains 'limit' range and default, going beyond the schema. However, both parameters are simple, and the schema already covers constraints.
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?
Clearly states it searches institutional 13F filers by name, with case-insensitive substring search and minimum 2 chars. Distinguishes from siblings like 'find_similar_managers' and 'list_all_managers' by specifying the search scope and data constraints.
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 explicitly warns that data is research-only and not to infer intent. However, it does not contrast with siblings (e.g., when to use this vs 'find_similar_managers') nor specify when not to use it.
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.
v0.1.1find_similar_managersget_consensus_portfolioget_manager_holdingsget_manager_holdings_bulkget_market_regimeget_sector_flowslist_all_managerslist_quarterssearch_managersScored across 9 tools
Each tool targets a distinct operation: searching managers, retrieving holdings, comparing portfolios, getting consensus data, sector flows, regime states, and quarter listings. No two tools have overlapping purposes.
All tool names follow a consistent verb_noun pattern (find_, get_, list_, search_) with clear action and domain. The only minor deviation is 'find_similar_managers' being more specific than others, but it remains readable.
With 9 tools, the server covers a well-scoped domain of 13F data analysis including lookups, comparisons, and market overview. Each tool serves a clear purpose without bloat.
The tool set covers key workflows: manager search, holdings retrieval (single and bulk), portfolio comparison, consensus portfolio, sector flows, and market regime. A minor gap is the lack of a tool to retrieve historical quarter-by-quarter changes for a single manager, but the core CRUD and analysis operations are present.
Global stock research, ML forecasts, valuation signals, screeners & portfolio tracking in Claude
Real SEC, 13F, insider, congress & macro data your AI agent can cite. Hosted MCP, 24 tools.
Market data, SEC 13F/filings, quant scores, forecasts for agents. x402 USDC pay-per-call on Base.
SEC filings for Claude, ChatGPT, Cursor — 23 tools + 5 recipes. Financials, insider, 13F, funds.
