DEV Community: Altavista360

Turning four compliance and lead-cost checks into a local, read-only MCP server

Altavista360 — Sun, 25 Oct 2026 08:13:35 +0000

We run a small call-centre outsourcing brokerage, and a few questions kept coming back to us. Is this telemarketing consent still valid under France's new one-year rule? Which lead source is actually cheapest once you count the meetings that took place, not the leads? What is missing in a GDPR set-up when customer service is outsourced outside the EU?

Over the last weeks we turned those questions into small, standard-library Python packages. This weekend we wrapped four of them in an MCP server, so that Claude, Cursor and other MCP clients can call them directly: kanibal-tools-mcp.

claude mcp add kanibal-tools -- uvx kanibal-tools-mcp

For Claude Desktop, Cursor or any other client, the configuration is the usual one:

{
  "mcpServers": {
    "kanibal-tools": { "command": "uvx", "args": ["kanibal-tools-mcp"] }
  }
}

The four tools

Tool	What it does
`check_telemarketing_consent`	France only: is a consent to telephone canvassing still valid under décret 2026-662? Returns `valide`, `expire`, `revoque` or `preuve_manquante`.
`rank_lead_sources_by_kept_meeting`	Ranks B2B lead sources, from CSV text, on cost per kept qualified meeting instead of cost per lead.
`gdpr_offshore_gap_report`	GDPR gap report for customer service outsourced outside the EU/EEA (transfer basis, transfer impact assessment, Art. 28 clauses, security, breach notification).
`select_least_cost_capable_model`	From a catalogue you supply, picks the model with the lowest declared cost rank among those that have every required capability and are available and authorised.

Each one wraps a package that is published on its own: demarchage-consent, cost-per-kept-meeting, rgpd-offshore-check and least-cost-capable.

Design choices

Local, read-only, closed-world. Every tool computes from its arguments only: no network call, no file access, no state kept between calls. The tools say so to the client through MCP annotations:

LOCAL_READ_ONLY = ToolAnnotations(
    readOnlyHint=True,
    destructiveHint=False,
    idempotentHint=True,
    openWorldHint=False,
)

Fail-closed. A missing or unreadable consent date is preuve_manquante, never valide. In the GDPR checklist, only a JSON true satisfies a check: an unanswered item is reported as "to verify" and still counts as blocking.

Bounded claims. The consent and GDPR tools are checklists, not legal advice. A low cost per kept meeting does not prove profitability. The model picker only uses the facts in the catalogue it receives; it does not call providers or promise savings.

Testing through a real MCP session

The tests do not call the Python functions directly. They go through an in-memory MCP client session, so they also check the tool names, schemas and annotations that a client sees:

from mcp.shared.memory import create_connected_server_and_client_session
from kanibal_tools_mcp.server import mcp

async def list_tools():
    async with create_connected_server_and_client_session(mcp._mcp_server) as client:
        return (await client.list_tools()).tools

One small surprise: FastMCP takes no version argument, so the server reported the SDK version (1.30.0) instead of its own. Setting it on the low-level server fixed it:

mcp._mcp_server.version = __version__

Publishing: PyPI, the MCP Registry, Glama

PyPI uses Trusted Publishing from a release.yml workflow. The publish job runs in a GitHub environment called pypi that requires a maintainer's approval and only accepts v* tags, so no token is stored anywhere.

The official MCP Registry lists the server as io.github.kanibal-studio/kanibal-tools-mcp. Two details mattered:

The registry checks ownership of a PyPI package through an mcp-name: io.github.kanibal-studio/kanibal-tools-mcp line in the README that PyPI shows.
The interactive mcp-publisher login github flow cannot currently publish under an organisation namespace. Publishing from GitHub Actions with mcp-publisher login github-oidc can, so the release workflow does it right after the PyPI job, and waits until PyPI serves the new version first.

Glama runs its own checks before listing a server. For a repository that belongs to an organisation, it first wants a glama.json at the root naming the maintainers. Its Dockerfile is generated from a small form. The first build failed: uv pip install --system . targeted Debian's Python, which is marked as externally managed. A dedicated virtual environment fixed it:

["uv venv /opt/venv --python 3.12", "uv pip install --python /opt/venv/bin/python ."]

with /opt/venv/bin/python -m kanibal_tools_mcp as the start command. Glama then started the server and listed its four tools.

Try it, and tell us what is missing

Code: https://github.com/kanibal-studio/kanibal-tools-mcp (MIT)
PyPI: https://pypi.org/project/kanibal-tools-mcp/
Product Hunt: https://www.producthunt.com/products/kanibal-tools-mcp

We would like feedback on the tool interfaces, especially from people who run outbound or customer-service teams across EU borders.

Coordinating several AI coding agents on one machine with a 230-line SQLite tool

Altavista360 — Sat, 24 Oct 2026 21:26:24 +0000

When you run several AI coding agents at once on the same machine (several Claude Code sessions, a worker plus an integrator, or a mix of tools), two problems show up quickly:

Messages get lost. One agent finishes something, says so in its own terminal, and nobody else ever sees it.
Two agents edit the same file. Each one is convinced it owns src/add.py, and the second write quietly wins.

We hit both while building our own internal tooling, so we wrote a deliberately small answer to them: agent-collab-kit, one Python file of about 230 lines, standard library and SQLite only, MIT licensed.

Durable messages with explicit acknowledgements

Every message lives in a local SQLite file until the recipient acknowledges it. Here is the demo from the README, run against a throwaway database:

