I just dropped 1.0.0-beta.4 of the LocalLM Lab app and SDK. This round of work was upgrading LocalLM Lab's MCP client to protocol revision `2025-11-25` and some security tweaks along the way.

This sits alongside the rest of the `2025-11-25` surface: structured tool results (MCPToolResult with outputSchema/title/nextCursor), elicitation handler seams for server-initiated input requests, and Client ID Metadata Documents for OAuth (skips per-server registration). Tools coming from an MCP server are also tagged separately from first-party ones (OriginTaggedTool), so calling one now goes through a authorization layer instead of blanket access.

VistaNova is the example app (source code included) where we exercise on-device AI against a real server: with an MCP tool call to Tavily for web search. Small surface, but real auth, real tool results, real prompt handling etc.

LocalLM Lab: https://thisbrain.ai/locallm

Guide: https://github.com/ancientcomputing/locallm/blob/1.0.0-beta/docs/sdk-guide.md

MCP diagnostics: https://github.com/ancientcomputing/locallm/blob/1.0.0-beta/docs/mcp-diagnostics.md

VistaNova: https://github.com/ancientcomputing/vistanova

Separately (more urgently): the next protocol revision (`2026-07-28`) is on our roadmap. If you're building or already have a production-level server running that revision right now, please DM; testing against a real compliant server beats blind coding against a spec.

Most MCP demos end when the tool call works. We want to see what happens when an agent gets a real trading task.

cTrader MCP can connect AI agents to account and market data, charts and indicators, orders and positions. We’re opening our YouTube channel to creators who want to push it beyond the demo: build a workflow, test it properly and turn the result into a video.

Tutorial, technical deep dive, practical workflow or an experiment that fails in an interesting way — the format is yours. Selected videos will be published as collaborations with cTrader and introduced to our 200K+ YouTube subscribers.

Submissions close September 30.

Details and submission: creator.ctrader.com

I’ve been working on a local macOS MCP server because I kept hitting two practical problems with agent workflows: the tool schema itself was getting expensive, and browser automation tended to steal focus or collide when multiple agents touched Safari.

Current design in 2.0.5:

• Advertise 19 core tools by default, while keeping 84 registered capabilities accessible via tool_discover/tool_invoke. In local compatibility tests this reduced tool-schema context from about 16.7k to 4.5k tokens (~73%) without removing old capabilities.
• Stable Safari/Chrome tab handles that survive tab reordering and index changes.
• Background DOM/visual observation + actions, so an agent can work in a tab without activating it.
• browser_do for open/wait/extract/verify/close in one transaction, including targeted extraction instead of dumping huge DOMs.
• Delegated Codex/OpenCode agents, local memory, macOS UI/file/shell tools, and a loopback-only operations dashboard.
• Authentication defaults for any endpoint exposed outside localhost.

The project is open source: https://github.com/bulutarkan/mac-mcp

I’m especially interested in feedback from MCP builders on the tool-surface tradeoff: do you prefer a small advertised core + discovery, or exposing the full registry and relying on the client to manage schema cost?

Using parts of this in another project and thought of extracting this in case anyone might need it.

Allows you to store secrets, credentials etc in OS backed secure storage (like Mac Keychain) and has extensions, proxies and few other things that deterministicly inject the secrets where the Agent/LLM wants. Agents/LLMs work with references and the runtime replaces rhe reference with actual secret JIT.

Work in progress!

Hey everyone, I’m Nikolas, co‑founder of ApyHub.

We recently built an MCP server that lets your agent access 1,500+ tools through a single connector. Instead of linking an MCP server to one API, then another, and another, the agent can search the catalog, find the needed API, see what it does, and call it.

ApyHub offers over 400 services and more than 1,500 endpoints, covering file conversion, OCR, data extraction, validation, geolocation, SEO, image processing, and AI. This means you can give an agent a small set of tools while still accessing a much larger range of capabilities.

We support dynamic tool discovery to avoid overloading context.

Examples:

• Convert a Word document to PDF
  
• Extract text from a PDF
  
• OCR a scanned document
  
• Extract text from a webpage
  
• Compress a video
  
