A
licenseB
qualityB
maintenanceA Model Context Protocol server providing real-time stock data and options analysis through Yahoo Finance, enabling LLMs to access market data, analyze stocks, and evaluate options strategies.
3
27
MIT
Agentic AI with MCP
by dev484p
モデルコンテキストプロトコル（MCP）を備えたエージェント型AI
このプロジェクトは、Groqホスト型LLM（qwen-qwq-32bモデル）をカスタムモデルコンテキストプロトコル（MCP）サーバーを介して様々なツールに接続するエージェント型AIシステムを実装します。このシステムは、Wikipedia、インターネット検索（Tavily API経由）、金融データ（Yahoo Finance API経由）からのコンテキスト情報を提供することで、LLMの機能を強化します。
MCPについて
モデルコンテキストプロトコル（MCP）は、Anthropicが開発したオープンスタンダードであり、アプリケーションが大規模言語モデル（LLM）にコンテキストを提供する方法を標準化します。MCPは、LLMアプリケーションと外部データソースおよびツールとのシームレスな統合を促進し、AIシステムが標準化されたインターフェースを介して様々なサービスと動的に連携することを可能にします。
MCP の主な機能:
標準化: AI アシスタントを構造化されたツールおよびデータ レイヤーとインターフェイスするための汎用プロトコルを提供します。
モジュラー アーキテクチャ: 通常はホスト AI システムによって仲介される永続ストリーム上のクライアント サーバー パターンに従います。
動的イントロスペクション: tools/list や resources/list などのメソッドを通じてツールとリソースの動的な検出をサポートします。
セキュリティ: ホストを介した認証を組み込み、安全なトランスポート プロトコルをサポートします。MCP を採用することで、開発者は相互運用性とセキュリティが向上し、複雑なワークフローに対応できる AI アプリケーションを構築できます。
MCP サーバーに新しいツールを追加するには:
ツールを定義する: 特定のタスクまたはデータの取得を処理する新しい関数を作成します。
ツールを登録する: ツールの名前と説明を指定して、新しい機能が含まれるようにサーバーのツール レジストリを更新します。
リクエストの処理: サーバーがクエリに基づいて受信リクエストを適切なツールにルーティングできるようにします。このモジュール式のアプローチにより、サーバーの機能を簡単に拡張でき、言語モデルがより広範なコンテキスト情報にアクセスできるようになります。
Related MCP server: Wikipedia MCP Server
特徴
MCP サーバー: さまざまなツールへのアクセスを提供する中央ハブ
3つの統合ツール:
Wikipedia検索 - 事実情報の検索
インターネット検索 - Tavily API を活用した包括的なウェブ検索結果
Yahoo Finance API - リアルタイムの株価と金融データ
Groq API 統合: qwen-qwq-32b モデルを使用した超高速 LLM 処理
クライアントサーバーアーキテクチャ: ツール管理とLLMの相互作用を明確に分離
前提条件
始める前に、次のものがあることを確認してください。
インストール
リポジトリをクローンします。
git clone https://github.com/dev484p/AgenticAI_MCP cd AgenticAI_MCP依存関係をインストールします:
uv add "mcp[cli]"環境変数を設定します:keys.json の Groq および Tavily API キーを更新します
オプション (開発用に MCP Inspector を使用してサーバーを実行する場合):
uv run mcp dev server.pyチャットボットを開始するには、次のコマンドを実行します。
uv run client.py
利用可能なツール
システムは、MCP サーバーを通じて次の 3 つのツールを提供します。
ウィキ検索:
Wikipediaの情報にアクセスする
クエリ例:「人工知能の歴史について教えてください」
インターネット検索（Tavily）：
包括的なウェブ検索結果を取得する
クエリの例: 「量子コンピューティングの最新の開発状況は何ですか?」
ヤフーファイナンス:
株価や財務データにアクセスする
クエリの例: 「AAPL 株の現在の価格はいくらですか?」
参照
Available Tools
3 toolsinternet_searchC
Search the internet using Tavily API.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No | ||
| include_raw_content | No |
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the Tavily API but doesn't describe key traits like rate limits, authentication needs, response format, or error handling. This is inadequate for a tool that performs external searches with potential constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to parse quickly, though this brevity contributes to gaps in other dimensions.
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 (external API search with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral traits, parameter meanings, or return values, making it insufficient for reliable agent use.
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 description coverage is 0%, so the schema provides no parameter details. The description adds no information about parameters like 'query', 'limit', or 'include_raw_content', failing to compensate for the coverage gap. This leaves the agent without semantic understanding of inputs.
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 action ('Search') and target ('the internet'), and mentions the specific API ('Tavily API'), which provides implementation context. However, it doesn't explicitly differentiate from sibling tools like 'wiki_search' or 'yahoo_finance_search' beyond the general internet scope.
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 sibling tools ('wiki_search' and 'yahoo_finance_search'). The description lacks any context about appropriate use cases, exclusions, or alternatives, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wiki_searchC
Search Wikipedia for articles.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a search operation but doesn't describe what the search returns (e.g., article summaries, links), whether it has rate limits, authentication needs, or any constraints like language or date ranges. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it easy to parse. It's front-loaded with the core action and resource, though it could benefit from additional context to improve usefulness without sacrificing brevity.
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 lack of annotations and output schema, the description is incomplete. It doesn't address the tool's complexity (a search operation with parameters), leaving the agent unsure about return values, error handling, or how results are structured. For a tool with 2 parameters and no structured output, more detail is needed to be fully helpful.
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 schema description coverage is 0%, so the description must compensate, but it adds no information about parameters. It doesn't explain what 'query' should contain or that 'limit' controls the number of results, leaving both parameters undocumented beyond their schema definitions. However, with only 2 parameters and a default for 'limit', the baseline is slightly higher.
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 action ('Search') and resource ('Wikipedia for articles'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'internet_search' or 'yahoo_finance_search', which would require mentioning Wikipedia specifically as the search target versus broader internet or finance searches.
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. It doesn't mention that it's for Wikipedia-specific searches as opposed to general internet searches or finance-related searches, nor does it specify any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
yahoo_finance_searchC
Get stock information from Yahoo Finance.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| period | No | 1mo |
TDQS
C2.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'gets' information, implying a read-only operation, but doesn't clarify if it's safe, requires authentication, has rate limits, or what kind of data it returns. For a tool with zero annotation coverage, this is insufficient to guide the agent's expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of a single sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration, making it efficient for quick understanding.
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 complexity (2 parameters, no annotations, no output schema), the description is incomplete. It doesn't cover parameter meanings, return values, or behavioral traits. While it states the basic purpose, it lacks the depth needed for the agent to use the tool effectively without additional context.
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?
The description adds no meaning beyond what the input schema provides. With 0% schema description coverage, both parameters ('symbol' and 'period') are undocumented in the schema, and the description doesn't explain what they represent, their formats, or valid values. This leaves the agent guessing about parameter usage.
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's purpose: 'Get stock information from Yahoo Finance.' It specifies the verb ('Get') and resource ('stock information from Yahoo Finance'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'internet_search' or 'wiki_search', which prevents a perfect score.
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. It doesn't mention sibling tools or any context for choosing this over general search tools. There's no information about prerequisites, limitations, or specific use cases, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
- First observed
internet_search - First observed
wiki_search - First observed
yahoo_finance_search
TDQS
B3.1/5.0
Scored across 3 tools
Disambiguation5/5
Each tool has a clearly distinct purpose: internet_search uses Tavily API for general web searches, wiki_search targets Wikipedia articles specifically, and yahoo_finance_search focuses on stock information from Yahoo Finance. There is no overlap in functionality or ambiguity between these three tools.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with a clear verb_noun structure: internet_search, wiki_search, and yahoo_finance_search. The naming is uniform and predictable across the entire set.
Tool Count3/5
With only 3 tools, the server feels thin for the broad domain implied by 'Agentic AI with MCP', which suggests a more comprehensive set of capabilities. While each tool is distinct, the count is borderline low for typical agentic AI tasks that might require more varied operations.
Completeness2/5
The tool surface is severely incomplete for an 'Agentic AI' server, as it only provides search functionalities without any CRUD operations, data processing, or other AI-related actions. There are significant gaps that will limit agent effectiveness, such as missing tools for data manipulation, analysis, or interaction with AI models.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Financial data MCP server for Claude, ChatGPT, Cursor and Codex. Real-time stock quotes, financial statements, options flow, SEC filings, insider trades, 13F holdings, macro data and market news from gloom.sh, the open-source Bloomberg Terminal alternative.
Related MCP Servers
- AlicenseBqualityCmaintenanceA Model Context Protocol server that retrieves information from Wikipedia to provide context to LLMs, allowing users to search articles, get summaries, full content, sections, and links from Wikipedia.222,859 PyPI299MIT
- AlicenseBqualityAmaintenanceA Model Context Protocol server that enables interaction with Yahoo Finance to retrieve stock pricing, company information, and historical financial data through natural language queries.211,290 PyPI28MIT
- AlicenseCqualityNot gradedmaintenanceA Model Context Protocol server that provides tools for interacting with Yahoo Finance, allowing users to retrieve stock prices, company information, and perform financial data comparisons.11MIT