Introduction & Contribution Interest: AI and Data Science Engineer with LLM and MCP experience

[satheeshk50]

Hi @strawgate and maintainers,

I’m Satheesh Kuraba, an AI and Data Science Engineer passionate about agentic systems and modern orchestration frameworks like FastMCP.

About me:

• Currently Studying B.Tech Final Year in Computer Science and Engineering from Rajiv Gandhi University of Knowledge Technologies (CGPA: 8.5/10).
• Strong technical background in Python, FastAPI, TensorFlow, and Docker.
• Skilled with LLMs, Retrieval-Augmented Generation (RAG), and real-time scalable AI applications.
• Worked on multiple projects including:
  • LLM-Powered Contextual Web Toolchain (MCP Project): Built modular MCP tools using FastAPI, LangChain, and Docker for real-time, context-aware responses. Integrated hierarchical web scraping and SSE-driven microservices.
  • AI-Powered LinkedIn Content Automation Agent: Developed an agent for automated content creation and posting, using advanced language models and LangGraph workflows.
  • Facial Recognition System using FaceNet and FastAPI: Developed real-time backend and integrated MongoDB for secure embedding storage.

Why I want to contribute:
I’m particularly interested in agent orchestration using FastMCP and building modular tools that support scalable, context-aware workflows. I see that fastmcp-agents aligns perfectly with my skills and interests.

How I can help:

• Develop or improve agent modules and tool integrations.
• Contribute to workflow design and optimization.
• Enhance documentation and onboarding guides.
• Implement additional features or help with testing and CI.

Would you be able to suggest any good first issues or areas where I can start contributing? Looking forward to collaborating with you and the team!

Thank you so much for your work on this project — excited to get started!

Best regards,
Satheesh Kuraba

[strawgate]

Hi!

Thanks for the note!

Contributing to FastMCP Agents is a bit interesting because my goal is that it's a "disappearing project".

What do I mean by that?

Well, everything that is built into or built for FastMCP Agents should go away in the future.

The goal is to prove out concepts around FastMCP Agents and then upstream those concepts into FastMCP.

For example, tool transformation: jlowin/fastmcp#745

Up next I'm trying to bring runtime MCP server transformation to FastMCP here jlowin/fastmcp#1132

After that will be adding a completions (LLM responses) mechanism to FastMCP.

I'll be landing a large PR later today or early tomorrow that removes a lot of functionality that has since been upstreamed and if you wanted to try using FastMCP Agents to solve a problem and report and issues or suggestions I think that would be a great place to start and I'll think about good first issues in the meantime

[satheeshk50]

Thank you so much for the detailed explanation!

I really like the idea of FastMCP Agents as a "disappearing project" to prove and upstream concepts.

I'll start by setting up FastMCP Agents locally and using it to build a sample workflow (possibly a RAG-based or multi-agent orchestration task). I'll report any issues or suggestions I find while using it.

Meanwhile, if you come up with any "good first issues", please do let me know — I'd be happy to help with those as well.

Thanks again for guiding me!

[strawgate]

I have a sample rag flow I can share, will post in a little bit

[strawgate]

knowledge-base.yml

