Mert

The AI agent ecosystem is exploding. Every week brings new frameworks (CrewAI, LangGraph, AutoGen), new protocols (MCP, A2A), and new tools. But there’s a fundamental problem nobody is solving well: discovery.

The Fragmentation Problem

Right now, if you want to find an MCP server for your use case, you have to:

1. Search GitHub and hope the README is good
2. Check npm and hope the package is maintained
3. Browse scattered directories with no quality signals
4. Ask on Discord/Reddit and hope someone answers

There’s no unified place to compare tools, check security, verify maintenance status, or read real user reviews. It’s like the early days of mobile apps before the App Store existed.

What Makes This Hard

Building a marketplace for AI skills isn’t just a directory problem. You need:

Trust Metrics: How do you know an MCP server won’t exfiltrate your data? We score every tool on security practices, code quality, and maintenance frequency.

Compatibility Matrix: Does this skill work with Claude? With GPT-4? With your specific framework? Most tools don’t document this.

Versioning: When the underlying LLM changes capabilities, skills can break silently. You need a way to track which versions work with which models.

Governance: For enterprise teams, you need approval workflows, audit trails, and the ability to restrict which skills agents can use.

The MCP Ecosystem Today

The Model Context Protocol has been a game-changer for standardizing how AI agents interact with tools. But the ecosystem is still young:

• The official MCP Registry has hundreds of servers
• GitHub has thousands of repos tagged with MCP
• npm has growing number of MCP packages
• But there’s no single place that aggregates, scores, and curates all of them

What We’re Building with SkillFlow

SkillFlow is our attempt to solve this. It’s a curated AI Skills Marketplace where you can:

• Discover MCP servers, AI agent tools, and skills across all registries
• Compare tools side-by-side with trust metrics and compatibility data
• Install with one command via our MCP server
• Review and rate tools based on real usage

We’re not trying to replace existing registries. We’re building the aggregation and curation layer on top of them.

Lessons Learned So Far

After weeks of building in public, here’s what we’ve learned:

1. The MCP community is incredibly welcoming. We’ve submitted PRs to 36 awesome-lists and the response has been positive.

2. Enterprise buyers want security first. Every conversation with potential partners starts with “how do you handle security?”

3. Discovery is the real bottleneck. Most MCP servers have fewer than 10 GitHub stars, not because they’re bad, but because nobody can find them.

4. The ecosystem needs standards. There’s no standard way to describe what an MCP server does, what it requires, or how well it works.

What’s Next

We’re working on:

• A trust scoring algorithm based on code analysis, maintenance patterns, and community signals
• Integration with major AI platforms (we’re in conversations with several)
• An open API so other tools can use our curation data

If you’re building in the MCP/AI agent space, I’d love to hear what discovery problems you’re facing. Drop a comment below or check out skillflow.builders.

This is part of our “building in public” series. Follow for updates on the AI skills ecosystem.

This guide explains how to properly configure a testing environment in Laravel using .env.testing and phpunit.xml.

📌 Overview

When running automated tests, you should isolate your testing environment from development and production. This prevents accidental data loss and improves test reliability.

⚙️ 1. Create .env.testing

Create a .env.testing file in the root of your Laravel project:

APP_NAME=laravel
APP_ENV=local
APP_KEY= # application key
APP_DEBUG=true
APP_URL=http://laravel.test

APP_LOCALE=en
APP_FALLBACK_LOCALE=en
APP_FAKER_LOCALE=en_US

APP_MAINTENANCE_DRIVER=file

BCRYPT_ROUNDS=12

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE= # your testing database (e.g., laravel-testing)
DB_USERNAME=root
DB_PASSWORD=

SESSION_DRIVER=database
SESSION_LIFETIME=120
SESSION_ENCRYPT=true
SESSION_PATH=/
SESSION_DOMAIN=null

✅ Notes
Use a separate database for testing.
Never reuse your development or production database.

🧪 2. Configure phpunit.xml

Update your phpunit.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="vendor/phpunit/phpunit/phpunit.xsd"
         bootstrap="vendor/autoload.php"
         colors="true"
