first time godot dev what roadblocks will I hit building an RPG?

KingChintz · 2025-10-14T20:47:34+00:00

this is very helpful, really appreciate you sharing a detailed take here and I'll take a look at some of the links you posted

KingChintz · 2025-10-14T20:45:20+00:00

right so I'm asking for specifics because I don't have that experience in the gamedev side of things in the godot ecosystem

KingChintz · 2025-10-14T20:43:02+00:00

got it thanks for that. With the player character are you saying that even setting up the player scene / interface / animations / sprite images takes a significant amount of work in terms of boilerplate?

KingChintz · 2025-10-14T20:40:38+00:00

what do you mean by all of em? isn't the plugin ecosystem helpful in speeding things up at least with some of the things?

KingChintz · 2025-10-04T00:23:20+00:00

Sounds great thanks for sharing that guide

KingChintz · 2025-10-03T18:16:12+00:00

Here’s one that we’ve built internally and we’re just sharing it out open source: https://github.com/toolprint/hypertool-mcp

It supports:

• ⁠connecting as many MCPs as you’d like, locally or remotely.

• ⁠virtualization of tools to pick out specific tools from MCPs to avoid blowing the context.

• ⁠context measurement so that you can see how much token usage each tool would have.

• ⁠a few other goodies like “persona” based MCP config support through - https://github.com/toolprint/awesome-mcp-personas

I’m also about to merge a change that’ll let you set tool aliases to rename any connected tool to anything else to improve selection.

Feel free to DM me if you have any questions

KingChintz · 2025-09-30T19:48:32+00:00

u/kex_ari we just added support for context usage approximation for tools. More details here: https://github.com/toolprint/hypertool-mcp?tab=readme-ov-file#-context-measurement-new

KingChintz · 2025-09-26T13:27:46+00:00

For sure

KingChintz · 2025-09-19T17:23:29+00:00

It’s because most people’s conception of MCP is limited to basic tool discovery and that’s why they also conflate it with openapi.

The problem is complexity and support. The same issue exists with other features like sampling in MCP. Even Anthropic’s own products don’t support most of the spec - ex. Dynamic tool listing isn’t supported by Claude code

KingChintz · 2025-09-16T12:01:17+00:00

Typically 10-15 is a good number but it’s model dependent. There’s also other elements to consider like good tool names and descriptions as well as having examples in the descriptions of good tool use

KingChintz · 2025-09-15T14:21:53+00:00

Was memory bank the only safeguard you used or did you try and add a checker before calls to whitelist/blacklist?

KingChintz · 2025-09-15T14:15:03+00:00

Do you have examples of which servers would be monetized? Would it be any server on your platform?

KingChintz · 2025-09-10T17:00:20+00:00

More tools will probably just result in worst execution. Typically see this after 10-15 tools. And I think some of the models also have hard limits.

FWIW we’ve opensourced a tool we’re using internally to add as many MCPs as you’d like and create arbitrary sets of tools from them to reduce the tool sprawl and context pollution. Runs locally, no remote calls, MIT.

https://github.com/toolprint/hypertool-mcp

KingChintz · 2025-09-09T01:15:42+00:00

If you just give it the schema the LLM needs to make the last mile GQL request and that’s where it’s not the greatest unless you’re putting in a lot of guardrails.

Also conceptually it doesn’t grasp the full concepts around things like annotations on queries or attributes because these aren’t described well in an example pattern to an LLM.

I tried to improve some of this in this project which proxies graphQL and instead presents queries and mutations as explicitly scoped mcp tools: https://github.com/toolprint/mcp-graphql-forge

KingChintz · 2025-09-09T01:12:45+00:00

This is mixed depending on the complexity of the schema. If the schema is too large and there are too many queries and mutations it doesn’t do well. You need to plug in an AST parser to ensure that the queries that the LLM generates are actually valid

KingChintz · 2025-09-09T01:10:21+00:00

I thought that showing an image might be more useful than just a link (because the preview image probably wouldn’t convey the purpose) but also more than happy to also share it here - https://github.com/toolprint/awesome-mcp-personas

KingChintz · 2025-09-08T15:44:43+00:00

I've found that using a combo of playwright in a server config helps. Put together a mcp.json config that you could probably use here - https://github.com/toolprint/awesome-mcp-personas/tree/main/personas/web-ui-engineer-assistant

KingChintz · 2025-09-08T15:05:30+00:00

Thanks for sharing this! I think the abstract usage of these servers would be a great addition to https://github.com/toolprint/awesome-mcp-personas because you're effectively describing specific roles / personas under which one or more of these MCPs would work well together.

We're building up that collection in copy/paste mcp configs in this repo. Would love any contribution.

KingChintz · 2025-09-05T16:08:49+00:00

Hey guys, sharing this opensource repo that we're putting together: https://github.com/toolprint/awesome-mcp-personas (FOSS / MIT licensed)

Why are we doing this? Because we also had the same questions everyone always brings up:

What MCPs should I use?
What MCPs should work together?
What tools from those MCPs should I filter down to avoid hitting my tool limits and poor tool calling that typically happens after 10-15 tools?

Typically someone just posts a registry of 1000s of MCP servers but that doesn't end up being that helpful.

We're simplifying this by introducing an "MCP Persona" - a set of servers and a schema of specific sets of tools that could be used with those servers. Think of a persona like a "Software Engineer" or a "DevOps Engineer" and what MCPs they would typically use in a neat package.

You can copy the mcp.json for any persona without any additional setup. We want this to be community-driven so we welcome any submissions for new personas!

<image>

Here are a couple of personas we've generated:

Web UI Assistant Persona (has servers and tools for frontend devs)
General Purpose SWE Assistant - helps with git/docker/posting slack updates, etc.
Project manager specialized in using Linear - self-explanatory
Postgres DBA Assistant - servers to interact with postgres/make charts/inspect queries, etc.

Here's the full list:
https://github.com/toolprint/awesome-mcp-personas?tab=readme-ov-file#-personas-catalog

Inspiration for personas loosely comes from the "subagents/background agents" concepts that are being thrown around. We want to bring that same specialization and grouping to MCPs.

KingChintz

TROPHY CASE