shared_instructions:
  esql: &esql_instructions >-
    When you are asked to perform a task that requires you to perform an ESQL query.
      
    You have access to a knowledge base to answer questions. This knowledge base has two types of information in information:
    1. ES|QL Query Syntax and tips
    2. The Elastic Commmon Schema, a set of common fields (not exhaustive)

    Do not specify a Knowledge base when running queries, then they will run against all KBs
    
    You should leverage the knowledge base to determine what functionality of ESQL is relevant for the task and what fields to recommend
    to the user to resolve the task.

    ```   
    # What's ES|QL?

    It's not SQL. ESQL is a query language for Elasticsearch. It is a powerful tool for querying and analyzing data in Elasticsearch.

    You can author ES|QL queries to find specific events, perform statistical analysis, and create visualizations.
    It supports a wide range of commands, functions, and operators to perform various data operations, such as filter,
    aggregation, time-series analysis, and more. It initially supported a subset of the features available in Query DSL,
    but it is rapidly evolving with every Elastic Cloud Serverless and Stack release.

    ES|QL is designed to be easy to read and write, making it accessible for users with varying levels of technical expertise.
    It is particularly useful for data analysts, security professionals, and developers who need to work with large datasets in Elasticsearch.

    How does it work?
    ES|QL uses pipes (|) to manipulate and transform data in a step-by-step fashion. This approach allows you to compose a series 
    of operations, where the output of one operation becomes the input for the next, enabling complex data transformations and analysis.

    Here's a simple example of an ES|QL query:

    FROM sample_data
    | SORT @timestamp DESC
    | LIMIT 3
    Note that each line in the query represents a step in the data processing pipeline:

    The FROM clause specifies the index or data stream to query
    The SORT clause sorts the data by the @timestamp field in descending order
    The LIMIT clause restricts the output to the top 3 results
    ```

    When calculating metrics, bucketing by time requires careful consideration of the query. here's an example of how to bucket by week:

    ```esql
    FROM employees
    | STATS COUNT(*) BY BUCKET(hire_date, 1 week)
    ```

    You can also assign friendly names to these stats and buckets:
    ```esql
    FROM employees
    | STATS hires_per_week = COUNT(*) BY week = BUCKET(hire_date, 1 week)
    | SORT week
    ```

    You will always verify that every command you use is valid and has a supporting piece of documentation from the knowledge base.
    If you cannot find a piece of documentation for the command, that means it is not a valid command so do not use it. If you cannot
    solve the task with commands that exist, you will report failure for the task.

    When building a query it's helpful to build the query in stages, adding one command at a time and testing it.

    If there are parts that are variable (like a threshold, or a date range, source index, etc) that the user will need to provide, 
    you should indicate as such in your response.

    Things to avoid:
    - Targeting `metrics-*` or `logs-*` indices. Use more specific targets.
    - Add a limit to your queries: `| limit 100`
    - When querying with ES|QL if a field you're targeting doesn't actually exist in a mapping it will error. You must
      only target fields that exist when running ES|QL queries.
    - You cannot use `AS` to name fields, the syntax is `field_name = expression`

  elasticsearch: &elasticsearch_instructions >-
    You have access to the Elasticsearch MCP Server to perform queries so you can verify the indices, fields, mappings and more:
    1. Call indices_data_streams_stats to get a list of data streams
    2. For interesting datastreams, call summarize_data_stream, providing the list of datastreams you're interested in more information about
       This will provide a summary of fields along with sample data for each field and some sample documents.

    You should always run any ES|QL query you write for a task and make sure it works. In addition, you should always provide a 
    markdown formatted response with a small set of actual results of the query for the user to see.

    If the user asks you a specific question, like how many of X are there, you should run a query to get the answer but you should
    also provide the full query, explanation, documentation links, and results in your response unless specifically asked not to.

  knowledge_base: &knowledge_base_instructions >-
    You have access to a knowledge base to answer questions. This knowledge base has two types of information in information:
    1. ES|QL Query Syntax and tips
    2. The Elastic Common Schema, a set of common fields (not exhaustive)

    When searching the Knowledge Base you should almost never perform only one query. You should perform several queries!
    1. Start with high-level questions about the problem and task, for example what kind of query and what types of fields might
    be relevant to the task.
    2. Narrow down to more specific questions, for example more specific information on a specific ES|QL command or field.

    You should never answer a user question without having first queried the knowledge base. If you cannot query the knowledge
    base you will report failure for the task.

  formatting: &formatting_instructions >-
    Provide answers in Markdown and explain each part of the query with links to documentation for that part of the query.

agents:
  - name: ask_esql_agent
    description: >-
      Ask the ESQL Agent to perform ESQL queries on your behalf. Can take plain language requests and
      perform the necessary operations to complete the task. You must be as specific as possible
      if you intend to have the Agent perform tasks on your behalf.
    instructions:
      - *esql_instructions
      - *formatting_instructions
      - *knowledge_base_instructions
  
    allowed_tools:
      - docs_query

mcpServers:
  knowledge-base:
    command: uvx
    args:
      - knowledge-base-mcp
      - duckdb
      - persistent
      - run

Run using

uvx fastmcp_agents config --file ./knowledge-base.yml call load_website '{"knowledge_base": "ESQL", "seed_urls": ["https://www.elastic.co/docs/reference/query-languages/esql/"], "background": false}' run
uvx fastmcp_agents config --file ./knowledge-base.yml call load_website '{"knowledge_base": "Elastic Common Schema", "seed_urls": ["https://www.elastic.co/docs/reference/ecs/"], "background": false}' run

uvx --refresh fastmcp_agents --transport sse config --file ./knowledge-base.yml run

This will use my Knowledge Base (RAG) MCP server to crawl docs from two domains and then wrap the knowledge base MCP in an Agent that can be used to answer questions about the docs.

The Knowledge Base server is a project I've been working on for a while that does 100% local, on-device RAG with vector search using DuckDB by default, local embeddings, and local search.

LiteLLM is the provider so you'll need to pick a Model (I've only tested with Gemini and briefly Claude). For me this means first running gcloud init and exporting a model environment variable:
MODEL=vertex_ai/gemini-2.5-flash

[strawgate]

also see the quickstart for a list of 'bundled' agents which you can just hit run on and start playing with https://github.com/strawgate/fastmcp-agents/blob/main/docs/quickstart.md

[strawgate]

The yaml block above was using uv instead of uvx which would have required cloning the knowledge base repo. I edited it to use uvx which should allow that yaml and script to run totally standalone as long as you've got UVX on your system