mcp-server

delete_ai_source

DestructiveIdempotent

Remove an AI source (its CSV + registration) by code so it is no longer applied on future imports. Use this when the user explicitly asks to remove an AI source. DESTRUCTIVE: confirm with the user first, then call with confirm:true. Without confirm:true this tool returns error 'confirm_required' and nothing is deleted (the gate is enforced here, before the call reaches Koongo). NOTE: the custom_ values already written onto products are NOT immediately erased — they clear on the next import; call run_ai_source_import to clear them now. project_id is OPTIONAL (inferred for a single-project customer). If this feature is not included in this Koongo account, the call is refused with error 'addon_required' (HTTP 403); tell the user it is not available for this account and do not retry. Returns {status:'deleted'|'not_found', code, applied}.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "code": "<code>"
    },
    "name": "delete_ai_source"
  }
}

Input Schema

Name	Required	Description	Default
`code`	Yes
`confirm`	No
`project_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026
- removedInput schema / properties / apply
```
Removed value: -{
-  "type": "boolean"
-}
```
Changed1 schema field changedSep 14, 2026
- addedInput schema / properties / confirm
```
Added value: +{
+  "type": "boolean"
+}
```
First observedSep 1, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds substantial behavior beyond them: the confirm_required gate enforced before reaching Koongo, the deferred side effect that custom_<code> product values persist until the next import, the addon_required 403 refusal with a do-not-retry instruction, and the exact return shape. These are exactly the non-obvious traits an agent needs before invoking a destructive mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the destructive/confirm instruction are front-loaded, and nearly every sentence carries unique operational information (gate, side effect, 403 path, return shape). It is a dense single block rather than scannable segments, and the return-shape sentence is arguably over-specified given no output schema, but there is little waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, gated mutation with no output schema and zero schema descriptions, the description covers the action, the confirmation requirement, the delayed cleanup path, an account-entitlement failure mode, and the return value. An agent has everything needed to call it correctly and to explain outcomes to the user.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 load, and it does for all three parameters: `code` identifies the source's CSV + registration, `confirm` must be true or the call fails with confirm_required, and `project_id` is explicitly optional and auto-inferred for single-project customers. It stops short of saying where to obtain a valid `code` (e.g., list_ai_sources), which keeps it from a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Remove an AI source (its CSV + registration)') keyed by `code`, and distinguishes itself implicitly from delete_api_source/delete_feed by naming the AI-source artifact pair being removed. An agent can tell exactly what entity is destroyed and on what key.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger ('when the user explicitly asks to remove an AI source'), an explicit prerequisite (confirm:true), and routes to a named sibling (run_ai_source_import) for the related-but-different task of clearing custom_<code> values immediately. That is when-to-use plus a concrete alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?