An MCP server that gives AI assistants four local, read-only tools from Kanibal Studio (ALTA VISTA360, S.L.U.):
Tool | What it does |
| France only: tells whether a consent to telephone canvassing is still valid under décret 2026-662. Fail-closed. |
| Ranks B2B lead sources, from CSV text, on cost per kept qualified meeting instead of cost per lead. |
| GDPR gap report for customer service outsourced outside the EU/EEA. Not legal advice. |
| Picks the lowest declared cost rank among the capable, available and authorised models of a supplied catalogue. |
Each tool computes from its arguments only: no network call, no file access, no state kept between calls. All four are marked read-only and closed-world for MCP clients. They wrap the published packages demarchage-consent, cost-per-kept-meeting, rgpd-offshore-check and least-cost-capable.
claude mcp add kanibal-tools -- uvx kanibal-tools-mcpRelated MCP server: linkedin-prospection-mcp
Add this server to the client's MCP configuration:
{
"mcpServers": {
"kanibal-tools": {
"command": "uvx",
"args": ["kanibal-tools-mcp"]
}
}
}Without uv, install it with pip install kanibal-tools-mcp and use kanibal-tools-mcp as
the command. The server speaks MCP over stdio and needs Python 3.10 or newer.
"Is a telemarketing consent collected on 2025-11-02 still valid today?"
"Here is my CSV of lead sources for October: rank them by cost per kept meeting."
"Prepare a GDPR gap report for our customer service in Tunisia: we have SCCs but no transfer impact assessment."
"From this model catalogue, which is the cheapest one that can do Python and debugging?"
The consent tool applies French rules only (décret 2026-662). It is a check, not legal advice.
The GDPR report is a checklist: a report without blocking gap is not a finding of compliance.
A low cost per kept meeting does not prove profitability.
The model selection uses only the facts in the catalogue you supply; it does not switch models, call providers or guarantee savings.
pip install -e ".[dev]"
pytestThe tests call every tool through an in-memory MCP client session.
Prepared by Kanibal Studio, associated with ALTA VISTA360, S.L.U. Our public sites are Altavista360, Altavista Conseil and K-Pulse.
Licensed under the MIT License.
France only: is a consent to telephone canvassing still valid under décret 2026-662?
Dates are ISO 8601 (a date without time zone is read as UTC). Statuses:
"valide", "expire" (older than the ceiling, 365 days at most), "revoque"
(any sign of revocation wins), "preuve_manquante" (no readable collection
date, or one in the future). Fail-closed. Not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| now | No | ||
| revoked_at | No | ||
| collected_at | Yes | ||
| max_age_days | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive and closed-world, but the description adds substantive policy the agent cannot get elsewhere: fail-closed handling, revocation precedence ('any sign of revocation wins'), a 365-day ceiling, future collection dates treated as missing proof, UTC assumption for naive dates, and a 'not legal advice' caveat. That is exactly the extra context annotations do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with jurisdiction and the core question, then the status vocabulary which is genuinely load-bearing for interpreting results. The parenthetical glosses are dense but each earns its place; only the trailing disclaimer is padding, and it is one short phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the description's status definitions and fail-closed rule give the agent what it needs to read results correctly. The remaining gap is the role of the 'now' and 'max_age_days' parameters, which neither schema nor description clarifies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the parameter burden and it only partly does. It explains ISO 8601 formatting and UTC interpretation for the date inputs and implies a 365-day maximum ceiling, but never names 'now' or 'max_age_days' or states their defaults and override behavior, leaving two of four parameters to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('is a consent to telephone canvassing still valid') plus a clear jurisdictional scope ('France only') and the governing rule (décret 2026-662). No sibling tool overlaps, so an agent can route to it unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'France only' is an explicit applicability constraint that will exclude many calls, and the question framing makes the intended use obvious. It stops short of naming alternatives or stating a when-not condition beyond the jurisdiction limit, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GDPR gap report for customer-service processing outsourced outside the EU/EEA.
answers follows https://github.com/kanibal-studio/rgpd-offshore-check#input-format.
Only a JSON true satisfies a check; anything else is reported as a gap or
"to_verify". lang is "en" or "fr". Not legal advice and not a certification:
a report without blocking gap is not a finding of compliance.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| answers | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description is free to add real value — and it does: 'Only a JSON true satisfies a check; anything else is reported as a gap or to_verify' discloses the evaluation logic, and the closing sentence warns that a gap-free report is not a compliance finding. That is meaningful behavioral context an agent could not get from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first clause and every following sentence adds a distinct fact (input format pointer, check semantics, lang values, legal disclaimer). Slight cost: the bare URL and the trailing disclaimer take space an agent may not need at call time.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the description covers purpose, check semantics, language, and the important caveat that absence of a gap is not compliance. The one real gap is that the required 'answers' object's shape lives only behind an external link rather than in the definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the load. It partially does: it supplies the enum values for 'lang' that the schema omits ('en' or 'fr') and explains what answer values mean (only JSON true satisfies a check). However, the structure of the required 'answers' object is delegated entirely to an external GitHub URL, which gives no in-band guidance if the agent cannot fetch it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific deliverable (GDPR gap report) and scopes it precisely to customer-service processing outsourced outside the EU/EEA, which is enough to separate it from all three siblings (lead scoring, telemarketing consent, model selection). It never explicitly names a sibling as the alternative, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The domain scoping ('customer-service processing outsourced outside the EU/EEA') implies when the tool applies, but there is no explicit when-to-use/when-not statement, no prerequisites, and no comparison to the sibling tools. The usage context is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank B2B lead sources on cost per kept qualified meeting instead of cost per lead.
csv_text is the CSV file content, with the columns documented at
https://github.com/kanibal-studio/cost-per-kept-meeting#input-columns.
Results under min_meetings qualified kept meetings are flagged as a small
sample, never hidden. A low cost per meeting does not prove profitability.
| Name | Required | Description | Default |
|---|---|---|---|
| csv_text | Yes | ||
| min_meetings | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: small-sample rows are flagged rather than hidden, and a low cost per meeting is explicitly not proof of profitability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first line, followed by caveats that each carry real information. Slightly weakened by offloading column documentation to an external URL rather than summarizing inline, but overall tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be described, and annotations cover safety. The description supplies parameter meaning and important interpretation caveats, leaving only the CSV column contract external.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description gives meaning to both parameters: csv_text is the CSV file content (with columns pointed to via URL) and min_meetings is the small-sample threshold below which results are flagged. The csv_text column details being relegated to an external URL is the main shortfall.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Rank), resource (B2B lead sources), and the exact metric (cost per kept qualified meeting instead of cost per lead), which sharply distinguishes it from the sibling tools that deal with consent, GDPR, and model selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The contrast with 'cost per lead' implies the situation in which this tool is preferred, but there is no explicit 'use this when' framing, no exclusions, and no named alternative tool. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pick, from a supplied catalogue, the model with the lowest declared cost rank among those that have every required capability and are available and authorised.
catalogue follows https://github.com/kanibal-studio/least-cost-capable (fields
required_capabilities and models). Unknown or non-comparable cost evidence stays
unresolved. Nothing is called, switched or launched; savings are not guaranteed.
| Name | Required | Description | Default |
|---|---|---|---|
| catalogue | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, yet the description still adds real behavioral content: no side effects on the runtime, unresolved results for inadequate cost evidence, and an explicit warning that savings are not guaranteed. It does not define what 'declared cost rank' means precisely or how ties are broken.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and selection rule are front-loaded in the first sentence, followed by the catalogue reference and then the side-effect/no-guarantee caveats. Every clause carries information; nothing is redundant padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation, and the description covers the resolution policy and the absence of side effects. The main residual gap is the internal structure of the nested catalogue, which is delegated to an external GitHub link rather than spelled out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter is a nested, open-ended object, so the description must carry the burden. It does name the two relevant top-level fields (required_capabilities and models) and points to an external spec, but leaves the per-model entry shape (cost rank, availability, authorisation fields) and the field naming/format entirely to the URL.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (pick/select), the resource (a model from a supplied catalogue), and the exact selection criterion (lowest declared cost rank among capability-satisfying, available, authorised models). The sibling tools (lead-source ranking, telemarketing consent, GDPR reporting) are in unrelated domains, so no disambiguation is needed and none is expected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Makes the operating context clear: this is a pure selection/decision helper over a caller-supplied catalogue, and explicitly not an execution step ('Nothing is called, switched or launched'). It also gives the fallback rule for ambiguous input (unknown or non-comparable cost evidence stays unresolved), though it never states explicit prerequisites for the catalogue or a when-not-to-use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_telemarketing_consentgdpr_offshore_gap_reportrank_lead_sources_by_kept_meetingselect_least_cost_capable_modelScored across 4 tools
The four tools target clearly different tasks: lead-source cost ranking, French telemarketing consent validity, GDPR offshore outsourcing gap reporting, and model selection. Their names and descriptions make misselection unlikely. Compliance-related tools exist, but one is narrowly about French consent and the other about GDPR outsourcing, so the boundary is clear.
All names use snake_case and are descriptive, but the naming pattern is not consistent: three tools start with verbs while gdpr_offshore_gap_report is a noun phrase. The convention is readable but not a uniform verb_noun pattern.
Four tools is a reasonable size for a compact utility server, and each tool appears to represent a substantive standalone operation. The set is heterogeneous rather than tightly scoped, but the count itself is not excessive or thin.
Each tool appears to cover its specific self-contained calculation or check, with documented input formats and fail-closed behavior. There is no obvious CRUD lifecycle to complete, though the server lacks broader validation, explanation, or workflow tools that might be expected in a larger toolkit.
Curated EU AI/Sec/DevTools/Fintech B2B leads, Claude-scored. MCP+x402. Free 250/mo.
335 MCP tools, 75 playbooks. AI-native CRM, email/SMS, events, OAuth.
AI legal compliance: contract review, risk scoring, EU/CN AI act, watermark check. 8 MCP tools.
13 pay-per-event data APIs for local-business and web intelligence: local presence audit (Google Business Profile + reviews + AI-readiness), Google Maps scraper, review radar and review pitch generator, TikTok, Instagram, YouTube and LinkedIn scrapers, RAG web browser, France fuel prices, hotel rate monitoring, and a free AEO/AI visibility checker.
