search_facts
Free. List filing-fact SKUs. Paid fetch is https://southpow.media/v1/fact?id=AAPL (SEC 10-K/10-Q), $0.01 USDC on Base to 0x5fB2FAeaAbd58Da0eA1E1F64a8C2134c4941eFe5.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
Free. List filing-fact SKUs. Paid fetch is https://southpow.media/v1/fact?id=AAPL (SEC 10-K/10-Q), $0.01 USDC on Base to 0x5fB2FAeaAbd58Da0eA1E1F64a8C2134c4941eFe5.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It usefully reveals cost behavior ('Free', '$0.01 USDC'), payment address, and source data (SEC 10-K/10-Q). But it does not disclose output format, rate limits, pagination, or whether the query parameter is required for the listing 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 short and front-loaded with the key action: 'Free. List filing-fact SKUs.' The paid-fetch detail is dense but relevant. It could be slightly better structured by separating the payment details into a clearer sentence, but there is no real 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?
Given one optional parameter, no output schema, and no annotations, the description is not complete enough for confident invocation. It does not explain the query parameter, likely return values, or how this tool relates to the sibling tools beyond the paid URL. An agent would still have to guess at key details.
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 has zero description coverage and the only parameter, 'query', is optional. The description gives no direct guidance on what to put in query, how it filters SKUs, or whether omitting it returns all SKUs. The paid URL hinting at id=AAPL is indirect and insufficient.
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-resource pair: 'List filing-fact SKUs.' It also clearly distinguishes this tool from the paid fetch path by labeling search as 'Free' and giving the paid fetch URL. This is enough for an agent to understand what the tool does and to tell it apart from fetch_fact.
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 clear context: listing SKUs is free, fetching a fact is paid, and it includes the paid endpoint URL. This implies when to use this tool vs the paid fetch. However, it does not explicitly name sibling tools or mention get_schema, and it does not state when not to use search_facts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a distinct purpose: fetch_fact retrieves a specific fact, get_schema provides the schema, and search_facts lists available facts. No overlapping functionality.
All tools follow the consistent verb_noun pattern (fetch_fact, get_schema, search_facts), which is clear and predictable.
Three tools is a well-scoped set for a simple fact-fetching API, covering the essential operations without unnecessary bloat.
The tool set covers the full lifecycle for this domain: searching for facts, retrieving a specific fact, and understanding the data structure via the schema. No obvious missing operations.