Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: add Foxy Contexts to additional resources #352

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

strowk
Copy link
Contributor

@strowk strowk commented Dec 15, 2024

Description

This adds a library to list of additional resources in README.

Motivation and Context

Library helps Golang developers to quickly bootstrap new servers.

How Has This Been Tested?

I took functional testing approach: https://foxy-contexts.str4.io/testing

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Protocol Documentation
  • My changes follows MCP security best practices
  • I have updated the server's README accordingly
  • I have tested this with an LLM client
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have documented all environment variables and configuration options

Additional context

The lib embraces DI concept to allow for more scalable development. It also very nicely works with generating new tools with LLM, as they just need to get an example of a tool with whatever context is injected to understand how to build a tool with same dependencies, but different logic. Compared to approaches where API has a setRequestHandler handler method and LLM have to be explained how to modify a file with all the other tools, here LLM only needs to focus on one tool at a time.

Copy link
Member

@jspahrsummers jspahrsummers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Is this specific to foxyapps.com? If so, can you please explain it as such?

@strowk
Copy link
Contributor Author

strowk commented Dec 16, 2024

No, it has no relation to that website except for accidental collision in first word. I have named my library foxy after "fx" framework that is used for dependency injection and "contexts" after MCP's middle name.

@jspahrsummers
Copy link
Member

jspahrsummers commented Dec 17, 2024

No, it has no relation to that website except for accidental collision in first word. I have named my library foxy after "fx" framework that is used for dependency injection and "contexts" after MCP's middle name.

@strowk Hmm, I'm a bit confused by this mention in the README, then:

Using it you can build context servers using declarative approach, by defining tools, resources and prompts and then registering them with your FoxyApp …

What is a "FoxyApp" here?

@strowk
Copy link
Contributor Author

strowk commented Dec 17, 2024

What is a "FoxyApp" here?

It is just a builder that wraps "fx" app, which is why it has "App" word. No relation to website you linked. Coincidences happen as there are only so much words in english :)

See here in godoc: https://pkg.go.dev/github.com/strowk/[email protected]/pkg/app#FoxyApp

FoxyApp is essentially a builder for a foxy app, that wraps fx.App and provides a more user-friendly interface for building and running your MCP server
You would be calling WithTool, WithResource, WithResourceProvider, WithPrompt to register your tools, resources, resource providers and prompts and then calling Run to start the server, or you can instead call BuildFxApp to get the fx.App instance and run it yourself. You must set transport using WithTransport. Unless you configure server using WithName and WithVersion, it will use default values "my-foxy-contexts-server" and "0.0.1". Finally you can use WithFxOptions to pass additional fx.Options to the fx.App instance before it is built.

I could probably rename this particular structure to AppBuilder or simply Builder so users can refer to it as app.Builder and app.NewBuilder() (it's a Golang thing..) so then there is no confusion. Would that help?

UPD: I have renamed that structure to be simply Builder and it is referred to from other packages as app.Builder to avoid any extra confusion, plus it describes the nature of that structure better.
Docs changed now: https://foxy-contexts.str4.io/app_builder/ and README is new too, godoc sees the change as well: https://pkg.go.dev/github.com/strowk/[email protected]/pkg/app#Builder

@strowk strowk requested a review from jspahrsummers December 18, 2024 21:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants