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
IA agente con protocolo de contexto de modelo (MCP)
Este proyecto implementa un sistema de IA Agentic que conecta un LLM alojado en Groq (modelo qwen-qwq-32b) con diversas herramientas mediante un servidor de Protocolo de Contexto de Modelo (MCP) personalizado. El sistema mejora las capacidades del LLM al proporcionar información contextual de Wikipedia, búsquedas en internet (mediante la API de Tavily) y datos financieros (mediante la API de Yahoo Finance).
Acerca de MCP
El Protocolo de Contexto de Modelo (MCP) es un estándar abierto desarrollado por Anthropic para estandarizar la forma en que las aplicaciones proporcionan contexto a los grandes modelos lingüísticos (LLM). Facilita la integración fluida entre las aplicaciones LLM y las fuentes de datos y herramientas externas, permitiendo que los sistemas de IA interactúen dinámicamente con diversos servicios a través de una interfaz estandarizada.
Características principales de MCP:
Estandarización: proporciona un protocolo universal para interconectar asistentes de IA con herramientas estructuradas y capas de datos.
Arquitectura modular: sigue un patrón cliente-servidor a través de un flujo persistente, generalmente mediado por un sistema de inteligencia artificial host.
Introspección dinámica: admite el descubrimiento dinámico de herramientas y recursos a través de métodos como herramientas/lista y recursos/lista.
Seguridad: Incorpora autenticación mediada por el host y admite protocolos de transporte seguro. Al adoptar MCP, los desarrolladores pueden crear aplicaciones de IA más interoperables, seguras y capaces de gestionar flujos de trabajo complejos.
Para agregar nuevas herramientas al servidor MCP:
Definir la herramienta: crear una nueva función que maneje la tarea específica o la recuperación de datos.
Registrar la herramienta: actualice el registro de herramientas del servidor para incluir la nueva función, especificando el nombre y la descripción de la herramienta.
Manejar solicitudes: garantizar que el servidor pueda enrutar las solicitudes entrantes a la herramienta adecuada en función de la consulta. Este enfoque modular permite una fácil expansión de las capacidades del servidor, lo que permite que el modelo de lenguaje acceda a una gama más amplia de información contextual.
Related MCP server: Wikipedia MCP Server
Características
Servidor MCP : Centro central que proporciona acceso a varias herramientas
Tres herramientas integradas :
Búsqueda en Wikipedia: para recuperar información factual
Búsqueda en Internet: con tecnología de API de Tavily para obtener resultados web completos
API de Yahoo Finance: para datos bursátiles y financieros en tiempo real
Integración de la API de Groq : procesamiento LLM ultrarrápido con el modelo qwen-qwq-32b
Arquitectura cliente-servidor : separación clara entre la gestión de herramientas y la interacción LLM
Prerrequisitos
Antes de comenzar, asegúrese de tener lo siguiente:
Instalar UV para la instalación de Python
Clave API de Groq. Consulta la documentación.
Clave API de Tavily (regístrese en Tavily AI )
Instalación
Clonar el repositorio:
git clone https://github.com/dev484p/AgenticAI_MCP cd AgenticAI_MCPInstalar dependencias:
uv add "mcp[cli]"Configura tus variables de entorno: Actualiza la clave API de Groq y Tavily en keys.json
Opcional (para ejecutar el servidor con el Inspector MCP para desarrollo):
uv run mcp dev server.pyEjecute el siguiente comando para iniciar el chatbot:
uv run client.py
Herramientas disponibles
El sistema proporciona tres herramientas a través del servidor MCP:
Búsqueda en Wiki:
Acceder a la información de Wikipedia
Ejemplo de consulta: "Cuéntame sobre la historia de la inteligencia artificial"
Búsqueda en Internet (Tavily):
Obtenga resultados de búsqueda web completos
Ejemplo de consulta: "¿Cuáles son los últimos avances en computación cuántica?"
Yahoo Finanzas:
Acceda a precios de acciones y datos financieros
Ejemplo de consulta: "¿Cuál es el precio actual de las acciones de AAPL?"
Referencia
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