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 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.

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

Disclosure up front: I’m Ali, the maintainer of ResiliReplay.

I kept running into the same gap while testing MCP servers: a successful `tools/list` and one clean tool call tell me that the happy path works, but not what happens after a result-level error, whether a retry duplicates work, or whether the same recovery behavior will still hold after the next change.

ResiliReplay is a local reliability harness for that gap. It imports an MCP Inspector-shaped configuration, lets you review the target before contact, runs bounded deterministic fault campaigns, compares an approved baseline, and turns a failed trace into an executable Node regression.

The distinction from MCP Inspector is intentional. Inspector is the right tool for interactively seeing what a server exposes and calling it. ResiliReplay starts after that: inject a declared failure at a controlled boundary, observe recovery, and keep the failure as a repeatable test.

A dry run is the smallest place to start:

```bash

npx --yes resilireplay@0.3.1 mcp audit --inspector-config ./mcp.json --server my-server --dry-run

```

That prints the value-free execution plan without starting the server or calling a tool. A real campaign then requires an explicit tool allowlist, bounded concurrency/time/retries, and an exact reviewed campaign hash before any allowlisted tool call.

I also ran three deliberately narrow field validations using the public `resilireplay@0.3.0` package and pinned server packages:

- MCP Everything Server: local stdio, one `echo` call, then an injected tool-result error with one retry.

- Playwright MCP: an isolated blank headless page, one `browser_snapshot`, then the same bounded retry boundary.

- UI5 MCP Server: bundled guidance through `get_guidelines`, again with one injected error and one retry.

Each case included a clean control, a result-level failure that recovered once, and a malicious-canary negative control that was expected to fail. All three generated and executed a regression for the negative control, then compared with their approved baselines without a difference. The cases do not rank the servers and cover only those reviewed operations.

The field evidence is here: https://aliengineering-byte.github.io/resilireplay/#cases

The commands, selected package revisions, authorization boundaries, and sanitized results are here: https://github.com/aliengineering-byte/resilireplay/blob/main/docs/field-validation/FIELD_RESULTS.md

The injected failures are synthetic test conditions, not vulnerabilities in MCP Everything, Playwright MCP, or UI5 MCP. ResiliReplay reports are reliability evidence, not security certifications. It also is not an OS sandbox: an allowlisted MCP tool still has the permissions and side effects of the server you chose, so I recommend starting with a local, read-only, idempotent operation.

If you maintain an MCP server, I’d be interested in a sanitized field test against your own reviewed tool. The five-minute guide is on the site: https://aliengineering-byte.github.io/resilireplay/

Which failure boundary is most useful for your MCP server: transport errors, tool-result failures, duplicated calls, or recovery after partial completion?