DB=$(mktemp -d)/demo.db
python3 agent_collab.py --db "$DB" init
python3 agent_collab.py --db "$DB" send --sender worker-a --recipient integrator \
  --key demo-result-1 --body 'Addition is ready for review'
python3 agent_collab.py --db "$DB" inbox --recipient integrator

[{"id": "2fd715fc-...", "idempotency_key": "demo-result-1", "sender": "worker-a",
  "recipient": "integrator", "body": "Addition is ready for review",
  "acknowledged_at": null}]

The idempotency key matters for agents: an agent that retries after a crash and sends the same sender, recipient and body gets the existing message back instead of a duplicate. Reusing the key for different content is an error. ack marks the message as received. It does not prove the work was delivered or tested, and the README says so.

Leases on exact resource names

Before editing, an agent claims the exact resource it is about to touch:

python3 agent_collab.py --db "$DB" claim --resource src/add.py --owner worker-a --ttl 300
# {"resource": "src/add.py", "owner": "worker-a", "generation": "6ca2d25b-...", ...}

python3 agent_collab.py --db "$DB" claim --resource src/add.py --owner worker-b --ttl 300
# resource has an active lease   (exit code 1)

Each claim gets a fresh generation UUID. Renewing or releasing requires the matching owner and generation, and an unexpired lease. That closes a nasty case: an agent that was paused, whose lease expired and was taken over, cannot later renew or release its successor's lease, even under the same owner name. Every mutation runs inside SQLite BEGIN IMMEDIATE, and the test suite includes two real processes racing for one claim.

What it does not do

This is the part we care most about stating clearly:

Leases are cooperative. An agent that ignores them is not stopped. There is no filesystem fencing.
Expiry does not stop a worker. A paused worker may resume after a takeover, so workers must check ownership and stop when they lose it.
No identities. Names and UUIDs are cooperative tokens, not authentication. Anyone with access to the database file can impersonate a participant.
One trusted machine, local disk. Network filesystems and separate hosts are unsupported.
No orchestration. It does not launch agents, call a model provider or run Git.

In practice we pair it with one rule: a single integrator reviews and merges, and a shared resource such as __commit__ serializes integration. The repository includes a fictitious COLLAB.md board and a short method for letting project agents propose improvements under supervision.

Four other small tools from the same place

We publish the reusable pieces of our stack under kanibal-studio, each with its own tests and the same habit of saying what it does not do:

least-cost-capable: a portable Agent Skill that picks the lowest declared cost rank among the models in your catalogue that actually have the capabilities a task needs. Unknown evidence stays "unresolved".
cost-per-kept-meeting: ranks B2B lead sources by cost per kept qualified meeting instead of cost per lead.
rgpd-offshore-check: a GDPR gap report for outsourcing customer service outside the EU. Not legal advice.
demarchage-consent: French cold-call consent validity under decree 2026-662, on PyPI.

Issues and criticism are welcome, especially about the lease semantics.

Aymen, Altavista360 : automatiser la relation client sans perdre de vue le résultat

Altavista360 — Sun, 04 Oct 2026 09:39:17 +0000

Bonjour DEV,

Je m’appelle Aymen et je porte Altavista360, une activité de relation client, de centres d’appels et d’acquisition. Je m’intéresse à la façon dont l’IA et l’automatisation peuvent rendre ces services plus utiles et plus fiables au quotidien. Je ne présente pas l’autonomie complète ni un résultat commercial comme acquis.

La question technique qui m’occupe est simple : comment vérifier qu’un agent ou un automatisme a réellement produit l’effet attendu ? Une réponse réussie, une tâche mise en file et une action visible sont trois états différents.

Quelques principes que j’applique :

Séparer les preuves. Le code existe, un test passe, une version est chargée, l’effet public est visible, puis un résultat métier est mesuré. Chaque étape demande sa propre observation. Un HTTP 200 ne prouve pas à lui seul qu’une page contient l’information attendue.
Tester hors des données réelles. Les scénarios de concurrence et d’échec utilisent des données isolées. Désactiver temporairement un mécanisme dans un test permet de vérifier que le test détecte bien sa disparition, puis la source est restaurée et vérifiée.
Regarder le chemin réellement exécuté. Une option de configuration n’est utile que si les appelants la lisent. Je compare le réglage déclaré, la clé effectivement résolue et le comportement du composant, sans exposer de secret.
Nommer l’inconnu. Si une mesure publique échoue, le résultat reste non mesurable. Le remplacer par “tout va bien” masquerait le prochain problème.
Rendre une modification réversible. Préparer le retour arrière et vérifier l’état chargé aide à distinguer une correction locale d’une amélioration réellement en exploitation.

Ces principes servent autant aux flux de publication qu’aux outils de mesure et aux échanges entre composants. Ils ne remplacent pas la qualité du service : l’étape suivante reste de suivre les visites, les demandes et les opérations réellement exécutées, sans transformer les tests en clients fictifs.

Mes trois sites ont des fonctions distinctes : Altavista360 pour l’activité de relation client et d’acquisition, Altavista Conseil pour les parcours de demande et de mise en relation, et K-Pulse 360 pour les articles et guides francophones.

Je souhaite partager ici des retours techniques concrets sur les agents, les tests, l’observabilité et l’automatisation. Quelle preuve vous manque le plus souvent entre “la commande a réussi” et “l’effet attendu est réellement présent” ?

Présentation rédigée avec une assistance IA. Les principes décrivent ma démarche de développement ; ils ne constituent pas une promesse d’autonomie complète ou de revenu.