aigroup-finnhub-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.2.1
Disambiguation4/5
Tools are well-separated by domain, but there is operation overlap between 'finnhub_stock_market_data' and 'finnhub_stock_fundamentals' (both include get_basic_financials, get_financials_as_reported), and between 'finnhub_market_events' and 'finnhub_stock_estimates' regarding analyst data. This could cause some agent confusion.
Naming Consistency5/5
All tools follow a consistent 'finnhub_<domain>_<subdomain>' pattern with snake_case. Operation names are uniformly verb_noun (e.g., get_quote, create_project). No mixing of conventions.
Tool Count5/5
With 15 tools covering diverse financial data domains (stocks, forex, crypto, news, SEC filings, etc.), the count is well-scoped. Each tool serves a clear purpose without being excessive or insufficient.
Completeness4/5
The tool set covers a broad range of financial data including stocks, forex, crypto, news sentiment, fundamentals, technical analysis, and calendars. Missing asset classes like options or bonds, and some operation duplication, prevent a perfect score. The project management tools add extra utility.
Average 2.9/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions JSON export support but does not disclose behavioral traits like read-only nature, rate limits, or consequences of parameter choices. Each operation's behavior is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise (two sentences plus a list), but the list of operations is not structured in a readable way (comma-separated). It could be more organized with bullet points or clearer formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 12 parameters, no output schema, and no annotations, the description is severely lacking. It does not explain the four different operations, how they differ, or how parameters relate to each operation. An AI agent would have difficulty invoking this tool correctly without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description adds no additional meaning for any of the 12 parameters. It does not explain the required 'operation' parameter or optional parameters like 'days', 'stdDev', or 'timePeriod'. The agent must rely solely on the schema, which has many undocumented fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides technical analysis tools including indicators, pattern recognition, and support/resistance levels, and lists the four operations. This distinguishes it from sibling tools that focus on other data types like stock fundamentals or crypto. However, it lacks a single clear verb describing the tool's action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Sibling tool names provide some context, but the description does not mention when to prefer technical_analysis over other finnhub tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It only states creation, but lacks details on side effects (e.g., duplicate names, persistence), required permissions, or any behavioral traits beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but includes redundant 'Operations: create'. It is not front-loaded with key information and could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no output schema and minimal parameters, the description misses essential context such as uniqueness guarantees, default behavior, and post-creation actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (name has description, operation has enum). Description adds 'Operations: create' which merely restates the enum. No additional parameter context provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new project workspace' indicating verb and resource. It distinguishes from sibling 'finnhub_project_list' which lists projects. However, 'Operations: create' is redundant and adds no clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites, limitations, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It only states the basic operation without disclosing any behavioral traits (e.g., pagination, authentication, what 'available' means).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) and front-loaded. However, it is borderline under-specified, lacking important context. Score 3 as minimal viable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description is adequate but incomplete. It does not clarify the return format or what constitutes 'available projects'. Score 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only 'verbose' described in schema). The description adds no parameter meaning beyond the schema, failing to compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all available projects' with the verb 'list' and resource 'available projects'. It distinguishes from sibling 'finnhub_project_create' but does not differentiate from other siblings, so score is 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. No exclusions, prerequisites, or context provided beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions JSON export support but fails to state read-only nature, authentication needs, rate limits, or any side effects. The operations imply read access but are not explicitly described as non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with purpose. However, it includes a typo (double period) and the operation list duplicates schema information, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, one required, and no output schema, the description is incomplete. It lacks explanations for when to use each operation, data range implications, frequency options, and metricType meaning. Significant gaps remain for proper agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 63%, but the description adds little beyond the schema. It does not explain uncovered parameters like freq, operation, or metricType. The list of operations provides some context but no semantic meaning for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool accesses fundamental financial data including metrics, dividends, and revenue breakdown. It provides a specific verb 'Access' and resource 'fundamental financial data', but does not differentiate from sibling tools like finnhub_stock_market_data or finnhub_stock_ownership.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 which operation to choose. The description lists operations but offers no context for selection, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only mentions JSON export for large datasets, but does not disclose rate limits, operation-specific behaviors, or whether operations share state. This is insufficient for a tool with multiple sub-actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus a list of operations. It front-loads the main purpose. The only minor flaw is a double period after 'datasets', but overall it is efficient and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description covers the operation enum but under-explains other parameters' usage and dependencies. It provides a broad overview but is not fully complete for an agent to use all parameters correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (83%), so the baseline is 3. The description adds context by listing the operation options and mentioning JSON export, but does not explain the interplay of parameters like 'to' and 'from' across operations, nor does it clarify the 'project' parameter further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool accesses IPO, earnings, economic, and FDA calendars, listing the specific operations. It is specific about the resource and verb, but does not explicitly differentiate from sibling tools like finnhub_market_events or others, though the distinct domain is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 lacks context about prerequisites or exclusions, leaving the agent with no help in selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like read-only nature, side effects, or error conditions. It merely states the action without deeper transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but omits essential details; it is not merely concise but under-specified. It front-loads purpose but lacks supporting information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema or cross-references to creation tools, the description fails to provide a complete context for effective tool usage, especially given the complexity of job workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (job_id described), but the description adds no extra meaning beyond 'Operations: get'. It doesn't explain job_id's optionality or source, leaving semantics vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check the status of background jobs. Operations: get' clearly states the verb (check status) and resource (background jobs). It distinguishes itself from sibling tools like finnhub_stock_market_data by focusing on job status management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as after creating a job via finnhub_project_create. It lacks explicit context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It notes JSON export support but does not disclose side effects, required permissions, or data source reliability. The listed operations suggest read-only actions, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences serve the purpose well. The first sentence introduces the tool's scope, and the second lists operations. The double period is a minor formatting issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's news and sentiment domain and mentions JSON export, but lacks guidance on parameter combinations, operation-specific behavior, or output examples. Given no output schema, more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (75%), so the description provides marginal additional value. Listing the operations helps contextualize the required 'operation' parameter, but no details are added for other parameters like 'to', 'from', or 'days'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides access to company news, market news, and sentiment analysis, listing four specific operations. This differentiates it from siblings like stock fundamentals or technical analysis, but the verb 'access' is somewhat generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 description mentions JSON export for large datasets, but lacks context on prerequisites or scenarios where other siblings are more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only mentions JSON export for large datasets, but lacks details on authentication, rate limits, or any side effects. Operations are likely read-only but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and to the point with two sentences plus a list of operations. Could be improved with bullet points or more structure, but no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and 4 operations, the description is insufficient. Does not explain operation differences, return format, or error handling. No output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (86%), so baseline is 3. Description adds minimal value beyond schema; lists operations but does not clarify parameter usage like cik vs symbol or date ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it accesses insider transactions and institutional ownership data, and lists specific operations. Distinguished from sibling tools by resource type, but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., finnhub_stock_fundamentals) or which operation to choose based on use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions 'Supports JSON export for large datasets' which is a useful behavioral trait, but fails to disclose whether operations are read-only, require authentication, have rate limits, or produce side effects. For a tool with three distinct operations, the absence of per-operation behavior 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences plus a list of operations), but contains a typo (double period) and repeats the enum values from the schema. The list of operations could be integrated more concisely. It is adequately sized but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should explain return values or results for each operation. It does not. For a tool with 7 parameters and three distinct operations, the description is too minimal to guide an agent on what to expect from each call, reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (86%, effectively all parameters described), so the baseline is 3. The description adds value by noting JSON export capability, which relates to the 'export' parameter, but does not elaborate on other parameters beyond what the schema already provides. No additional meaning is added for parameters like 'from', 'to', 'form', or 'symbol'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool accesses 'SEC filings and filing sentiment analysis' and lists three specific operations (get_sec_filings, get_filing_sentiment, get_similarity_index). This distinguishes it from sibling tools like finnhub_crypto_data or finnhub_news_sentiment, which focus on different data types. The verb 'access' plus specific resource 'SEC filings' makes 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.
Usage Guidelines2/5
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 sibling tools cover different domains (crypto, forex, news, etc.), but the description does not provide a decision rule or mention when to use this tool specifically. It only states the operations without context on suitability or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must bear full burden. It mentions JSON export but fails to disclose side effects, rate limits, permissions, or what the export operation actually does (e.g., file creation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise two sentences plus a list; no fluff. The list of operations is somewhat redundant with the schema enum, but the JSON export note adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite listing operations, the description lacks details on return values, error handling, required permissions, and data freshness. With no output schema, more context is needed for a multi-operation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (83%), so baseline is 3. Description adds context about operations and export use cases but does not significantly enhance parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as accessing alternative data (ESG, social sentiment, patents) and lists specific operations, distinguishing it from sibling tools like stock fundamentals or news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like finnhub_stock_fundamentals or finnhub_news_sentiment. No when-not-to-use or prerequisite information provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions JSON export support, which is a behavioral trait, but lacks details on data freshness, rate limits, or any side effects. The listed operations are present but not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. It uses two sentences, though there is a grammatical double period and missing space. Overall, it is efficient but could be cleaner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, multiple operations, no output schema, and no annotations, the description is incomplete. It does not explain how parameters relate to operations (e.g., get_candles likely needs symbol, exchange, resolution, days) or what data is returned. The agent lacks sufficient context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 57% (4 of 7 parameters have descriptions). The description adds context for the 'export' parameter (JSON export for large datasets) but does not compensate for missing descriptions on 'days', 'operation', and 'resolution'. The operation list is helpful but already in the schema enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it accesses cryptocurrency market data and lists four operations. This distinguishes it from sibling tools like finnhub_stock_market_data by resource type, though it does not explicitly differentiate from other finnhub crypto-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many sibling tools. There are no usage triggers, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions JSON export support but does not disclose behavioral traits like side effects, authorization needs, rate limits, or whether operations are destructive. Incomplete for a tool with multiple operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. However, there is a minor typo (double period after 'datasets'). Otherwise efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description should provide more detail on operations, parameter usage, and return format. It mentions JSON export but not what the operations return, making it incomplete for an agent to fully understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (80%), so baseline is 3. The description adds minor context about JSON export but does not explain the purpose of symbol, project, exchange, or when to use each operation parameter beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool accesses market holidays, analyst ratings, and M&A activity, and lists the specific operations. It distinguishes from sibling tools that focus on other Finnhub data categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 to choose one operation over another. The only implicit usage context is the listed operations themselves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description lacks behavioral details such as rate limits, authentication needs, or side effects. It mentions JSON export but no other traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, efficient. However, the second sentence has formatting issues (double period) and could be more streamlined. Still concise overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks output schema and annotations. The description does not specify return structure, pagination, or data freshness, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value by explaining the 'export' parameter's purpose (force export) and listing operations, but the schema already covers 75% of parameters. No additional syntax or constraints beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides analyst estimates and recommendations, listing specific operations. It distinguishes from sibling tools by focusing on analyst data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like finnhub_stock_fundamentals. The description does not specify prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description only mentions JSON export support but lacks details on rate limits, data freshness, authentication needs, or side effects of operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences plus a list) and front-loads the purpose, but the list of operations is placed without clear separation, slightly reducing readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and 7 operations, no output schema, and no annotations, the description is insufficient. It does not explain parameter dependencies, operation-specific behaviors, or return value structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (73%), so the baseline is 3. The description adds minimal new meaning beyond the schema, only indicating that JSON export is supported for large datasets.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Access stock market data' with specific examples (real-time quotes, historical candles, etc.) and lists all operations, effectively distinguishing it from sibling tools like finnhub_crypto_data or finnhub_forex_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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; no mention of prerequisites or scenarios. The description simply lists operations without explaining which to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions JSON export for large datasets but does not disclose behavioral traits such as read-only nature, authentication needs, rate limits, or potential side effects from the export parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences with key information front-loaded. However, there is a typo (double period) and the structure could be improved by separating the operations list more cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema, no annotations), the description is insufficient. It fails to explain parameter usage per operation, return format, or any dependencies, leaving significant gaps for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 67% schema description coverage, the description adds no meaning to parameters beyond what the schema provides. It does not explain how parameters relate to specific operations or provide any additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Access foreign exchange market data' and lists specific operations (get_exchanges, get_symbols, get_rate, get_candles), which distinguishes it from sibling tools focused on other asset classes like crypto or stocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for forex data access and lists operations, but does not explicitly state when to use this tool over alternatives or provide exclusions. No guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![aigroup-finnhub-mcp MCP server](https://glama.ai/mcp/servers/jackdark425/aigroup-finnhub-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jackdark425/aigroup-finnhub-mcp)

Score Badge

Copy to your README.md:

[![aigroup-finnhub-mcp MCP server](https://glama.ai/mcp/servers/jackdark425/aigroup-finnhub-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jackdark425/aigroup-finnhub-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jackdark425/aigroup-finnhub-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server