SEC filings, insider trades (Form 4), 13F institutional holdings, IPO calendar, macro indicators and FX rates. Pay-per-call in USDC on Base via x402 — no signup, no API keys.
Corpus coverage: which SEC datasets exist, 10-K backfill progress by quarter (2015→now), and — given a ticker — which fiscal years are on file for it. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | No | Optional stock ticker to check company-specific 10-K coverage |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses that the tool is free and describes the coverage information returned, but it does not state whether the operation is read-only, what the response structure looks like, or any limitations beyond optional ticker 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?
The description is a single, information-dense sentence that packs relevant details (datasets, backfill progress, fiscal years, free) without unnecessary fluff. It is front-loaded with the core concept 'Corpus coverage'.
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 no output schema and no annotations, the description is reasonably complete for a simple metadata tool, clearly listing the covered information. However, it does not describe the exact return format or how output may differ with and without the optional ticker, leaving some ambiguity for an agent.
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 fully documents the only parameter 'ticker' with description and examples. The description adds minimal extra meaning beyond saying 'given a ticker', which largely duplicates the schema. Baseline 3 is appropriate because schema coverage is 100%.
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 identifies the tool as providing corpus coverage details: which SEC datasets exist, 10-K backfill progress, and per-ticker fiscal year availability. It distinguishes itself from sibling data-retrieval tools by focusing on coverage/metadata, though it lacks an explicit action verb.
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 implies usage through 'given a ticker' and describes the scope, but it does not explicitly state when to use this tool versus alternatives like find_data or sec_filing_section. No exclusion or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe the data you need in plain language (e.g. 'Apple risk factors 2023', 'is this token a honeypot', 'is this email deliverable', 'read this page'). Searches this server's datasets first, then the whole Professor Sausages catalog, and returns matching endpoints with method, URL, price, and how to call them. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | What you're trying to find or do, in your own words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses the search order (server datasets first, then catalog) and what the response contains (method, URL, price, call instructions) plus the fact that it is free. It does not mention error handling, rate limits, or authentication, but for a search/discovery tool, this is reasonably transparent and gives the agent a good sense of what to expect.
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: three sentences that front-load examples, state the search behavior, and summarize output. Every sentence earns its place with no filler, and the structure guides the agent from usage examples to process to result format efficiently.
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 a single parameter and no output schema, the description covers the essential context: what to provide, how the search works, and what the response will include. It could mention potential limitations or error cases, but for a tool of this complexity, the description is complete enough for an agent to select and use it correctly. A 5 would require more explicit details on edge cases or failure modes.
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 fully describes the single 'task' parameter with an example. The description adds value by offering multiple plain-language examples ('Apple risk factors 2023', 'is this token a honeypot', 'is this email deliverable', 'read this page') and clarifies that the task can be phrased in any way, expanding the parameter's semantics beyond the schema's minimal description.
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's function: it searches for data endpoints based on a plain-language description and returns matching endpoints with method, URL, price, and call instructions. The verb 'searches' and 'returns' plus resource scope (server datasets + catalog) distinguishes it from sibling tools that each target a specific data type, so an agent can easily tell when to use it for discovery versus direct retrieval.
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 explains the tool's purpose and search process, implying it should be used when you need to locate an endpoint or data source. However, it does not explicitly state when not to use it or mention alternatives like the specific sibling tools. The guidance is clear enough for an agent to infer usage, but it lacks explicit exclusions or contrast with alternatives, so it misses a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ECB reference exchange rate for a currency pair (e.g. EUR/USD). Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | Base currency, ISO 4217 code. | |
| quote | Yes | Quote currency, ISO 4217 code. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly reveals the paid nature and the mandatory x402 payment flow, explaining what the first call returns (amount, asset, network) and how settlement works. It does not mention update frequency or result format, but the critical payment behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, each earning its place: the first states the tool's purpose, the second explains the payment workflow and points to the free alternative. There is no filler or 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 simple currency-rate tool with a nontrivial payment workflow, the description adequately covers purpose, usage flow, and alternative tool. It does not specify the exact return schema, but no output schema is provided and the data type (a reference rate) is straightforward.
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 input schema already documents all three parameters at 100% coverage. The description adds significant value by explaining the x_payment parameter's dynamic role: omitting it returns terms, including it settles and returns data. This goes beyond the schema's static type description.
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 and identifiable resource: 'ECB reference exchange rate for a currency pair,' including a concrete example (EUR/USD). It distinguishes itself from the sibling `pricing` tool by noting the paid nature and pointing to the free alternative.
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 explains the two-step paid workflow: call without x_payment to receive terms, sign, then call again with x_payment. It also gives a usage pointer to `pricing` for a broader listing, though it doesn't explicitly enumerate all cases where `pricing` should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What an institutional manager bought, sold, added, and trimmed vs the prior quarter — the whale-watch view. Requires the manager's CIK. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | Yes | Manager CIK (digits) | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the paid nature, the required CIK, and the exact payment protocol. However, it does not describe the return format or any rate limits, leaving some behavioral opacity, but the critical payment behavior is well covered.
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?
Three sentences, front-loaded with the core function, followed by prerequisites and payment details. No filler or redundant phrasing; every sentence serves a purpose.
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 purpose, prerequisites, and payment settlement clearly. With no output schema, it adequately hints at the returned data ('bought, sold, added, trimmed'). It could mention response structure explicitly, but for a paid data call with a well-defined payment flow, this is sufficient.
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 detailed descriptions for both `cik` and `x_payment`, including the payment flow in `x_payment`. The description adds little beyond restating the CIK requirement and the payment process already explained in the schema, so the baseline 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 shows an institutional manager's quarter-over-quarter changes (bought, sold, added, trimmed) and labels it the 'whale-watch view.' This specific verb+resource+scope distinguishes it from siblings like `pricing`.
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 explains the paid two-step payment flow: call without x_payment to receive terms, sign them, then call again with x_payment to get data. It also points to the free `pricing` tool as an alternative for price listings, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insider buy/sell activity. With a ticker: that company's summary (net buys/sells, top insiders). Without: the most recent filings market-wide. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | No | Optional ticker or CIK; omit for market-wide recent filings | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly discloses the paid nature and the two-step protocol: call without x_payment to get terms, then call again with x_payment to receive data. It also explains the output scope for each mode. It omits details like pagination or rate limits, but the key behavioral aspects are covered.
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 remarkably concise: the first sentence states the purpose, the next two define parameter-dependent behavior, and the final sentence clarifies the payment path and references the free pricing tool. Every sentence serves a purpose with no 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?
Given the tool's moderate complexity (2 optional params, no output schema), the description covers the essential invocation modes and the unique payment requirement. It gives enough context for an agent to correctly begin a call. Minor gaps exist around result size or pagination, but these do not prevent correct initial use.
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 baseline is 3. The description adds value by explaining the outcome for ticker (company summary vs market-wide filings) and summarizing the x_payment flow, but it does not introduce new parameter-level details beyond what the schema already specifies.
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 identifies the tool as insider buy/sell activity and describes the two invocation modes (with/without ticker). The title 'Insider trades (SEC Form 4)' further specifies the resource. However, it does not explicitly distinguish itself from related sibling tools such as manager_holdings or security_holders.
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 explains when to use the tool with and without a ticker, and outlines the payment flow. It does not provide explicit when-not-to-use guidance or contrast with sibling tools that also cover insider-related data, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The SEC IPO pipeline: view=pipeline (in registration), priced, expected, or withdrawn. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | Which slice of the IPO pipeline to return. | pipeline |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the key behavioral trait: this is a paid tool requiring signed payment. It details the exact payment negotiation process (terms, signing, resubmission), which is beyond typical read-only expectations.
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, front-loaded with the tool's core purpose and payment condition. Every clause contributes necessary information—views, paid mechanism, and alternative tool—without 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?
The tool is relatively simple (2 params, no output schema). The description covers the essential aspects: views, payment flow, and alternative. It doesn't describe return format, but that is less critical for a data-retrieval tool with clear schema.
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 baseline is 3. The description adds value by explaining what each view means (e.g., pipeline means 'in registration') and reinforcing the x_payment flow, enhancing the schema's enum and description.
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 identifies the tool as providing SEC IPO pipeline data with configurable views (pipeline, priced, expected, withdrawn). It distinguishes itself from the sibling `pricing` tool by naming it as the free alternative for listing all prices at once.
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?
Explicitly explains the paid two-step flow: call without x_payment to receive terms, sign them, then call again with x_payment. It also points to `pricing` as the free alternative for bulk price listing, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
US macroeconomic series (CPI, unemployment, fed funds, 10-year treasury, real GDP). Pass an id for one series, omit to list what's available. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Series id; omit to list available series | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the paid nature and the two-step payment process, which is a key behavioral trait. It does not detail error handling or output format, but for a listing/data tool, this is sufficient. The payment flow is transparently explained.
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?
Three sentences, front-loaded with the main purpose, then usage, then payment. No wasted words. Each sentence 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?
For a tool with two optional parameters and a payment flow, the description covers all necessary context: available data types, how to retrieve a single series, how to list all, and the exact payment protocol. It is complete and self-contained.
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 baseline is 3. The description adds value by explaining the semantic difference between passing an id vs omitting it, and elaborating the x_payment parameter's role in the payment flow beyond the schema's description. It reinforces and clarifies parameter usage.
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 provides US macroeconomic series (CPI, unemployment, fed funds, 10-year treasury, real GDP) and explains the two modes: pass an id for one series, omit to list available series. This is a specific verb+resource, and the mention of the pricing tool distinguishes it from siblings.
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?
Explicit usage guidance is provided: how to use id (pass/omit), and the payment flow (call without x_payment to get terms, sign, then call again with x_payment). It also explicitly points to an alternative: 'The free `pricing` tool lists every price at once.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
An institutional manager's 13F holdings for the latest quarter. Pass a CIK for the portfolio, or a name to search managers first. Examples: {manager:'1067983'} (Berkshire's book), {manager:'bridgewater'} (search). Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| manager | Yes | Manager CIK (digits) for holdings, or a name fragment to search | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the two-step paid call mechanism, the latest-quarter scope, and the search behavior. It doesn't detail the response format or error handling, but the essential behavioral traits are covered, earning above baseline.
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?
Four sentences cover purpose, usage, examples, payment flow, and an alternative tool. Each sentence contributes non-redundant information, though the density is somewhat high. It's concise without being 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?
The tool has a complex payment flow and dual-mode parameter. The description covers how to use both modes, the paid two-step sequence, and the free pricing alternative. Given the lack of an output schema, it sets sufficient expectations for a holdings query.
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?
Although the schema already covers both parameters at 100%, the description adds significant value: explaining the dual CIK/name search mode, giving examples, and clarifying the x_payment workflow with signing instructions. This goes well beyond 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 tool returns an institutional manager's 13F holdings for the latest quarter, distinguishing it from sibling tools like holdings_changes and security_holders. It supports both CIK and name search, making the purpose and scope explicit.
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 provides explicit usage instructions: pass a CIK for a specific portfolio or a name to search, with concrete examples. The payment flow is explained (call without x_payment to get terms, then sign and call again), and it points to the pricing tool as an alternative for price lists, helping the agent decide when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every endpoint this server fronts, with its exact per-call USD price (x402, USDC on Base) and a one-line summary, read live from the route table. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and states it reads live from the route table, indicating a read-only operation. It also discloses the 'Free' aspect. It does not mention auth or rate limits, which are likely irrelevant for a simple introspection 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 entire description is one sentence that packs in the core function, source, and cost. Every word adds value with no 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 simple no-parameter tool, the description conveys what is returned (endpoints, prices, summaries) and the source (live route table). It could specify the output format, but that is easily inferred.
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 zero parameters, so the schema is fully covered by default. The description adds no parameter details because none exist, warranting the baseline score of 4 for no-parameter tools.
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 every endpoint with its exact per-call price and a one-line summary, read live from the route table. This is a specific, unambiguous purpose and distinguishes it from sibling tools like coverage or fx_rate.
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 discovering costs before calling other endpoints by emphasizing 'exact per-call USD price' and 'Free.' It provides clear context about what the tool does, though it does not explicitly name alternatives or 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.
The suggestion box: ask for data we don't have (a pre-2015 filing, an uncovered ticker, an unsupported chain, a whole dataset). Requests feed the nightly ingestion queue — filings are usually available within ~24h. Include contact if you want to hear back. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| contact | No | Optional: URL/email/handle for follow-up | |
| use_case | No | Optional: what you're building | |
| description | Yes | What data you need, in your own words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses the nightly ingestion queue, ~24h turnaround, the need for optional contact, and that the service is free. It does not mention potential limitations or success criteria, but the behavior is reasonably transparent for a request 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?
Two sentences, front-loaded with the core purpose, followed by concrete examples and behavioral notes. Every clause earns its place; no fluff.
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 request tool with no output schema, the description covers the workflow, timing, and cost. It could mention how to track request status or what happens if a request is rejected, but it is largely complete 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 coverage is 100%, so the baseline is 3. The description adds context around the 'description' parameter (examples of what to ask for) and 'contact' (optional follow-up), but it does not substantially extend what the schema already provides. It reinforces rather than enriches.
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 identifies the tool as a request mechanism for missing data, with specific examples (pre-2015 filing, uncovered ticker, unsupported chain) that distinguish it from sibling retrieval tools. The verb 'ask for' and resource 'data we don't have' make the purpose unambiguous.
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 when to use it (when data is missing from existing coverage) and gives concrete examples, but it doesn't explicitly reference sibling tools or state 'use this if find_data/coverage fails.' The implied guidance is strong but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parsed sections of a SEC filing by ticker or CIK: 10-K (default), 10-Q, or 8-K. Sections like business, risk_factors, mdna. Corpus 2015→now; missing filings can be requested via request_data. Example: {ticker:'AAPL', selector:'2023', sections:'risk_factors,mdna'}. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | Which filing form to fetch. | 10-K |
| ticker | Yes | Ticker symbol or 10-digit CIK | |
| sections | No | Comma-separated section keys to include in full, or 'all'. Omit for the manifest only. | |
| selector | No | 10-K: fiscal year. 10-Q/8-K: period-end date YYYY-MM-DD or a year. Omit for the latest on file. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden of behavioral disclosure. It reveals the corpus date range (2015→now), the payment mechanism (call without x_payment to get terms, sign them, then call again), and the fallback for missing filings via request_data. It does not mention rate limits or response format, but for a data access tool this is substantial and honest disclosure.
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 paragraph that front-loads the main purpose and then efficiently covers corpus, example, payment, and pricing. Every sentence contributes unique information without redundancy, making it appropriately concise for the complexity.
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 5 parameters, no output schema, and no annotations, the description covers the essential operational workflow: how to request data, how to handle payments, and what to do about missing filings. It does not describe the response structure, but the schema already documents parameter details, and the example plus payment explanation gives an agent enough context to invoke the tool successfully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3, but the description adds meaningful value by providing a concrete example ({ticker:'AAPL', selector:'2023', sections:'risk_factors,mdna'}) and explaining the x_payment workflow beyond the schema's terse description. It also gives representative section keys (business, risk_factors, mdna), helping the agent construct valid requests.
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 purpose: 'Parsed sections of a SEC filing by ticker or CIK' and enumerates the specific forms (10-K, 10-Q, 8-K) and section types (business, risk_factors, mdna). This distinguishes it from sibling tools and leaves no ambiguity about its core function.
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 provides practical usage context, including a concrete example call and a detailed explanation of the two-step payment process. It also points to alternatives: 'missing filings can be requested via request_data' and 'the free pricing tool lists every price at once.' While it doesn't explicitly say 'use this tool when...', the context is clear enough for an agent to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Institutional holders of a security by CUSIP: who owns it, position sizes, and changes. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| cusip | Yes | 9-character CUSIP | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the key behavioral trait: the tool is paid and requires a two-step process (call without x_payment to get terms, then sign and call again). This is valuable transparency for the agent to handle payment correctly. It also describes the content scope but doesn't mention potential errors, rate limits, or pagination.
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?
Three sentences, each with a distinct purpose: purpose, payment flow, and alternative tool. No redundant wording and the most critical info is front-loaded.
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 data lookup with no output schema, the description tells the user what to expect (holders, position sizes, changes) and how to handle the paid flow. It doesn't cover edge cases like as-of date or format details, but it is adequate for the tool's 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 description coverage is 100%, so the schema already documents both parameters. The description reinforces CUSIP and x_payment by mentioning them in context, but adds no new parameter semantics beyond what the schema already 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 clearly states the resource (institutional holders of a security by CUSIP) and the data returned (who owns it, position sizes, changes). This distinguishes it from sibling tools like manager_holdings (which likely lists a manager's holdings) and pricing (which provides prices).
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 clear from the purpose, and the description explicitly points to an alternative: 'The free `pricing` tool lists every price at once.' However, it doesn't explicitly say when NOT to use this tool or compare with other siblings, so it falls short of full explicit 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. Dates show when Glama detected each change.
coveragefind_datafx_rateholdings_changesinsider_activityipo_calendarmacro_seriesmanager_holdingspricingrequest_datasec_filing_sectionsecurity_holdersClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool targets a distinct data area or action: coverage vs find_data vs request_data are clearly separate (metadata, search, and suggestion box), and the three holdings tools (holdings_changes, manager_holdings, security_holders) each address a different question (changes, portfolio, owners). No two tools have ambiguous boundaries.
All tool names use consistent lowercase snake_case (coverage, find_data, fx_rate, request_data, etc.). While some are verb phrases and others are noun phrases, the naming style is uniform and predictable, making it easy to guess tool purposes.
Twelve tools is a well-scoped size for a financial data API server. Each tool covers a distinct data domain, and there is no excessive redundancy or crowding. The count is within the ideal 3-15 range.
The tool set covers a broad range of financial data needs: SEC filings, holdings, insider activity, IPO, macro, and FX. Minor gaps exist (e.g., no direct company fundamentals or full filing text), but the request_data tool provides a path to fill missing datasets, so agents are not at a dead end.