>
    <testsuites>
        <testsuite name="Unit">
            <directory>tests/Unit</directory>
        </testsuite>
        <testsuite name="Feature">
            <directory>tests/Feature</directory>
        </testsuite>
    </testsuites>

    <source>
        <include>
            <directory>app</directory>
        </include>
    </source>

    <php>
        <env name="APP_ENV" value="testing"/>
        <env name="APP_MAINTENANCE_DRIVER" value="file"/>
        <env name="BCRYPT_ROUNDS" value="4"/>

        <env name="BROADCAST_CONNECTION" value="null"/>
        <env name="CACHE_STORE" value="array"/>
        <env name="DB_CONNECTION" value="mysql"/>
        <!-- <env name="DB_DATABASE" value="your-testing-db"/> -->
        <env name="DB_URL" value=""/>

        <env name="MAIL_MAILER" value="array"/>
        <env name="QUEUE_CONNECTION" value="sync"/>
        <env name="SESSION_DRIVER" value="array"/>

        <env name="PULSE_ENABLED" value="false"/>
        <env name="TELESCOPE_ENABLED" value="false"/>
        <env name="NIGHTWATCH_ENABLED" value="false"/>
    </php>
</phpunit>

🚀 3. Run Tests

Before running tests:

Ensure your testing database exists
Run migrations if needed

Then execute:

php artisan test

⚡ Tips
Isolation: APP_ENV=testing ensures .env.testing is used.
Performance:
CACHE_STORE=array
SESSION_DRIVER=array
QUEUE_CONNECTION=sync
Faster Hashing:
Reduce BCRYPT_ROUNDS during testing
Disable Extras:
Disable tools like Telescope, Pulse, etc., to speed up tests

✅ Summary

With this setup:

Tests run faster ⚡
Data remains safe 🔒
Environment stays isolated 🧪

Claude can now read your screen, run Python code, and access your local files. But it still can’t send you cryptocurrency or trade on your behalf. What if your AI agent could actually execute onchain transactions, not just talk about them?

Why AI Agents Need Real Financial Capabilities

We’re at an inflection point. AI agents are becoming sophisticated enough to make financial decisions — analyzing market data, identifying arbitrage opportunities, managing DeFi positions. But they hit a wall when it comes to execution. They can tell you to “buy ETH” but can’t actually buy ETH.

The missing piece is secure wallet infrastructure designed for AI agents. Traditional wallets assume human interaction — clicking confirm buttons, manually copying addresses, approving each transaction. AI agents need programmatic access with built-in safeguards.

This is where WAIaaS (Wallet-as-a-Service for AI agents) bridges the gap, especially through its native Model Context Protocol (MCP) integration.

MCP: The Missing Link for AI Wallet Integration

If you’re already using Claude Desktop, you’re probably familiar with MCP servers. They extend Claude’s capabilities by providing tools the AI can call directly. Want Claude to read your Git commits? Add an MCP server. Want it to query your database? Another MCP server.

WAIaaS takes this same approach for blockchain interactions. It’s an MCP server that exposes 45 wallet and DeFi tools to your AI agent. One configuration change, and Claude can check balances, send payments, execute swaps, and manage DeFi positions.

Here’s what that looks like in practice:

You: “Check my Solana wallet balance”

Claude: Calls get_balance tool → “You have 12.45 SOL (~$2,156 USD)”

You: “Swap 1 SOL for USDC on Jupiter”

Claude: Calls execute_action with jupiter-swap → “Swap submitted. Transaction: 3x7K…9mP2”

You: “Show my current DeFi positions”

Claude: Calls get_defi_positions → “You’re earning 8.2% APY on 1,000 USDC in Aave…”

The agent isn’t just telling you what to do — it’s actually doing it.

Setting Up WAIaaS as an MCP Server

The setup is surprisingly straightforward. WAIaaS runs as a local daemon that Claude connects to via MCP.

First, start the WAIaaS daemon:

npm install -g @waiaas/cli
waiaas init
waiaas start                       # Sets master password on first run
waiaas quickset --mode mainnet     # Creates wallets + MCP sessions

This creates both EVM and Solana wallets, generates session tokens for AI access, and outputs the MCP configuration you need.

Next, add WAIaaS to your Claude Desktop configuration. Edit claude_desktop_config.json:

{
  "mcpServers": {
    "waiaas": {
      "command": "npx",
      "args": ["-y", "@waiaas/mcp"],
      "env": {
        "WAIAAS_BASE_URL": "http://127.0.0.1:3100",
        "WAIAAS_SESSION_TOKEN": "wai_sess_<your-token>",
        "WAIAAS_DATA_DIR": "~/.waiaas"
      }
    }
  }
}

Restart Claude Desktop, and you’ll see the WAIaaS tools appear in the MCP connection status. Your agent now has access to 45 financial tools spanning wallets, DeFi protocols, NFTs, and cross-chain bridging.

Security Without Friction

