Provides security trust scores and analysis for MCP servers and agent skills hosted on the npm registry, identifying risks like tool poisoning and data exfiltration.
Provides security trust scores and analysis for MCP servers and agent skills hosted on the Python Package Index (PyPI), identifying risks like tool poisoning and data exfiltration.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@vigile-mcp check the trust score for the fetch-mcp server"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Vigile AI Security — query trust scores for MCP servers and agent skills directly from your AI coding assistant.
Works with Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, and any MCP-compatible client.
Add to your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"vigile": {
"command": "npx",
"args": ["-y", "vigile-mcp"]
}
}
}claude mcp add --transport stdio vigile --scope user -- npx -y vigile-mcpOr add to your project's .mcp.json:
{
"vigile": {
"command": "npx",
"args": ["-y", "vigile-mcp"]
}
}Add to ~/.cursor/mcp.json:
{
"mcpServers": {
"vigile": {
"command": "npx",
"args": ["-y", "vigile-mcp"]
}
}
}Add to .vscode/mcp.json in your project:
{
"servers": {
"vigile": {
"command": "npx",
"args": ["-y", "vigile-mcp"]
}
}
}Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"vigile": {
"command": "npx",
"args": ["-y", "vigile-mcp"]
}
}
}npm install -g vigile-mcpThen replace "command": "npx", "args": ["-y", "vigile-mcp"] with "command": "vigile-mcp" in any config above.
Related MCP server: ZeroPath MCP Server
Vigile scans and scores MCP servers and agent skills for security issues like tool poisoning, data exfiltration, prompt injection, and supply chain attacks. This MCP server brings those trust scores into your AI workflow — so your coding assistant can check whether a tool is safe before using it.
Covers servers from npm, Smithery, PyPI, and other registries, plus agent skills from Claude Code, Cursor, OpenClaw/ClawHub, and more.
Tool | Description |
| Look up trust score for an MCP server by name or package |
| Look up trust score for an agent skill (claude.md, .cursorrules, OpenClaw skills, etc.) |
| Scan raw content from a claude.md, .cursorrules, skill.md, or similar file for security issues |
| Search the Vigile trust registry by keyword |
| Verify whether a skill uses location data safely and check for location-based attack patterns |
Once installed, your AI assistant can use these tools naturally:
"Check if @anthropic/mcp-server-filesystem is safe" "Scan this claude.md file for security issues" "Search for database MCP servers and show me their trust scores"
Vigile rates every server and skill on a 0-100 scale:
Score | Level | Meaning |
80-100 | Trusted | No significant issues found |
60-79 | Caution | Minor issues, review recommended |
40-59 | Risky | Notable security concerns |
0-39 | Dangerous | Critical issues, do not use |
By default, vigile-mcp uses the public Vigile registry (rate-limited). For higher limits, set your API key:
{
"mcpServers": {
"vigile": {
"command": "npx",
"args": ["-y", "vigile-mcp"],
"env": {
"VIGILE_API_KEY": "vgl_your_key_here"
}
}
}
}Get an API key at vigile.dev.
Tier | Scans/min | Monthly Quota |
Free (no key) | 10 | 50 |
Pro ($30/mo) | 60 | 1,000 |
Pro+ ($100/mo) | 300 | 5,000 |
Registry lookups (vigile_check_server, vigile_check_skill, vigile_search) do not count against your scan quota. Only vigile_scan_content consumes scans.
Node.js 18+
An MCP-compatible client
THIS SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. Vigile AI Security provides security scanning and trust scoring as informational tools only. Trust scores, scan results, and security assessments are based on automated analysis and should not be considered definitive security guarantees.
Vigile does not guarantee the detection of all security threats, vulnerabilities, or malicious behavior. Users are solely responsible for their own security decisions and should use Vigile as one component of a comprehensive security strategy.
By using this software, you agree to the Vigile Terms of Service.
MIT
Fetch canonical provenance payload for a memory source ID.
| Name | Required | Description | Default |
|---|---|---|---|
| source_id | Yes | Canonical source identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states 'Fetch', implying a read-only operation, but fails to mention whether it is safe, idempotent, or has side effects. No disclosure of auth needs, error conditions, or payload characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description (7 words) is extremely concise and front-loaded with the key action and object. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 param, no nested objects, no output schema), the description is minimally adequate but lacks information about the return value, possible errors, or constraints like source_id format beyond schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage (source_id is described as 'Canonical source identifier'), the description adds no additional meaning. Per guidelines, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and clearly identifies the resource as 'canonical provenance payload' for a 'memory source ID'. It is distinct from sibling tools like vigile_check_server or vigile_recall, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or when not to use it. There are no mentions of prerequisites, exclusions, or context-specific recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the trust score and security findings for an MCP server in the Vigile registry. Returns trust score (0-100), trust level, findings summary, and a link to the full report.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | MCP server name or npm package name (e.g., '@anthropic/mcp-server-filesystem') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states a read-like operation returning data, but does not mention side effects, authentication needs, rate limits, or whether the registry query is live. Minimal transparency beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Purpose is front-loaded, returns are listed immediately. Efficient and scannable.
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 single-parameter lookup tool, the description covers purpose and output. However, it lacks usage guidelines, error conditions, and any context on when to use this versus sibling tools, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter with a description. The tool description adds no further detail about the parameter beyond the schema, resulting in baseline score per high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up trust score and security findings for an MCP server, specifying returned data (score, level, findings, link). It distinguishes from siblings like vigile_check_provenance and vigile_check_skill by focusing on trust and security for servers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives (e.g., vigile_check_provenance). No mention of prerequisites or scenarios where this tool is preferred, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the trust score for an agent skill (claude.md, .cursorrules, skill.md, etc.) in the Vigile registry. Returns trust score, trust level, findings summary.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Agent skill name (e.g., 'react-component-builder') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like read-only nature or side effects. It only states it returns data, but does not confirm it is a read operation or mention any potential errors or rate limits. This is insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that effectively communicates the action (look up) and the return values. There is no wasted text, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with one parameter and no output schema, the description provides the essential purpose and return structure. It lacks details on the trust scale or findings summary format, but is adequately complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the sole parameter 'name' with an example description. The tool description does not add additional semantic meaning beyond the schema, so the baseline score 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 clearly states the tool looks up the trust score for an agent skill, specifying examples like claude.md and .cursorrules. It mentions the return values (trust score, trust level, findings summary), distinguishing it from sibling tools like vigile_check_provenance that target other entities.
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 the tool is for checking trustworthiness of skill files, but it does not explicitly state when to use it versus alternatives like vigile_check_server or vigile_check_provenance. No exclusions or comparative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recall prior Vigile security memory context for an entity, pattern, or incident. Returns compact context, evidence chunks, and source references with provenance status.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Recall query, e.g. 'previous incident for inc_123' | |
| scope | No | Optional retrieval scope filters | |
| max_chunks | No | Maximum evidence chunks (default: 8) | |
| risk_level | No | Set to high for high-risk actions | |
| retrieval_mode | No | Experimental retrieval mode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral traits. It mentions return types but does not disclose whether the tool is read-only, idempotent, requires specific permissions, or has any side effects. This is insufficient for a tool that lacks annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and followed by return details. Every sentence adds necessary information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description provides a high-level overview of returns but lacks details on output structure, error handling, or behavioral constraints. It is adequate but not complete for safe agent usage.
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 schema already documents all parameters. The description adds no extra meaning beyond the schema, such as examples, dependencies, or formatting constraints. The baseline of 3 is appropriate given high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it recalls prior Vigile security memory context and specifies what is returned (compact context, evidence chunks, source references with provenance status). It effectively distinguishes from siblings like vigile_remember (store) or vigile_check_provenance (verify) by focusing on retrieval of past data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for recalling prior context but provides no explicit guidance on when to use this tool versus alternatives like vigile_search or vigile_timeline. It lacks instructions on when not to use it, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a bounded security memory episode for future recall (idempotent write path).
| Name | Required | Description | Default |
|---|---|---|---|
| event_type | Yes | Episode event type | |
| entity_id | No | Optional linked entity ID | |
| summary | No | Optional human summary | |
| adapter_type | No | ||
| sensitivity | No | ||
| payload | No | Structured payload (PII/secrets redacted by API policy) | |
| source_refs | No | ||
| idempotency_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses idempotency ('idempotent write path') and boundedness, but lacks details on side effects, authentication needs, rate limits, or what happens if an episode with the same idempotency_key already exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core action and a key behavior. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, nested objects, no output schema, and no annotations. The description is too brief to cover important usage context such as parameter semantics, return values, error handling, or prerequisites. A more detailed description is needed for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 50% description coverage (4 out of 8 parameters have descriptions). The tool description adds no parameter-specific information; it only provides general context. This does not compensate for the missing parameter descriptions 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 clearly states the tool's purpose: 'Record a bounded security memory episode for future recall', specifying a verb and resource. The phrase 'idempotent write path' distinguishes it from sibling tools like vigile_recall, which likely retrieves episodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use instructions are given. The sibling tool names and the description imply that vigile_remember is for recording while vigile_recall is for retrieval, but the description does not explicitly guide the agent on choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan the content of an agent skill file for security issues. Submit raw content from a claude.md, .cursorrules, skill.md, or similar file for analysis. Returns trust score and detailed findings.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The raw text content to scan (max 100KB) | |
| file_type | No | File type: skill.md, claude.md, cursorrules, mdc-rule (default: skill.md) | |
| name | No | Optional name for the scan result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It mentions no side effects, authentication needs, or whether content is stored/transmitted. It only describes the output, leaving safety and privacy implications unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no redundancy. Every piece of information is relevant and front-loaded. Efficiently communicates purpose and input format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high schema coverage, no output schema, and a straightforward task (scan content), the description provides sufficient context: what to submit, what it does, and what is returned. No gaps remain.
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%, with each parameter having a description. The tool description adds little beyond the schema, such as mentioning file types already covered in file_type's description. No additional meaning or constraints are introduced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('scan'), the resource ('content of an agent skill file'), and the purpose ('for security issues'). It provides concrete file type examples and states the output ('trust score and detailed findings'), effectively differentiating from sibling tools like vigile_check_skill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user has raw content to analyze, but it does not contrast with sibling tools (e.g., vs vigile_check_skill for existing skills) or specify when not to use it. Some guidance on prerequisites or alternatives is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Vigile registry for MCP servers and agent skills by keyword. Returns matching entries with trust scores. Use this when you need to find servers by description or capability.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g., 'filesystem', 'database', 'code execution') | |
| limit | No | Max results to return (default: 10, max: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions returning 'matching entries with trust scores' but does not disclose pagination, rate limits, or behavior for empty results. Adequate but could add more.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with front-loaded purpose and immediate usage guidance. Every word serves a purpose with no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only two parameters and no output schema, the description covers the main purpose and usage. However, it lacks details on result structure (e.g., how trust scores are presented), leaving some incompleteness for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both 'query' and 'limit'. The tool description adds no new semantic information beyond what the schema already provides. Baselines at 3 are 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 clearly states the tool searches the Vigile registry for MCP servers and agent skills by keyword, which is specific and differentiates it from sibling tools that check, recall, or verify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when you need to find servers by description or capability,' providing clear context. It doesn't mention when not to use it or alternatives, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a security timeline for an incident or topic from Vigile memory.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Topic selector for timeline lookup | |
| incident_id | No | Incident ID selector (preferred when known) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral traits. It only indicates a read operation ('fetch'), but lacks details on idempotency, authentication, rate limits, error handling, or behavior when both parameters are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. It is concise, though it could benefit from additional structure like bullet points or a note on parameter selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description is insufficient. It does not explain the return format, pagination, error scenarios, or how to choose between topic and incident_id. The sibling tools have diverse purposes, but the description does not help the agent decide when to use this specific tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters. The description only paraphrases the schema ('incident or topic') without adding extra meaning, such as specificity on format, interactions between parameters, or default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'security timeline for an incident or topic from Vigile memory'. It references the two parameters in the schema. However, it does not explicitly differentiate from sibling tools like vigile_search, which may also fetch security data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the siblings. It does not mention prerequisites, when not to use, or alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess location-related privacy and safety risks for AI agent interactions involving physical-world context (deliveries, meetups, financial transactions). Accepts an H3 cell index (preferred, privacy-preserving) or lat/lng coordinates with optional context. Returns risk level, score, factors, and recommendation. All assessment is performed locally — no location data is transmitted to Vigile servers.
| Name | Required | Description | Default |
|---|---|---|---|
| h3_cell | No | H3 cell index (15-character hex string, preferred for privacy over raw coordinates) | |
| latitude | No | Latitude (-90 to 90). Provide with longitude as an alternative to h3_cell. | |
| longitude | No | Longitude (-180 to 180). Provide with latitude as an alternative to h3_cell. | |
| context | No | Context of the interaction (e.g., 'delivery to home address', 'in-person meetup', 'financial transaction') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that all assessment is performed locally and no location data is transmitted, and describes return fields (risk level, score, factors, recommendation). This is good but could mention any logging or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The first sentence states purpose and context; the second covers inputs and key behavioral trait. Every sentence is essential and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations or output schema, the description is complete: it covers purpose, inputs with guidance, behavioral privacy assurance, and return values. No gaps for this simple risk assessment tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by noting H3 cell as 'preferred, privacy-preserving' and specifying that context is optional, improving upon the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'assess' and the resource 'location-related privacy and safety risks', specifying the context of use (deliveries, meetups, financial transactions). It effectively distinguishes from sibling tools like vigile_scan_content or vigile_check_provenance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (physical-world interactions) and gives guidance on input preference (H3 over lat/lng). However, it lacks explicit when-not-to-use or mention of alternative sibling tools.
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.
v0.1.7vigile_check_provenancevigile_recallvigile_remembervigile_timelinev0.1.8vigile_check_servervigile_check_skillvigile_scan_contentvigile_searchvigile_verify_locationScored across 9 tools
Each tool targets a distinct operation: checking provenance, server/skill trust, scanning content, searching, recall/remember memory, timeline, and location verification. No functional overlap.
All prefixed with 'vigile_' and mostly verb_noun (check_provenance, scan_content). A few single verbs (recall, remember, search) and one noun (timeline) break the pattern, but overall consistent.
9 tools cover a security registry and memory system well. Not excessive nor inadequate for the domain.
Covers key operations: reading trust info, scanning, searching, memory read/write, timeline. Missing explicit update/delete for memory, but search and recall allow discovery.
Signed security scores for what an AI agent runs and reads: skills, MCP servers, prompts, tokens.
Search, vet & assemble MCP servers from your agent: verified tools, risk labels, and trust scores.
Find, vet, and run MCP tools through a secure audited gateway with prompt-injection risk scoring
MCP-native Trust Infrastructure for AI Agents. Persistent encrypted memory with Trust Quotient.
