Cross-market (US/JP/KR) structured financials, segments, ownership & metrics, traceable to filings.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 2.9/5 across 19 of 19 tools scored. Lowest: 2.3/5.
Each tool targets a distinct financial data aspect (e.g., balance sheet vs income statement vs cash flow; different holding types; metrics vs history). No overlapping purposes.
All tools follow verb_noun pattern with snake_case (e.g., get_balance_sheet, compare_metrics). Consistent and predictable.
19 tools is slightly above the typical 3-15 range but covers a broad domain (statements, metrics, holdings, screening). Still reasonable and well-scoped.
Covers most key financial data needs: statements, metrics, insider trades, institutional holdings, screen/search. Minor gaps like earnings estimates or dividend history are absent but core workflows are complete.
compare_metricsCInspectCompare valuation metrics across multiple tickers.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | ||
| tickers | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It does not mention that the tool is read-only, any authentication requirements, rate limits, or error handling (e.g., for invalid tickers). The minimal description fails to convey key behavioral traits.
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 sentence, making it concise. However, it lacks structure (e.g., bullet points or separate sections for usage) and does not front-load critical information beyond the basic 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?
Given the presence of an output schema and the moderate complexity (2 parameters, comparison across multiple tickers), the description should provide more context. It does not explain what valuation metrics are included, how the output is structured, or any constraints, leaving the agent underinformed.
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 0%, so the description must explain parameter usage. It hints at the 'tickers' parameter but does not clarify the 'fields' parameter (optional, default null, possible string or null). No details on how to format tickers or fields are provided.
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 action ('compare'), the resource ('valuation metrics'), and the scope ('across multiple tickers'). It effectively distinguishes the tool from sibling tools like 'get_metrics' or 'screen_companies' which are for single-ticker or screening operations.
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?
No guidance is provided on when to use this tool versus alternatives such as 'get_metrics' for single-ticker valuation or 'screen_companies' for filtering. There is no mention of prerequisites, limitations, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_balance_sheetCInspectGet balance sheet (assets, liabilities, equity).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| ticker | Yes | ||
| frequency | No | quarterly | |
| fiscal_year | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It only states what data is returned, omitting details like pagination, rate limits, return format, or whether it's read-only (likely safe). Minimal behavioral insight.
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 very short and direct, which is good for conciseness, but it omits essential parameter and usage details, making it under-specified rather than lean.
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 has four parameters, an output schema, and many siblings, the description is far from complete. It fails to guide parameter usage, explain output, or differentiate from similar tools.
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 no information about the four parameters (ticker, limit, frequency, fiscal_year). Schema coverage is 0%, so the description should compensate, but it doesn't address any parameter meaning or 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?
The description clearly states the tool retrieves a balance sheet and lists its main components (assets, liabilities, equity), making the purpose unambiguous and distinct from sibling tools like get_income_statement or get_cash_flow.
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?
No guidance on when to use this tool versus alternatives (e.g., get_financials, get_income_statement). The description implies it's for balance sheet data, but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_cash_flowCInspectGet cash flow statement (OCF, ICF, FCF, capex, dividends).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| ticker | Yes | ||
| frequency | No | quarterly | |
| fiscal_year | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as whether data is historical only, if it supports custom date ranges, currency, or units. The description lacks important behavioral context beyond listing return items.
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 very concise at one sentence, but it lacks structure such as bullet points or sections. It is efficient but could be better organized for readability.
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 having an output schema (which reduces need to explain returns), the description is insufficient given the tool's complexity (4 parameters, financial data). It omits how to specify fiscal periods, what limits do, or how frequency interacts with results. The description is incomplete for effective 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 description coverage is 0%. The description does not explain any of the four parameters (ticker, limit, frequency, fiscal_year). For example, it does not mention that frequency defaults to 'quarterly' or what fiscal_year accepts. The description adds no parameter-level meaning.
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 verb 'Get' and the resource 'cash flow statement', and lists specific components (OCF, ICF, FCF, capex, dividends). It distinguishes from siblings like get_balance_sheet and get_income_statement by naming unique cash flow items.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or context for selecting this tool over siblings like get_financials.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_companyAInspectGet company facts (name, exchange, industry, regulator id, filings url).
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states what facts are retrieved, which is adequate for a simple lookup. However, it does not mention idempotency, rate limits, data freshness, or authentication requirements.
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, front-loaded sentence that communicates the tool's purpose efficiently. 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?
Given the tool's simplicity (one parameter, clear output, output schema exists), the description is mostly complete. It could mention the output schema or provide a usage example, but it is sufficient for basic understanding.
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 0%, so the description should elaborate on the 'ticker' parameter. It only states 'ticker' in the schema title but adds no explanation (e.g., that it's a stock symbol). The description fails to add meaning beyond the parameter name.
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 contains a specific verb ('Get') and resource ('company facts'), and lists the exact fields returned: name, exchange, industry, regulator id, filings url. This clearly distinguishes it from sibling tools that focus on financial metrics or statements.
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 use when basic company information is needed, but provides no explicit guidance on when to use this tool versus alternatives like get_financials or screen_companies. No when-not or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_director_holdingsCInspectGet director / officer shareholdings (insider equity stakes).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description alone must convey behavioral traits. It only states the tool gets holdings, but does not disclose if it returns current or historical data, any side effects, or authentication needs. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that conveys the core purpose without extraneous words. However, it could be slightly expanded to add differentiation without loss of conciseness.
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 18 sibling tools and an output schema present, the description should provide more context to differentiate it from similar tools like 'get_insider_trades'. It lacks details on scope, data fields, or usage scenarios.
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 0%, and the tool description does not explain the parameters ('ticker' and 'limit'). The schema provides basic info (types, default), but the description adds no further meaning.
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 action ('Get') and the resource ('director / officer shareholdings'), with a brief clarification in parentheses. However, it does not differentiate from sibling tools like 'get_insider_trades' or 'get_institutional_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?
No guidance on when to use this tool versus alternatives. There is no mention of context, exclusions, or prerequisites, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_filing_sourceBInspectGet the original SEC filing URL for a fiscal quarter or year from Rockmoon's stored provenance; use this instead of web search.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | ||
| ticker | Yes | ||
| frequency | No | auto | |
| statement | No | all |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as authentication requirements, rate limits, or error handling. The mention of 'Rockmoon's stored provenance' hints at source but lacks depth.
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, front-loaded sentence with no redundancy. Every word 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?
While an output schema exists, the description lacks parameter explanations and behavioral details for a tool with four parameters and no annotations. It is too minimal given the 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 0%, and the description does not explain any of the four parameters (ticker, period, frequency, statement). The agent must rely solely on parameter names, which is 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 clearly states the tool retrieves the original SEC filing URL for a fiscal quarter or year, and distinguishes it from web search. The verb 'Get' and the resource 'SEC filing URL' are specific.
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 explicit guidance: 'use this instead of web search,' which tells agents when to prefer this tool. However, it does not mention when not to use it or address sibling tools, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_financialsBInspectGet all three financial statements (IS + BS + CF) for a ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| ticker | Yes | ||
| frequency | No | quarterly | |
| fiscal_year | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. It only states what is retrieved but omits any details on authentication, rate limits, error handling, or whether multiple statements are returned as separate entities or combined.
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 concise sentence with no superfluous words. However, its brevity sacrifices informational value, making it less helpful than it could be.
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?
While the tool has an output schema (not shown) that likely explains return values, the description lacks context about how this aggregation tool relates to siblings, what the three statements include, or any limitations. It is adequate but leaves gaps.
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 0%, requiring the description to compensate. The description only mentions 'ticker', leaving limit, frequency, and fiscal_year undocumented. It adds no semantic meaning beyond the schema field names.
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 verb 'Get', the resource 'all three financial statements', and the input requirement 'for a ticker'. It effectively distinguishes this tool from siblings like get_income_statement, get_balance_sheet, and get_cash_flow by indicating it aggregates 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?
No guidance is provided on when to use this tool versus alternatives, such as individual statement tools or compare_metrics. There is no mention of prerequisites, context, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_income_statementCInspectGet income statement (revenue, costs, margins, EPS).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| ticker | Yes | ||
| frequency | No | quarterly | |
| fiscal_year | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose any behavioral traits beyond the returned data, such as authentication needs or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks necessary detail, making it under-specified rather than 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?
Despite an output schema existing, the description fails to cover input parameter semantics, making it insufficient for proper tool usage.
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 0%, and the description does not explain any of the four parameters, leaving the agent to infer their meaning from names only.
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 specifies the tool returns an income statement with revenue, costs, margins, and EPS, distinguishing it from sibling tools like get_balance_sheet and get_cash_flow.
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?
No guidance is provided on when to use this tool versus alternatives, or any prerequisites needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_insider_tradesCInspectGet insider trading activity (US Form 4 filings).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'Get insider trading activity', implying a read operation but not detailing behaviors like data freshness, required permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) but lacks critical parameter and usage details, making it under-informative for the agent.
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 having an output schema, the description omits parameter semantics and usage context, which are necessary given the 2 parameters and sibling tools.
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 0%, and the description does not explain the 'ticker' or 'limit' parameters, leaving the agent to infer meaning from names 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?
Clearly states the verb 'Get', the resource 'insider trading activity', and specifies 'US Form 4 filings', which differentiates it from sibling tools like get_institutional_holdings or get_director_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?
No guidance on when to use this tool vs alternatives such as get_director_holdings or get_institutional_holdings. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_institutional_holdingsBInspectGet institutional holders (US 13F filings).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation, which is appropriate for a 'get' tool. However, with no annotations provided, it does not disclose any additional behavioral traits such as idempotency, required permissions, rate limits, or the nature of returned data.
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 one short sentence (7 words) with no wasted words. However, it is slightly under-specified due to missing parameter context.
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 tool with two parameters and an output schema, the description fails to cover parameter guidance or use cases. The agent lacks information on how to construct a valid request.
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 does not mention either parameter ('ticker' or 'limit'), despite 0% schema description coverage. It adds no value over the schema, leaving the agent to guess the meaning of 'ticker' and the effect of 'limit'.
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 institutional holders from US 13F filings. The verb 'Get' and resource 'institutional holders' combined with the specific filing type distinguish it from sibling tools like get_director_holdings or get_insider_trades.
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?
No guidance on when to use this tool versus alternatives or when not to use it. The description only states what it does, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_large_holdings_eventsCInspectGet large-holdings disclosure events (JP 350/360 reports).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only restates the tool's purpose without mentioning whether it is read-only, any rate limits, pagination behavior, or what happens on missing data. The output schema exists but is not referenced.
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 short sentence that efficiently communicates the core purpose. It could be expanded without harming conciseness, but as-is it is not 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 existence of an output schema and two parameters, the description is too brief. It lacks essential details about parameter behavior and return value structure, leaving significant gaps for the 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 input schema has 2 parameters with 0% description coverage. The description adds no meaning about 'ticker' (presumably a stock ticker) or 'limit' (how results are limited, possibly pagination). The agent must infer from parameter names 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 'Get large-holdings disclosure events (JP 350/360 reports)', specifying the verb and resource with additional context about the report type. However, it does not distinguish from sibling tools like get_institutional_holdings or get_major_shareholders.
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?
No guidance is provided on when to use this tool versus alternatives such as get_director_holdings or get_institutional_holdings. There is no mention of prerequisites, typical scenarios, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_metricsCInspectGet latest valuation + financial metrics snapshot (PE, PB, ROE etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear full burden. It mentions 'latest' implying recency but does not disclose data freshness, error handling, or any side effects. Minimal behavioral info.
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 a single short sentence with no wasted words. However, it is too sparse to earn a 5.
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?
Only one parameter and no annotations, but the description does not explain the output schema or provide sufficient context for a simple snapshot tool. Lacks details on metric definitions or data range.
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%, but description adds no explanation beyond the parameter name 'ticker'. The meaning is implicit, and no format or examples are given.
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 retrieves a snapshot of valuation and financial metrics (PE, PB, ROE), using a specific verb 'Get'. It distinguishes the data type but does not explicitly differentiate from siblings like 'compare_metrics' or 'get_metrics_history'.
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?
No guidance on when to use this tool vs alternatives such as 'compare_metrics' or 'get_metrics_history'. No mention of prerequisites, limitations, or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_metrics_historyCInspectGet historical derived metrics (TTM aggregates + margins per period).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| ticker | Yes | ||
| frequency | No | quarterly |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only explains the output (TTM aggregates + margins per period) but does not state side effects, idempotency, authorization needs, or rate limits. For a tool that queries historical data, it is assumed safe but not confirmed.
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 sentence with no filler, making it concise. It front-loads the core action and output. However, it could be slightly improved by clarifying 'derived metrics' or adding a brief note on parameter defaults.
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 complexity of historical metrics and the presence of many sibling tools, the description is incomplete. It neither explains what 'TTM aggregates' means nor how parameters like 'frequency' affect results. The output schema exists but is not shown, so the description alone does not equip the agent adequately.
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 0%, and the description does not explain any parameters. 'limit', 'ticker', and 'frequency' are undefined in the description. The agent must infer their meaning from the tool's name and context, which is 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 'Get historical derived metrics (TTM aggregates + margins per period)', which indicates the tool retrieves historical financial metrics. However, 'derived metrics' is vague without further explanation, and the description does not differentiate from siblings like 'get_metrics' (likely current) or other historical tools like 'get_balance_sheet'.
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?
No explicit guidance on when to use this tool versus alternatives. The implied use case is for historical derived metrics, but there is no mention of when to prefer this over 'get_metrics' or avoid it for non-derived data. Lack of context for the 'frequency' and 'limit' parameters also hampers correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pricesCInspectGet daily price history for a ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | 1y | |
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It is too brief and does not disclose whether the tool is read-only, what data is returned, or any restrictions. This is insufficient for a tool with 2 parameters.
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?
While very concise (one sentence), it is under-specified. Every sentence should earn its place, but here the single sentence is too vague to be useful. The structure does not front-load critical details.
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 has 2 parameters (one required) and no schema descriptions, the description is incomplete. It does not explain input formats or the scope of the price history. The presence of an output schema does not excuse the lack of parameter guidance.
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 0%, and the description adds no meaning beyond parameter names. The 'period' parameter with default '1y' is not explained, and 'ticker' has no additional context. The description fails to compensate for the missing schema descriptions.
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 'Get daily price history for a ticker' clearly states the action (get) and resource (daily price history for a ticker). It distinguishes from siblings like get_metrics_history which might cover other metrics. However, it could be more specific about time granularity or source.
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?
No guidance is provided on when to use this tool versus alternatives. There are no exclusions or context about suitable scenarios, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_segmentsCInspectGet reported business / geographic / product segments.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | ||
| ticker | Yes | ||
| concept | No | revenue | |
| frequency | No | yearly |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 only states it gets segments without specifying behavioral traits such as permission requirements, rate limits, or data freshness. The existence of an output schema is not mentioned.
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 short sentence, which is concise but lacks structure. It does not waste words but also does not provide enough information, balancing at an acceptable brevity.
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 parameters and an existing output schema, the description is too sparse. It does not describe what the tool returns or how to use the parameters, leaving the agent with minimal guidance for a tool with 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?
With 0% schema description coverage, the description should add meaning to the parameters. However, it provides no explanation for 'period', 'concept', or 'frequency', leaving their semantics unclear beyond their names.
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 (Get) and resource (reported segments), and mentions the types (business, geographic, product). It is clear in purpose but does not differentiate from the sibling tool 'get_segments_trend' which likely provides trend 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?
No guidance on when to use this tool versus alternatives like 'get_segments_trend' or other get_ tools. No context on prerequisites or expected use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_segments_trendBInspectGet time-series of segment values across periods for trend analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| ticker | Yes | ||
| concept | No | revenue | |
| frequency | No | yearly |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the tool returns time-series data but does not mention any behavioral traits such as rate limits, authentication requirements, or what happens with missing data. The description is minimal and does not add significant transparency.
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 concise sentence that front-loads the tool's purpose. Every word carries meaning with no redundancy or 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?
Given the tool has 4 parameters and an output schema exists, the description is adequate but incomplete. It states it returns time-series for trend analysis but does not explain how segments are defined, the meaning of concept/frequency, or how to interpret results. However, the output schema may supplement return value information, so it is minimally viable.
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 0%, meaning the description does not explain any parameters. The input schema provides defaults and titles (e.g., concept default 'revenue', frequency default 'yearly'), but the description adds no extra meaning or context for how parameters affect the output. This is insufficient given 4 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 the specific action 'Get time-series of segment values across periods for trend analysis'. It uses a specific verb (Get) and resource (segment values) and distinguishes from sibling tools like get_segments (likely point-in-time) and get_metrics_history (different resource) by emphasizing trend analysis across periods.
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 trend analysis but does not explicitly state when to use this tool versus alternatives like get_segments or get_metrics_history. No when-not-to-use or prerequisites are mentioned. The context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screen_companiesAInspectScreen stocks across US/JP/KR/HK/CN by valuation + quality metrics (PE, PB, ROE, margins, market cap, dividend yield).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| order | No | desc | |
| market | No | ||
| pb_max | No | ||
| pb_min | No | ||
| roa_min | No | ||
| roe_max | No | ||
| roe_min | No | ||
| sort_by | No | market_cap | |
| pe_ttm_max | No | ||
| pe_ttm_min | No | ||
| gics_sector | No | ||
| market_cap_max | No | ||
| market_cap_min | No | ||
| net_margin_min | No | ||
| ttm_revenue_min | No | ||
| gross_margin_min | No | ||
| ev_ebitda_ttm_max | No | ||
| gics_industry_group | No | ||
| operating_margin_min | No | ||
| dividend_yield_ttm_min | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 indicates a read-like operation (screening) but does not disclose pagination, rate limits, or auth requirements. The presence of an output schema (not shown) may partially compensate, but the description omits key behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and resource, containing no redundant words. Every part adds value.
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 21 parameters, 0% schema coverage, and no annotations, the description is too minimal. It omits default behavior (e.g., limit=20, sort by market_cap), how to use optional filters like GICS sectors, and the meaning of order. The output schema may help, but the description alone is insufficient for complete understanding.
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 0%, and the description only enumerates a subset of metrics (PE, PB, ROE, margins, market cap, dividend yield), leaving many parameters like limit, order, sort_by, GICS filters, and ev_ebitda undocumented. The description does not compensate for the lack of parameter descriptions.
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 explicitly states the action 'Screen stocks' across specific markets (US/JP/KR/HK/CN) and lists the key metrics (PE, PB, ROE, etc.), making the tool's purpose clear and distinguishing it from siblings like search_companies or get_metrics.
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 when to use this tool (for screening by valuation and quality metrics) but does not explicitly state when not to use it or reference alternatives like get_metrics for specific companies or search_companies for name-based search. However, the context is sufficient for an AI agent to infer typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_companiesBInspectSearch companies by ticker or name across US/JP/KR/HK/CN/UK.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states the search scope but omits critical traits such as whether partial matches are supported, case sensitivity, pagination, rate limits, or result structure. The brief description provides minimal behavioral insight.
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 sentence that directly states the core functionality. It is efficient and front-loaded, though somewhat lacking in detail. Every word contributes to the 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?
Given the tool's complexity (multiple markets, search term), the description is too brief. It does not specify matching behavior, result limits, or other parameters. Although an output schema exists, the missing behavioral context makes the description incomplete for reliable agent 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 description coverage is 0%, so the description must compensate. It mentions 'by ticker or name' for the query parameter but does not explain format, constraints, or the limit parameter at all. The compensation is incomplete; the description adds only marginal meaning beyond 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 explicitly states the verb 'search' and resource 'companies', specifies search criteria (ticker or name) and geographic scope (US/JP/KR/HK/CN/UK). It clearly distinguishes from sibling tools like get_company and screen_companies.
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 tool is for searching companies by identifier across specific markets, but it does not explicitly state when to use it versus alternatives like get_company, nor does it provide exclusions or conditions. It offers context but no explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
