Get step-by-step Standard Operating Procedure (SOP) guidance for common compliance processes. Available SOPs: KYC onboarding, FRR monthly return, complaint handling, STR filing. Returns detailed steps with responsible person, legal basis, and estimated time.
| Name | Required | Description | Default |
|---|---|---|---|
| process | Yes | Which SOP process to retrieve | |
| licence_type | No | Optional: licence type for context |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, which the description does not contradict. The description adds useful context that returned steps include responsible person, legal basis, and estimated time, but it does not disclose other behavioral aspects like response size, error conditions, or any rate limits. Given the annotations cover the safety profile, a mid-range score is appropriate.
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 long, front-loaded with the purpose, and includes a concise list of available SOPs. Every word earns its place; there is no redundant or filler content.
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 read-only tool with no output schema, the description explains the output content (steps with responsible person, legal basis, estimated time) and enumerates valid processes. It does not mention how licence_type might affect the response, but given the schema notes it as 'optional context', this is a minor gap.
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% for both parameters, but the description adds value by mapping enum values to human-readable process names and explaining what the returned steps contain (responsible person, legal basis, estimated time). This goes beyond the schema's minimal descriptions, providing practical context for selecting process values.
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 retrieves step-by-step SOP guidance for common compliance processes, listing the available SOPs (KYC onboarding, FRR monthly return, complaint handling, STR filing). This distinguishes it from siblings like compliance_check or risk_assessment by focusing on procedural guidance rather than assessment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need SOP guidance for the listed processes) but gives no explicit guidance on when not to use it or how it compares to alternatives like checklist_lookup or compliance_check. No exclusions are mentioned, leaving the boundary with sibling tools unclear.
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.
Most tools have clearly distinct purposes: querying regulations, searching enforcement, checking compliance health, assessing risk, getting SOPs, etc. However, checklist_lookup and query_regulation overlap somewhat in general regulatory questions, and compliance_check vs compliance_score could be confused, though descriptions help.
Tool names are all lowercase with underscores, but the pattern is inconsistent: some start with verbs (get_license_guide, query_regulation, search_enforcement), while others are noun-led (compliance_check, checklist_lookup, risk_assessment). This mixed convention reduces predictability.
10 tools is well-scoped for an SFC compliance assistant, covering a range of tasks from regulation lookup to risk assessment and enforcement search without being excessive. Each tool earns its place.
The tool surface covers the core domain lifecycle: regulatory knowledge, compliance checking, risk assessment, enforcement research, SOP guidance, license info, and updates. Minor gaps like direct form submission or detailed compliance item management exist, but the set is near complete for an advisory/analysis tool.