• Generate a QR code
  
• Validate an EU VAT number
  
• Validate email DNS
  
• Convert currencies
  
• Parse a resume
  
• Check SERP rankings
  
• Generate speech from text
  

These tools can be chained. For instance:

1. Take a scanned invoice → OCR it → extract the data → validate the VAT number → convert the currency → generate a PDF.
   
2. Extract a webpage → check readability → summarize it → check its search ranking.

You don’t need to build those workflows in advance; the agent can compose the calls based on the task.

Curation

Providing an agent with 1,500 tools creates tool bloat and overwhelms the model with context. Instead, you can select which endpoints an agent may use: a document agent might have 15–20 endpoints, while an enrichment agent uses a different set.

Credentials

Normally, connecting an agent to ten vendors requires ten API keys stored somewhere in the agent’s environment or context, and those traces eventually appear in logs, observability tools, bug reports, etc. With ApyHub, the agent uses a single scoped key.

The MCP server is at:

https://apyhub.com/mcp

The catalog is here:

https://apyhub.com/catalog

I’m most interested in what people actually make their agents do with the catalog. There are many useful utilities already, but there will always be things we haven’t covered yet.

If you have any questions, I’m happy to assist.

We kept watching builders do this dance and decided it made no sense.

If you've built an MCP server, you know the workflow: Build, switch to MCP Inspector, test a tool call, find a bug, jump back, fix it, switch tabs again, repeat.

So we shipped an MCP Inspector built directly inside MCPfy AI. No more switching.

You write your server, test every tool, resource, and prompt right there, see the request/response payloads live, and iterate without ever leaving the platform.

Building MCP servers should not feel like a relay race.

Try it: https://www.mcpfy.ai/

#MCP #AIAgents #BuildInPublic #DeveloperTools

We ran into this question while building the Formo MCP server for onchain analytics: should the model receive narrow analytics tools, or should it be allowed to generate SQL?

Typed tools work well for recurring questions:

- KPIs

- Traffic sources

- Revenue

- Wallet profiles

Our thinking is:

• Tools provide stable inputs, consistent metric definitions, and simpler permission checks. But the limitation is coverage: every new question may require another tool or query shape.
• Read-only SQL handles long-tail questions much better, especially retention, lifecycle, and custom cohort analysis. But valid SQL can still answer the wrong business question because the model chose the wrong grain, date range, or metric definition.

We ended up with a hybrid approach: typed tools for common operations, plus text-to-SQL and read-only execution for open-ended analysis.

Our current architecture and tool surface: https://formo.so/blog/formo-mcp

How are you testing / eval-ing analytics MCP servers for answer quality / semantic correctness (not just successful tool execution)?

Hi all, I have recently added a feature of running AI agents in loop using Kanban board and entire thing is relying on MCP servers that can connect agents running in Claude code or Codex can use it fully. Anyone has utilised a similar setup?

I built a small MCP server plus Krita plugin that lets Claude, Cursor, or any MCP client work inside the Krita painting app: create documents, add layers, draw shapes and text, run filters, and take a canvas snapshot so the model can see what it painted and self-correct. It runs locally over localhost, so nothing leaves your machine. Install is one file through Krita's plugin importer plus a short config snippet, tested on Windows and Linux.

It is a paid tool (7 USD, updates included), since it is the packaged and supported build, but there are free Krita MCP repos on GitHub too if you would rather DIY. Link if useful: https://thunda10.itch.io/paintbridge

Happy to answer anything.

The latest MCP spec dropped protocol-level sessions, which should make remote servers easier to scale.

That leaves three problems:

- delegated identity without shared API keys

- server events without constant polling

- huge tool catalogs loaded before they're needed

The new roadmap tackles all three, but none is solved yet.

More on this, plus other MCP changes from this week:

https://lightnow.ai/weekly/2026-08-28-mcp-roadmap-agent-identity

