What is VITNA and how do I use it to keep myself in check? Call this FIRST after connecting to learn the safety and oversight checks available: how to check risky actions BEFORE running them, what a deny / hold decision means, trial vs claimed mode, and how the user can monitor and audit what you do. Runs entirely locally: no account, no API call, and no dashboard timeline trace.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well by disclosing that it runs entirely locally with no account, no API call, and no dashboard timeline trace. It also previews the behavioral topics it covers (deny/hold decisions, trial vs claimed mode, monitoring). It could go further by describing output format, but the privacy and operational disclosures are valuable and non-generic.
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 moderately concise and front-loaded with the core question and 'Call this FIRST' instruction. The two sentences pack a lot of relevant information without excessive fluff, but the opening structure is slightly informal and could be more direct. Still, every sentence earns its place and the length is appropriate for onboarding guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema) and its role as a help/onboarding tool, the description is remarkably complete. It covers when to use it, what concepts it explains, and privacy characteristics. The provided context is sufficient for an agent to know exactly when and why to invoke this tool, and what to expect in terms of local execution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so schema coverage is complete with no argument semantics to explain. According to the rubric, the baseline for 0 params is 4. The description adds no parameter details, but none are needed; it focuses on the tool's purpose and usage, which is appropriate for a parameterless help tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is an onboarding/help assistant for VITNA, explaining that it should be called first to understand safety and oversight checks. It defines a specific role—teaching usage and monitoring—and distinguishes itself from sibling tools like vitna_preflight by positioning itself as the introductory helper.
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 'Call this FIRST after connecting,' providing a strong, actionable trigger for when to use the tool. It doesn't enumerate exclusions or alternatives, but the 'first' directive implies it should precede other compliance and validation tools, which is sufficient guidance for this help-focused tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.