U.S. closed-end funds from SEC filings: activist stakes, tender offers, votes, costs, holdings.
Scored across 9 tools
Every tool targets a distinct resource and action: get_activist vs list_activists (single vs list), get_fund vs search_funds (single vs search), get_fund_events vs list_events (single vs all funds), get_fund_holdings vs which_funds_hold (holdings of a fund vs funds holding a security). No overlap in purpose or return type.
Names are consistently lowercase with underscores and mostly follow a verb_noun pattern (get_*, list_*, search_*), but two tools deviate: latest_filings (adjective_noun) and which_funds_hold (interrogative). The deviations are still intuitive and don't break the overall pattern.
9 tools is well within the ideal 3-15 range and each tool covers a necessary query type for the closed-end fund domain. No redundancy or bloat, and the count matches the scope of the service.
The tool set covers all core read-only workflows: searching/finding funds, retrieving fund details, events, and holdings, listing activists and events, recent filings, and reverse lookup by holding. For an informational SEC-filing-based service, there are no obvious gaps that would prevent an agent from fulfilling typical user requests.
Describes one large investor in plain words: how many funds it is in and where it is pushing for changes, what it usually does, the funds it has left and its recent moves, from SEC filings, with as-of dates and links to the original documents. Results are informational, read automatically from public filings and may contain errors; always show the source link and never present results as personal investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The investor's short name from list_activists, e.g. saba. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable context beyond annotations: it is read from public filings, may contain errors, must always show the source link, and must not be presented as personal investment advice. This is exactly the kind of behavioral disclosure needed.
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 a single, information-dense sentence that front-loads the core purpose and then layers details and disclaimers. It is efficient, though the sentence is somewhat long and could be split for readability. Still, 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 tool with one parameter and no output schema, the description fully covers what the agent needs: what is returned (funds, pushes, moves, dates, links), the source (SEC filings), and the required output behavior (show source link, avoid advice). 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?
The single parameter slug is fully documented in the schema with an example and a source reference to list_activists. Schema description coverage is 100%, so the tool description adds no further parameter meaning. The baseline of 3 is appropriate.
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 verb ('Describes') and a precise resource ('one large investor') and enumerates the content it returns (funds, pushes, moves, recent filings). It clearly differentiates from list_activists, which lists investors, and other sibling tools that focus on funds or 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?
Usage is implied by the parameter schema (slug from list_activists) and the description's focus on a single investor. It does not explicitly name alternatives or exclusion criteria, but the workflow is clear: you first list activists then fetch details by slug.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tells you, in plain words, whether a large investor is targeting a U.S. closed-end fund, whether the fund has announced something you must act on and by when, what it costs, how much it borrows, how big it is and what it holds, from SEC filings, with as-of dates and links to the original documents. Results are informational, read automatically from public filings and may contain errors; always show the source link and never present results as personal investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | The fund's exchange ticker, e.g. JOF (use search_funds when you only know the name). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent annotations, the description adds critical behavioral context: results are informational, read automatically from public filings, may contain errors, and must always include the source link. It also explicitly states never to present results as personal investment advice. This is valuable disclosure that the annotations alone do not provide.
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 a single long sentence that packs many details (targeting, actions, costs, borrowing, size, holdings, as-of dates, links, error disclaimer). It front-loads the core purpose and then lists specifics, but the run-on structure could be split into two sentences for clarity. Still, it is efficient and avoids redundancy.
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-parameter tool with no output schema, the description fully explains what the agent can expect: the types of information returned (targeting, action items, costs, etc.) and the presence of as-of dates and source links. It also warns about potential errors and usage requirements, making it complete for correct invocation.
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 schema already documents the single parameter ticker fully (including the hint to use search_funds when only the name is known). The description adds no additional parameter-level detail. Since schema coverage is 100%, a baseline of 3 is appropriate.
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 what the tool does: it tells the user about a large investor targeting a U.S. closed-end fund, action items, costs, leverage, size, and holdings, all sourced from SEC filings with as-of dates and links. It distinguishes itself from siblings like get_fund_holdings and get_fund_events by offering a comprehensive single-fund overview.
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 implies that this is the go-to tool for a full fund snapshot, but it does not explicitly state when to choose it over alternatives such as get_fund_holdings or get_fund_events. It also does not mention exclusions (e.g., 'use get_fund_holdings if you only need holdings'). The schema for ticker does hint to use search_funds for name-only lookups, but that guidance is not in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists one closed-end fund's dated announcements a holder may need to act on (offers to buy back shares, shareholder votes, closings, mergers, offers of new shares, payout notices) with the deadline and what to do, from SEC filings, with as-of dates and links to the original documents. Results are informational, read automatically from public filings and may contain errors; always show the source link and never present results as personal investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| months | No | How many months back to look, 1 to 120 (default 24). | |
| ticker | Yes | The fund's exchange ticker, e.g. JOF (use search_funds when you only know the name). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and idempotent, so the description is not needed for that. It adds valuable behavioral context by warning that results are informational, 'may contain errors,' and should always be presented with the source link and never as personal investment advice.
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 compact and front-loads the core purpose, then adds essential caveats in the second sentence. The parenthetical list of event types is slightly dense but still serves to clarify scope without waste.
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 compensates by specifying what results contain: event types, deadlines, actions, as-of dates, and source links. It also covers the reliability caveat and the required presentation behavior, making the tool fully understandable for selection and invocation.
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%, with both 'ticker' and 'months' already described, including defaults and an example. The description does not add parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.
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 verb and resource: 'Lists one closed-end fund's dated announcements' and enumerates concrete event types such as buyback offers, shareholder votes, and mergers. This clearly distinguishes it from sibling tools that cover holdings, fund profiles, or general events.
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 makes the intended use clear: it is for announcements 'a holder may need to act on,' with deadlines and instructions, sourced from SEC filings. It does not explicitly name alternatives or exclusions, but the singular 'one closed-end fund's' scope provides enough contextual routing for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describes what a closed-end fund holds - the mix by type of holding and country and its largest positions - from SEC filings, with as-of dates and links to the original documents. Results are informational, read automatically from public filings and may contain errors; always show the source link and never present results as personal investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | The fund's exchange ticker, e.g. JOF (use search_funds when you only know the name). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses that data is read from public filings and 'may contain errors', and it instructs the agent to 'always show the source link' and not present results as personal investment advice. This is important behavioral context the annotations do not provide.
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 main description is two sentences with the core action front-loaded, followed by essential caveats. Every sentence adds value and there is no redundant or filler text.
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 a single parameter and no output schema, the description covers what the result contains (holding mix, country, largest positions, as-of dates, source links), the data source, and accuracy limitations. An agent has enough context to invoke it correctly and handle its output appropriately.
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 ticker parameter already has a useful description with an example and a search_funds fallback. The tool description does not add new parameter detail beyond framing the data as closed-end fund holdings, so the baseline of 3 is appropriate.
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 opens with a specific verb and resource: it 'Describes what a closed-end fund holds' and enumerates the exact dimensions (mix by type/country, largest positions) plus provenance from SEC filings. This clearly differentiates it from sibling tools like get_fund or get_fund_events, even without naming them.
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 intended use is implied by the description, but there is no explicit guidance about when to prefer this over sibling tools such as get_fund, get_fund_events, or which_funds_hold. The only alternative it names is search_funds, and that is in the schema's parameter description rather than the tool description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the newest notices large investors filed about owning 5% or more of a fund (raised or cut a stake, may push for changes, passive, sold down), one plain sentence each, from SEC filings, with as-of dates and links to the original documents. Results are informational, read automatically from public filings and may contain errors; always show the source link and never present results as personal investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many days back to look, 1 to 365 (default 7). | |
| cef_only | No | True (default) = closed-end funds only; False = companies too. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description adds valuable behavioral context: results are informational, read automatically from public filings, may contain errors, and the agent must show the source link and avoid presenting results as investment advice. This is a meaningful addition that helps the agent handle results responsibly. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the core purpose and output format, followed by caveats. It earns its place, though the second sentence could be tightened. Overall it is appropriately structured and not bloated.
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?
The description covers the return format (plain sentences with dates/links), data source (SEC filings), error potential, and usage constraints. Given there is no output schema and only two simple parameters, this is essentially complete for an agent to call the tool 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?
Both parameters (days, cef_only) already have complete descriptions in the input schema (100% coverage). The tool description does not add any new meaning or context for these parameters, so the baseline score 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?
The description clearly states the tool lists the newest notices from large investors about owning 5% or more of a fund, including the types of actions (raised, cut, passive, sold down) and the output format (one plain sentence with as-of dates and source links). This specific verb+resource description distinguishes it from sibling tools like list_events or get_fund_events, which focus on different event types or fund-specific 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?
The description implies usage: an agent should call this when wanting recent SEC filings from large investors about stake changes. However, it provides no explicit guidance on when to choose this over alternatives (e.g., list_events for general events or get_fund_holdings for current positions), and no exclusionary conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the large investors we follow - those who buy into closed-end funds and sometimes push for changes - with how many funds each is in now and its newest move, from SEC filings, with as-of dates and links to the original documents. Results are informational, read automatically from public filings and may contain errors; always show the source link and never present results as personal investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations already declare readOnlyHint=true and idempotentHint=true, the description adds valuable behavioral context: results are machine-read from public filings, may contain errors, require source-link display, and must not be presented as personal investment advice. This goes well beyond the safety profile in the annotations.
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 sentences carry a complete picture: the first front-loads the purpose and data fields, the second adds necessary caveats. No filler or repetition.
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 parameter-less list tool with no output schema, the description covers the return contents, data provenance, and result-handling guidance. It could be slightly more explicit about any default ordering or result limits, but those are not critical for correct invocation.
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 the baseline per the rubric is 4. The description correctly focuses on output semantics rather than input semantics, and there is nothing to compensate for in the schema.
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 opens with a specific action and resource ('Lists the large investors we follow'), then details the content (fund counts, newest move), source (SEC filings), and metadata (as-of dates, document links). It clearly differentiates itself from sibling tools like get_activist, which focuses on a single investor.
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 intended use is implied: call this when you want an overview of the large investors the system tracks. However, it does not explicitly contrast with alternatives such as get_activist (for a single investor) or list_events (for event-level data), nor does it state any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists recent announcements across all U.S. closed-end funds (buy-back offers, votes, closings, mergers, offers of new shares, payout notices), newest first, each with the fund, the deadline and what to do, from SEC filings, with as-of dates and links to the original documents. Results are informational, read automatically from public filings and may contain errors; always show the source link and never present results as personal investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Only one kind of announcement, written as its code: tender_offer (offer to buy back shares), tender_update (buy-back offer updated), tender_result (buy-back offer results), proxy_contest (a fight over the shareholder vote), liquidation (closing down), open_ending (vote on becoming a regular mutual fund), term_change (vote on the fund's planned closing date), merger (folding into another fund), merger_acquirer (taking in another fund), rights_offering (offer of more shares to holders), share_offering (may sell new shares), managed_distribution (fixed payout notice), preferred_redemption (repaying borrowed money), deregistration (stopped reporting to the regulator), delisting (shares no longer trade). | |
| since | No | Only announcements filed on or after this date, written YYYY-MM-DD. | |
| only_open | No | True = only announcements a holder can still act on. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as read-only, idempotent, and non-destructive. The description adds valuable behavioral context: results are informational, read automatically from public filings, may contain errors, and must always show the source link and never be presented as investment advice. This goes beyond annotations and sets expectations for reliability and usage.
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: front-loaded with the main purpose, then details of content, followed by caveats. While slightly long, each sentence contributes (scope, content, reliability, advice disclaimer), with no filler. It earns its length.
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 explains the return structure (fund, deadline, what to do, as-of dates, links) and the data source (SEC filings). It covers the essentials for an agent to call and interpret results, though pagination or result limits are not mentioned, which is a minor gap.
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 all three parameters (kind, since, only_open) are fully documented in the schema with detailed descriptions. The tool description adds no additional parameter meaning beyond what the schema provides, matching the baseline of 3 for high coverage.
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 lists recent announcements across all U.S. closed-end funds, specifying the types (buy-back offers, votes, closings, etc.) and the content per item (fund, deadline, action). This specific verb-resource-scope combination distinguishes it from fund-specific tools like get_fund_events.
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 implies usage for cross-fund announcement scanning but does not explicitly contrast with siblings like get_fund_events or latest_filings, nor state when to prefer this tool over alternatives. The scope is clear but exclusions or conditions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds a U.S. closed-end fund by its ticker, its name or the firm that runs it and returns up to 6 matches with a link to each fund's page, from SEC filings, with as-of dates and links to the original documents. Results are informational, read automatically from public filings and may contain errors; always show the source link and never present results as personal investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Ticker, fund name or the firm that runs it, e.g. JOF or 'japan smaller'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description fully aligns with them (no contradiction). The description goes well beyond those by disclosing the 6-match cap, SEC-filing source, as-of dates, error caveat, the mandate to always show the source link, and the no-investment-advice disclaimer — genuinely useful behavioral context an agent 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?
Two sentences with zero waste. The first front-loads purpose and result shape; the second adds caveats and usage obligations. Every clause 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?
There is no output schema, so the description correctly carries the burden of explaining return values — up to 6 matches, links to fund pages, as-of dates, and source-document links. For a single-parameter search tool, nothing an agent needs to invoke it correctly 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 schema already documents 'query' with the example 'JOF or japan smaller'. The description reinforces the accepted query types (ticker, name, firm) consistently with that example but doesn't add syntax, formatting, or matching rules beyond the schema, meeting the baseline for high coverage.
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 ('Finds'), a precise resource ('U.S. closed-end fund'), and the three search dimensions (ticker, name, firm). This cleanly separates it from sibling retrieval tools like get_fund and list_activists — it's a search-by-partial-identifier tool, not a point lookup or a list.
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 conveys clear context: use this when you have a ticker, fund name, or firm name to search on. It doesn't explicitly name alternatives or exclusion conditions (e.g., 'use get_fund when you already have a fund ID'), so it stops short of the strongest routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists every U.S. closed-end fund whose latest quarterly holdings report includes a company or bond you name (or its CUSIP or ISIN), with each fund's share of it and the report date, from SEC filings, with as-of dates and links to the original documents. Results are informational, read automatically from public filings and may contain errors; always show the source link and never present results as personal investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A company or bond name as printed on a statement, or its CUSIP or ISIN, e.g. 'apple'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint, idempotentHint, and destructiveHint annotations, the description adds meaningful behavioral context: data comes from public SEC filings, is read automatically, may contain errors, and should be presented with source links and without investment-advice framing. This substantially helps the agent set user expectations and handle results correctly.
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 a single dense sentence that front-loads the core capability and then appends the necessary data-source, accuracy, and usage caveats. Every clause earns its place, with no filler or redundant restatement.
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 read-only tool, the description covers the query semantics, the result content (funds, share, report date, as-of dates, source links), and important reliability caveats. It does not specify the exact response shape or no-results behavior, but the absence of an output schema makes the provided field-level detail sufficient for safe invocation.
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 single required parameter 'query' is already fully documented in the schema with accepted forms and an example. The tool description rephrases that a company/bond name, CUSIP, or ISIN can be used but does not add new parameter-specific meaning beyond what the schema provides.
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 verb and resource: it lists U.S. closed-end funds from SEC filings based on a named security, CUSIP, or ISIN, and includes each fund's share and report date. This clearly differentiates it from siblings like get_fund_holdings, which would look up holdings for a given fund rather than funds holding a given security.
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 implies the tool should be used when you need to find which funds hold a particular security, and the schema reinforces the accepted query forms. However, it does not explicitly state when not to use it or name sibling alternatives for the opposite lookup direction, so the usage guidance is mostly inferred.
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.
get_activistget_fundget_fund_eventsget_fund_holdingslatest_filingslist_activistslist_eventssearch_fundswhich_funds_holdSEC filings, insider trades, and earnings data
SEC & institutional filings — Form 4, 8-K, 13F, Schedule 13D, Form D, IPO & earnings calendars.
SEC insider filings as clean economic events - Form 4 trades, Form 144 notices, 13D/G stakes.
SEC filings, financial statements, metrics, insider and institutional holdings as structured data
Add one secure layer between your agents and this server.