F
licenseNot graded
qualityD
maintenanceEnables AI agents to query trust scores and security reviews for MCP servers before connecting, helping assess safety via a composite score and letter grade.
-
HVTracker MCP
Server Details
Pre-connect trust checks for AI agents and MCP servers using HVTracker's public trust registry.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 99.8% over 49 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- YugantM/hvtracker-mcp
- GitHub Stars
- 1
- Server Listing
- io.github.yugantm/hvtracker-mcp
TDQS
A4/5.0
Scored across 8 tools
Disambiguation4/5
Most tools have clearly distinct purposes: search, leaderboard, history, compare, bulk scan, categories. However, check_agent_trust (profile for tracked agent) and verify_mcp_server (pre-connect verdict for agent name) overlap when checking an agent, which could cause misselection.
Naming Consistency5/5
All tool names use consistent snake_case with clear verb_noun or verb_noun_noun patterns (check_agent_trust, compare_agents, get_agent_history, etc.). No mixing of conventions.
Tool Count5/5
Eight tools are well-scoped for a trust-tracking service, covering single lookup, comparison, history, search, leaderboard, categories, bulk scan, and pre-connect verification without redundancy.
Completeness5/5
The surface covers the key lifecycle of trust intelligence: searching, listing categories, ranking, getting profiles and history, comparing agents, verifying single items, and bulk scanning dependency sets. No obvious missing operation for a read-only trust database.
Available Tools
8 toolscheck_agent_trustCheck Agent TrustBRead-onlyIdempotentInspect
Get the HVTracker supply-chain trust profile for a tracked AI agent or framework.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name_or_repo | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| name | No | |
| rank | No | |
| repo | No | |
| query | Yes | |
| message | No | |
| tracked | Yes | |
| category | No | |
| advisories | No | |
| submit_url | No | |
| profile_url | No | |
| trust_score | No | |
| capabilities | No | |
| coverage_grade | No | |
| credential_url | No | |
| evidence_grade | No | |
| has_provenance | No | |
| scorecard_score | No |
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety and side-effect profile is fully covered by structured data. The description adds only the domain framing ('supply-chain trust profile'), which is useful but modest; it says nothing about lookup failures for untracked agents or result freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the core resource and scope come first and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return-value explanation is rightly omitted, and annotations cover the behavioral profile. What remains missing for a lookup tool is the disambiguation from sibling lookup tools and any note about untracked or unknown agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden, and it partially does so by indicating the parameter identifies a tracked AI agent or framework. However, the parameter is named name_or_repo while the description never mentions repository form, leaving the accepted syntax and any name-vs-repo ambiguity unresolved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and a specific resource ('HVTracker supply-chain trust profile') for a specific input type (tracked AI agent or framework). An agent can distinguish it from write-oriented siblings like scan_stack or verify_mcp_server, but nothing separates it from get_agent_history or search_agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the seven siblings, no mention of prerequisites, and no indication of what 'tracked' means or how an agent becomes tracked. The usage context is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_agentsCompare AgentsBRead-onlyIdempotentInspect
Compare two tracked AI agents side by side: trust scores, grades, runtime capabilities, and an evidence-based verdict.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| a | Yes | |
| b | Yes | |
| verdict | Yes | |
| compare_url | Yes |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds the comparison dimensions and that a verdict is returned, but does not disclose operational details like rate limits, authentication needs, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-structured sentence that front-loads the verb and resource, then lists the comparison outputs. Every element earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough for tool selection and, since an output schema exists, need not explain return values. However, it omits any parameter format guidance, which is necessary for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%: parameters 'a' and 'b' have no descriptions, and the tool description only implies they are the two agents to compare. It does not specify acceptable formats (e.g., IDs, names) or constraints, leaving a significant gap for invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (compare) and resource (two tracked AI agents), and enumerates what is compared: trust scores, grades, runtime capabilities, and an evidence-based verdict. This clearly distinguishes it from siblings like check_agent_trust (single agent) and get_leaderboard (list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says what the tool does but gives no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites. An agent must infer that it is appropriate when comparing exactly two agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_agent_historyGet Agent HistoryARead-onlyIdempotentInspect
90-day trust-score, grade, and rank history for one tracked agent — is it improving or declining?
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name_or_repo | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| name | No | |
| note | No | |
| repo | No | |
| slug | No | |
| count | No | |
| history | No | |
| message | No | |
| tracked | Yes | |
| window_days | No |
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the 90-day lookback window and the returned dimensions, which is useful context, but says nothing about what 'tracked agent' means or what happens for an untracked one.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero waste; the resource and window come first, the motivating question last.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return structure need not be explained. Combined with annotations covering safety, the description is nearly sufficient; only the identifier format and untracked-agent behavior are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with 0% schema description coverage, so the description must compensate. It clarifies the scope is 'one tracked agent', but gives no hint about the name_or_repo format (bare name vs. owner/repo) or how it maps to the identifier used by siblings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific resource (90-day trust-score, grade, and rank history) scoped to one agent, and frames the question it answers. An agent can distinguish it from check_agent_trust (current state) by the historical framing, but no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The trailing question 'is it improving or declining?' implies a trend-analysis use case, but there is no explicit when-to-use guidance, no prerequisites, and no routing to compare_agents or check_agent_trust for alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_leaderboardGet LeaderboardARead-onlyIdempotentInspect
Top tracked AI agents and MCP servers ranked by HVTrust score, optionally filtered to one category.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| category | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| results | Yes | |
| category | Yes |
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing safety. The description adds context about ranking metric (HVTrust score) and optional category filtering. However, it does not detail pagination, sorting direction, or data freshness, but these are less critical given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loading the key information (resource, ranking, optional filter). No redundant or extraneous text. Maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which documents return values), the description is largely complete for a simple leaderboard tool. It covers the essential behavior. Minor improvement could be to mention the limit default, but it is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It explains the 'category' parameter as optional filtering. The 'limit' parameter is only implied by 'top', but no explicit mention of its default (10) or meaning. The description partially compensates for missing schema descriptions but could be more precise.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a ranked leaderboard of AI agents and MCP servers by HVTrust score, optionally filtered by category. The verb 'get' is implied by the title, and the resource and purpose are unambiguous. This distinguishes it from siblings like search_agents and check_agent_trust.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. It does not mention when to avoid it, prerequisites, or how it compares to sibling tools. The context of sibling tool names is provided but not utilized in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesList CategoriesARead-onlyIdempotentInspect
List the HVTracker categories with agent counts, so you can then pull a category's leaderboard.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| categories | Yes |
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety and idempotency. The description adds only that it returns agent counts, providing minor extra context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 13 words, concise and front-loaded with action and context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0 parameters, clear annotations, and an output schema, the description sufficiently explains what the tool does and its typical use case, leaving no gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4 per guidelines. The description does not need to add parameter details, and it aligns with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Verb 'list' clearly identifies the action, resource is 'categories', and the description adds 'with agent counts', distinguishing it from sibling tools like get_leaderboard or search_agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the follow-up action ('so you can then pull a category's leaderboard'), guiding the agent to use it before get_leaderboard. Does not mention when not to use, but for a 0-param tool this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_stackScan StackARead-onlyIdempotentInspect
Bulk pre-connect trust check for a whole dependency set — paste a requirements.txt, package.json, MCP client config, or a plain list and get a trust verdict per item plus a stack summary.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| summary | Yes |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and no destructiveness. The description adds context: it's a 'pre-connect trust check' that returns 'trust verdicts', implying read-only and non-destructive behavior. It does not contradict annotations and provides additional behavioral insight beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, tightly packed with essential information: action, input formats, and output summary. No extraneous words, front-loaded, and every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema (indicated), the description covers input flexibility and output. It could be more explicit about the verdict format, but overall it is sufficiently complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining the single parameter 'input' accepts various dependency list formats (requirements.txt, package.json, etc.) and describes the output structure. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (bulk pre-connect trust check), the resource (dependency set/stack), and the output (trust verdict per item + summary). It provides specific input format examples, distinguishing it from sibling tools like 'check_agent_trust'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool (bulk pre-connect trust checks for dependency sets) and lists input formats (requirements.txt, package.json, etc.). However, it does not explicitly state when not to use or provide direct comparisons to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_agentsSearch AgentsARead-onlyIdempotentInspect
Search tracked AI agents and frameworks by name, repo, description, or category, ranked by trust score.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| category | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| results | Yes |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, idempotent, non-destructive. Description adds that results are ranked by trust score, which is valuable beyond annotations. More details on search behavior (e.g., case sensitivity) could improve this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with core purpose, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description covers the input purpose and ranking well. It could mention optionality of parameters and pagination via limit, but overall sufficient for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates by listing searchable fields (name, repo, description, category). However, it does not detail the 'limit' parameter or explain that all parameters are optional. The description adds some meaning but is not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches agents and frameworks by multiple criteria (name, repo, description, category) and results are ranked by trust score. It distinguishes from siblings like check_agent_trust or compare_agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching and ranking agents, but does not explicitly state when not to use or suggest alternatives. However, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_mcp_serverVerify MCP ServerARead-onlyIdempotentInspect
Pre-connect trust verdict for an MCP server, package, GitHub repo, or agent name before connecting an AI agent to it.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| server | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| slug | No | |
| grade | Yes | |
| server | Yes | |
| reasons | Yes | |
| tracked | Yes | |
| trusted | Yes | |
| resolved | Yes | |
| advisories | No | |
| confidence | Yes | |
| submit_url | No | |
| trust_score | Yes | |
| tool_permissions | Yes | |
| mcp_server_support | Yes |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, open-world behavior. The description adds the pre-connect verification context but does not disclose what the trust verdict includes, any rate limits, or authentication requirements beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no redundant phrasing. It packs purpose, input domain, and timing into one compact statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return details need not be in the description, and annotations cover safety. However, the description does not resolve overlap with check_agent_trust or explain accepted input formats, leaving gaps for a verification tool with one required parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the single 'server' parameter has no schema description. The description partially compensates by saying the tool accepts an MCP server, package, GitHub repo, or agent name, but it gives no format examples or disambiguation for those input types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear purpose: produce a pre-connect trust verdict for an MCP server, package, GitHub repo, or agent name. It identifies the resource domain well but does not differentiate from sibling check_agent_trust, especially since 'agent name' is in scope here.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied timing ('before connecting an AI agent to it'), which signals when to use it. However, it does not name alternatives or exclusions, so an agent must infer whether check_agent_trust or scan_stack is preferable in overlapping cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
- Changed
check_agent_trust16 fields changed- added
Output schema / $defs / AdvisorySummaryAdded value: +{ + "properties": { + "advisories": { + "items": { + "additionalProperties": true, + "type": "object" + }, + "title": "Advisories", + "type": "array" + }, + "checked": { + "items": { + "type": "string" + }, + "title": "Checked", + "type": "array" + }, + "count": { + "title": "Count", + "type": "integer" + }, + "scored": { + "title": "Scored", + "type": "boolean" + }, + "worst": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "title": "Worst" + } + }, + "required": [ + "checked", + "count", + "worst", + "advisories", + "scored" + ], + "title": "AdvisorySummary", + "type": "object" +} - added
Output schema / properties / advisoriesAdded value: +{ + "anyOf": [ + { + "$ref": "#/$defs/AdvisorySummary" + }, + { + "type": "null" + } + ] +} - removed
Output schema / properties / capabilities / defaultRemoved value: -null - removed
Output schema / properties / category / defaultRemoved value: -null - removed
Output schema / properties / coverage_grade / defaultRemoved value: -null - removed
Output schema / properties / credential_url / defaultRemoved value: -null - removed
Output schema / properties / evidence_grade / defaultRemoved value: -null - removed
Output schema / properties / has_provenance / defaultRemoved value: -null - removed
Output schema / properties / message / defaultRemoved value: -null - removed
Output schema / properties / name / defaultRemoved value: -null - removed
Output schema / properties / profile_url / defaultRemoved value: -null - removed
Output schema / properties / rank / defaultRemoved value: -null - removed
Output schema / properties / repo / defaultRemoved value: -null - removed
Output schema / properties / scorecard_score / defaultRemoved value: -null - removed
Output schema / properties / submit_url / defaultRemoved value: -null - removed
Output schema / properties / trust_score / defaultRemoved value: -null
- Changed
compare_agents2 fields changed- added
Output schema / $defs / AdvisorySummaryAdded value: +{ + "properties": { + "advisories": { + "items": { + "additionalProperties": true, + "type": "object" + }, + "title": "Advisories", + "type": "array" + }, + "checked": { + "items": { + "type": "string" + }, + "title": "Checked", + "type": "array" + }, + "count": { + "title": "Count", + "type": "integer" + }, + "scored": { + "title": "Scored", + "type": "boolean" + }, + "worst": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "title": "Worst" + } + }, + "required": [ + "checked", + "count", + "worst", + "advisories", + "scored" + ], + "title": "AdvisorySummary", + "type": "object" +} - added
Output schema / $defs / CheckAgentTrustResult / properties / advisoriesAdded value: +{ + "anyOf": [ + { + "$ref": "#/$defs/AdvisorySummary" + }, + { + "type": "null" + } + ] +}
- Changed
get_agent_history8 fields changed- removed
Output schema / properties / count / defaultRemoved value: -null - removed
Output schema / properties / history / defaultRemoved value: -null - removed
Output schema / properties / message / defaultRemoved value: -null - removed
Output schema / properties / name / defaultRemoved value: -null - removed
Output schema / properties / note / defaultRemoved value: -null - removed
Output schema / properties / repo / defaultRemoved value: -null - removed
Output schema / properties / slug / defaultRemoved value: -null - removed
Output schema / properties / window_days / defaultRemoved value: -null
- Changed
verify_mcp_server4 fields changed- added
Output schema / $defsAdded value: +{ + "AdvisorySummary": { + "properties": { + "advisories": { + "items": { + "additionalProperties": true, + "type": "object" + }, + "title": "Advisories", + "type": "array" + }, + "checked": { + "items": { + "type": "string" + }, + "title": "Checked", + "type": "array" + }, + "count": { + "title": "Count", + "type": "integer" + }, + "scored": { + "title": "Scored", + "type": "boolean" + }, + "worst": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "title": "Worst" + } + }, + "required": [ + "checked", + "count", + "worst", + "advisories", + "scored" + ], + "title": "AdvisorySummary", + "type": "object" + } +} - added
Output schema / properties / advisoriesAdded value: +{ + "anyOf": [ + { + "$ref": "#/$defs/AdvisorySummary" + }, + { + "type": "null" + } + ] +} - removed
Output schema / properties / slug / defaultRemoved value: -null - removed
Output schema / properties / submit_url / defaultRemoved value: -null
4 tool updates
- Added
get_agent_history - Added
get_leaderboard - Added
list_categories - Added
scan_stack
2 tool updates
- Changed
check_agent_trust4 fields changed- added
Output schema / $defsAdded value: +{ + "Capabilities": { + "properties": { + "drift_status": { + "title": "Drift Status", + "type": "string" + }, + "mcp_status": { + "title": "Mcp Status", + "type": "string" + }, + "plugin_system": { + "title": "Plugin System", + "type": "string" + }, + "provider_count": { + "title": "Provider Count", + "type": "integer" + }, + "requires_api_keys": { + "title": "Requires Api Keys", + "type": "boolean" + } + }, + "required": [ + "mcp_status", + "provider_count", + "requires_api_keys", + "plugin_system", + "drift_status" + ], + "title": "Capabilities", + "type": "object" + } +} - added
Output schema / properties / capabilitiesAdded value: +{ + "anyOf": [ + { + "$ref": "#/$defs/Capabilities" + }, + { + "type": "null" + } + ], + "default": null +} - added
Output schema / properties / coverage_gradeAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Coverage Grade" +} - added
Output schema / properties / credential_urlAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Credential Url" +}
- Added
compare_agents
3 tool updates
- Changed
check_agent_trust1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "category": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Category" + }, + "evidence_grade": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Evidence Grade" + }, + "has_provenance": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Has Provenance" + }, + "message": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Message" + }, + "name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Name" + }, + "profile_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Profile Url" + }, + "query": { + "title": "Query", + "type": "string" + }, + "rank": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Rank" + }, + "repo": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Repo" + }, + "scorecard_score": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Scorecard Score" + }, + "submit_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Submit Url" + }, + "tracked": { + "title": "Tracked", + "type": "boolean" + }, + "trust_score": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Trust Score" + } + }, + "required": [ + "query", + "tracked" + ], + "title": "CheckAgentTrustResult", + "type": "object" +}
- Changed
search_agents1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$defs": { + "AgentSearchResult": { + "properties": { + "category": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "title": "Category" + }, + "evidence_grade": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "title": "Evidence Grade" + }, + "name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "title": "Name" + }, + "profile_url": { + "title": "Profile Url", + "type": "string" + }, + "repo": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "title": "Repo" + }, + "trust_score": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "title": "Trust Score" + } + }, + "required": [ + "name", + "repo", + "trust_score", + "evidence_grade", + "category", + "profile_url" + ], + "title": "AgentSearchResult", + "type": "object" + } + }, + "properties": { + "count": { + "title": "Count", + "type": "integer" + }, + "results": { + "items": { + "$ref": "#/$defs/AgentSearchResult" + }, + "title": "Results", + "type": "array" + } + }, + "required": [ + "count", + "results" + ], + "title": "SearchAgentsResult", + "type": "object" +}
- Changed
verify_mcp_server1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "confidence": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "title": "Confidence" + }, + "grade": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "title": "Grade" + }, + "mcp_server_support": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "title": "Mcp Server Support" + }, + "reasons": { + "items": { + "type": "string" + }, + "title": "Reasons", + "type": "array" + }, + "resolved": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "title": "Resolved" + }, + "server": { + "title": "Server", + "type": "string" + }, + "slug": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Slug" + }, + "submit_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Submit Url" + }, + "tool_permissions": { + "items": { + "type": "string" + }, + "title": "Tool Permissions", + "type": "array" + }, + "tracked": { + "title": "Tracked", + "type": "boolean" + }, + "trust_score": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "title": "Trust Score" + }, + "trusted": { + "title": "Trusted", + "type": "boolean" + } + }, + "required": [ + "server", + "resolved", + "tracked", + "trusted", + "grade", + "trust_score", + "confidence", + "reasons", + "mcp_server_support", + "tool_permissions" + ], + "title": "VerifyMcpServerResult", + "type": "object" +}
3 tool updates
- First observed
check_agent_trust - First observed
search_agents - First observed
verify_mcp_server
Related MCP Connectors
Trust checks for MCP servers: trust scores, tool-drift detection, signed diligence receipts. Free.
Trust verification for MCP servers. Check scores, scan for security issues, search 4,200+ servers.
Trust registry for agents: check_trust verdict A0-A4, signed fact passports, honest refusals.
Check an A2A agent before you delegate, or an MCP server's measured conduct. Free, no key.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceBehavioral trust scoring for MCP servers and AI agents. Live registry tracking 4,500+ servers with trust scores (0-100) based on interaction history, success rates, and latency2MIT
- AlicenseAqualityDmaintenanceMCP server for AI agent trust verification, enabling agents to verify identities, check trust scores, and build reputation across multiple blockchain and web platforms.1216 npm1MIT
- FlicenseNot gradedqualityBmaintenanceProvides trust infrastructure for AI agents by enabling reputation lookup, website trust scanning, and identity verification via MCP tools.1-
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.