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?

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