headcleaner
Server Quality Checklist
Latest release: v0.14.0
- Disambiguation2/5
Several tool groups are hard to distinguish: okf_related_tool vs okf_impact_tool both analyze links, search_chunks vs okf_search_tool both search, and okf_doctor_tool/get_diagnostics/get_readiness/list_review_queue all sound like status/health endpoints. The descriptions help only after close reading, but an agent could easily pick the wrong tool.
Naming Consistency2/5Naming conventions are mixed: some tools use okf_*_tool, some use bare get_*/list_* verbs, and registry tools use okf_registry_*. There is no consistent verb_noun or prefix/suffix rule across the set.
Tool Count3/519 tools is on the heavy side; many are justified by the range of bundle, registry, search, SQL, and graph-analysis capabilities, but the status-envelope and search/link-analysis overlaps add bulk. It is not egregiously overpopulated, but it exceeds the comfortable 3-15 range.
Completeness4/5The server covers the main read-side lifecycle: list/load bundles, search/read concepts and chunks, inspect health/diff, manage registry aliases, and run SQL. Missing mutation tools for bundle content and review actions are likely out of scope, forming only minor gaps agents can work around.
Average 3.1/5 across 19 of 19 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 135 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It mentions a conditional ('when available') but does not explain what happens when the additive indexed package is unavailable, whether the operation is read-only, what output to expect, or what side effects may occur. This is far too little disclosure for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and starts with the action, which is structurally clean. However, it is under-specified: the sentence is concise but does not convey enough useful information to warrant giving it a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, four undocumented optional parameters, and a large sibling set, the description is nowhere near complete. An agent cannot reliably decide when to invoke this tool, what inputs to provide, or what the response will contain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of depth, start, bundle, or max_tokens. The phrase 'additive indexed package' might loosely relate to bundle, but it is not explicit or sufficient. The agent cannot determine parameter meaning, constraints, or how the parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'assemble' and identifies resources ('legacy graph context', 'additive indexed package'), so it is more than a pure tautology. However, it is vague about what the tool actually returns or does, and 'context' closely mirrors the tool name without explaining the operation's effect. It does not clearly distinguish itself from sibling tools like okf_related_tool or search_chunks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus any of the many sibling tools. The description names no conditions, alternatives, exclusions, or prerequisites. An agent is left to infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds some behavioral color by calling the envelope 'stable' and 'content-free,' but it does not clarify side effects, failure modes, prerequisites such as the bundle needing to exist locally, or what happens when the optional bundle parameter is null.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, and the key resource ('readiness envelope for a local bundle') is front-loaded. It is appropriately brief, though the jargon and ambiguity reduce the value of that brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple input schema and an output schema, but the description is still under-specified for an agent: it gives no sense of what 'readiness envelope' contains, what qualifies as a local bundle, or how the optional parameter behaves. With no annotations and 0% schema coverage, the description leaves too much to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented 'bundle' parameter. It does add the qualifier 'local bundle,' which hints that the parameter identifies a local bundle, but it does not explain accepted formats, the significance of the default null, or what values are valid.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description does state a specific verb and resource: 'Return a stable, content-free readiness envelope for a local bundle.' However, the meaning of 'readiness envelope' is not explained, so the tool's actual purpose remains vague and it is not clearly distinguished from sibling diagnostic/readiness-related tools like get_diagnostics or okf_doctor_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. The description only states what it returns, with no conditions, exclusions, or mention of sibling tools, leaving the agent to infer the appropriate invocation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only adds 'stable' and 'content-free', which vaguely suggest deterministic ordering and no actual content, but it does not explain side effects, pagination, errors, or how parameters affect behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, but its unusual terms ('envelope', 'content-free') reduce clarity. It is concise in length but not optimally clear in wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value detail is less critical, but the description is still incomplete for a tool with no annotations and no parameter documentation. It does not explain what an envelope is, what 'content-free' means, or how 'limit' and 'bundle' are used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the undocumented 'limit' and 'bundle' parameters. 'Local bundle' weakly maps to the 'bundle' parameter, but 'limit' and the meaning of the returned envelope are left entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('return') and names a resource ('review-queue envelope'), so it avoids tautology. However, 'content-free envelope' is jargon and does not clarify what is actually returned or how this differs from the many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. 'For a local bundle' hints at a context, but no conditions, exclusions, or sibling-tool comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that root, policy, and index validation occur before returning, which is useful, but it does not state what happens on validation failure, whether the operation has side effects, or any error semantics. This leaves significant behavioral ambiguity for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and result. Every word earns its place, and 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits parameter semantics, failure behavior, and usage context. While an output schema exists, the agent still lacks critical information about how to invoke the tool correctly and what happens under invalid conditions. The description is not complete enough for reliable autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not mention chunk_id or bundle at all. It only says 'chunk,' which does not clarify parameter meaning, optionality, or how bundle affects behavior. The description fails to compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and a specific resource ('one cited chunk'), and adds validation context ('after root, policy, and index validation'). This clearly identifies the tool's basic function, though it does not explicitly differentiate it from sibling tools like search_chunks or get_diagnostics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for retrieving a single validated chunk, but it provides no explicit guidance on when to use it versus alternatives. There are no exclusions or references to sibling tools, so an agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It indicates a read-only diff-like operation and a temporal baseline, but it does not explain what output is returned, whether a bundle must be explicitly supplied, what happens if the bundle is null, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler or redundant restatement of the tool name. It is concise and readable, though the brevity comes at the cost of needed detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too incomplete to guide correct invocation in an unambiguous way. Missing parameter semantics, return format, and relationship to the bundle loading workflow leave significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single 'bundle' parameter. The description only mentions 'the bundle' in passing, giving slight context that the parameter likely identifies the loaded baseline, but it does not explain valid values, source, or behavior when omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: reporting changes on disk relative to the loaded bundle. It is specific enough for an agent to understand the core function, though it does not distinguish itself from related okf_* tools or explicitly use an imperative verb like 'show' or 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus any of the sibling tools such as okf_related_tool, okf_impact_tool, or okf_doctor_tool. The description implies a use case for checking disk changes but provides no conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does add meaningful behavioral context: it defines 'related' as link degree (inbound + outbound count) and indicates top-k ordering. However, it does not disclose sorting direction, exact matching semantics, bundle scoping, or whether the operation is a pure read with no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler, and the core ranking metric is front-loaded. It is appropriately concise for a tool that could be summarized in one line, though the brevity does contribute to the parameter-semantics gap.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no annotations, and 0% schema description coverage, the description is not complete enough for correct invocation. It leaves key semantics unresolved, especially the bundle parameter and the role of concept. The output schema may cover return shape, but it cannot substitute for missing input and selection semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining any of the three parameters. 'Top-k' loosely maps to k, and 'concepts' loosely maps to concept, but bundle is completely unexplained. The description provides almost no parameter-level meaning beyond what the schema shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Top-k concepts by link degree (inbound + outbound count)' uses a clear verb-plus-resource structure, states the ranking criterion, and distinguishes this from generic search or context tools. However, it never explicitly says it operates relative to a supplied concept, which is the required parameter and a core part of the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the many siblings such as okf_search_tool, okf_get_concept_tool, or okf_context_tool. The behavior implies a use case (ranking related concepts by link degree), but no explicit usage context, conditions, or alternative exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals the effect (updating the in-memory catalog) but does not disclose whether re-ingestion is destructive, idempotent, requires permissions, or what happens when 'bundle' is null or omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and stays free of fluff. It is concise and readable, though it could afford an additional sentence to clarify parameter semantics without losing its tight structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a schema with zero description coverage, the description leaves important invocation details unstated, especially the meaning of the optional 'bundle' parameter and whether a null value refreshes all bundles. The agent can grasp the high-level intent but not reliably make a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 0% description coverage for the single 'bundle' parameter. The description only says 'a bundle' without explaining how to identify it, what formats are accepted, or what the default of null means. This is minimal added meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('re-ingest') with a clear resource ('a bundle') and an explicit goal ('so the in-memory catalog reflects current files'). It communicates the core action clearly, though it does not explicitly distinguish itself from sibling tools such as okf_diff_tool or okf_doctor_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'so the in-memory catalog reflects current files' implies the tool should be used when files have changed and the catalog is stale. However, it does not state when not to use it or mention alternatives, leaving the decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds useful behavioral traits such as 'cited' (chunks include citations), 'policy-gated' (access may be restricted by policy), and 'existing local bundle index' (the bundle must already exist locally). However, it does not explain what policy-gating entails, how failures are surfaced, or whether the operation is purely read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one efficient, front-loaded sentence with no filler words. It is slightly under-specified, which limits 'appropriately sized', but structurally it is concise and immediately states the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks essential usage context: when to use it, how to scope with bundle, what policy-gating means in practice, and how limit behaves. With zero annotations and zero schema descriptions, this is not enough for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameters. It only loosely hints at 'bundle' via 'bundle index' and at 'query' via 'search_chunks', but provides no explicit meaning for query, limit, or bundle. The default/null behavior of bundle is left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource: cited, policy-gated chunks from an existing local bundle index. It gives a specific and distinct purpose, though it does not explicitly compare itself to siblings like get_chunk or okf_search_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It neither names sibling tools nor states conditions or exclusions, leaving the agent to infer usage context from the tool name and generic phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does reveal that the result is 'stable' and 'content-free,' which hints that the call is predictable and returns no actual diagnostic data. However, it does not describe side effects, error behavior for invalid bundles, authentication needs, or what the envelope contains beyond what an output schema might show.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence with no filler or repetition. The key characteristics ('stable', 'content-free') are front-loaded, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return-value details are not strictly necessary. However, the description leaves the meaning of 'diagnostics envelope' unexplained and gives no usage context relative to siblings. With no annotations, the overall package is incomplete for an agent deciding whether to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('bundle') with no description and zero schema coverage. The description only says 'for a local bundle,' which hints that the parameter identifies a bundle, but it does not explain accepted format, how null behaves, or what 'local' means in this context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and points to a specific resource ('a stable, content-free diagnostics envelope for a local bundle'), making the tool's purpose clear. However, it does not explicitly differentiate from sibling diagnostic/readiness tools like get_readiness or okf_doctor_tool, though the 'content-free' modifier adds some distinctiveness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool rather than the many sibling tools, nor any mention of prerequisites or context. The phrase 'for a local bundle' implies a use case, but no alternatives, exclusions, or selection criteria are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden. It discloses that the tool produces a report containing score, errors, warnings, and per-rule findings, which implies a read-only diagnostic operation. It does not explain side effects, prerequisites, or how stale_days affects behavior, but the report framing provides reasonable transparency for a simple diagnostic tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently conveys the tool's purpose and output highlights. It could include more guidance, but as far as conciseness and structure go, it is appropriately compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and zero schema description coverage, so the description must carry more weight. It does list key return elements, but it omits meaningful context for the stale_days parameter, input expectations, and any behavioral caveats. For a two-parameter tool this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'bundle' is the subject being analyzed, but it leaves 'stale_days' completely unexplained. The parameter names offer some hints, but the description adds little beyond the schema itself and fails to define the meaning or acceptable use of stale_days.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-like resource ('Health report for a bundle') and enumerates concrete output components: score, errors, warnings, per-rule findings. This clearly identifies the tool's core purpose and gives enough detail to distinguish it from generic search or data-retrieval siblings, though it does not explicitly name a differentiating sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when an agent needs a health assessment of a bundle, including score and rule findings. However, it provides no explicit when-to-use or when-not-to-use guidance, and it does not mention alternatives among the many okf_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of disclosing behavior. It clearly indicates removal, but does not state whether the deletion is permanent, reversible, idempotent, or what happens if the slug does not exist. This is a notable gap for a mutating registry tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence communicates the core action with no wasted words. For a one-parameter tool, this is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a destructive operation with no annotations and no output schema. It does not explain the return value, error cases, or downstream effects of removing the slug, leaving an agent without enough context to handle unexpected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description could have compensated, but it only echoes the parameter name 'slug' without explaining its format, origin, or constraints. It minimally links the slug to the registry context, but adds little meaning beyond the schema's property name and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and a specific resource ('a slug from the registry'), making the operation immediately clear. It also distinguishes itself from sibling tools like okf_registry_add, okf_registry_list, and okf_registry_resolve by naming the removal action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as okf_registry_add or okf_registry_resolve. The description does not mention prerequisites, exclusions, or conditions under which removal should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It indicates a mutating operation ('Add') and the resulting alias-reference behavior, but it does not disclose what happens if the slug already exists, whether the operation is persistent, or what errors or side effects may occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action, then immediately provides a concrete usage example. The example earns its place by clarifying parameter meaning and expected invocation style.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description is reasonably complete: it states the action, defines the alias concept, and demonstrates usage. However, it does not mention return values, overwrite behavior, or failure conditions, and there is no output schema to compensate for those omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only parameter titles with no descriptions, and schema description coverage is 0%. The description adds meaning by defining the concept of a slug alias and showing an example where slug='docs' and bundle_path is a local directory path. This is helpful but still leaves some semantic details implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: adding a bundle under a slug alias, and shows how to reference it afterward. It is specific about the verb ('Add') and resource ('bundle under a slug alias'), though it does not explicitly contrast itself with sibling registry tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The example strongly implies when to use the tool: register a bundle under a short alias so it can be referenced as @<slug>/... . However, it does not explicitly explain when not to use it or mention alternatives like okf_registry_remove or okf_registry_resolve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of signaling behavior. 'Report' implies a read-only operation with no side effects, which is useful, but the description does not disclose how transitive links are computed, what the bundle parameter affects, or any permissions or performance considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler, restatement, or irrelevant details. Every word contributes to identifying the operation and its scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter, the description provides enough to make a basic call using 'concept'. Yet the lack of an output schema, the unexplained 'bundle' parameter, and absent sibling differentiation leave meaningful gaps for an agent deciding whether this is the right tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for missing parameter details. It clarifies that 'concept' is the focus of the link report, but the optional 'bundle' parameter is entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action, 'Report', and a specific resource: 'outbound / inbound / transitive links for a concept'. It makes the tool's core function easy to grasp, but it does not explicitly distinguish it from siblings like okf_related_tool or okf_get_concept_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose statement: use this tool when you need outbound, inbound, or transitive link information for a concept. However, there is no explicit guidance on when not to use it or which alternative tool should be preferred in overlapping scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It usefully reveals that hits from other bundles include a `bundle` field when all_bundles is set, but it does not disclose ordering, pagination semantics of limit, or behavior when both bundle and all_bundles are supplied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with the main action front-loaded and no filler. Every sentence adds information about scope or result behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and zero parameter descriptions, the description is only moderately complete. It explains the all-bundles mode and the bundle field on hits, but leaves ambiguous how to address a specific bundle and how limit applies; the output schema does help cover return-value expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description was expected to compensate. It only clarifies all_bundles and vaguely implies the bundle parameter via 'one or all loaded bundles'; term and limit receive no semantic explanation beyond their schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Search') on a clear resource ('one or all loaded bundles') and explains the all_bundles mode. It is clear but does not explicitly differentiate this tool from the sibling search_chunks, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete guidance for using all_bundles=True to cover every registered bundle, and implies the alternative of searching a single bundle. However, it does not mention when to prefer this tool over sibling search tools such as search_chunks, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only', which clearly signals no mutation, and 'in-memory' adds useful context about data scope and volatility. It does not mention permissions or limitations, but the core safety-relevant behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to understanding the tool's core nature and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only query tool with an output schema, the description covers core function and safety. However, it omits how the optional 'bundle' parameter affects queries and gives no indication of SQL dialect or usage constraints, leaving some practical gaps for an agent invoking it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters, but it does not explain 'query' or 'bundle' in any detail. The phrase 'SELECT' implies query is a SQL string, yet 'bundle' remains entirely unexplained, leaving a meaningful semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read-only SELECT'), resource ('in-memory catalog'), and scope ('concepts, links'), making it clear what the tool does. It does not explicitly name sibling tools for differentiation, but the SQL-focused wording distinguishes it from nearby semantic-search and context tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The read-only SELECT framing implies this tool is for querying catalog data with SQL, which gives useful context. However, it does not explicitly say when to choose this tool over alternatives like okf_search_tool or okf_related_tool, nor does it provide exclusions or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core behavior: listing all bundles registered under @slug aliases. However, with no annotations available, it carries the full burden of behavioral disclosure and does not mention read-only guarantees, sorting, pagination, or other potential behaviors. The output schema helps, but the description alone is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundant phrasing. It is concise and immediately communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with an output schema, the description is mostly sufficient. However, it leaves the concept of '@slug aliases' unexplained and does not clarify how this differs from the sibling okf_list_bundles_tool, which could matter for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so there is no parameter semantics for the description to add. This matches the baseline of 4 for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('all bundles registered under @slug aliases'), making the operation immediately understandable. It also distinguishes itself from sibling registry operations like add/remove/resolve by focusing on enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the closely related okf_list_bundles_tool or other lookup tools. The phrase 'List all' implies an enumeration use case, but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It suggests a read-only resolution operation, but it does not explicitly state that it is non-mutating, what happens for invalid references, or whether it performs a network/registry lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It states the input format and the output in about ten words, making it easy to parse and apply.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one required string parameter, no output schema, and no nested objects. The description covers the core input/output contract, though it omits failure modes and explicit usage context, which are somewhat mitigated by the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the bare parameter name 'Target'. It does so by indicating that the target should be a `@slug/concept` string and that the result is a bundle path plus concept id, adding meaningful semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Resolve' with a concrete resource pattern `@slug/concept` and names the expected output ('bundle path + concept id'). This clearly distinguishes it from sibling registry tools like list/add/remove and makes the tool's function immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: if you have a reference like `@slug/concept` and need a bundle path and concept id, this is the tool. However, there is no explicit guidance about when to prefer this over alternatives such as okf_get_concept_tool or okf_search_tool, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description correctly carries the behavioral burden: 'Read' signals a read-only operation, and 'frontmatter + body' discloses what the returned concept contains. It does not discuss ambiguity or error cases (e.g., duplicate titles) or a detailed return shape, but the essential side-effect profile is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with the core action front-loaded before parameter details. There is no filler, and every phrase ('Read', 'one concept', 'frontmatter + body', accepted identifier forms) contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with no output schema, the description covers the action, the target identifier options, and the returned content ('frontmatter + body'). The unexplained optional bundle and absence of error/ambiguity behavior are minor gaps that do not block correct invocation when using the required target.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no field descriptions (0% coverage), so the description must add meaning. It does this for the required target parameter by specifying it can be an id, title, or filename stem, which is exactly what an agent needs to invoke the tool. The optional bundle parameter remains undocumented, preventing a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action verb ('Read') and names the exact resource ('one concept') with its composition ('frontmatter + body'), so an agent can tell what the tool does. It implicitly differentiates from search and related siblings by targeting a single concept, but does not explicitly name any sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The statement 'Accepts id, title, or filename stem' gives practical targeting guidance and implies when to use the tool (when you know a concept identifier). However, there is no explicit when-to-use versus alternatives such as okf_search_tool or okf_related_tool, and no exclusions or conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. 'List' conveys a read-only, non-mutating operation and 'loaded' scopes the behavior, but the description does not explicitly state side-effect safety or response characteristics. For a zero-parameter list tool, this is acceptable but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It front-loads the action and object, making the purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing operation with an output schema, the description provides enough information to call the tool correctly: it identifies the resource type and scope. Return values are covered by the output schema, so their absence from the description is not a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema is already complete and there is nothing for the description to explain. The description adds useful context by naming the resource and scope, but no parameter-specific semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List'), a specific object ('OKF bundles'), and a scope qualifier ('this server has loaded'). This distinguishes it from sibling tools like okf_registry_list and list_review_queue by subject matter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when needing to see loaded OKF bundles) but gives no explicit guidance about alternatives or when not to use it. With siblings like okf_registry_list present, an explicit differentiation would strengthen this dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md: