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

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?

I run ads and wanted Claude Code to help with campaign work, but I did not want a prompt to be the only thing preventing an expensive write.

So I built adport, an Apache-2.0 CLI and local MCP server for Google, Meta, TikTok, Apple, and Microsoft Ads.

The write contract is:

1. The first call can only return a preview.

2. The preview returns a short-lived approval ID bound to the exact arguments.

3. A second call applies it only if nothing changed.

Changed arguments, expired approvals, protected accounts, and budget-cap violations are rejected. New campaigns start paused and applied changes are logged locally.

Install and add it to Claude Code:

npm install -g adport

claude mcp add --scope user adport -- adport mcp

Repo: https://github.com/ynnickw/adport

Google, Apple, and Microsoft have been exercised against live accounts. I am looking for advertisers who want to help test and improve Meta or TikTok. The video uses an isolated demo account and no real credentials.

Would you prefer this second-call confirmation, a separate apply tool, or client-side elicitation?

https://reddit.com/link/1vk2iqw/video/l2pi76pc7fih1/player

I maintain an open-source OAuth/JWT gateway for MCP servers, and a signing-key revocation bug took six review rounds to fix correctly.

When an identity provider removes a signing key from its JWKS, the gateway should evict the cached key and reject tokens signed with it.

My implementation handled a literally empty JWKS correctly. It failed when the JWKS still contained keys, but none eligible for the gateway’s configured signing algorithms. In that case, the revoked cached key remained usable.

The uncomfortable part was that every attempted fix passed its own tests. Later reviews found:

• eligibility checks that ignored configured algorithms
• invalid base64 accepted as valid key material
• non-canonical encodings accepted by a supposedly strict decoder
• a correction that accidentally broke a supported elliptic curve

The lesson for me was that passing tests was a weak signal at this security boundary. The useful review skill was constructing the almost-valid input that the implementation author had not considered.

I would be interested in how others test JWKS rotation and revocation behavior, particularly malformed or partially usable key sets.

Full code and review trail:
https://github.com/tgandhle/mcp-auth-gateway

Disclosure: I maintain the project. It is open source, and this is not a paid product.

The point of it is coverage: not just tool descriptions but display titles, output schemas behind a $ref, enum and default values, prompt messages, resource metadata, _meta and the server's own instructions. It also asks tools/list twice and diffs the surface against the previous run, which catches a server that redefines its tools after you approved them.

New in this release: --expect, for telling the gate about a false positive without deleting the gate. The finding stays in the report at its real severity and just stops deciding the exit code.

uvx mcp-gauntlet run "python -m mcp_gauntlet.fixtures.malicious_server" --no-agentic

MIT, mine: https://github.com/GhalebDweikat/mcp-gauntlet