This is where WAIaaS differs from traditional wallet solutions. It’s built specifically for AI agent use cases, with 3-layer security that doesn’t require constant human intervention:

Layer 1: Session Authentication — AI agents use JWT tokens with configurable time limits and renewal policies. No private keys in agent memory.

Layer 2: Policy Engine — 21 policy types create guardrails around agent behavior. Spending limits, recipient whitelists, time restrictions, and default-deny token policies.

Layer 3: Human Oversight — Large transactions trigger delays or require approval via WalletConnect, Telegram, or push notifications.

Here’s an example policy that allows small transactions instantly but requires approval for larger amounts:

curl -X POST http://localhost:3100/v1/policies 
  -H 'Content-Type: application/json' 
  -H 'X-Master-Password: <password>' 
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "SPENDING_LIMIT",
    "rules": {
      "instant_max_usd": 10,
      "notify_max_usd": 100,
      "delay_max_usd": 1000,
      "delay_seconds": 300,
      "daily_limit_usd": 500
    }
  }'

The agent can execute small trades immediately, gets notifications for medium trades, faces delays for larger trades, and needs explicit approval for anything above the daily limit.

Beyond Basic Payments: DeFi Integration

What makes WAIaaS particularly powerful is its integration with 14 DeFi protocols. Your Claude agent doesn’t just send tokens — it can participate in the entire DeFi ecosystem.

The supported protocols include:

• DEX trading: Jupiter (Solana), 0x (Ethereum)
• Lending: Aave v3, Kamino
• Liquid staking: Lido (Ethereum), Jito (Solana)
• Cross-chain bridging: LI.FI, Across
• Derivatives: Hyperliquid perpetuals
• Prediction markets: Polymarket

Each protocol exposes its functionality through simple MCP tools. Want your agent to manage a leveraged position on Hyperliquid? The hyperliquid tool handles authentication, position management, and risk monitoring.

Here’s how an agent might execute a DeFi strategy:

You: “I think ETH will outperform SOL. Move some funds accordingly.”

Claude:

1. Calls get_defi_positions to see current allocations
2. Calls execute_action with jupiter-swap to convert SOL → USDC
3. Calls execute_action with lifi to bridge USDC from Solana to Ethereum
4. Calls execute_action with aave-v3 to supply USDC and borrow ETH
5. Reports the new leveraged ETH position

All of this happens through natural language instructions, with the agent handling the technical details of multi-protocol interactions.

Multi-Wallet Agent Management

For more complex setups, WAIaaS supports multiple wallets with separate MCP server instances. This is useful when you want specialized agents for different purposes:

{
  "mcpServers": {
    "waiaas-trading": {
      "command": "npx",
      "args": ["-y", "@waiaas/mcp"],
      "env": {
        "WAIAAS_AGENT_ID": "019c47d6-51ef-7f43-a76b-d50e875d95f4",
        "WAIAAS_AGENT_NAME": "trading-agent"
      }
    },
    "waiaas-payments": {
      "command": "npx",
      "args": ["-y", "@waiaas/mcp"],
      "env": {
        "WAIAAS_AGENT_ID": "019c4cd2-86e8-758f-a61e-9c560307c788",
        "WAIAAS_AGENT_NAME": "payment-wallet"
      }
    }
  }
}

Each agent gets its own wallet, policies, and capabilities. Your trading agent might have higher spending limits and access to derivatives, while your payment agent has stricter limits and only basic transfer capabilities.

Try It Now

Ready to give your Claude agent financial superpowers? Here’s the fastest path:

1. Start WAIaaS: npm install -g @waiaas/cli && waiaas init && waiaas start
2. Create wallets: waiaas quickset --mode mainnet
3. Add MCP config: Copy the output to claude_desktop_config.json
4. Restart Claude Desktop and watch the MCP tools connect
5. Test it: Ask Claude to check your wallet balance

The entire setup takes less than 5 minutes, and you’ll have a working AI agent with wallet capabilities on both Ethereum and Solana.

What’s Next

This is just the beginning. WAIaaS provides the infrastructure for AI agents to interact with the financial world safely and programmatically. From here, you can explore advanced DeFi strategies, cross-chain arbitrage, or automated portfolio management — all through natural language instructions to your AI agent.

Get started with the code and documentation at https://github.com/minhoyoo-iotrust/WAIaaS, or learn more about the project at https://waiaas.ai.

Production issues in SAP Commerce don’t announce themselves politely. They arrive as vague alerts, customer complaints, or a sudden spike in error rates at the worst possible time. The difference between a 15-minute resolution and a 4-hour outage comes down to how quickly you can identify the root cause, and that requires knowing where to look and what tools to use.

