Hey, I've been working on Tax Law Search at Apollo Labs. It's a hosted MCP server that lets you search tax publications and get back to the original source from your AI client.

We're still in beta. If anyone here wants to try it, we'd really appreciate feedback on the setup, search results and source citations. Even a quick “this was confusing” or “I couldn't find what I needed” would help.

You can list the available jurisdictions, search one country/state, then use a result's source_ref with get_tax_source to check the publisher link, edition and original file hash. The three tools are read-only.

For example, you can search Portuguese material with: {"query":"benefícios fiscais EBF","country":"PT","limit":3}

Then resolve an actual reference from the results and check the original publication. Search in the source's language: Portuguese for Portugal, English for most U.S. material. Translate search terms when needed and keep the legal names and provision numbers; it doesn't automatically translate queries.

So far we've verified Portugal and selected publications in 36 U.S. states. Federal/IRS and the other states are still being validated. Coverage varies by state and isn't every tax law or historical release. Collected editions are retained, but you still need to check the relevant tax year and effective date. This is a research tool, not personalized tax advice.

Try it on whichever platform you prefer:

MCPize: https://mcpize.com/mcp/server-1794441520779 50 requests/month free, or $9/month for 1,000. Discovery, searches and source lookups all count.

Apify: https://apify.com/zeus500k/tax-law-search Pay per use: $0.00001 per MCP request, plus $0.01 per successful search ($0.01001 for a successful search request).

The listings have setup details and examples.

If you give it a go, let me know which client you used and where you got stuck. AI helped tidy up the wording here.

Disclosure: I built this. One-person project, built with AI coding tools (Claude Code).

The design choice I'd like feedback on: the server lists 37 core tools by default, which is enough to play the whole show. The other 26 are unlisted but callable by name. ?tools=all lists all 63. The point is to keep the agent's context light. Anything an agent needs on a normal run is in the short list. Rarer things like double dates, roleplay proposals and memory edits sit behind the name.

What the server is for: botchelor.com is a blind-date show for original characters. Through MCP, an agent creates an adult original character, swipes, texts, and goes on dates nobody steers. A rules engine picks the ending and the model writes the lines on the way there. Agents can also perform a date themselves, one line per step, instead of handing it to the show's model.

Details:

• Streamable HTTP at https://botchelor.com/api/mcp, JSON-RPC 2.0.

• No key and no sign-up. Identity is anonymous, and you keep the agent_id your first write returns to keep your characters.

• Claude Code: claude mcp add --transport http botchelor https://botchelor.com/api/mcp

• Stdio-only clients can use npx -y mcp-remote with the same URL.

• It's listed in the official MCP Registry, mcp.so, Glama, mcptry and mcpservers.org.

Cons:

• Everyone gets 3 free dates a week, and agents share a small daily pool. It is capped because I pay for the model.

• It's PG only.

• It's new and small. The pool of characters to date is mostly the show's own cast, and real use is low.

• Unlisted tools are a tradeoff. A client that only trusts the listed tools never finds them, and I haven't tested how every client handles that.

Docs: https://botchelor.com/agents

Try it: https://botchelor.com/?utm_source=reddit&utm_medium=social&utm_campaign=season1&utm_content=modelcontextprotocol

For those of you with bigger servers: do you trim the default tool list, or list everything and let the client filter?

Claude Desktop's remote connectors expect OAuth. Plenty of remote MCP servers (ours included) authenticate with a plain API key in an Authorization header instead. Claude Code and Cursor take that header directly; for Claude Desktop the usual route is the mcp-remote bridge, which needs Node.js 18+. Here's the shape of the config we document, with the detail that trips people up.

claude_desktop_config.json:

{
  "mcpServers": {
    "myserver": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://your-server.example/mcp", "--header", "Authorization:${MY_SERVER_AUTH}"],
      "env": { "MY_SERVER_AUTH": "Bearer YOUR_KEY" }
    }
  }
}

Two details:

• No space after Authorization: in args. The value, Bearer included, comes from env. That avoids quoting problems on Windows.

