Tool Calling

v1.0.0

Deep workflow for LLM tool/function calling—schema design, validation, permissions, errors, idempotency, testing, and safe orchestration with agents. Use whe...

0· 206·0 current·0 all-time
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Benign
high confidence
Purpose & Capability
Name and description match the SKILL.md: the document is guidance for designing tool schemas, validation, authz, idempotency, errors, and testing. There are no binaries, env vars, or installs requested that would be unrelated to the stated purpose.
Instruction Scope
SKILL.md contains best-practice guidance and checklists only; it does not instruct the agent to read arbitrary files, access environment variables, download or transmit data to external endpoints, or perform system actions. It warns about risky patterns (raw SQL, shell, filesystem) rather than instructing their use.
Install Mechanism
No install spec and no code files — instruction-only. This minimizes on-disk footprint and execution risk.
Credentials
The skill declares no required environment variables, credentials, or config paths. The SKILL.md discusses carrying user-scoped credentials as a design topic but does not request any secrets or access itself.
Persistence & Privilege
Flags are default (always:false, model invocation allowed). The skill does not request permanent presence or to modify other skills or system settings.
Assessment
This skill is a safety-and-design playbook, not executable code—so installing it has minimal direct risk. Before you rely on it in production: (1) ensure any real tool implementations enforce server-side schema validation, authorization, and output filtering as the guide recommends (do not trust the model); (2) avoid giving the model direct filesystem, database, or credential access—use validated server-side adapters and least-privilege principals; (3) if you will allow autonomous agent invocation, pair that with strict allowlists, rate limits, and human approval for dangerous ops; (4) treat the checklist as a design spec to implement securely rather than as an instruction to expose sensitive systems to the model. If you want extra assurance, ask for the concrete tool implementation details you plan to use and have them reviewed for the specific risks (credential handling, logging, and sandboxing).

Like a lobster shell, security has layers — review code before you run it.

latestvk970ckt53wbb0b1p33cv9rphfx83ga3w

License

MIT-0
Free to use, modify, and redistribute. No attribution required.

Comments