This article is a field guide for diagnosing and resolving the most common production issues in SAP Commerce Cloud: memory problems, slow queries, thread deadlocks, cache issues, CronJob failures, and deployment errors.

Problem 1: OutOfMemoryError

Symptoms

• Application pods restarting repeatedly
• java.lang.OutOfMemoryError: Java heap space in logs
• Increasing response times before the crash

Immediate Response

#    Navigate to: Environments → [env] → Monitoring

# 2. If you have access, trigger a heap dump before restart
jmap -dump:format=b,file=/tmp/heapdump.hprof <pid>

# 3. Check recent deployments or configuration changes
#    Was anything deployed in the last 24 hours?

Common Causes

Large ImpEx imports consuming memory:

# Check for running imports in HAC → ImpEx → Import
# Large imports without batching can consume gigabytes

# Fix: Split large imports into batches
# Before: Single 2GB import file
# After: Multiple files, 50,000 lines each

Catalog synchronization on large catalogs:

# Catalog sync loads products into memory
# For catalogs with 500k+ products, increase memory or optimize sync

# Reduce sync batch size
catalog.sync.workers=4
synchronization.itemcopycreator.batchSize=100

Unbounded FlexibleSearch results:

// PROBLEM: Loading all products into memory
String query = "SELECT {pk} FROM {Product}";
List<ProductModel> allProducts = flexibleSearchService.search(query).getResult();
// With 500,000 products, this consumes massive heap

// FIX: Always paginate
FlexibleSearchQuery fsq = new FlexibleSearchQuery(query);
fsq.setStart(0);
fsq.setCount(100);  // Process in pages

Session data accumulation:

# Sessions storing too much data (cart calculations, comparison lists)
# Check session sizes in Dynatrace or via JMX

# Reduce session timeout for anonymous users
default.session.timeout=600

# Store large session data externally (Redis) rather than in-memory

Analyzing Heap Dumps

# Download heap dump from pod
kubectl cp commerce-pod:/tmp/heapdump.hprof ./heapdump.hprof

# Open with Eclipse MAT (Memory Analyzer Tool)
# Key reports:
# 1. Leak Suspects Report — shows objects retaining the most memory
# 2. Dominator Tree — shows largest objects by retained size
# 3. Top Consumers — aggregate view by class

# Common findings:
# - Large HashMap instances (session data)
# - List<ProductModel> with millions of entries (unbounded queries)
# - byte[] arrays (media processing without streaming)

Problem 3: Thread Deadlocks and Pool Exhaustion

Symptoms

• Requests hanging indefinitely
• Thread pool metrics showing 100% utilization
• RejectedExecutionException in logs

Taking Thread Dumps

# Via jstack (if you have pod access)
jstack <pid> > thread_dump_$(date +%s).txt

# Take 3 dumps, 10 seconds apart, to see thread progression
for i in 1 2 3; do
  jstack <pid> > thread_dump_${i}.txt
  sleep 10
done

# Via HAC → Monitoring → Thread Dump
# Downloads a formatted thread dump

Reading Thread Dumps

# Look for BLOCKED threads
"http-nio-9002-exec-42" #142 daemon prio=5
   java.lang.Thread.State: BLOCKED (on object monitor)
    at de.hybris.platform.persistence.GenericBMPBean.ejbLoad(GenericBMPBean.java:456)
    - waiting to lock <0x00000007f8e45678> (a java.lang.Object)
    - locked by "http-nio-9002-exec-17" #117

# This thread is blocked waiting for a lock held by thread exec-17
# Check what exec-17 is doing — likely stuck in a long database operation

# Look for deadlocks (two threads each waiting for the other's lock)
"Found one Java-level deadlock:"
  Thread 1 waiting for lock held by Thread 2
  Thread 2 waiting for lock held by Thread 1

Common Thread Issues

Database connection pool exhaustion:

# Symptom: Threads waiting for database connections
# Check: All DB connections are in use, new requests queue up

# Increase pool size (default is often 10-20)
db.pool.maxActive=50
db.pool.maxIdle=20
db.pool.minIdle=5

# Add connection validation to reclaim leaked connections
db.pool.testOnBorrow=true
db.pool.validationQuery=SELECT 1

# Set max wait time to fail fast rather than queue indefinitely
db.pool.maxWait=5000

Long-running transactions blocking other threads:

