Auto Derive DSL

[mmbarness]

Adds automatic tool generation to FastMCP through adapter classes and method exposure.

Features

ActiveRecord Adapters

• find: Locate records by ID
• where: Query records by attributes
• create: Create new records
• update: Modify existing records
• destroy: Remove records
• random: Retrieve random record sets

Model Method Exposure

expose_to_mcp :find_by_sku,
              description: "Find a product by its SKU code",
              parameters: { sku: { type: :string, description: "The SKU code" } }

Controller Action Exposure

expose_action_to_mcp :search,
                     description: "Search for products", 
                     parameters: {
                       query: { type: :string, description: "Search query" }
                     }

Configuration

FastMcp.configure do |config|
  auto_register_tools: true,
  read_only: true,
  excluded_namespaces: ["ActionText", "ActionMailbox", "ActiveStorage"]
end

[yjacquin]

Hey @mmbarness thanks a lot for this great PR!
It will take a while for me to review it fully, but I love the idea, great work !

[mmbarness]

i'll rebase this within the next day or two

[mmbarness]

Rebased. Something I didn't note before: I've widened the version window for rack from ~> 3.1 to >= 2.2.4, < 4.0, mostly out of self-interest; I can't use this library in my work if the rack version is pegged to 3.1, but I also think that more generally a lot of people who work on older rails applications might have a harder time adopting MCP tooling in their work if they have to update everything that depends on rack versions older than the latest one. I believe we're safe from regressions, too. I've been using this for a while in my local environment with rack v2.2.10 with no issues, but maybe it's worth proving out further.

Let me know what you think!

[Kevin-K]

Rebased. Something I didn't note before: I've widened the version window for rack from ~> 3.1 to >= 2.2.4, < 4.0, mostly out of self-interest; I can't use this library in my work if the rack version is pegged to 3.1, but I also think that more generally a lot of people who work on older rails applications might have a harder time adopting MCP tooling in their work if they have to update everything that depends on rack versions older than the latest one. I believe we're safe from regressions, too. I've been using this for a while in my local environment with rack v2.2.10 with no issues, but maybe it's worth proving out further.

Let me know what you think!

I'm in the same boat, lowering to >= 2.x on a fork of this gem was sufficient for unblocking a project I'm working on. Could we make that rack version change as a separate pr? I'd be happy to help on verifications.

[Kevin-K]

Added a separate pr for lowering rack requirement to >= 2.2: #107

[mmbarness]

@yjacquin do you have a roadmap in mind for merging this?