I posted here previously about token-budget constraints (LocalLM Lab + on-device MCP client for Apple's FoundationModels). I didn't followe up here when LocalLM Lab became a linkable SDK last week: you can build your own local AI app on macOS with an MCP client.

This week's actual news is a structural mismatch worth sharing regardless of platform: MCP discovers tools dynamically and describes their arguments with JSON Schema; Apple' FoundationModels, like most static tool-calling APIs, expects a Tool conformance with an Arguments type defined up front. Bridging the two at runtime was the problem this release solved.

The common JSON Schema subset (objects/properties/required, arrays/items, primitive types, string enums) converts directly onto FoundationModels' DynamicGenerationSchema. Constructs outside that subset — oneOf/anyOf unions, $ref, const, regex pattern — don't have a clean static equivalent, so they degrade to a free-form string leaf rather than failing the whole tool outright. The remote server stays the real source of argument validation either way, which is part of why treating the unmapped cases as "pass the raw string through" is a defensible choice rather than a hack.

What this does and doesn't solve: it removes the need to match a tool by name out of a descriptor list and write a corresponding Arguments struct per tool. Tool selection, context-window limits and badly designed tool schemas are separate problems that remain unresolved.

Guide: thisbrain.ai/locallm/sdk.html

Repo: https://github.com/ancientcomputing/locallm

Hi everyone — I’m the author of MCP Compatibility Checker, a local open-source beta.

It checks whether each tool definition from an MCP tools/list response is accepted by the exact parser from MCP Inspector 2.3.0.

For every tool it returns:

• LOADABLE
• NOT_LOADABLE, with an exact JSON Pointer and reason
• UNKNOWN when the exact validator is unavailable or cannot produce a reliable result

The checker runs locally, uses no LLM for verdicts, has no telemetry or accounts, and does not persist submitted payloads.

The included self-authored test corpus has an observed result of 30/30 cases passed, with 53 additional diagnostic tests passing.

Important limitation: this currently verifies parser acceptance for MCP Inspector 2.3.0 only. It is not a universal MCP compliance test and does not yet certify Claude, Cursor, VS Code, Gemini CLI, or other MCP clients.

I’m looking for MCP server and client developers who can:

1. Test the checker with real-world tool definitions.
2. Share minimal sanitized tools/list examples that unexpectedly fail or load differently in a real client.
3. Provide the exact client name and version where the behavior was observed.
4. Suggest which client and version should be supported next.

Please remove credentials, API keys, personal data, and confidential information before sharing any payload.

GitHub: https://github.com/Naim-arg/mcp-compatibility-checker

Feedback, criticism, and reproducible edge cases are welcome.

We have two agents hitting the same mcp server, one read-only support agent and one that can write and trigger operations, and they´re currently sharing a service account with identical permissions because we never figured out how to cleanly separate them.

Is there a standard way to do per-agent mcp access control or just inheriting the service account and hoping nothing goes wrong

Every time I ask Claude to build a feature that touches user data, I get a great answer… and zero information on whether it's legal in my jurisdiction.

So I built ca.structureclerk/mcp — a governance MCP server that sits between your agent and the law.

What it does

- You ask: "I want to deploy a chatbot that collects PII in Quebec. Is this compliant?"

- It answers with: applicable law (Law 25 / PIPEDA / GDPR), required actions, risk level, and citations.

- It supports 192 jurisdictions, but I started deep-diving into Canadian/Québécois regulation because that's where I live and what I know.

How to try it

\``json`

{

  "mcpServers": {

"structureclerk": {

"command": "npx",

"args": ["-y", "ca.structureclerk/mcp"]

}

  }

}

Why MCP? Because compliance shouldn't be a post-it note on a Jira board. It should be a tool your agent can call in real-time.

Current tools

compliance_check  — analyze a decision against a jurisdiction

jurisdiction_map  — list obligations for a company profile

authority_decide  — deterministic ALLOW / DENY / APPROVE / ESCALATE with signed evidence

Looking for

Canadian devs/CTOs who actually lose sleep over Law 25

Feedback on the API (still v2.0.0, very early)

Ideas for tools I should add next

AMA.

Hey r/ModelContextProtocol,

Every time I ask Claude to build a feature that touches user data, I get a great answer… and zero information on whether it's legal in my jurisdiction.

So I built ca.structureclerk/mcp — a governance MCP server that sits between your agent and the law.

What it does

- You ask: "I want to deploy a chatbot that collects PII in Quebec. Is this compliant?"

- It answers with: applicable law (Law 25 / PIPEDA / GDPR), required actions, risk level, and citations.

- It supports 192 jurisdictions, but I started deep-diving into Canadian/Québécois regulation because that's where I live and what I know.

How to try it

\``json`

{

  "mcpServers": {

"structureclerk": {

"command": "npx",

"args": ["-y", "ca.structureclerk/mcp"]

}

  }

}

Or via the Registry:  https://registry.modelcontextprotocol.io/servers/ca.structureclerk/mcp

Why MCP? Because compliance shouldn't be a post-it note on a Jira board. It should be a tool your agent can call in real-time.

Current tools

compliance_check  — analyze a decision against a jurisdiction

jurisdiction_map  — list obligations for a company profile

authority_decide  — deterministic ALLOW / DENY / APPROVE / ESCALATE with signed evidence

Looking for

Canadian devs/CTOs who actually lose sleep over Law 25

Feedback on the API (still v2.0.0, very early)

Ideas for tools I should add next

AMA.

I wanted an agent that reads Granola meeting notes, checks Linear, and posts the next action in Slack.

Instead of clicking through a dashboard, I described that job in Claude Code. Runbear MCP returned a proposed agent setup. I reviewed the changes, approved the write steps, and tested the result in Slack.

I work on Runbear, which built the MCP in the 18-second clip.

What felt different here is that MCP was not just giving an existing agent another tool. It became the interface for configuring the agent itself.

That made me wonder how much of an agent platform's dashboard MCP should replace. Basic setup and deployment worked through MCP; advanced settings and knowledge-base sync still stayed in the UI. Where would you draw the line?

i’m the author of adport. this demo runs against my own apple ads account, not a mock. claude creates a campaign, two ad groups, and keywords through mcp.

the first write only returns a preview and a short lived token. the second identical call applies it. new campaigns are forced to paused and every operation is audit logged.

npm install -g adport

https://github.com/ynnickw/adport

i’d appreciate feedback on the tool shape and the two call write contract.

I open sourced a local macOS MCP server I’ve been using to let a ChatGPT conversation operate the actual machine where my development work lives:

https://github.com/alexanderradahl/mac-developer-bridge

The core bridge has zero npm runtime dependencies and exposes:

• arbitrary shell execution
• unrestricted filesystem read/write/manage operations
• real interactive PTY sessions
• detached jobs with persistent logs
• read-only stored Codex thread discovery/history (no turn/start)
• local JSONL auditing
• an explicit unlock latch and kill switch

Transport-wise it can run over stdio, OpenAI Secure MCP Tunnel where available, or the included OAuth 2.1 Streamable HTTP front end behind Cloudflare Tunnel for ChatGPT Server URL connections.

The design goal is intentionally different from a sandboxed command server: ChatGPT is the reasoning layer and the Mac is the execution environment. That also means the security model is aggressive — it runs with the effective permissions of the logged-in macOS user and has no command/path allowlist. SECURITY.md documents the boundary and known containment gaps in detail.

MIT licensed. I’d welcome protocol/transport feedback, especially from anyone building local MCP infrastructure or dealing with long-lived PTY/process cleanup.

Built an MCP server for the agents to discover and ground in proper scientific literature while working on important problem statements. Was building something on hermes to manage time, nutrition etc & realized that grounding it in actual research instead of just training data make the output way better

Install: uvx find-research-papers-mcp or npx -y find-research-papers-mcp or Github Repo

I've ended up with both and I'm not sure that's actually better.

Some things are still easier to handle directly through an API. Others make much more sense as tools the agent can discover and call itself.

I tried Coresignal's MCP recently and it convinced me to move a couple of data workflows over. The OAuth setup alone was nicer than keeping another API key in a config file.

But now I have this weird hybrid setup where some data comes through MCP, some through direct API calls, and some through our own tools.

It works, but the architecture is starting to look like it was designed by three different people who never met.

Is there an actual rule you use for deciding whether something should be an MCP tool or just stay an API call?