Locate Open Knowledge Format bundle roots under a directory by finding index.md files that declare okf_version; accept a direct bundle path when that declaration is absent.
Bundle roots under a directory: each index.md declaring okf_version (§12). A bundle without that declaration looks like any folder; pass it as bundle= directly.
| Name | Required | Description | Default |
|---|---|---|---|
| bundle | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description does add one genuinely useful behavioral trait beyond that: detection silently misses bundles lacking the okf_version declaration, plus a workaround. However, it says nothing about scan scope (cwd? recursive? depth), what is returned, or why §12 matters.
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?
It is short and front-loaded, but dense with unexplained jargon ("okf_version", "§12") and written in fragments rather than complete clauses. No sentence is wasted in length, yet the first sentence earns little because it describes the domain object instead of the action.
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?
With no output schema, the description must explain what the agent gets back — a list of bundle root paths? — and it does not. For a discovery tool with an optional parameter defaulting to empty, the agent can't predict behavior at the default, and the §12 citation points at documentation the agent cannot see.
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 0%, so the description carries the burden for the single optional 'bundle' parameter. "Pass it as bundle= directly" conveys that the param takes a path to a bundle root that bypasses detection, which is real added meaning, but the default empty string and its semantics (cwd? all?) remain unexplained.
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 is a noun fragment ("Bundle roots under a directory") with no verb, so it never states whether the tool lists, validates, or creates bundles. It spends more words defining what a bundle is (an index.md declaring okf_version) than saying what the tool does, and it doesn't distinguish itself from siblings like list, index, or search.
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 only guidance is the cryptic note that an undeclared bundle "looks like any folder; pass it as bundle= directly," which hints at a fallback path but never says when to call this tool versus list/search/index. There are no exclusions or preconditions an agent can act on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.