What the specification fixes, and what it leaves open
The field is optional. The specification says only that it is a space-separated string of tools pre-approved to run, that it is experimental, and that support may vary between agent implementations. Its example is Bash(git:*) Bash(jq:*) Read. How such a pattern is matched is not defined there, so a skill that relies on the field needs testing in each agent that loads it.
How Claude Code applies it
Claude Code treats the list as permission for the turn that invokes the skill. The grant clears when you send your next message, though the skill's text stays in context, and invoking the skill again reapplies it. It narrows nothing: every tool remains callable, and unlisted ones go through your permission settings as before. Removing tools while a skill is active takes a separate field, disallowed-tools.
Read it before running a repository's skills
Workspace trust does not gate the field. Claude Code applies a project skill's allowed-tools even in a -p run inside a folder that was never trusted, so a skill checked into a repository can grant itself broad tool access. The documentation advises reviewing that field before running Claude Code there. Organizations can make Claude Code ignore it in project and personal skills with allowManagedPermissionRulesOnly in managed settings.