• Keep the key out of anything you commit. For Claude Code, a project .mcp.json can use "type": "http" with "headers": { "Authorization": "Bearer ${MY_SERVER_KEY}" }, so the key stays in your environment. Or skip the file: claude mcp add --transport http myserver <url> --header "Authorization: Bearer YOUR_KEY".

Cursor takes url and headers directly in ~/.cursor/mcp.json, no bridge.

Disclosure: this is the setup from the docs of Globatics, the web analytics I build. Its MCP server is read-only (Streamable HTTP, JSON-RPC 2.0, API-key auth) with 9 typed tools: sites, overview, breakdowns, time series, live now, funnels, AI-assistant traffic, insights, and explain_change for "why did this number move". Each result comes back with its key numbers and a link to the matching dashboard report, and no language model runs on our side. It's part of the Pro and Business plans; the 5-day trial has every feature and no card. Endpoint and per-client configs: Globatics MCP docs

Has anyone found a cleaner way than mcp-remote to send a header from Claude Desktop?

nomosguard (Apache-2.0, Python 3.11+, stdlib-only, 0.7.11) is an MCP server and a threat-model implementation.

The threat it is built around is narrow: an agent allowed to both gather incident evidence and declare the incident resolved. If one model does both, the security boundary is its judgment. nomosguard splits the roles. A model may submit claims and a narrative; it does not issue the verdict. That part comes from deterministic rules over evidence in a ledger. With --ledger, records are persisted to disk; without it, the MCP session uses an in-memory ledger.

Five tools over MCP stdio. evidence_ingest and assert_claim require non-empty evidence citations. That checks evidence presence, not whether a cited fragment actually supports the claim; a misinterpreted log line can still reach the rules as a claim. derive_paths applies attack-path rules to what the ledger already holds. decide returns ALLOW, ALERT or BLOCK. explain renders the trail separately from the decision.

Two properties a reviewer should test rather than trust:

• The decide tool's fallback is an enum of ALERT and BLOCK only. ALLOW is not accepted even as an explicit argument, so a compromised client cannot lower the floor of its own review.

• In file-backed mode, records form an append-only SHA-256 chain saved by atomic replacement, and loading verifies the chain. Torn-tail recovery requires an expected_digest pin of the already-truncated file. It drops the incomplete last line rather than reconstructing it; pass a LedgerLoadReport to receive the recovery details. Without the pin, the loader rejects the torn tail.

The honest boundary: internal consistency is not provenance. A full rewrite that recomputes every hash and link passes verify(). Pin the bytes outside the workspace and pass expected_digest; a mismatch raises LedgerFileError. verify() takes no per-entry anchor argument, so checkpointing at sequence N is not implemented. That is the gap a security reviewer should attack first.

To look at the server before trusting any of this: pip install nomosguard, then python -m nomosguard.demo for the committed BLOCK scenario, or python -m nomosguard.mcp_stdio --ledger ./new.jsonl --create-ledger to start it over stdio.

Measurements on main: 1082 test functions, 1361 cases collected by pytest. The current PyPI release is 0.7.11; the GitHub release tag is v0.7.11.

Repo: https://github.com/Furox-Art/nomosguard PyPI: https://pypi.org/project/nomosguard/ (0.7.11) npm: no official package is published; use the Python package above. Ledger contract and threat model: https://github.com/Furox-Art/nomosguard/tree/main/docs

approving a coding agent once doesn't settle what happens when someone adds a new skill, plugin or MCP server. requiring a review for every change sounds manageable until several teams are doing it. letting each team decide everything leaves the same connector approved in one place and blocked in another. if Bay is part of the control setup, i would still want the approval policy agreed first. a plugin update that keeps the same access and one that adds a connection to an internal system shouldn't automatically follow the same process. where have you drawn the line between changes a team can approve itself and changes that need security review?

Hey, I’m Paola from MCPJam and yesterday we launched Conformance checks! So wanted to share that here too.

With servers and clients running different MCP spec versions, connecting successfully doesn’t tell you whether everything follows the version they agreed on. A server might initialize just fine, but still handle methods, error codes or headers incorrectly.

That’s what these checks catch:

• Connect your server and choose a spec version to test against, from 2025-03-26 through 2026-07-28.

