vigo-mcp

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true; description adds valuable behavioral context about internal process (planning execution strategy, gathering from regulations/enforcement/knowledge graph, synthesizing report). Discloses data sources accessed. No contradiction with readOnly status.

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 with zero waste. Front-loaded with primary action ('Execute...autonomously'), followed by process explanation, then usage guidance. Every word 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 complex autonomous tool with 3 params and no output schema, description adequately covers execution behavior and output types (report synthesis). Could enhance by mentioning execution time expectations or async nature, but sufficient for invocation decision.

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 has 100% coverage with comprehensive descriptions (e.g., task example, output_format enum). Description mentions 'multi-step regulatory task' giving context to the task parameter, but given high schema coverage, the description appropriately focuses on behavior rather than repeating parameter details.

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 specific action (execute) with clear resource scope (complex multi-step regulatory task) and distinguishes from siblings via 'autonomously' and explicit contrast with single-step tools like checklist_lookup or query_regulation. Use cases provided (due diligence, compliance planning) further clarify scope.

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?

Provides clear when-to-use guidance via 'Use for due diligence, compliance planning...' and emphasizes 'multiple analysis steps' as threshold criteria. Lacks explicit when-NOT-to-use (e.g., 'don't use for simple lookups'), but implies complexity threshold sufficiently.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations confirm readOnlyHint=true; the description adds valuable behavioral context by detailing what the search returns beyond just 'results'—specifically compliance items with legal references, SOP guidance, case law, and grey area analysis, which helps the agent understand the tool's coverage and depth. 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?

Two tightly constructed sentences with zero waste—first describes the action and return payload, second specifies usage contexts. Front-loaded with the core operation and appropriately scoped for the parameter complexity.

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 lacking a formal output schema, the description comprehensively characterizes the return payload (compliance items, legal references, case law, grey area analysis). Combined with 100% schema parameter coverage and clear domain scope (SFC/MIC), the description provides sufficient context for tool selection.

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?

Though schema coverage is 100%, the description adds semantic value by noting specific searchable codes 'CF1-CF8' (MIC functions) and contextualizing the query parameter capability with concrete examples ('FRR月報提交', 'MIC CF7 duties') that clarify expected input formats beyond the schema's generic 'Search query' description.

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 opens with a specific verb ('Search') and resource ('SFC compliance checklist'), explicitly scopes the searchable dimensions ('topic, licence type, or MIC function'), and distinguishes from siblings like sop_guide and query_regulation by emphasizing the specific content returned (legal references, case law, grey area analysis).

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?

Provides clear positive guidance ('Use for questions about regulatory obligations, MIC responsibilities...') indicating appropriate contexts, but lacks explicit exclusions or named sibling alternatives (e.g., when to use sop_guide vs this tool).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, establishing the tool is non-destructive. The description adds value by disclosing the specific scope of the assessment (FRR capital, RO/MIC roles, annual obligations), which is behavioral context not present in annotations. However, it omits other traits like synchronous/asynchronous execution, caching behavior, or authentication requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description comprises two tightly constructed sentences. The first establishes the operation; the second details inputs, outputs, and specific coverage areas. Every clause serves a purpose with zero redundancy or boilerplate, achieving appropriate front-loading of critical information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 100% schema coverage and readOnly annotations, the description adequately compensates for the missing output schema by enumerating the five specific assessment areas returned (FRR, RO, MIC, obligations, focus areas). However, for a complex regulatory tool with six parameters, it could further clarify output format or error conditions.

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%, documenting all six parameters (aum, num_ros, has_vatp, num_staff, license_types, business_areas) individually. The description provides conceptual grouping ('Input company profile') but adds no syntax details, validation rules, or semantic relationships beyond the schema. Baseline score 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 'perform[s] a compliance health check' (specific verb + resource) for licensed corporations. It lists specific regulatory domains covered (FRR capital, RO configuration, MIC roles, annual obligations), which implicitly distinguishes it from the more generic sibling 'risk_assessment'. However, it lacks explicit differentiation from siblings like 'compliance_score'.

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 siblings such as 'risk_assessment', 'compliance_score', or 'checklist_lookup'. It states the procedural mechanism ('Input company profile, get...') but offers no contextual rules for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no output schema exists, description adds valuable disclosure of return structure ('total items, completed, overdue, and score percentage'). Also notes data source ('Portal system'). Complements readOnlyHint annotation without contradiction.

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 sentences with zero waste. Purpose front-loaded, followed by requirement, then return value. 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?

Appropriately complete for a simple single-parameter tool. Compensates for missing output schema by describing return fields. Could benefit from mentioning error cases or rate limits, but sufficient for tool selection.

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 'Company UUID from OrphicOne Portal' already documented. Description repeats 'Portal system' context but adds no syntactic details beyond schema. Baseline 3 appropriate for high-coverage 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?

Clear verb 'Calculate' with specific resource 'compliance health score' and scope 'for a company'. Mentions 'score percentage' which distinguishes from sibling 'compliance_check', though explicit differentiation guidance is absent.

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?

States prerequisite 'Requires company_id from the Portal system' implying when it can be used, but lacks explicit when-to-use guidance versus siblings like 'compliance_check' or 'risk_assessment', and no exclusions mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true (safe read operation), so safety is covered. Description adds valuable domain context by listing specific content categories (exam papers, capital requirements, etc.) that the guide covers, helping agents understand scope. Does not address return format, pagination, or data freshness.

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?

Single sentence, zero waste. Front-loaded with purpose ('Comprehensive guide'), followed immediately by scope specifics. Every phrase earns its place by conveying distinct information about content coverage.

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?

Adequate for a 2-parameter read-only tool, with aspect semantics well-covered. However, given no output schema exists, the description should ideally indicate the guide's format (structured data vs. narrative text vs. markdown) to set expectations for result handling.

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 50% schema coverage (license_type described, aspect not described), description compensates effectively by semantically mapping abstract enum values to domain concepts: 'exam papers' maps to 'exam' enum, 'capital requirements' to 'capital', 'fit-and-proper criteria' to 'fit_and_proper'. Adds substantial meaning for the aspect parameter.

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?

Clear verb-resource combination ('guide' for 'license type') and specific domain coverage (exam papers, capital requirements, fit-and-proper criteria, CPD hours). Lists concrete content areas but does not explicitly differentiate from similar sibling tools like 'sop_guide' or 'checklist_lookup'.

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 guidance on when to select this tool versus functionally similar siblings (e.g., 'sop_guide', 'checklist_lookup', 'query_regulation'). No mention of prerequisites or conditions where this tool is preferred over alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, confirming safe read operation, which aligns with the description's 'Get' verb. The description adds value by specifying the five document types returned, but omits behavioral details like time window for 'latest', pagination behavior, or result ordering.

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?

Single dense sentence with colon-separated list is efficient and front-loaded. No redundant text, though extreme brevity leaves gaps in usage guidance and parameter documentation that a second sentence could address.

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 two optional parameters and readOnlyHint coverage, the description adequately identifies the resource but lacks scope definition (time range for 'latest') and return value hints. Adequate but minimal for a tool with no output 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?

Schema coverage is 50% ('count' is described, 'category' is not). The description compensates partially by listing the content types that map to the category enum values (circular, enforcement, vatp, consultation), implicitly documenting the parameter's purpose, though it doesn't explain 'VATP' jargon or the 'all' default.

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?

Clear verb 'Get' and resource 'SFC regulatory updates' with specific content types enumerated (circulars, enforcement news, VATP developments, consultation papers). However, it does not explicitly differentiate from sibling 'search_enforcement' or 'query_regulation', leaving ambiguity about when to use which retrieval tool.

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 provided on when to use this temporal retrieval tool versus 'search_enforcement' or 'query_regulation'. No mention of prerequisites (e.g., whether 'SFC' context is required) or exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true. Description adds valuable behavioral context: specific knowledge domains covered (Type 1-13, virtual assets), bilingual support, and implied closed-world scope (Hong Kong SFC specific). 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?

Two efficiently structured sentences. First sentence front-loads the action and scope; second covers language support. No redundancy or wasted text despite covering multiple content domains.

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?

Appropriately complete for a read-only query tool. Domain coverage (SFC-specific abbreviations like VATP/ASPIRe, CPD/CPT) is well-specified. Absence of output schema explanation is acceptable per rules; description sufficiently establishes the knowledge base scope.

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 coverage, baseline is 3. Description adds concrete examples for license_type parameter ('Type 1', 'Type 9' implied via Type 1-13 range) and confirms language capabilities, enriching the raw schema definitions.

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?

Specific verb 'Query' with explicit resource 'Hong Kong SFC regulatory knowledge'. Distinguishes from siblings by enumerating specific coverage areas (Type 1-13 licenses, VATP/ASPIRe, AML/CFT) that differentiate it from search_enforcement or checklist_lookup.

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?

Provides implied usage through comprehensive topic enumeration (licensing, compliance, exams, CPD/CPT), allowing agents to infer when to use it. Lacks explicit 'when to use vs alternatives' guidance (e.g., distinguishing from get_license_guide or compliance_check).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, but description adds valuable output disclosure: specific rating format (Red/Yellow/Green), inclusion of regulatory basis, and recommended actions. This output specification is critical since no output schema is present, going beyond what structured 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficiently structured sentences: first establishes purpose, second documents return value. Zero redundancy, no filler, appropriately scoped for the tool's complexity.

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?

Explains return values (ratings, basis, actions) which compensates for missing output schema. Covers the three parameters adequately given 100% schema coverage. Sufficient for a read-only assessment tool, though could mention if assessment is saved/tracked.

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%, providing full documentation for description, urgency, and license_types. Description adds contextual framing ('planned business activity') that aligns parameters to the use case but does not add syntax, format constraints, or semantic details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb 'Assess' with specific resource 'compliance risk of a planned business activity'. Distinguishes from siblings by targeting planned/future activities vs existing compliance status, though it lacks explicit 'use this when X' differentiation from compliance_check or compliance_score.

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?

Implies usage context with 'planned business activity' suggesting use for future initiatives, but provides no explicit when-not-to-use guidance or named alternatives among siblings like compliance_check or query_regulation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, confirming safe read operation. Description adds valuable scope context (specific enforcement types: fines, suspensions, bans, prosecutions) not detailed in annotations. However, lacks details on result ordering, pagination, or data freshness that would fully leverage the annotation baseline.

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, zero waste. First sentence establishes domain and scope (enforcement action types), second sentence establishes search criteria. Front-loaded with specific entity types. No redundancy with title or annotations.

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?

Adequate for a 2-parameter search tool with 100% schema coverage and readOnlyHint. Description successfully conveys the domain (financial enforcement) and search capabilities. Minor gap: could mention if searches are exact match or fuzzy, but sufficient for tool selection.

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 has 100% description coverage (query and year fully documented). Description mirrors the parameter capabilities ('Search by company, person, or violation type') but does not add syntax details, format constraints, or examples beyond what the schema already provides. Baseline 3 appropriate for high schema 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?

Excellent specificity: verb 'Search' + resource 'SFC enforcement actions' with concrete examples (fines, suspensions, bans, prosecutions). Clearly distinguishes from siblings like compliance_check or query_regulation by focusing specifically on enforcement actions rather than general compliance or regulation text.

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?

Provides implied usage by listing searchable entities (company, person, violation type), but lacks explicit guidance on when to prefer this over compliance_check or risk_assessment siblings. No 'when not to use' or prerequisites mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint:true annotation confirms this is a safe read operation. The description adds valuable behavioral context by detailing the return structure ('detailed steps with responsible person, legal basis, and estimated time'), compensating for the missing output schema. It omits caching behavior, auth requirements, or rate limits.

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 consists of two highly efficient sentences. The first front-loads the action and enumerates available options; the second describes the return payload. There is no redundant or wasted information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a retrieval tool with full schema coverage and read-only annotations, the description is appropriately complete. It compensates for the missing output schema by describing the return structure, lists all valid inputs, and defines the tool's domain clearly.

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 coverage, the baseline is 3. The description adds significant value by translating the technical enum values (kyc_onboarding, frr_monthly) into business-readable terms ('KYC onboarding, FRR monthly return'), clarifying what each option represents beyond the schema's generic 'Which SOP process to retrieve'.

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 resource 'Standard Operating Procedure (SOP) guidance' and lists the four exact available processes (KYC onboarding, FRR monthly return, complaint handling, STR filing), which maps directly to the enum values. It lacks explicit differentiation from siblings like checklist_lookup or get_license_guide, preventing a 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?

The description provides implied usage context by enumerating the four specific SOPs available, clarifying the tool's scope. However, it lacks explicit guidance on when to use this tool versus alternatives like checklist_lookup or autonomous_task, and omits prerequisites or constraints.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.