Gandoki is a precision-first MCP security scanner featuring 55 detectors, layered evidence verification, AI-assisted false-positive suppression, and read-only credential validation. Discover exposed secrets, debug interfaces, and sensitive files across authorized assets with explainable findings and minimal noise.
Scored across 7 tools
Most tools have clearly distinct purposes: job lifecycle (list_jobs, get_job), finding retrieval (get_finding, explain_finding), comparison (diff_jobs), and scanning (scan_domains, scan_file). The only potential overlap is scan_domains vs scan_file, both initiating scans, but the descriptions clarify inline domains versus file input.
All seven tools follow a consistent snake_case verb_noun pattern (list_jobs, get_job, get_finding, scan_domains, scan_file, diff_jobs, explain_finding). No deviations or mixed conventions.
Seven tools is well within the ideal 3-15 range and each earns its place across the scan, job, and finding workflow. No obvious redundancy.
The surface covers scan initiation, job status/listing, finding retrieval/explanation, and cross-job diffing, forming a coherent workflow. Minor gaps exist around job lifecycle management (e.g. cancel/retry a job) and exporting or listing findings across jobs, but agents can work around these.
Compare ACCEPTED findings between two jobs (new / fixed / persisting).
| Name | Required | Description | Default |
|---|---|---|---|
| job_id_a | Yes | ||
| job_id_b | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 disclose two real behaviors: only ACCEPTED findings are considered, and results are bucketed into new/fixed/persisting. It omits the directionality of the comparison (whether job_id_a is the baseline or the newer run) and any cost/pagination characteristics of the diff.
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?
One short sentence, front-loaded with the verb and resource, with the parenthetical enumerating outcomes efficiently. Nothing is wasted, though the parenthetical takes space that could have gone to the a-vs-b ordering.
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 shape needn't be explained, and the accepted-only filter is stated. For a two-input comparison tool, however, the unresolved A/B ordering plus missing preconditions (job completion, matching target) leave the definition only adequate.
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 parameters are bare job_id_a / job_id_b. The description never explains which ID is the reference and which is the comparison, which is the single most important semantic for a diff tool — swapping them inverts 'new' and 'fixed'.
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 ('Compare ACCEPTED findings between two jobs') and even enumerates the diff categories (new / fixed / persisting), which no sibling tool (get_job, get_finding, explain_finding) does. It stops short of naming the sibling it replaces, so 4 rather than 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?
Usage is implied: you call this when you have two job IDs and want the delta in findings. There is no explicit when-not guidance, no statement about whether both jobs must be complete/same target, and no pointer to get_job for inspecting a single job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain a finding in plain language, keeping the honesty contract.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| finding_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden and doesn't say whether this is read-only, whether explanations are cached or generated per call, whether it can be slow or costly, or what the "honesty contract" obligates. A mutation-free read is implied by "explain" but never confirmed.
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?
A single front-loaded sentence is efficient, but brevity here comes at the cost of under-specification, and the trailing clause about the honesty contract consumes space without conveying usable 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?
An output schema exists so return values needn't be described, but with no annotations, zero parameter documentation, and no usage routing, the definition leaves too much unspecified for an agent to invoke it confidently.
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?
Two required parameters with 0% schema description coverage, and the description never mentions job_id or finding_id or their relationship. The agent must guess that a finding is scoped to a job and where those identifiers come from.
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?
"Explain a finding" gives a verb and a resource, so the core action is identifiable, but it isn't clear how this differs from the sibling get_finding, and the phrase "honesty contract" is unexplained jargon that an agent cannot operationalize.
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?
There is no stated condition for when to call this instead of get_finding or after which job/finding lookup. The only hint is "plain language," which implies a summarization angle but names no alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single finding by id (accepted or retracted).
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| finding_id | Yes |
| Name | Required | Description |
|---|---|---|
No output 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, and it does disclose one useful trait: retracted findings remain fetchable, so a result is not guaranteed to be current. It says nothing about not-found behavior, whether job scoping restricts access, or any permission requirements.
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?
A single short sentence with the resource and lookup key front-loaded; nothing is wasted. It is arguably too terse rather than padded, so the only cost is under-specification, not verbosity.
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 presence of an output schema means return values need no explanation, but for a two-parameter lookup tool with zero schema coverage the description should explain the job_id/finding_id relationship and disambiguate against explain_finding. Neither is present, so an agent must guess.
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 both parameters are required with no type beyond string. The description only gestures at finding_id ("by id") and says nothing about job_id, leaving the crucial question of whether finding_id is globally unique or scoped to a job entirely unanswered.
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?
"Fetch a single finding by id" gives a specific verb and resource, and the parenthetical clarifies that both accepted and retracted findings are retrievable. It distinguishes itself reasonably from list_jobs and get_job, though it never explicitly contrasts with explain_finding, the sibling most likely to be confused with it.
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?
There is no explicit when-to-use or when-not-to-use guidance and no named alternative. The only implied condition is that the caller already possesses a finding id, and nothing tells the agent whether to prefer explain_finding when it wants interpretation rather than raw data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch job status and (if done) its findings.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. 'Fetch' implies a read operation, and 'if done' discloses that findings are conditionally returned, which is useful context. However, it does not state whether this is safe to call repeatedly, how incomplete jobs are represented, or any permission/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?
The description is a single front-loaded sentence with no unnecessary wording. It communicates the core behavior and the conditional findings behavior efficiently.
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?
This is a simple read tool with an output schema, so the description need not explain return values in detail. It covers the basic operation and conditional findings, but leaves gaps in usage guidance and parameter semantics. It is minimally adequate 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?
Schema description coverage is 0%, so the description should compensate by explaining the sole parameter. It does not describe the job_id format, source, or expected values. The parameter is obvious by name, but the description adds no meaning beyond the 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 uses a specific verb and resource: 'Fetch job status and (if done) its findings.' This clearly identifies the operation and adds useful conditional behavior. It does not explicitly distinguish itself from siblings like get_finding or list_jobs, so it is clear but lacks sibling differentiation.
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 provides no guidance on when to use this tool versus alternatives such as list_jobs or get_finding. It also omits prerequisites, polling advice, or any indication of when not to call it. Usage is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent jobs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the entire burden of behavioral disclosure. It does not say what "recent" means (time window, ordering), whether results are paginated, whether a token or cursor is needed, or what permissions are required; only the implicit read-only nature of "list" conveys anything.
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 single short sentence is front-loaded and wastes no words, but its brevity comes from under-specification rather than economy. There is room to add recency and paging details without bloat.
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, but with no annotations and an undocumented parameter the definition leaves the agent without ordering, recency semantics, or paging behavior. For a list tool whose main risk is misinterpreting scope, this is thin.
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 (limit, default 20) is undocumented in the schema. The description never mentions the limit, its default, its maximum, or what happens when results exceed it, so it fails to compensate for the coverage gap.
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?
"List recent jobs" states a verb (list) and resource (jobs), which is better than a tautology, but "recent" is undefined and nothing distinguishes it from siblings like get_job or diff_jobs. An agent can guess this returns a collection, but the scope boundary versus get_job is left to inference.
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 no when-to-use guidance and never mentions the alternatives that exist in the sibling set (get_job for a single job, diff_jobs for comparison). There are no exclusions, prerequisites, or context cues, so routing relies entirely on the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a list of domains for exposed secrets and debug exposures.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | ||
| domains | Yes | ||
| timeout_s | No | ||
| include_suspected | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden and discloses almost nothing. It does not say whether the scan is synchronous or dispatched as a background job (the presence of get_job and list_jobs strongly suggests async), what wait=false does, how timeouts are surfaced, or whether scanning third-party domains has authorization implications.
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?
A single front-loaded sentence with zero waste, but the brevity reflects under-specification rather than disciplined editing. Nothing needs trimming; several things need adding.
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 four parameters, zero schema coverage, no annotations, and an async-looking job model, one sentence is far short of complete. The output schema covers return values, which helps, but callers still lack the behavior and parameter semantics needed to invoke it correctly.
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 only implicitly covers the required domains array. The three optional parameters — wait, timeout_s, and include_suspected — get no explanation of their effect on results or behavior, which matters most for include_suspected since it likely changes the finding set.
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: scanning a domain list for exposed secrets and debug exposures. That implicitly separates it from scan_file, which presumably takes a file path, but the description never names the alternative or the exact unit of work.
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?
There is no when-to-use guidance at all — nothing about when to prefer this over scan_file, when to use wait=false with get_job, or any prerequisite such as authorization to probe the targets. The agent must infer the workflow from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a CSV or TXT domain list.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| wait | No | ||
| timeout_s | No | ||
| include_suspected | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and discloses almost nothing: it does not say whether a job is queued asynchronously, what the wait/timeout parameters imply about blocking behavior, whether the scan is read-only or consumes quota, or what happens on timeout. Only the input file formats are conveyed, which is minimal for a four-parameter scan operation.
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?
A single front-loaded sentence with no filler, but it is terse to the point of under-specification rather than efficiently dense. Nothing is wasted, yet little is delivered.
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 output schema excuses explaining return values, but for a job-producing scan tool with four parameters and no annotations, the definition omits async behavior, timeout semantics, and the meaning of include_suspected. An agent cannot invoke this confidently without opening the schema and experimenting.
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 for three undocumented optional parameters (wait, timeout_s, include_suspected) and it says nothing about any of them. The only semantic hint is that path accepts CSV or TXT, which is marginal value over 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?
States a specific verb (Scan) and a specific input resource (a CSV or TXT domain list), so an agent can tell this consumes a file rather than raw domains. It does not name the sibling scan_domains or state the relationship, so differentiation is left to inference.
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?
There is no when-to-use guidance, no mention of prerequisites, and no reference to alternatives such as scan_domains for inline domain input or get_job/list_jobs for tracking results. The agent must guess whether this is the right entry point for file-based scanning.
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.
diff_jobsexplain_findingget_findingget_joblist_jobsscan_domainsscan_file
Add one secure layer between your agents and this server.