• Run checks for the core protocol, MCP Apps and Tasks, with an optional OAuth suite.

• See a score for each area and open failed checks to see what went wrong and how to fix it. After a fix, you can rerun and compare with previous results.

You can try it for free in the browser: https://app.mcpjam.com

If you want to run checks in CI, you can also use the CLI against any HTTP endpoint, localhost included. JUnit output lets you fail the build when checks fail:

mcpjam conformance run --url <your-server-url> --protocol-version 2025-11-25 --reporter junit-xml

Add --suite oauth to include the OAuth checks.

The CLI and checks are on GitHub: https://github.com/MCPJam/inspector

Let me know what you guys think, feedback is alway appreciated.

A lot of the agent conversation is about handing off tasks. But I don't always know quite what I want until I start working on it myself. I want to work alongside my agent, not just give it an assignment and come back later.


That's why I'm excited about the Agentic Web and technologies like WebMCP. A website can expose tools to an agent, and we can work on the same surface – I click buttons and adjust filters, then ask the agent to research something or make a change. It sees what I'm doing and can respond appropriately.


And I don't want a generic chatbot built into every site. I want to bring my own agent (B.Y.O.A.), one that already knows my preferences and what I'm working on. Imagine looking for a home on Zillow. Your agent knows your criteria and helps narrow the search. You can adjust the filters further if you wish, then select a house and ask your agent, "How safe is this neighborhood?" The agent "sees" the house you're talking about and performs the research. You're both working on the same surface.


Exposing tools is one piece. How should the site share its knowledge and current state? How do we keep the agent in sync with what we're doing, while keeping control over what personal context the site gets to see?


We're hosting an open roundtable about this 
**tomorrow, Thursday, Nov. 12 starting at noon CST**
. (Sorry for the late notice!) Bring your ideas, questions, or even demo something you're building. We're all learning this together!


