Signed, offline-verifiable safety scores for the MCP servers, packages & tools an agent connects to
Scored across 8 tools
The three scan tools have clearly distinct targets (MCP server, package, repo), and about_agentavow/get_trust_badge are unique. The main ambiguity is among lookup_identity, verify_trust, and check_interaction_safety, which all surface trust-score information and could be confused even though their described purposes differ.
All names use snake_case, and the action tools follow a predictable verb_noun pattern (check_interaction_safety, get_trust_badge, lookup_identity, scan_mcp_server, verify_trust). about_agentavow is a minor deviation since it is not verb_noun, but the overall convention is clear.
Eight tools is a well-scoped set for a read-only trust and scanning service. Each tool covers a distinct resource or workflow, and none appears redundant or purely ornamental.
The surface covers the core trust workflows: identity lookup, trust verification, interaction safety, scanning MCP servers/packages/repos, badges, and onboarding documentation. A minor gap is that signed attestations are returned but there is no explicit tool for verifying an attestation through the MCP surface.
What AgentAvow is, which tool to use for what, how to read a verdict, and example scans. Call this for an overview or when getting started. No input, read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile fully (readOnlyHint true, idempotentHint true, destructiveHint false). The description's 'read-only' echoes readOnlyHint and 'No input' restates the empty schema, adding little new behavioral context. It is fully consistent with annotations, so no contradiction penalty applies, but the description contributes minimal behavioral value beyond the structured fields.
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?
Three sentences with no filler. Content scope is front-loaded, followed by the when-to-call guidance and the no-input/read-only constraint. Every sentence earns its place.
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 no-input, read-only overview tool the description is essentially complete. Since there is no output schema, the description carries the burden of describing the return content, which it does ('what AgentAvow is, which tool to use for what, how to read a verdict, and example scans'). Nothing an agent needs to invoke it successfully 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?
There are zero parameters and schema description coverage is 100%, so the baseline is 4. The description's 'No input' correctly confirms what the empty schema already shows, and no further parameter documentation is needed.
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 purpose — an overview/help tool covering what AgentAvow is, tool routing, verdict interpretation, and examples. The verb 'Call this for an overview' clarifies its role, and the content list distinguishes it from the sibling scan/verify/check tools, though the differentiation is implicit rather than explicit.
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?
'Call this for an overview or when getting started' gives a clear when-to-use trigger. It doesn't name alternatives or give explicit when-not-to-use conditions, but the contrast with the operational siblings (scan, verify, lookup) makes the intended context reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether it is safe to interact with another agent by trust threshold. Thresholds: delegate 0.6, trade 0.5, collaborate 0.4, follow 0.1. Returns is_safe, risk_level, the score, and a recommendation. Read-only, no auth.
| Name | Required | Description | Default |
|---|---|---|---|
| interaction_type | Yes | ||
| target_entity_id | Yes | UUID of a registered target entity (resolve one with lookup_identity). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by stating 'Read-only, no auth' and by disclosing the return fields (is_safe, risk_level, score, recommendation), which goes beyond the annotations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The core purpose is front-loaded, thresholds are compactly listed, return fields are summarized, and the read-only/no-auth note is a single efficient clause. Every sentence earns its place.
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 read-only check tool with two required parameters, an enum, and no output schema, the description is nearly complete. It covers purpose, thresholds, return fields, and safety profile. The only minor gap is that it doesn't explain what happens if the target entity is not found or if the trust score is exactly at a threshold, but those are edge cases an agent can infer from the threshold list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: interaction_type is fully documented via enum, and target_entity_id has a description. The description adds meaning by mapping each interaction_type to a numeric threshold (delegate 0.6, trade 0.5, etc.), which is not in the schema. This helps the agent understand the semantics of the enum values. It does not add detail about target_entity_id beyond the schema, but the schema already covers 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 states a specific verb ('check'), a clear resource ('whether it is safe to interact with another agent'), and the mechanism ('by trust threshold'). It also lists the exact thresholds for each interaction type, which distinguishes it from sibling tools like verify_trust or get_trust_badge. The purpose is unambiguous and immediately actionable.
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 this tool: when you need to determine safety for a specific interaction type with a target agent. It provides thresholds that help an agent decide which interaction_type to pass. However, it does not explicitly state when NOT to use it or name alternatives like verify_trust, so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an embeddable AgentAvow trust badge (SVG) for an entity, with ready-to-paste Markdown and HTML. The badge auto-updates as the score changes. Read-only, no auth.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | UUID of a registered AgentAvow entity (resolve one with lookup_identity). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: 'no auth' requirement, the badge 'auto-updates as the score changes', and that output includes both Markdown and HTML variants. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, purposeful sentences. The core purpose is front-loaded in sentence one, behavioral behavior in sentence two, and auth in sentence three. No filler, no repetition of the title or schema content, and each sentence earns its place.
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 one-parameter, read-only, idempotent tool with no output schema, the description covers what is needed to call it correctly: the artifact type and format (SVG + MD/HTML), dynamic behavior (auto-updates), and auth requirements (none). The schema covers the parameter and the annotations cover the safety profile. Nothing an agent needs 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?
Schema coverage is 100%, so the schema already fully documents entity_id, including its format (UUID), constraint (maxLength 64), and a pointer to lookup_identity for resolution. Per baseline, high schema coverage means the description need not repeat parameter details; it adds nothing beyond the 'for an entity' scope already in 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 names a specific verb ('Get'), a specific resource ('embeddable AgentAvow trust badge (SVG)'), and a clear scope ('for an entity'). The output format (SVG, Markdown, HTML) makes it unmistakably distinct from the sibling scan_*, verify_trust, and lookup_identity tools, so an agent can differentiate it without opening a schema.
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 use case is implied by 'embeddable' and 'ready-to-paste Markdown and HTML' — an agent can infer this is for embedding a badge on a page. However, the description never explicitly names alternatives, states when-not-to-use it, or contrasts it with verify_trust or lookup_identity. The only cross-tool guidance (resolve entity with lookup_identity) lives in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up an AgentAvow entity by W3C DID or display name. Returns the entity's id, name, type, trust score and tier. Read-only, no auth. Use to resolve an identity before checking its trust.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A did:web:... or a display name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, open-world, and non-destructive behavior. The description adds useful context beyond annotations by stating 'Read-only, no auth' and summarizing what the entity returns.
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?
Four short, front-loaded sentences each add distinct value: purpose, return fields, auth/safety, and usage context. There is no fluff or 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 simple one-parameter lookup with annotations covering safety, the description is complete: it specifies the input kind, output fields, auth requirements, and intended use. No crucial information 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?
Schema coverage is 100%, so the single parameter is already well documented by the schema. The description's mention of DID/display name mirrors the schema rather than adding new semantic detail, so the baseline of 3 is appropriate.
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 ('Look up'), a specific resource ('AgentAvow entity'), and the lookup keys (W3C DID or display name). It also differentiates from trust/verification siblings by framing this as the resolution step before checking trust.
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 when to use it: 'Use to resolve an identity before checking its trust.' It does not name alternative tools, but the use case clearly separates it from verification and scanning siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a live MCP server's tool definitions for tool-poisoning, prompt-injection, invisible-unicode, and manifest-execution risks before your agent connects to it. Returns one of three answers with its reason (Safe to connect, Review before you connect, or Do not connect), a 0-100 trust score, findings, and a signed attestation. Read-only; calls the agentavow.com public API.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Re-scan now instead of returning the cached verdict (results cache ~1h). | |
| endpoint_url | Yes | The MCP server's https:// URL. |
| Name | Required | Description |
|---|---|---|
| high | No | High findings, static and sandbox. |
| tier | No | Trust tier for the score (detail, not the headline). |
| cached | No | Served from the ~1h cache. |
| signed | No | True when a signed (Ed25519/JWS) attestation backs this. |
| target | Yes | What was scanned, as given. |
| install | No | Install command, only when nothing blocks it. |
| sandbox | No | What the behavioral sandbox observed; null if it does not apply. |
| verdict | Yes | Binary form of the decision, kept for older clients. |
| adoption | No | The adoption score: real usage (downloads per week, stars or installs). Never changes the decision. |
| critical | No | Critical findings, static and sandbox. |
| decision | Yes | The answer to lead with: safe = Safe to connect, review = Review before you connect, do_not_connect = Do not connect. |
| incident | No | Known past compromise (context only, never scored). |
| certified | No | Matches the signed attestation's certified.eligible. |
| subscores | No | Per-category 0-100 scores behind the trust score. |
| deprecated | No | The maintainer's deprecation notice, or null. |
| report_url | Yes | Full report page. |
| scanned_at | No | When the scan ran (ISO 8601, UTC). |
| verify_url | No | How to verify offline. |
| not_checked | No | Plain-English notes for what the scan could not read or check (empty when it read everything). Say these alongside the answer. |
| target_type | Yes | github, npm, pypi, crates, docker, hf, or mcp. |
| trust_score | Yes | Trust score, 0-100. Evidence under the decision. |
| published_at | No | When that version was published. |
| top_findings | No | Up to five most important findings. |
| coverage_gaps | No | Machine form of not_checked: gap kinds (e.g. tool_list_paged, oversized_files) with a flag or count. Empty when nothing was skipped. |
| certified_mark | No | Certified and safe: show the Certified mark. |
| decision_final | Yes | False while the behavioral sandbox is still running; the decision can still change. |
| findings_total | No | All findings, every severity. |
| rescan_pending | No | A fresh scan was started; this is the previous result. |
| verdict_reason | No | Machine reason for the binary verdict, e.g. clean, clean_partial (clean, but not everything was read), blocking_findings, thin_coverage. |
| decision_reason | Yes | One sentence naming what decided it. |
| package_version | No | Package version scanned. |
| report_json_url | No | The full verdict as JSON. |
| static_findings_total | No | Findings from static analysis only. |
| advisories_affecting_version | No | Published advisories that affect this version. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond that: it discloses the exact return contract (three verdicts, 0-100 trust score, findings, signed attestation) and that it hits the agentavow.com public API, which matters for an openWorld call. Not stated: rate limits, or that results are cached ~1h (that lives only in 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?
Three sentences, front-loaded with purpose, then output contract, then the operational note about the external API. No filler or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full output schema and complete annotations, the description only needed to supply purpose, decision framing, and the external-API dependency — all present. Nothing an agent needs to call it correctly 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?
Schema coverage is 100%, so both parameters including the ~1h cache and force-rescan behavior are already documented in structured fields. The description only indirectly signals that endpoint_url is a live server URL; it adds no format or syntax detail beyond the schema. Baseline 3 applies.
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) against a specific resource (a live MCP server's tool definitions) and enumerates the risk classes checked (tool-poisoning, prompt-injection, invisible-unicode, manifest-execution). This also implicitly separates it from scan_package and scan_repo, which target static artifacts rather than a live endpoint.
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 phrase 'before your agent connects to it' gives a clear trigger condition and the decision context (pre-connection vetting). It stops short of naming a sibling alternative or stating when not to use it, so the agent must infer that scan_package/scan_repo cover packages and repos.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a published package (npm, PyPI, crates, Docker, or Hugging Face) with AgentAvow. Returns one of three answers with its reason (Safe to connect, Review before you connect, or Do not connect), a 0-100 trust score, an adoption score from real usage (downloads per week), findings with remediation, and a signed attestation. Also reports published advisories that affect the scanned version, the maintainer's deprecation notice, repo-vs-artifact drift (files shipped that aren't in the source), and AgentAvow's behavioral sandbox results when available. Scans the latest version unless version (or a pin in the name) names one. Read-only; calls agentavow.com.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name, e.g. 'chalk' (or 'org/model' for hf). | |
| force | No | Re-scan now instead of returning the cached verdict (results cache ~1h). Use after a new version ships. | |
| surface | No | Alias for registry. | |
| version | No | Exact version to scan, e.g. '5.3.0'. Optional: the latest version by default. A pin in the name ('chalk@5.3.0', 'requests==2.32.5') works too. | |
| registry | No | Package registry: npm, pypi, crates, docker, or hf. | |
| ecosystem | No | Alias for registry. |
| Name | Required | Description |
|---|---|---|
| high | No | High findings, static and sandbox. |
| tier | No | Trust tier for the score (detail, not the headline). |
| cached | No | Served from the ~1h cache. |
| signed | No | True when a signed (Ed25519/JWS) attestation backs this. |
| target | Yes | What was scanned, as given. |
| install | No | Install command, only when nothing blocks it. |
| sandbox | No | What the behavioral sandbox observed; null if it does not apply. |
| verdict | Yes | Binary form of the decision, kept for older clients. |
| adoption | No | The adoption score: real usage (downloads per week, stars or installs). Never changes the decision. |
| critical | No | Critical findings, static and sandbox. |
| decision | Yes | The answer to lead with: safe = Safe to connect, review = Review before you connect, do_not_connect = Do not connect. |
| incident | No | Known past compromise (context only, never scored). |
| certified | No | Matches the signed attestation's certified.eligible. |
| subscores | No | Per-category 0-100 scores behind the trust score. |
| deprecated | No | The maintainer's deprecation notice, or null. |
| report_url | Yes | Full report page. |
| scanned_at | No | When the scan ran (ISO 8601, UTC). |
| verify_url | No | How to verify offline. |
| not_checked | No | Plain-English notes for what the scan could not read or check (empty when it read everything). Say these alongside the answer. |
| target_type | Yes | github, npm, pypi, crates, docker, hf, or mcp. |
| trust_score | Yes | Trust score, 0-100. Evidence under the decision. |
| published_at | No | When that version was published. |
| top_findings | No | Up to five most important findings. |
| coverage_gaps | No | Machine form of not_checked: gap kinds (e.g. tool_list_paged, oversized_files) with a flag or count. Empty when nothing was skipped. |
| certified_mark | No | Certified and safe: show the Certified mark. |
| decision_final | Yes | False while the behavioral sandbox is still running; the decision can still change. |
| findings_total | No | All findings, every severity. |
| rescan_pending | No | A fresh scan was started; this is the previous result. |
| verdict_reason | No | Machine reason for the binary verdict, e.g. clean, clean_partial (clean, but not everything was read), blocking_findings, thin_coverage. |
| decision_reason | Yes | One sentence naming what decided it. |
| package_version | No | Package version scanned. |
| report_json_url | No | The full verdict as JSON. |
| static_findings_total | No | Findings from static analysis only. |
| advisories_affecting_version | No | Published advisories that affect this version. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations: discloses that it makes a network call to agentavow.com, that results are cached (~1h) with a force override, the shape of the verdict space (three named answers with reasons), trust/adoption scoring basis (downloads per week), and extras like advisories, deprecation notices, repo-vs-artifact drift, and sandbox results. Annotations already cover safety; the description adds real operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and ecosystems, then layered detail; every clause is on-topic. The return-value enumeration is somewhat long given an output schema already exists, but it functions as a quick expectation-set for the agent rather than pure 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?
Covers scope, external dependency, caching, and default version resolution, which is what an agent needs to invoke it correctly. Since an output schema exists, the described return fields are a bonus rather than a necessity, and the only real gap is sibling routing guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description earns an increment by explaining the default version behavior and that a pin can be embedded in the name ('chalk@5.3.0', 'requests==2.32.5'). It does not explain the registry/surface/ecosystem aliasing, which the schema carries on its own.
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 ("scan a published package") and enumerates the exact ecosystems covered (npm, PyPI, crates, Docker, Hugging Face), which implicitly separates it from scan_repo (source repos) and scan_mcp_server. It never names those siblings explicitly, so the boundary is inferred rather than stated.
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 by the outcome language (connect/do-not-connect verdicts) and by "Scans the latest version unless `version` (or a pin in the name) names one," plus the cache note from the schema. There is no explicit when-to-use-this-vs-scan_repo-or-scan_mcp_server guidance, so the agent must infer which scan tool to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a public GitHub repository with AgentAvow and return whether it is safe for an agent to connect to: one of three answers with its reason (Safe to connect, Review before you connect, or Do not connect), a 0-100 trust score, an adoption score from real usage (stars), the findings behind it (with where and how to fix), and a signed, offline-verifiable attestation. Read-only, no account. Calls the AgentAvow public API at agentavow.com.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Repo as 'owner/name' (e.g. 'vercel/next.js'), or just the name when 'owner' is given separately. | |
| force | No | Re-scan now instead of returning the cached verdict (results cache ~1h). Use after the target has changed. | |
| owner | No | Repo owner (optional if 'repo' is already 'owner/name'). |
| Name | Required | Description |
|---|---|---|
| high | No | High findings, static and sandbox. |
| tier | No | Trust tier for the score (detail, not the headline). |
| cached | No | Served from the ~1h cache. |
| signed | No | True when a signed (Ed25519/JWS) attestation backs this. |
| target | Yes | What was scanned, as given. |
| install | No | Install command, only when nothing blocks it. |
| sandbox | No | What the behavioral sandbox observed; null if it does not apply. |
| verdict | Yes | Binary form of the decision, kept for older clients. |
| adoption | No | The adoption score: real usage (downloads per week, stars or installs). Never changes the decision. |
| critical | No | Critical findings, static and sandbox. |
| decision | Yes | The answer to lead with: safe = Safe to connect, review = Review before you connect, do_not_connect = Do not connect. |
| incident | No | Known past compromise (context only, never scored). |
| certified | No | Matches the signed attestation's certified.eligible. |
| subscores | No | Per-category 0-100 scores behind the trust score. |
| deprecated | No | The maintainer's deprecation notice, or null. |
| report_url | Yes | Full report page. |
| scanned_at | No | When the scan ran (ISO 8601, UTC). |
| verify_url | No | How to verify offline. |
| not_checked | No | Plain-English notes for what the scan could not read or check (empty when it read everything). Say these alongside the answer. |
| target_type | Yes | github, npm, pypi, crates, docker, hf, or mcp. |
| trust_score | Yes | Trust score, 0-100. Evidence under the decision. |
| published_at | No | When that version was published. |
| top_findings | No | Up to five most important findings. |
| coverage_gaps | No | Machine form of not_checked: gap kinds (e.g. tool_list_paged, oversized_files) with a flag or count. Empty when nothing was skipped. |
| certified_mark | No | Certified and safe: show the Certified mark. |
| decision_final | Yes | False while the behavioral sandbox is still running; the decision can still change. |
| findings_total | No | All findings, every severity. |
| rescan_pending | No | A fresh scan was started; this is the previous result. |
| verdict_reason | No | Machine reason for the binary verdict, e.g. clean, clean_partial (clean, but not everything was read), blocking_findings, thin_coverage. |
| decision_reason | Yes | One sentence naming what decided it. |
| package_version | No | Package version scanned. |
| report_json_url | No | The full verdict as JSON. |
| static_findings_total | No | Findings from static analysis only. |
| advisories_affecting_version | No | Published advisories that affect this version. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, and open-world behavior. The description adds genuine context beyond them: no account/authentication required, results are cached (~1h, per the force param), and it calls the external AgentAvow public API at agentavow.com. It stops short of noting rate limits or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first clause and the rest is supporting detail in a tight two-sentence block. The enumeration of return values is somewhat redundant with the output schema, slightly diluting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With rich annotations, full schema coverage, and an output schema, the description covers what the agent needs: what is scanned, what comes back conceptually, no auth, and the external API dependency. Nothing essential is missing, though caching is only documented in the schema rather than the description.
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 100%, so the meaning of repo, owner, and force is already fully documented in the schema, including the cache behavior and the 'owner/name' format. The description adds nothing parameter-specific, which is the expected baseline when the schema does the work.
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 ('Scan a public GitHub repository') plus the exact decision it produces ('safe for an agent to connect to') and the three possible verdicts. The resource (GitHub repo) is naturally distinguished from siblings that scan MCP servers or packages.
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?
Clear context for use: you want a safety verdict on a repo before connecting an agent, and it works without an account. It does not explicitly name when to prefer siblings like scan_mcp_server, scan_package, or verify_trust, so the routing is implied by resource rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an AgentAvow entity's trust score. Returns trust_score (0-1), trust_score_pct (0-100), trust_tier, and whether it meets a minimum threshold. Read-only, no auth. Use before interacting with an unknown agent.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | UUID of a registered AgentAvow entity (resolve one with lookup_identity; unknown ids return guidance, not an error). | |
| min_trust | No | Min score, 0-1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent/non-destructive behavior. The description adds value by stating 'Read-only, no auth' and 'unknown ids return guidance, not an error,' which are not in annotations. It also specifies the exact return shape, aiding agent expectations.
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?
Four short sentences with no redundancy. Purpose is front-loaded, followed by return values, safety, and usage. Every clause earns its place.
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 compensating by listing trust_score, trust_score_pct, trust_tier, and threshold result is valuable. Combined with annotations covering safety and schema covering inputs, the agent has everything needed to call this tool 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 coverage is 100%: both entity_id and min_trust have descriptions, so baseline is 3. The description adds a minor cue that min_trust is a threshold ('whether it meets a minimum threshold'), but this is already inferable from the schema's 'Min score, 0-1.'
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: 'Verify an AgentAvow entity's trust score' and enumerates the return fields, making the core function unambiguous. It does not explicitly differentiate from the sibling get_trust_badge, so it stops short of a full 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?
It gives a clear use case: 'Use before interacting with an unknown agent,' and the entity_id schema hints to resolve via lookup_identity. However, it does not state when not to use this tool or mention alternatives like check_interaction_safety or get_trust_badge.
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.
scan_mcp_server3 fields changedOutput schema / properties / coverage_gapsAdded value: +{
+ "description": "Machine form of not_checked: gap kinds (e.g. tool_list_paged, oversized_files) with a flag or count. Empty when nothing was skipped.",
+ "type": "object"
+}Output schema / properties / not_checkedAdded value: +{
+ "description": "Plain-English notes for what the scan could not read or check (empty when it read everything). Say these alongside the answer.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / verdict_reason / descriptionPrevious value: -"Machine reason for the binary verdict, e.g. clean, blocking_findings, thin_coverage."New value: +"Machine reason for the binary verdict, e.g. clean, clean_partial (clean, but not everything was read), blocking_findings, thin_coverage."scan_package3 fields changedOutput schema / properties / coverage_gapsAdded value: +{
+ "description": "Machine form of not_checked: gap kinds (e.g. tool_list_paged, oversized_files) with a flag or count. Empty when nothing was skipped.",
+ "type": "object"
+}Output schema / properties / not_checkedAdded value: +{
+ "description": "Plain-English notes for what the scan could not read or check (empty when it read everything). Say these alongside the answer.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / verdict_reason / descriptionPrevious value: -"Machine reason for the binary verdict, e.g. clean, blocking_findings, thin_coverage."New value: +"Machine reason for the binary verdict, e.g. clean, clean_partial (clean, but not everything was read), blocking_findings, thin_coverage."scan_repo3 fields changedOutput schema / properties / coverage_gapsAdded value: +{
+ "description": "Machine form of not_checked: gap kinds (e.g. tool_list_paged, oversized_files) with a flag or count. Empty when nothing was skipped.",
+ "type": "object"
+}Output schema / properties / not_checkedAdded value: +{
+ "description": "Plain-English notes for what the scan could not read or check (empty when it read everything). Say these alongside the answer.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / verdict_reason / descriptionPrevious value: -"Machine reason for the binary verdict, e.g. clean, blocking_findings, thin_coverage."New value: +"Machine reason for the binary verdict, e.g. clean, clean_partial (clean, but not everything was read), blocking_findings, thin_coverage."scan_mcp_server1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "adoption": {
+ "description": "The adoption score: real usage (downloads per week, stars or installs). Never changes the decision.",
+ "properties": {
+ "count": {
+ "type": "integer"
+ },
+ "score_0_100": {
+ "type": "integer"
+ },
+ "unit": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "advisories_affecting_version": {
+ "description": "Published advisories that affect this version.",
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "cached": {
+ "description": "Served from the ~1h cache.",
+ "type": "boolean"
+ },
+ "certified": {
+ "description": "Matches the signed attestation's certified.eligible.",
+ "type": "boolean"
+ },
+ "certified_mark": {
+ "description": "Certified and safe: show the Certified mark.",
+ "type": "boolean"
+ },
+ "critical": {
+ "description": "Critical findings, static and sandbox.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "decision": {
+ "description": "The answer to lead with: safe = Safe to connect, review = Review before you connect, do_not_connect = Do not connect.",
+ "enum": [
+ "safe",
+ "review",
+ "do_not_connect"
+ ],
+ "type": "string"
+ },
+ "decision_final": {
+ "description": "False while the behavioral sandbox is still running; the decision can still change.",
+ "type": "boolean"
+ },
+ "decision_reason": {
+ "description": "One sentence naming what decided it.",
+ "type": "string"
+ },
+ "deprecated": {
+ "description": "The maintainer's deprecation notice, or null.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "findings_total": {
+ "description": "All findings, every severity.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "high": {
+ "description": "High findings, static and sandbox.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "incident": {
+ "description": "Known past compromise (context only, never scored).",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "install": {
+ "description": "Install command, only when nothing blocks it.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "package_version": {
+ "description": "Package version scanned.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "published_at": {
+ "description": "When that version was published.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "report_json_url": {
+ "description": "The full verdict as JSON.",
+ "type": "string"
+ },
+ "report_url": {
+ "description": "Full report page.",
+ "type": "string"
+ },
+ "rescan_pending": {
+ "description": "A fresh scan was started; this is the previous result.",
+ "type": "boolean"
+ },
+ "sandbox": {
+ "description": "What the behavioral sandbox observed; null if it does not apply.",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "scanned_at": {
+ "description": "When the scan ran (ISO 8601, UTC).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "signed": {
+ "description": "True when a signed (Ed25519/JWS) attestation backs this.",
+ "type": "boolean"
+ },
+ "static_findings_total": {
+ "description": "Findings from static analysis only.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "subscores": {
+ "additionalProperties": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "description": "Per-category 0-100 scores behind the trust score.",
+ "type": "object"
+ },
+ "target": {
+ "description": "What was scanned, as given.",
+ "type": "string"
+ },
+ "target_type": {
+ "description": "github, npm, pypi, crates, docker, hf, or mcp.",
+ "type": "string"
+ },
+ "tier": {
+ "description": "Trust tier for the score (detail, not the headline).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "top_findings": {
+ "description": "Up to five most important findings.",
+ "items": {
+ "properties": {
+ "count": {
+ "description": "How many times it occurs.",
+ "type": "integer"
+ },
+ "remediation": {
+ "description": "How to fix it.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "severity": {
+ "description": "critical, high, medium, or low.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "what": {
+ "description": "What was found.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "where": {
+ "description": "File and line, if file-based.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "trust_score": {
+ "description": "Trust score, 0-100. Evidence under the decision.",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "verdict": {
+ "description": "Binary form of the decision, kept for older clients.",
+ "enum": [
+ "safe",
+ "needs_review"
+ ],
+ "type": "string"
+ },
+ "verdict_reason": {
+ "description": "Machine reason for the binary verdict, e.g. clean, blocking_findings, thin_coverage.",
+ "type": "string"
+ },
+ "verify_url": {
+ "description": "How to verify offline.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "target",
+ "target_type",
+ "decision",
+ "decision_final",
+ "decision_reason",
+ "trust_score",
+ "verdict",
+ "report_url"
+ ],
+ "type": "object"
+}scan_package2 fields changedInput schema / properties / versionAdded value: +{
+ "description": "Exact version to scan, e.g. '5.3.0'. Optional: the latest version by default. A pin in the name ('chalk@5.3.0', 'requests==2.32.5') works too.",
+ "maxLength": 64,
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "adoption": {
+ "description": "The adoption score: real usage (downloads per week, stars or installs). Never changes the decision.",
+ "properties": {
+ "count": {
+ "type": "integer"
+ },
+ "score_0_100": {
+ "type": "integer"
+ },
+ "unit": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "advisories_affecting_version": {
+ "description": "Published advisories that affect this version.",
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "cached": {
+ "description": "Served from the ~1h cache.",
+ "type": "boolean"
+ },
+ "certified": {
+ "description": "Matches the signed attestation's certified.eligible.",
+ "type": "boolean"
+ },
+ "certified_mark": {
+ "description": "Certified and safe: show the Certified mark.",
+ "type": "boolean"
+ },
+ "critical": {
+ "description": "Critical findings, static and sandbox.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "decision": {
+ "description": "The answer to lead with: safe = Safe to connect, review = Review before you connect, do_not_connect = Do not connect.",
+ "enum": [
+ "safe",
+ "review",
+ "do_not_connect"
+ ],
+ "type": "string"
+ },
+ "decision_final": {
+ "description": "False while the behavioral sandbox is still running; the decision can still change.",
+ "type": "boolean"
+ },
+ "decision_reason": {
+ "description": "One sentence naming what decided it.",
+ "type": "string"
+ },
+ "deprecated": {
+ "description": "The maintainer's deprecation notice, or null.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "findings_total": {
+ "description": "All findings, every severity.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "high": {
+ "description": "High findings, static and sandbox.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "incident": {
+ "description": "Known past compromise (context only, never scored).",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "install": {
+ "description": "Install command, only when nothing blocks it.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "package_version": {
+ "description": "Package version scanned.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "published_at": {
+ "description": "When that version was published.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "report_json_url": {
+ "description": "The full verdict as JSON.",
+ "type": "string"
+ },
+ "report_url": {
+ "description": "Full report page.",
+ "type": "string"
+ },
+ "rescan_pending": {
+ "description": "A fresh scan was started; this is the previous result.",
+ "type": "boolean"
+ },
+ "sandbox": {
+ "description": "What the behavioral sandbox observed; null if it does not apply.",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "scanned_at": {
+ "description": "When the scan ran (ISO 8601, UTC).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "signed": {
+ "description": "True when a signed (Ed25519/JWS) attestation backs this.",
+ "type": "boolean"
+ },
+ "static_findings_total": {
+ "description": "Findings from static analysis only.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "subscores": {
+ "additionalProperties": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "description": "Per-category 0-100 scores behind the trust score.",
+ "type": "object"
+ },
+ "target": {
+ "description": "What was scanned, as given.",
+ "type": "string"
+ },
+ "target_type": {
+ "description": "github, npm, pypi, crates, docker, hf, or mcp.",
+ "type": "string"
+ },
+ "tier": {
+ "description": "Trust tier for the score (detail, not the headline).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "top_findings": {
+ "description": "Up to five most important findings.",
+ "items": {
+ "properties": {
+ "count": {
+ "description": "How many times it occurs.",
+ "type": "integer"
+ },
+ "remediation": {
+ "description": "How to fix it.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "severity": {
+ "description": "critical, high, medium, or low.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "what": {
+ "description": "What was found.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "where": {
+ "description": "File and line, if file-based.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "trust_score": {
+ "description": "Trust score, 0-100. Evidence under the decision.",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "verdict": {
+ "description": "Binary form of the decision, kept for older clients.",
+ "enum": [
+ "safe",
+ "needs_review"
+ ],
+ "type": "string"
+ },
+ "verdict_reason": {
+ "description": "Machine reason for the binary verdict, e.g. clean, blocking_findings, thin_coverage.",
+ "type": "string"
+ },
+ "verify_url": {
+ "description": "How to verify offline.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "target",
+ "target_type",
+ "decision",
+ "decision_final",
+ "decision_reason",
+ "trust_score",
+ "verdict",
+ "report_url"
+ ],
+ "type": "object"
+}scan_repo1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "adoption": {
+ "description": "The adoption score: real usage (downloads per week, stars or installs). Never changes the decision.",
+ "properties": {
+ "count": {
+ "type": "integer"
+ },
+ "score_0_100": {
+ "type": "integer"
+ },
+ "unit": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "advisories_affecting_version": {
+ "description": "Published advisories that affect this version.",
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "cached": {
+ "description": "Served from the ~1h cache.",
+ "type": "boolean"
+ },
+ "certified": {
+ "description": "Matches the signed attestation's certified.eligible.",
+ "type": "boolean"
+ },
+ "certified_mark": {
+ "description": "Certified and safe: show the Certified mark.",
+ "type": "boolean"
+ },
+ "critical": {
+ "description": "Critical findings, static and sandbox.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "decision": {
+ "description": "The answer to lead with: safe = Safe to connect, review = Review before you connect, do_not_connect = Do not connect.",
+ "enum": [
+ "safe",
+ "review",
+ "do_not_connect"
+ ],
+ "type": "string"
+ },
+ "decision_final": {
+ "description": "False while the behavioral sandbox is still running; the decision can still change.",
+ "type": "boolean"
+ },
+ "decision_reason": {
+ "description": "One sentence naming what decided it.",
+ "type": "string"
+ },
+ "deprecated": {
+ "description": "The maintainer's deprecation notice, or null.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "findings_total": {
+ "description": "All findings, every severity.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "high": {
+ "description": "High findings, static and sandbox.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "incident": {
+ "description": "Known past compromise (context only, never scored).",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "install": {
+ "description": "Install command, only when nothing blocks it.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "package_version": {
+ "description": "Package version scanned.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "published_at": {
+ "description": "When that version was published.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "report_json_url": {
+ "description": "The full verdict as JSON.",
+ "type": "string"
+ },
+ "report_url": {
+ "description": "Full report page.",
+ "type": "string"
+ },
+ "rescan_pending": {
+ "description": "A fresh scan was started; this is the previous result.",
+ "type": "boolean"
+ },
+ "sandbox": {
+ "description": "What the behavioral sandbox observed; null if it does not apply.",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "scanned_at": {
+ "description": "When the scan ran (ISO 8601, UTC).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "signed": {
+ "description": "True when a signed (Ed25519/JWS) attestation backs this.",
+ "type": "boolean"
+ },
+ "static_findings_total": {
+ "description": "Findings from static analysis only.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "subscores": {
+ "additionalProperties": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "description": "Per-category 0-100 scores behind the trust score.",
+ "type": "object"
+ },
+ "target": {
+ "description": "What was scanned, as given.",
+ "type": "string"
+ },
+ "target_type": {
+ "description": "github, npm, pypi, crates, docker, hf, or mcp.",
+ "type": "string"
+ },
+ "tier": {
+ "description": "Trust tier for the score (detail, not the headline).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "top_findings": {
+ "description": "Up to five most important findings.",
+ "items": {
+ "properties": {
+ "count": {
+ "description": "How many times it occurs.",
+ "type": "integer"
+ },
+ "remediation": {
+ "description": "How to fix it.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "severity": {
+ "description": "critical, high, medium, or low.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "what": {
+ "description": "What was found.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "where": {
+ "description": "File and line, if file-based.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "trust_score": {
+ "description": "Trust score, 0-100. Evidence under the decision.",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "verdict": {
+ "description": "Binary form of the decision, kept for older clients.",
+ "enum": [
+ "safe",
+ "needs_review"
+ ],
+ "type": "string"
+ },
+ "verdict_reason": {
+ "description": "Machine reason for the binary verdict, e.g. clean, blocking_findings, thin_coverage.",
+ "type": "string"
+ },
+ "verify_url": {
+ "description": "How to verify offline.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "target",
+ "target_type",
+ "decision",
+ "decision_final",
+ "decision_reason",
+ "trust_score",
+ "verdict",
+ "report_url"
+ ],
+ "type": "object"
+}about_agentavowcheck_interaction_safetyget_trust_badgelookup_identityscan_mcp_serverscan_packagescan_repoverify_trustSigned security scores for what an AI agent runs and reads: skills, MCP servers, prompts, tokens.
Runtime behavioral trust scoring for MCP servers. Check reliability before calling unknown tools.
Independent trust scores, tool surfaces and change history for MCP servers.
Decay-weighted reputation + tamper-evident trust attestations for the agent economy.
Add one secure layer between your agents and this server.