// PROBLEM: Transaction held open during external API call
@Transactional
public void processOrder(OrderModel order) {
    orderService.updateStatus(order, OrderStatus.PROCESSING);

    // This external call takes 30 seconds during peak load
    // The transaction stays open, holding database locks
    paymentGateway.charge(order.getPaymentInfo());

    orderService.updateStatus(order, OrderStatus.PAID);
}

// FIX: Separate the external call from the transaction
public void processOrder(OrderModel order) {
    updateOrderStatus(order, OrderStatus.PROCESSING);

    PaymentResult result = paymentGateway.charge(order.getPaymentInfo());

    if (result.isSuccess()) {
        updateOrderStatus(order, OrderStatus.PAID);
    }
}

@Transactional
private void updateOrderStatus(OrderModel order, OrderStatus status) {
    orderService.updateStatus(order, status);
}

Problem 5: Deployment Failures on CCv2

Symptoms

• Build succeeds but deployment fails
• Pod crashes immediately after startup
• Health checks failing

Debugging Deployment Failures

CCv2 Cloud Portal → Builds:

1. Check build logs for compilation errors
2. Check deployment logs for startup errors
3. Check pod logs for runtime exceptions

Common failure patterns:
┌─────────────────────────┬──────────────────────────────────────┐
│ Error                    │ Cause                                │
├─────────────────────────┼──────────────────────────────────────┤
│ Build timeout            │ Too many extensions, slow network    │
│ OOM during build         │ Increase build memory in manifest    │
│ Type system update fail  │ Incompatible items.xml changes       │
│ Bean definition error    │ Missing Spring dependency            │
│ Health check timeout     │ Slow startup, increase timeout       │
│ License validation fail  │ License expired or misconfigured     │
└─────────────────────────┴──────────────────────────────────────┘

Manifest Configuration Issues

// manifest.json — common misconfigurations

{
  "commerceSuiteVersion": "2211.25",
  "extensions": [
    // PROBLEM: Extension listed but not in repository
    "myextension",
    // PROBLEM: Dependency extension missing
    // myextension requires basecommerce but it's not listed
  ],
  "aspects": [
    {
      "name": "backoffice",
      "properties": [
        {
          "key": "db.pool.maxActive",
          "value": "50"
          // PROBLEM: Value too high for pod memory allocation
          // 50 connections × ~5MB each = 250MB just for DB connections
        }
      ]
    }
  ]
}

Rolling Back a Failed Deployment

CCv2 Cloud Portal → Deployments:

1. Identify the last working build number
2. Create new deployment using the previous build
3. Deploy to the affected environment

Important: If the failed deployment included database changes
(new types, removed attributes), the rollback build may need
to handle the modified schema. Test rollback scenarios before
production deployments.

Problem 7: Cluster Synchronization Issues

Symptoms

• Changes made on one node not visible on others
• Inconsistent behavior between requests (load balancer routing to different nodes)
• Stale cache data despite modifications

Diagnosis

# Check cluster node status in HAC → Platform → Cluster

# Verify cluster communication
# All nodes should show as "ALIVE" with recent heartbeat

# If nodes show as "STALE" or "DEAD":
# 1. Check network connectivity between pods
# 2. Verify JGroups configuration
# 3. Check if cluster broadcast is enabled

cluster.broadcast.methods=jgroups
cluster.broadcast.method.jgroups.channel.name=hybris-broadcast

Cache Invalidation Verification

// Test: modify an item and check if other nodes see the change
// On Node 1:
ProductModel product = productService.getProductForCode("TEST-001");
product.setName("Updated Name");
modelService.save(product);

// On Node 2 (via different request):
ProductModel product = productService.getProductForCode("TEST-001");
// If name is still old → cache invalidation is not working
// If name is updated → cluster sync is working

Best Practices

1. Monitor proactively — set alerts for memory usage >80%, cache hit rates <70%, error rates above baseline, and CronJob failures.

2. Keep thread dumps and heap dumps accessible — configure the JVM to dump on OOM (-XX:+HeapDumpOnOutOfMemoryError) and know how to take thread dumps quickly.

3. Maintain runbooks — document every production issue and its resolution. The next incident at 3 AM shouldn’t require the same diagnosis from scratch.

4. Test at production scale — issues that appear with 500,000 products and 10,000 concurrent users don’t show up in dev environments.

5. Deploy during low-traffic windows — CCv2 supports rolling deployments, but having fewer users during deployment reduces the blast radius of issues.

6. Know the rollback process — practice rolling back deployments before you need to do it under pressure.

7. Separate background processing from customer-facing traffic — CronJobs, catalog sync, and indexing should run on dedicated nodes, not on nodes serving API requests.