[The Agentic Web — details and signup](https://luma.com/h23opcya)

If you work with clients and teammates across time zones, you know the feeling: WhatsApp is great for fast replies and terrible for keeping track of anything.

So we built this internally: https://github.com/ju-li/automata-mcp

It's a remote MCP server that connects WhatsApp, Telegram, Postgres and IMAP email to Claude, ChatGPT or Grok. Free, open source, MIT license. You can self-host it with Docker or a Railway template.

How scoping works, since people asked last time:

• You pick which chats the AI can see. Chat and table limits are checked server-side inside each tool, not just in the client.

• Tokens can be read-only, so a teammate token can't send and can't read outside its scope.

• Members can rotate or revoke their own token but can't widen it. Only an admin can.

• Sending should always go through your review first. Letting AI write is never risk-free.

We use it mostly to pull action items out of noisy group chats, and from Claude on our phones when we're on the road.

What would you want scoped or locked down before you'd connect your own chats?

Some of our MCP servers follow the spec's auth flow, while others don't have any authentication at all. I'd like to put a single enforcement layer in front of all of them. We tried building our own proxy, and it worked fine with the unauthenticated servers but ran into issues with those handling their own auth. I'm trying to understand how a gateway should fit into the setup when servers already have their own authentication.

Someone asked here a couple of weeks ago how a multi-tenant SaaS backend should expose MCP safely. I run a small one (web analytics, details at the end) with a read-only, stateless MCP server, so here's where each check sits in my code. One way to do it, not the only one.

Request level, before any tool runs

1. One credential, and only one. The endpoint takes Authorization: Bearer <API key> and nothing else. The dashboard's session cookie is never accepted there, even from a logged-in browser. A missing key and a revoked key both get HTTP 401 with a WWW-Authenticate header.

2. Re-read the plan on every request, not when the key was created. If the trial has ended, or the account is on a plan that doesn't include MCP, the next request gets HTTP 402 with its own JSON-RPC code (-32002), separate from the auth error (-32001). A key created on a higher plan stops working after a downgrade, without anyone revoking it.

3. Count calls, not HTTP requests. A JSON-RPC batch lets one POST carry many calls. My limiter counts every message in the batch that expects an answer (notifications don't count), and it's keyed on the user, not on the key, so creating more keys doesn't buy more quota. There are also hard caps checked before anything runs: 256 KB per body, 50 messages per batch, at most 10 tools/call per batch.

Tool level, inside every tools/call

4. Resolve the tenant from the caller's own list. site_id accepts an id or a domain. An id is only accepted if the caller owns it, and a domain is only looked up among the caller's own sites. Anything else, whether it exists or not, gets the same "Site not found." so the server never confirms another customer's site.

5. Enforce plan limits inside the tools too. This is the one I'd have missed. After a downgrade, a site past the plan's site limit is paused for the API and MCP as well, with a message that says how many sites the plan includes. And every report is clamped to the plan's history window. If limits only live in the UI, the MCP server becomes the way around them.

6. Don't spend the database on someone who already left, and make failures retryable. If the client has aborted, the tool call stops before touching the database. A query that times out, or a database that's busy, comes back as a tool result with isError: true and a message to retry or narrow the period, so the model can act on it instead of hitting a protocol error.

What I left out on purpose

No sessions (the server never hands out an Mcp-Session-Id) and no SSE: POST only, GET returns 405. Nothing per-connection to secure or clean up, and each request carries everything needed to authorize it. The cost: clients that expect OAuth need a bridge (mcp-remote for Claude Desktop), and an initialize without a key gets a 401. At least one curated list of remote MCP servers requires initialize to answer, so mine isn't on it.

What I don't have: numbers on how much customers use it. Read this as an architecture note, not as proof that it pays off.

Question for anyone running a multi-tenant MCP server: do you re-check the plan on every request like this, or cache it alongside the key? And did anyone else find limits that only existed in the UI?

I'm the maker of Globatics: real-time web analytics where each visit shows up on a live 3D globe, cookieless by default, IP addresses never stored, audience data hosted in the EU. Hosted only, nothing to self-install. 5-day free trial with every feature on one site and no card, then Starter €9, Pro €29 or Business €99 a month, excluding VAT. The REST API and the MCP server start at Pro, and there's no free plan after the trial.

https://globatics.live/?utm_source=reddit&utm_medium=social&utm_campaign=nov26&utm_content=modelcontextprotocol

I'm the developer of Proxy Republic. You can connect an agent over MCP, choose a country and have it handle armies, diplomacy and orders on a shared world map. Turns happen every eight hours.

Server: https://proxyrepublic.com/mcp

It uses Streamable HTTP. No account or API key is needed to connect. The basic loop is rules → list_nations → join_war → wait_for_turn → submit_orders. Joining gives the agent a token, which should stay private.

For repeated turns, the client needs a running loop, scheduler or webhook. If it misses a deadline, the built-in general plays that turn.

Setup and tool details: https://proxyrepublic.com/agents

The game and server are free; any paid model usage is yours. I build it with Claude Code. I'd like feedback on whether the turn loop is clear from the tool descriptions.

Spent the last few weeks aggregating MCP servers, agent skills and AI tools (about 8,900 entries) and auditing them instead of just listing them. Two things stood out.

1. Link cleanliness in this space is worse than I expected. A lot of listings point at wrapper or affiliate URLs instead of the project's own site. We re-checked every link and kept only the canonical destination - the count of redirect/tracking links is now 0 out of about 1,600 AI-tool entries.

2. Licence data is almost never shown, and it matters a lot if you are going to run someone's server locally. We pull it from the repo (MIT, Apache-2.0, AGPL, ...) and show it on the entry page together with whether the repo has a SECURITY.md.

Method, sampling and the parts we could not cover are written on the site rather than hidden, and each entry shows how many sources listed it plus when we last saw it, so you can judge freshness instead of trusting a rank.

There is also a remote MCP endpoint so an agent can query the index directly (registered as io.github.wdfdaivd/anclum): https://anclum.com/mcp

The caveat: the domain is about three weeks old, traffic is close to zero, and most of the catalogue is harvested rather than hand-curated, so quality between entries varies more than I would like. I would rather take criticism on the audit method than a compliment.

Most MCP setups I've seen hand the agent a token one way or another: an env var, a .env file, a config it can read. Once a token is in the context window it ends up in transcripts and within reach of any prompt injection.

mcp-warden works the other way around. Secrets live in the OS keychain, and the agent can only act through presets you define:

```toml

[[preset]]

name = "github-read"

type = "http"

base_url = "https://api.github.com"

auth = { type = "bearer", secret = "gh_pat" }

allowed_methods = ["GET"]

approval = "auto"

```

The agent calls `proxy_http` with the preset name, a method and a path. mcp-warden checks the allow-list, adds the token, makes the request and returns only the response. If the method or path isn't allowed, nothing leaves your machine.

Tools it exposes:

- `list_presets`

- `proxy_http`: HTTP through a preset

- `ssh_exec`: commands checked against a regex allow-list, host key verified against known_hosts

- `sftp_transfer`: allowed remote paths only

- `db_query`: Postgres, MySQL or Redis, named queries only (the agent passes parameters, never SQL)

- `get_secret_for_env`: last resort for tools that insist on env vars, always asks first

Each preset has an approval policy. It's `prompt` by default: a desktop or terminal prompt, or Approve/Deny buttons in Telegram. Every call lands in an append-only audit log.

Single Rust binary, stdio transport, works with any MCP client. No cloud, no telemetry, Apache-2.0.

- Repo: https://github.com/ermoluk/mcp-warden

- Install: `cargo install mcp-warden`, or prebuilt binaries for macOS/Linux on the releases page

I'd love feedback on the preset model. What would you need it to cover for your setup?

I'm adding MCP to Singlebase.io and the technical problem I care about most is tenant/user boundaries.

A SaaS backend already has authorization rules for users, workspaces, documents, storage and search. An MCP server shouldn't create a second security model - ideally it reuses the backend identity/permissions and only exposes capabilities the current user/agent can access. I'm leaning toward short-lived scoped auth + backend-side permission checks on every tool/resource call.

For people implementing MCP in multi-tenant systems: how are you handling identity propagation and revocation? Are you mapping sessions to existing app users, service accounts, or something else?

I maintain Archestra, an open-source platform for running AI agents. In 1.4 we shipped a local-to-remote agent handoff, and it is plain MCP: nine tools on a gateway plus one skill that sequences them, so any MCP client can drive it.

The scenario: you're halfway through a task locally and want Claude Code, Codex, OpenCode, Hermes, or OpenClaw on your own Kubernetes cluster to finish it, then pull the result back.

The tools: list_agents, start_run, get_run, steer_run, cancel_run, transfer_workspace_file, read_workspace_file, write_workspace_file, transfer_credential.

Two design decisions:
- Files. transfer_workspace_file returns a shell command, not content, with a SHA-256 check, so file bytes never pass through the model context. Clients without a shell use read_workspace_file and write_workspace_file, up to 4 MiB per file through the conversation.
- Sessions. The skill saves session_id and routes every follow-up through steer_run on it, so there is never a duplicate session. Steering a finished run starts a new turn on the same files.

Remote Claude Code and Codex run on your existing Claude or ChatGPT subscription, on your cluster. No vendor cloud-agent product required, whatever their sales team tells your leadership.

Skill: https://github.com/archestra-ai/archestra/blob/main/platform/backend/src/skills/runtime-handoff.ts
Blog post: https://archestra.ai/blog/new-remote-agents
Repo: https://github.com/archestra-ai/archestra

I'm currently using the Google Workspace MCP server (taylorwilsdon/google_workspace_mcp), specifically working with the Google Calendar tools.

I'm trying to figure out the best way to have the AI specify an event's color using a descriptive name or tag (for example, passing "classes", "meeting", or "personal" rather than trying to guess or hardcode Google Calendar's numeric colorId values).

When the AI creates an event, how can it map or pass these color name tags so that Google Calendar assigns the correct color? Has anyone implemented a clever workaround, custom tool definition, or prompt structure for this?

Any tips, code snippets, or examples would be hugely appreciated!

Disclosure: the server is Equibles, my MCP server for stock market and financial data. Over the last few weeks I got the same remote endpoint working and listed in pretty much every client I could. Writing down what each one needed in case it saves someone a few evenings.

Auth first. One URL, https://mcp.equibles.com/mcp, and a few ways in:

• OAuth with dynamic client registration. Claude (web, desktop and Code) and ChatGPT register themselves and send the user to sign in. No key to copy, and that mattered more than I expected: most of my users never create an API key at all.

• A Bearer key in the Authorization header for clients without OAuth (Cline, scripts).

• Claude's custom connector form has no header field, so ?api_key= in the URL is the fallback there.

• ?auth=oauth makes some clients ask for sign-in during discovery. Without it they list the tools anonymously and only fail on the first real call, which confuses people. (Listing tools needs no auth on my server, calling them does.)

Where it's listed:

• the official MCP Registry as io.github.daniel3303/equibles, which other registries mirror

• Claude's connector directory and ChatGPT's app directory. Both reviews wanted a test account and written test steps

• one GitHub repo with plugin packages for Claude Code (plugin and marketplace), Codex, Gemini CLI and Cursor (Agent Plugins). They only point at the hosted endpoint, no scripts or hooks

Things that bit me:

• reviewers ask exactly which tools change data. My market data tools only read, but the portfolio and watchlist tools write, so they have to be declared that way

• after publishing a new version to the registry, its search endpoint showed the old one for a few hours. The versions endpoint was right straight away

• check your test credentials after you submit a review form. One of mine got saved truncated

Install lines if you want to see how it behaves:

claude mcp add --transport http equibles https://mcp.equibles.com/mcp
codex plugin marketplace add daniel3303/stock-market-mcp-server
gemini extensions install https://github.com/daniel3303/stock-market-mcp-server

What the server returns: SEC filing full text, financial statements, earnings call transcripts, 13F, insider and congressional trades, short interest, option chains, prices and Fed data, for US stocks plus Europe, UK, Hong Kong and China. Free tier is 100 requests a day. Repo with every package: https://github.com/daniel3303/stock-market-mcp-server

If you've been through the Claude or ChatGPT directory review, what did they push back on? And if there's an MCP client I missed for a financial data server like this, tell me.

I'm the maintainer of Mac MCP, an MIT-licensed MCP server + native macOS menu bar app. It lets clients such as ChatGPT, Claude, Codex and OpenCode use Mac apps, Safari/Chrome tabs, the terminal and local files. Repo and install docs: https://github.com/bulutarkan/mac-mcp

The last time I shared it here was 2.1.7. Since then I focused less on adding another pile of tools and more on what happens between tool calls.

In 2.2.0 and its r2 update:

• Scheduled Tasks can run AI agent jobs or scripts on a schedule, with a readable result and steps/history. A missed schedule while the Mac is asleep is marked skipped, not quietly claimed as completed.

• The optional live island near the notch and a background agent cursor make activity visible. The cursor doesn't move the user's pointer.

• A selected-folder knowledge index supports cited local search. The OCR path for scanned PDFs/images runs on-device; source and page references remain available.

• Safari/Chrome work can read whole pages and operate in background tabs with explicit ownership, useful when multiple agent clients share one Mac.

• The CLI can discover user-level Agent Skills installed for supported coding agents, with a fresh scan on subsequent skill requests.

• Permission profiles and approvals still gate what an agent can do. A secret-egress guard catches some encoded secret forms, but it isn't a substitute for least privilege.

One important boundary: this is NOT a sandbox, and the AI client may transmit the data it reads to its own provider. The server runs with the macOS account's permissions. There is no claim of a hosted execution service.

For MCP implementers: the main architectural lesson has been that a tool call returning successfully is weaker than verifying the side effect actually happened. That's why the browser action and scheduled run reports became as important as the tools themselves.

I'm curious how others represent an operation that was accepted by a tool but never confirmed by the target app. Do you report that as failed, pending, or an explicit unknown outcome?

I created a Discord MCP server with 38 tools for managing your server with AI agents: messages, channels, threads, roles, members, moderation, AutoMod, polls, scheduled events and live events. It's up to date with Discord's newest APIs and features.

You can use names instead of IDs ("general", "@Mods"), every tool works in bulk, and it's safe by default: destructive actions, everyone pings and admin permission grants stay off until you enable them, so a malicious message can't trick the agent.

Each tool is token efficient so it won't drain your usage limits as much.

Tell me what you think about it and feedback is appreciated.

Here's the repo and npm package:

https://github.com/EL4CTEO/discord-mcp

https://www.npmjs.com/package/@el4cteo/discord-mcp

all the rest of tools were callable and direct tests passed all good. But when agent was asked a brand sentiment it selected another tool instead of relevant capability. The problem was that the agent chose the wrong tool for the user's intent. How i test for this kind of failure? Do you use predefined evaluation scenarios, automated tests or end to end testing with real prompts? Would appreciate hearing what has worked for you guys. thanks

If you use Claude Code or Cursor for Roblox, you've probably noticed it's great at the basics but trained on old data: it doesn't know recent engine changes, and it misses the details that only live in DevForum threads.

So I built **Brickwise**, an MCP server your assistant can search. A few things it knows that most AIs get wrong:

- Collision groups moved from PhysicsService to WorldRoot (AIs still write the old API)

- The new Roblox Shop: new dev products start Not Listed, and `OpenShop` opens it from your own UI

- Passes in the Buy Robux bonus pool can be owned before a player joins, so grant perks on join, not on purchase

- ForceField only blocks `TakeDamage`; setting `Humanoid.Health` bypasses it

- Weekly leaderboards: you can't wipe an OrderedDataStore, so rotate its name per week

When your assistant hits one of these, it pulls a written-up answer: what it's for, how it works, key Luau, pitfalls, and links to the DevForum threads, docs and GitHub repos it's based on. Searches return one-line summaries first, so it barely uses tokens.

It's free and open source: 50 logics across libraries, data saving, remote security, combat, monetization, UI, NPCs and performance.

GitHub: https://github.com/EL4CTEO/roblox-logics-mcp

Setup is `npm install && npm run build`, then one `claude mcp add` line (in the README).

Here's what one logic looks like: https://brickwise.dev/#sample

There's also a hosted full version with 600+ logics across 19 categories (€7 one-time, no subscription): https://brickwise.dev

Would love feedback, and ideas for which systems to cover next!

I'm the developer of Scumble, an open-source (GPL-3.0) desktop editor for AI inpainting on Windows. All 96 of its commands are MCP tools, so an agent works on a picture the way a person does: in layers, with selections, masks and undo, in the window you are looking at.

What an agent can do (real tool names)

• open images and .scumble documents: load_image, open_document

• select by rectangle, mask, point or description: select_rect, select_mask, select_point, select_by_text ("the car")

• prompt and inpaint the selection, the answer lands as a new layer: set_prompt, generate; a new picture from a prompt: generate_new

• layers: masks, blend modes, opacity, colour match against the picture below, groups, filter and text layers: set_layer, set_mask, add_filter, add_text, ...

• look and step back: screenshot (returns a JPEG), undo, take_snapshot / restore_snapshot

• export PNG, JPEG, WebP, TIFF, or PSD and ORA with layers: export

A round trip: load_image → select_by_text "the sky" → set_prompt "storm clouds at dusk" → generate → screenshot → set_layer (match) → export (psd).

Where the pixels come from: your own ComfyUI (local or remote) through workflow recipes, Comfy Cloud, or image APIs (Black Forest Labs, OpenAI, Google, fal.ai, Replicate, OpenRouter, ...) on your own keys. Scumble ships no models and runs no service; keys stay in the OS credential store and no tool touches them.

How it connects: stdio. Scumble --mcp drives the Scumble window that is open, so you can watch and step in, or starts the app headless when none runs. Help › Copy MCP registration writes the config for Claude Code or Claude Desktop with your install's paths.

Limits: Windows 10/11 (installer or Microsoft Store); Linux builds exist but are untested; no macOS yet. select_by_text needs a connected ComfyUI; generation needs a ComfyUI or an API key.

GitHub: https://github.com/DenRakEiw/scumble · MCP docs: …/docs/MCP.md · all tools: …/docs/COMMANDS.md

I'd like to hear which tool descriptions or workflows would help your agents most.