What happened?
read_skill returns skill files verbatim, so the YAML front matter goes into the model's context along with the procedure.
Measured on the embedded skills on main:
| file |
total |
front matter |
body |
front matter |
SKILL.md |
796 |
87 |
709 |
10.9% |
detect-n-plus-one/SKILL.md |
1531 |
456 |
1075 |
29.8% |
error-root-cause/SKILL.md |
1425 |
421 |
1004 |
29.5% |
| total |
3752 |
964 |
2788 |
25.7% |
INSTRUCTIONS.md points the agent at SKILL.md first, so a skill-driven run reads the root plus at least one sub-skill. That is 508 bytes of front matter out of 2221 before any telemetry is fetched. Per #9290 everything read_skill returns goes on the wire about 2.1x, so it is paid twice.
What the block contains:
name and description, already used by the root catalog to route the agent herelicense, provenancemetadata, author and version, provenanceallowed-tools, declared but not read by any Go file
I grepped all 46 .go files under mcptools for yaml, frontmatter and allowed-tools. No matches. #8761 proposed a front matter parser during Term 2 and closed with no PR, so the shipped design serves the file raw. This is the cost of that choice rather than an oversight.
Expected behavior
The agent gets the procedure. The file on disk keeps its metadata for humans and tooling.
Two ways to do it:
- Strip the whole block in
read_skill. No YAML dependency, 26% smaller payload. Drops allowed-tools from what the model sees, which changes nothing today since nothing enforces it.
- Strip only
license and metadata. Keeps name, description and allowed-tools visible, saves about 70 bytes per file, needs a parser.
I went with option 1 in the linked PR because allowed-tools has no effect either way. Happy to switch if you would rather the model kept seeing it.
Separate question, probably its own issue: should allowed-tools constrain the tool surface server side, or stay advisory to the model?
Jaeger backend version
main (26c5612)
SDK
Not applicable, this is in the MCP handler layer.
Pipeline
Not applicable.
Stogage backend
Not applicable.
What happened?
read_skillreturns skill files verbatim, so the YAML front matter goes into the model's context along with the procedure.Measured on the embedded skills on main:
SKILL.mddetect-n-plus-one/SKILL.mderror-root-cause/SKILL.mdINSTRUCTIONS.mdpoints the agent atSKILL.mdfirst, so a skill-driven run reads the root plus at least one sub-skill. That is 508 bytes of front matter out of 2221 before any telemetry is fetched. Per #9290 everythingread_skillreturns goes on the wire about 2.1x, so it is paid twice.What the block contains:
nameanddescription, already used by the root catalog to route the agent herelicense, provenancemetadata, author and version, provenanceallowed-tools, declared but not read by any Go fileI grepped all 46
.gofiles undermcptoolsforyaml,frontmatterandallowed-tools. No matches. #8761 proposed a front matter parser during Term 2 and closed with no PR, so the shipped design serves the file raw. This is the cost of that choice rather than an oversight.Expected behavior
The agent gets the procedure. The file on disk keeps its metadata for humans and tooling.
Two ways to do it:
read_skill. No YAML dependency, 26% smaller payload. Dropsallowed-toolsfrom what the model sees, which changes nothing today since nothing enforces it.licenseandmetadata. Keepsname,descriptionandallowed-toolsvisible, saves about 70 bytes per file, needs a parser.I went with option 1 in the linked PR because
allowed-toolshas no effect either way. Happy to switch if you would rather the model kept seeing it.Separate question, probably its own issue: should
allowed-toolsconstrain the tool surface server side, or stay advisory to the model?Jaeger backend version
main (26c5612)
SDK
Not applicable, this is in the MCP handler layer.
Pipeline
Not applicable.
Stogage backend
Not applicable.