Deepfake detection, media intelligence, and invisible watermarking for audio, image, and video via the Resemble AI API, plus docs tools. Remote MCP server (Streamable HTTP) — also published in the official MCP registry as io.github.resemble-ai/resemble-mcp.
Scored across 18 tools
Most tools target distinct resources and actions: agent_detection_* handles website visitor classification, detect_ai_text/detect_deepfake/detect_watermark are clearly separated by input type and goal. A few tools overlap in intent, notably analyze_media versus detect_deepfake and run_detect_agent_investigation, though the descriptions provide enough boundary detail.
The set is mostly consistent: verb-first snake_case names like list_sites, create_site, detect_deepfake, get_detection are easy to predict. Minor deviations include the odd 'detect' adjective in get_detect_agent_run/list_detect_agents and the prepositional ask_about_detection, but these do not undermine the overall pattern.
18 tools is on the heavier side, but the count is justified by the server covering several related subdomains: agent detection, media/text deepfake detection, watermarking, and managed investigations. Each subdomain has a focused cluster of tools, so the number feels purposeful rather than bloated.
Core workflows are covered: create/list/update agent detection sites, detect deepfakes/watermarks/text, retrieve async results, and run managed investigations. Minor gaps exist, such as no delete operation for agent detection sites and no listing of past media/text detections, but agents can work around these.
Create an Agent Detection integration for a website and return its publishable key (pk_live_...) and the script snippet to install. domain is the site's domain, e.g. example.com. If the team already has an integration for that domain, the existing one is returned instead of a duplicate.
The publishable key is safe to put in a public web page: it only sends
telemetry, only from the listed domains. Never put the Resemble API key in
a page. Paste the snippet into the <head> of every page to cover; the page
can then listen for the 'resemble:verdict' event or call ResembleAgentDetection.onVerdict().| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and does so thoroughly. It reveals side effects, idempotency ('existing one is returned instead of a duplicate'), security properties of the publishable key, and explicit installation guidance, all of which go well beyond the schema.
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 description is front-loaded with the core purpose and return value, then adds idempotency, security, and installation details. Every sentence contributes useful information and there is no redundancy or filler.
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?
There is no output schema, so the description correctly explains the key return artifacts and how the delivered snippet should be used. It is nearly complete, but it omits any description of the `name` parameter and does not mention update/list alternatives, leaving a minor contextual gap.
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?
The schema has no parameter descriptions, so the description must compensate. It clearly explains `domain` with a format example ('e.g. example.com'), but it does not explain the optional `name` parameter at all. This is a partial gap, so the score is average rather than high.
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 first sentence uses a specific verb and resource: 'Create an Agent Detection integration for a website' and states the concrete return value (publishable key and script snippet). This clearly distinguishes it from siblings like agent_detection_list_sites or agent_detection_update_site, which have different purposes.
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 description gives clear context for when to use the tool: to create a new integration for a website, and it explains the idempotent behavior when an integration already exists. It does not explicitly name alternatives such as agent_detection_update_site for modifying an existing integration, but the usage context is unambiguous enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarise who is visiting a website: people vs AI agents. Returns totals (visits, decided, agents, people, agent_share, gated), counts per visitor class (human, computer_use_agent, browser_automation, scripted_client), and breakdowns by page, day, and network. Use this to show how much traffic comes from agents and which pages they use, so the site can be made easier for helpful agents and protected from harmful ones.
Filters are optional: site_id (one integration), settled ('human' or
'agent'), page_path, and since/until as ISO 8601 times. agent_share is
agents / decided visits, or null when nothing is decided yet.| Name | Required | Description | Default |
|---|---|---|---|
| since | No | ||
| until | No | ||
| settled | No | ||
| site_id | No | ||
| page_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the output structure and even derives agent_share, which is transparent about what is returned. However, it does not mention any side effects, authentication requirements, rate limits, or potential limitations (e.g., date range constraints). For a tool with no annotations, this leaves some behavioral gaps.
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 description is concise, consisting of two short paragraphs. The first paragraph delivers the core purpose and output summary upfront, while the second adds filter details. There is no redundant fluff, and every sentence earns its place. It is well-structured but could use bullet points for the output list.
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?
For a tool with 5 optional parameters and no output schema, the description covers the key aspects an agent needs: what the tool returns (totals, counts, breakdowns) and how to filter (all parameters explained). It does not specify the exact JSON response shape, but the field listing is sufficient for most use cases. Minor omissions like pagination or result limits are not addressed, but the core calling contract is clear.
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?
The schema has 0% description coverage, so the description must compensate. It does so by explaining each filter parameter: site_id ('one integration'), settled ('human' or 'agent'), page_path, and since/until as ISO 8601 times. It even clarifies agent_share's calculation. This provides meaningful semantics beyond the bare schema, though it could offer more detail on default behavior.
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 uses a specific verb ('Summarise') and resource ('who is visiting a website'), clearly indicating the tool's analytics purpose. It lists the exact output dimensions (totals, counts per visitor class, breakdowns) and states a use case, but does not explicitly distinguish itself from sibling tools like agent_detection_get_session or agent_detection_list_sessions, which prevents a perfect score.
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 description gives a direct usage instruction: 'Use this to show how much traffic comes from agents and which pages they use.' This provides clear context for when to call it. However, it does not mention when not to use it or direct to alternative tools, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one website visit and the evidence behind its verdict: the feature vector it was decided from, plain-language observations, and each model read. When the visit was recorded, the raw event stream is available; it is omitted unless include_events is true, and then capped at the first 200 events. The verdict is advisory: it comes from browser signals, which a determined attacker can fake.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| include_events | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does so well. It discloses that raw events are omitted unless include_events is true, that the stream is capped at 200 events, and that the verdict is advisory because browser signals can be spoofed by an attacker.
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 description is compact and front-loaded: the main action appears first, followed by the evidence contents, the conditional event-stream behavior, and a security caveat. Every sentence contributes useful information without repetition.
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?
For a tool with no output schema and no annotations, the description covers the return contents, the optional parameter's effect, and an important caveat about verdict reliability. It does not mention error behavior or how to obtain a valid session_id, but the core calling context is clear.
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 add meaning to the parameters. It enriches include_events with concrete behavior and the 200-event cap, and the purpose statement makes session_id's role obvious as the identifier of the visit being fetched, though it doesn't explicitly state where to obtain 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 opens with a specific verb and resource: 'Get one website visit and the evidence behind its verdict.' It then enumerates the exact return contents (feature vector, plain-language observations, model reads), which clearly differentiates it from listing, analytics, and site-management siblings.
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 description clearly establishes it is for retrieving a single website visit's evidence rather than listing or aggregating sessions. It lacks an explicit statement of when not to use it or which sibling to prefer, but the context is sufficient for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List individual website visits, newest first, each with its verdict (settled: human, agent, or null while still open), visitor_class, p_person, the page, referrer, user agent, and duration. Same filters as agent_detection_get_analytics plus a free-text search. per_page max 100.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| since | No | ||
| until | No | ||
| search | No | ||
| settled | No | ||
| site_id | No | ||
| per_page | No | ||
| page_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and largely succeeds: it discloses sort order, null verdict meaning while open, output fields, and the per_page cap of 100. It does not mention authentication, error behavior, or pagination mechanics beyond the limit.
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?
Two compact sentences, front-loaded with the verb and resource. Each clause adds either scope, output fields, filter relationships, or a constraint, with no redundant wording.
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?
For a list tool with no output schema and no annotations, the description covers result contents, ordering, the filter relationship to analytics, and the pagination limit. It omits per-parameter detail and auth/error context, but the sibling reference and clear field list make it largely complete.
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 there are 8 parameters, so the description must compensate. It only explains per_page (max 100), search (free-text), and indirectly points to analytics for the other filters, leaving the semantics of the remaining parameters under-specified.
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?
Description uses a specific verb ('List') with a distinct resource ('individual website visits') and immediately states ordering and the returned data fields. This clearly differentiates it from analytics and single-session siblings.
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?
It references agent_detection_get_analytics to define the filter set and calls out free-text search as the distinguishing capability, giving useful context for choosing this tool. It does not explicitly state exclusions like 'use get_session for a single visit,' so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List this team's Agent Detection integrations. Agent Detection tells a website whether each visitor is a person or an AI agent (for example a personal assistant browsing on someone's behalf). Each integration is one website, with the domains its publishable key works on and the one-line script snippet to paste into the site's .
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It conveys read-only behavior via 'List' and specifies what is returned: the domains and the one-line script snippet. It does not mention pagination, rate limits, or explicitly state 'does not modify', but for a simple list tool the core behavior is clear.
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 description is front-loaded with the action and uses two supporting sentences to explain what an integration is and what the listing contains. It is efficient, though the conceptual explanation of Agent Detection could be trimmed without losing invocation-critical information.
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?
For a zero-parameter list operation with no output schema, it sufficiently describes the return scope and contents: each integration is one website with its domains and script snippet. It does not address pagination or response format details, but those are minor gaps for this simple listing tool.
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?
There are zero parameters, so there is no parameter syntax to document. The only implicit scope is 'this team's', which is clearly stated in the description, satisfying the baseline for a no-parameter tool.
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 opens with a precise verb and object — 'List this team's Agent Detection integrations' — and then clarifies what an integration is (one website, domains, script snippet). This clearly distinguishes the tool from siblings like agent_detection_create_site, agent_detection_update_site, and agent_detection_list_sessions.
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?
It sets a clear context: use this when you need to enumerate this team's configured Agent Detection sites/integrations. It does not explicitly name alternatives or state when not to use it, but the wording is specific enough to avoid confusion with creating/updating sites or listing sessions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace the list of domains an Agent Detection integration's publishable key is valid on (for example to add a staging or www host), and optionally rename it. domains replaces the whole list, so include every domain to keep; at least one is required.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| domains | Yes | ||
| site_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and handles it well by disclosing that 'domains replaces the whole list' and that at least one domain is required. It also notes the optional rename behavior. It does not cover permission requirements or the effect on an existing key, but the core destructive-replacement semantics are clear.
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 description is two sentences with no filler. The main action is front-loaded, and the critical caveat about replacement semantics is placed immediately afterward.
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?
For a low-complexity update operation with three parameters and no output schema, the description is nearly complete: it covers required inputs, replacement behavior, and the optional rename. Minor gaps are the lack of return-value expectations and behavior for an invalid site_id.
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 description compensates well for the two most nuanced parameters: domains are explained as a whole-list replacement requiring at least one item, and name is described as an optional rename. site_id is not explicitly defined but is inferable from the tool name and the integer parameter name.
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 clearly states a specific action: replacing the list of domains valid on an Agent Detection integration's publishable key, with an optional rename. This distinguishes it from sibling tools like agent_detection_create_site and agent_detection_list_sites.
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 description implies when to use the tool via the example 'to add a staging or www host', but it does not explicitly mention when not to use it or present alternatives such as creating a new site. Usage context is present, but routing guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze media for structured intelligence: transcription, translation, language, speaker info, emotion, scene description, abnormalities, and misinformation analysis. media_type: auto | audio | video | image.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| media_type | No | auto | |
| structured_json | No | ||
| max_wait_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It lists outputs but does not disclose potential side effects, authentication needs, or processing behavior (e.g., asynchronous nature, error handling), leaving some gaps.
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 description is concise (two sentences) with no filler, but the first sentence could be better structured (e.g., grouping related outputs). Still efficient.
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?
No output schema and low parameter documentation make the description incomplete for an agent to fully understand tool behavior and response format, especially for a 4-param tool.
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?
With 0% schema description coverage, the description only clarifies media_type (auto/audio/video/image) but does not explain the required 'url' parameter or optional 'structured_json' and 'max_wait_seconds', leaving most parameters undocumented.
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 clearly states the tool analyzes media for structured intelligence and lists specific outputs (transcription, translation, etc.), distinguishing it from siblings that focus on watermarking and deepfake detection.
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 description implies use for general media analysis but lacks explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Embed an invisible Resemble provenance watermark into media (audio-first) and return the watermarked media URL. strength 0.0-1.0 (image/video only).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| strength | No | ||
| custom_message | No | ||
| max_wait_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It mentions embedding and returning a URL, but omits crucial details: whether the original is modified, what happens to existing watermarks, synchronous vs asynchronous behavior, authentication needs, or error handling. The 'audio-first' qualifier is vague.
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 description is concise (one sentence plus parenthetical) and front-loaded with purpose. However, it sacrifices completeness, missing key parameter details and behavioral notes, which makes it less effective.
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?
For a tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It does not explain the return type, async behavior (implied by max_wait_seconds), limitations, or parameter interactions. The 'audio-first' note is unclear.
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?
Only one parameter (strength) is partially described with a range and scope constraint. Three parameters (url, custom_message, max_wait_seconds) receive no explanation. Given 0% schema description coverage, the description should explain all parameters but fails to do so.
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 clearly states the tool's function: embedding an invisible Resemble provenance watermark into media, with 'audio-first' specified and a note about strength for image/video. It distinguishes from sibling tools like detect_watermark or trace_audio_source.
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?
No explicit guidance on when to use this tool versus alternatives. While implied for embedding watermarks, no exclusions or comparisons to siblings are provided, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask a natural-language question about a COMPLETED detection (e.g. 'how confident is the model that this is fake?'). Returns the grounded answer.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| detect_uuid | Yes | ||
| max_wait_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full burden for behavioral disclosure. It fails to mention key traits: side effects (none expected, but not stated), authentication needs, rate limits, or what happens on timeout (max_wait_seconds). The constraint 'completed detection' is useful but insufficient.
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 description is a single sentence with an example, which is concise and front-loaded. However, it lacks structure (e.g., broken into purpose, input, output) and the example is embedded rather than separated. It earns its place but could be more organized.
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?
Given the tool has 3 parameters, no output schema, and no annotations, the description is too brief. It does not explain the return format (e.g., plain text, structured JSON), how 'grounded answer' relates to the detection data, or how max_wait_seconds affects the call. A more complete description would include these details.
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?
With 0% schema description coverage, the description must explain all parameters. It covers detect_uuid and query implicitly via the example and phrasing, but completely omits max_wait_seconds—its meaning, default, and behavior. The example provides some context for query format, but not for detect_uuid format.
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 clearly states the tool's purpose: ask a natural-language question about a completed detection, with an example query. It distinguishes from sibling tools like detect_deepfake or get_detection by specifying the interaction type (question-answering) and input requirement (completed detection).
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 description implies usage context ('completed detection') but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives among siblings (e.g., analyze_media, get_detection) or prerequisites like detection completion status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect whether TEXT (an essay, email, post, review, comment, article) was written by an AI language model. Needs at least 25 words: shorter text comes back as prediction 'uncertain' with no model call - concatenate several messages from the same author to reach the minimum. Returns prediction ('ai' | 'human'), confidence (how sure the model is of that prediction; it is NOT an AI probability, so 'human' at 0.95 means strongly human), and the full result. Only the first ~400 words are read; chunk longer documents. A result can take several minutes when the model is cold or jobs are queued - if status is still 'processing' when the wait budget ends, resume with get_text_detection(uuid). Detection is probabilistic, not proof of authorship.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| threshold | No | ||
| max_wait_seconds | No | ||
| zero_retention_mode | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it delivers: it discloses async/cold-start delay, the 'processing' status, the 25-word/400-word boundaries, confidence semantics ('NOT an AI probability'), and the probabilistic, non-authoritative nature of results. There is no contradiction with annotations because there are none.
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?
Every sentence earns its place and follows a sensible order: purpose, input constraints, output semantics, performance warning, continuation, and caveat. It is long but information-dense, with no filler or repeated schema content.
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?
The description is unusually complete for a no-output-schema, no-annotation tool: it defines return fields, async behavior, and text limits. The remaining gap is optional parameter semantics (threshold, zero_retention_mode, exact max_wait behavior), which keeps it from being fully complete.
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 compensate; it explains the text parameter thoroughly (minimum length, chunking, concatenation) and indirectly references max_wait_seconds via 'wait budget.' However, it gives no semantics for threshold or zero_retention_mode, which remain cryptic without schema descriptions.
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?
Description opens with 'Detect whether TEXT ... was written by an AI language model,' a specific verb, resource, and input type. It also distinguishes this tool from siblings by focusing on text and explicitly naming get_text_detection for resuming an async run.
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?
Explicitly lays out when the tool is usable: text must be at least 25 words, shorter inputs should be concatenated, longer documents should be chunked, and queued runs can be resumed with get_text_detection(uuid). This provides actionable when-to-use and alternative routing, not just a vague hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect whether media (audio, image, or video) at a public HTTPS URL is a deepfake / AI-generated. Polls to completion and returns the verdict label, confidence score, and full result. Optional flags add media intelligence, audio source tracing, visualization, reverse image search (images), out-of-distribution detection, and zero-retention (auto-delete media after analysis). model_type: auto | image | talking_head.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| visualize | No | ||
| model_type | No | auto | |
| max_wait_seconds | No | ||
| run_intelligence | No | ||
| use_ood_detector | No | ||
| use_reverse_search | No | ||
| zero_retention_mode | No | ||
| audio_source_tracing | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses polling behavior (async), return values (verdict, confidence, full result), and optional features (e.g., zero-retention mode auto-deletes media). However, it does not discuss error handling, rate limits, or whether the operation is read-only. This is moderate transparency, neither excellent nor poor.
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 description is two sentences long, front-loading the core purpose and then detailing the polling behavior and optional flags. It is concise with no redundant information, though the parameter listing could be more structured. It earns its place without being verbose.
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?
Given 9 parameters and no output schema, the description explains the return values (verdict, confidence, full result) and covers key behaviors (polling, optional features). However, it omits error scenarios, the structure of 'full result', and comparative guidance against siblings. It is adequate but not fully comprehensive for the tool's complexity.
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?
With 0% schema description coverage, the description must compensate. It adds meaning for most parameters: explains flags like run_intelligence ('adds media intelligence'), zero_retention_mode ('auto-delete media'), and lists model_type options. However, it does not mention max_wait_seconds, leaving a gap. Overall, it adds significant value beyond the bare schema.
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 clearly states 'Detect whether media (audio, image, or video) at a public HTTPS URL is a deepfake / AI-generated', providing a specific verb (detect) and resource (media) with clear scope (deepfake/AI-generated). It distinguishes itself from sibling tools like detect_watermark or trace_audio_source by focusing on deepfake detection.
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 description implies usage by stating it polls to completion and lists optional features, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites beyond a public URL. The model_type parameter is mentioned but not explained in terms of when to choose each option.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether media at a public HTTPS URL carries a Resemble invisible watermark (audio-first; per-channel verdict for audio).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool checks a public HTTPS URL and gives a per-channel verdict for audio, but does not mention auth needs, rate limits, or behavior on inaccessible URLs.
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 description is a single sentence that efficiently conveys the main purpose and key constraints. It is concise without being overly terse, though it could be slightly more structured.
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?
For a single-parameter tool with no output schema, the description provides adequate context: what it checks (watermark), media type (audio-first), output format (per-channel verdict), and URL requirement (public HTTPS). It lacks detail on the verdict format but is mostly complete.
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?
With 0% schema description coverage, the description adds meaning by specifying the URL must be 'public HTTPS', which is not in the schema (just 'string'). This clarifies the parameter's constraints.
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 clearly states the tool checks media at a public HTTPS URL for a Resemble invisible watermark, specifying 'audio-first' and 'per-channel verdict for audio', which distinguishes it from siblings like detect_deepfake and apply_watermark.
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 description does not explicitly provide guidance on when to use this tool versus alternatives. While the sibling names imply different detection foci, the description lacks direct usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a persisted Detect Agent investigation by run_id, including its full event transcript. Use after run_detect_agent_investigation reported timed_out, or to re-read an earlier investigation.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | ||
| preset_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It says 'Fetch' and 'persisted', which strongly implies a read-only operation with no side effects. However, it does not explicitly state that it is non-mutating, nor does it mention any rate limits, authentication requirements, or error conditions. Given the simple getter nature, this is adequate but not exhaustive.
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 description is two concise sentences, front-loaded with the primary purpose and followed by usage guidance. Every word adds value, with no filler or repetition. It is efficiently structured for quick comprehension.
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?
While the description covers the purpose and usage well, it leaves out an explanation for the required preset_id parameter and does not describe the return format (though no output schema exists). For a tool with no annotations and no output schema, the description should compensate for these missing details, which it only partially does.
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?
The schema has 0% description coverage, so the description must explain both parameters. It mentions run_id as the identifier, but completely omits preset_id. An agent cannot infer what preset_id is for from the description alone, creating a significant gap in understanding how to properly invoke the tool.
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 clearly states the verb 'Fetch', the resource 'Detect Agent investigation', and the key identifier 'run_id'. It also mentions the included 'full event transcript', making it distinct from sibling tools like list_detect_agents or run_detect_agent_investigation. The purpose is unambiguous and specific.
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 description explicitly says 'Use after run_detect_agent_investigation reported timed_out, or to re-read an earlier investigation.' This provides clear, actionable guidance on when to invoke this tool versus alternatives, leaving no ambiguity about the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a detection by UUID, polling until it completes (bounded). Use after detect_deepfake when a long job exceeded its wait budget.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | ||
| max_wait_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Mentions polling 'until it completes (bounded)' and parameter max_wait_seconds, but doesn't detail timeout behavior, errors, or idempotency.
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?
Two sentences, no wasted words. Front-loads purpose and behavior, then usage context. Highly efficient.
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?
No output schema, description doesn't mention return value structure. Adequate for 2-param polling tool but missing details on response format and potential errors.
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 0% so description must compensate. Explains 'uuid' as identifier, implies max_wait_seconds as polling bound, but lacks explicit definition of max_wait_seconds beyond default.
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?
Clearly states verb 'Fetch', resource 'detection by UUID', and polling behavior. Distinguishes from siblings by referencing usage after detect_deepfake.
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?
Explicitly says 'Use after detect_deepfake when a long job exceeded its wait budget', providing clear context. Lacks explicit when-not but implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a text detection by UUID, polling until it completes (bounded). Use after detect_ai_text returned status 'processing' - typically a cold start.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | ||
| max_wait_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key non-obvious behavior: polling until completion, bounded waiting, and typical cold-start latency. It does not cover timeout/error behavior or explicitly confirm read-only semantics, but the central behavioral trait is transparent.
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?
Two short sentences deliver the essential behavior and usage condition with no filler. The most important information is front-loaded.
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?
The description fully captures the core workflow: call detect_ai_text, receive 'processing', then poll here. It omits the response shape and explicit timeout/error semantics, but for a simple fetch-and-poll tool with an explicit usage condition, the essential context is present.
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 compensate. It clarifies uuid as the lookup key and 'bounded' polling hints at timeout behavior, but it never explicitly links max_wait_seconds to the bound or explains what happens when the wait is exceeded.
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 states a specific verb and resource ('Fetch a text detection by UUID') and adds polling behavior that differentiates it from initiation tools like detect_ai_text. An agent can clearly identify this as the follow-up retrieval tool.
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?
It explicitly says when to use it: after detect_ai_text returned status 'processing', with the cold-start context adding nuance. It does not specify when not to use it or name alternatives such as get_detection, so it stops short of a full exclusion-based guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the managed Detect Agents — investigators that wrap detection in a multi-step workflow ending in a written assessment. Returns each agent's preset_id plus this team's run allowance (free_runs_remaining, entitled), which is worth checking before starting a run.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that this is a listing operation, names the returned fields (preset_id, free_runs_remaining, entitled), and explains why the returned allowance matters. That is meaningful transparency for a simple zero-parameter tool, though it does not address auth or error behavior.
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?
Two sentences with no filler. The main action is front-loaded, the defining context is compressed into a parenthetical clause, and the return-value note earns its place by adding actionable guidance.
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?
For a zero-parameter list tool with no output schema and no annotations, the description is complete: it says what is listed, what is returned, and when to check it. Nothing an agent needs to invoke or interpret the result is missing.
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?
The tool has zero parameters, so the baseline is 4. The description appropriately focuses on output rather than inputs, and there is no parameter meaning for it to add beyond the empty schema.
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 ('List') and resource ('managed Detect Agents'), then clarifies what those agents are with a distinctive definition (multi-step workflow ending in a written assessment). It is clearly distinguishable from siblings like list_sessions and list_sites, and the mention of returning preset_id and run allowance reinforces the tool's specific scope.
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 description gives clear usage context: checking run allowance before starting a run. This implicitly points toward run_detect_agent_investigation as the next step, but it does not explicitly name alternatives or state when not to use this tool, so it stops 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.
Run a managed Detect Agent investigation against media at a public HTTPS URL and return its verdict. preset_id is one of: investigate_social_content, review_insurance_claim, verify_breaking_news, verify_document, verify_evidence, verify_id (confirm with list_detect_agents). query states the investigation objective; check_urls adds URLs for the agent to check.
Consumes a run of the team's allowance. `label`/`score` are the Detect
evidence and are the only basis for an authenticity claim; `verdict` is the
agent's written assessment. If timed_out is true the investigation is still
running server-side — retrieve it later with get_detect_agent_run.| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| query | No | ||
| preset_id | Yes | ||
| check_urls | No | ||
| max_wait_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does so thoroughly. It discloses that the tool consumes a run of the team's allowance (a cost/consumption behavior), explains the meaning of label/score/verdict, and explicitly states that if timed_out is true the investigation continues server-side and should be retrieved later. This goes well beyond a simple 'runs an investigation' statement.
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 description is compact and front-loaded with the core action, then covers preset_id, query, check_urls, and the output semantics in a tight sequence. Every sentence earns its place; the only minor deduction is that the output-field explanation could arguably be split for readability, but it is still efficient.
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?
For a tool with no output schema and no annotations, the description is remarkably complete. It covers the required inputs, the optional parameters, the meaning of the return fields, the consumption behavior, and the timeout/retrieval path. An agent has everything needed to invoke it correctly and interpret the result.
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 compensate, and it does. It explains preset_id with a concrete list of valid values, defines query as the investigation objective, and clarifies check_urls as additional URLs for the agent to check. It also explains the meaning of the output fields label/score/verdict and the timed_out behavior, which adds meaning beyond the bare schema.
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 states a specific verb ('Run'), a specific resource ('managed Detect Agent investigation'), and the input ('media at a public HTTPS URL'), and it clearly distinguishes this from siblings like get_detect_agent_run and list_detect_agents. It also enumerates the valid preset_id values, which removes ambiguity about what the tool does.
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 description explicitly tells the agent when to use this tool (to run an investigation and get a verdict) and how to confirm preset_id values via list_detect_agents. It also explains the timeout behavior and directs the agent to use get_detect_agent_run later if timed_out is true, which is clear guidance versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the audio source-tracing report for a detection (which AI platform generated the fake audio). Only available when detection ran with audio_source_tracing and labeled the audio fake.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It mentions the prerequisite condition and the nature of the report (which AI platform). However, it does not describe the output format, error behavior if condition not met, or any side effects, leaving gaps.
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 description is two sentences with no wasted words. The first sentence states the purpose, the second adds a crucial condition. It is front-loaded and concise.
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?
For a simple tool with one parameter and no output schema, the description covers purpose and a key prerequisite. However, it lacks details on the report's contents (beyond platform) and error cases, making it somewhat incomplete.
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?
The only parameter 'uuid' has no description in the schema (0% coverage). The description partially clarifies that it is for a detection, but does not explicitly state it is the detection's UUID or provide further formatting details, adding minimal value.
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 clearly states the tool gets an audio source-tracing report for a detection, specifying which AI platform generated the fake audio. It distinguishes from siblings by focusing on source tracing and including a condition for availability.
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 description explicitly says the report is only available when detection ran with audio_source_tracing and labeled the audio fake, providing clear context for use. It does not explicitly compare to alternatives but implies the condition.
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.
agent_detection_create_siteagent_detection_get_analyticsagent_detection_get_sessionagent_detection_list_sessionsagent_detection_list_sitesagent_detection_update_sitedetect_ai_textget_detect_agent_runget_text_detectionlist_detect_agentsrun_detect_agent_investigationanalyze_mediaapply_watermarkask_about_detectiondetect_deepfakedetect_watermarkget_detectiontrace_audio_source
Add one secure layer between your agents and this server.