okf-mcp-server

by lorsabyan

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation5/5
Each tool targets a distinct operation: open gives an overview, list/get/search retrieve concepts, health/validate analyze quality and conformance, and reload manages the cache. The 'use when' examples clearly differentiate overlapping pairings like search vs. list and health vs. open.
Naming Consistency5/5
All tools share the consistent okf_ prefix and use clear action-oriented names (open_bundle, list_concepts, get_concept, search, health_report, validate, reload_bundle). While health_report is a noun compound, the pattern is otherwise verb_noun, and the prefix makes prediction trivial.
Tool Count5/5
Seven tools is a well-scoped size for an OKF bundle server. Each tool earns its place, covering discovery, retrieval, search, health analysis, validation, and cache management without unnecessary bloat or fat.
Completeness5/5
The tool surface fully covers the read/analyze lifecycle for OKF bundles: entry point, listing, detail retrieval, search, quality health, spec conformance, and cache refresh. No obvious gaps exist for the stated purpose, and editing is intentionally left outside the server.
Average 4.8/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- 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.json to 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

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description adds meaningful behavioral context: trust and stale_since are advisory signals, not access control; for Attested Computation the caller must not author or rewrite the computation, only supply parameter values; unknown IDs return near-miss suggestions. These details disclose important behavioral nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into clear sections (Args, Returns, Trust note, Computation note, Examples, Error Handling) and front-loaded with the core purpose. It is lengthy, but the detailed return schema and caveats are necessary given the absence of an output schema. No redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (trust signals, computation type, various fields) and no output schema, the description is exceptionally complete. It documents the full return structure, error behavior, usage examples, and critical trust/computation caveats. Everything an agent needs to invoke and interpret the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four tool parameters are already well-documented in the schema (100% coverage), so the description's parameter list adds little new semantic value. The note about 'declared parameters ONLY' refers to the computation's parameters, not the tool's own parameters, so it doesn't elevate the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Read a single concept in full' and enumerates the content (frontmatter, trust and lifecycle signals, provenance, body, links). This specific verb+resource clearly distinguishes it from siblings like okf_list_concepts (listing) and okf_search (searching).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete use cases ('How is revenue defined?' -> id='metrics/revenue' and 'need a concept's sources to cite it'), which clearly indicate when to use the tool. It does not explicitly name sibling tools or state when not to use it, but the examples and 'single concept' framing imply appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds substantial behavioral nuance beyond that: it distinguishes between 'stale' (spec-derived) and 'aging' (heuristic), warns against conflating them, and includes error handling for invalid as_of. This provides context that annotations alone cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with a clear summary, followed by a necessary disambiguation of stale vs. aging, then Args, Returns, Examples, and Error Handling. Every paragraph serves a purpose; the length is justified by the tool's semantic complexity, and no information is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully documents the return JSON structure. It also covers error handling and includes usage examples. Combined with annotations for safety and a straightforward input schema, the description leaves no critical gaps for an AI agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description's Args section restates the schema parameters and adds clarity (e.g., as_of evaluates staleness against a date 'instead of today', response_format default is 'markdown'). While largely redundant with the schema, the narrative context reinforces the semantics, justifying a slightly higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Analyze a bundle for documentation-health problems' and enumerates specific issue types (broken links, missing descriptions, untyped concepts, staleness, unverified/deprecated content, orphans). This is a specific verb+resource that distinguishes it from sibling tools like okf_open_bundle or okf_get_concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use when' examples ('Is anything in this catalog out of date?', 'What still needs human review?', 'auditing before relying on a bundle') that give clear context for when to invoke the tool. However, it does not mention when not to use it or name alternatives like okf_validate, so it lacks the explicit exclusions that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotent, non-destructive), the description discloses the caching-per-path behavior, the effect on subsequent calls, and the return value structure ({ cleared: number }). It also states that the action is a cache drop, aligning with readOnlyHint=false while adding context about what actually happens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a one-sentence summary, followed by rationale, args, returns, and examples. Every section adds value and the description is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers when to use, what happens (cache drop, next read), the optional parameter meaning, and the return shape. No gaps in context are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter bundle_path with 100% coverage and a clear description ('Bundle to drop; omit for all'). The description repeats essentially the same meaning ('bundle to drop; omit to drop every cached bundle') without adding significant new detail, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Drop the cached copy of a bundle') and resource (bundle cache), distinguishing it from sibling tools like okf_open_bundle or okf_get_concept. It explains the purpose with a concrete verb and outcome (re-read from disk), not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call after editing files, and provides both 'Use when' and 'Don't use when' examples. This gives clear conditions for use and implicitly names the alternative (do nothing when only reading), which satisfies the requirement for usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description discloses that it returns summaries only, is safe for large bundles, and explains error behavior for unmatched filters. This adds meaningful context without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with distinct sections for overview, parameters, return format, examples, and error handling. Every section earns its place, and the key purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description provides a full inline return structure, covers all parameters, includes examples, and addresses error handling. This makes it complete for a complex listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by providing examples for the type parameter (e.g., 'Metric') and clarifying the 'response_format' default, though it mostly repeats schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists concepts with optional filters by type, tag, or lifecycle status. It also distinguishes itself from okf_get_concept by noting it returns summaries without bodies, making it suitable for large bundles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises using okf_get_concept to read a concept in full, and provides concrete 'Use when' examples for type, trust, and status filters. This gives clear guidance on when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context beyond those hints: it explains the return shape (JSON structure with counts and health summary), error behavior for missing directories or non-concept folders, and the default response_format. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: intro, bundle definition, Args, Returns, Examples, and Error Handling. The 'Start here' opener is immediately useful, and each section adds necessary context without fluff. The length is justified by the tool's role as an entry point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description fully compensates by including a detailed return structure. It covers usage context, error cases, and relationships to sibling tools. The bundle definition provides essential domain knowledge for an AI agent, making the description complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds marginal value by including an Args section that restates defaults and types, plus concrete examples like bundle_path='./knowledge' and an explanation that response_format 'json' is for machine processing. This is helpful but not essential beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Open') and resource ('OKF bundle') and clearly states it describes the bundle's contents with 'Start here.' It distinguishes from siblings by noting when not to use it (if you already know the concept id, use okf_get_concept).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'Use when' examples, including concrete bundle_path values and a comparison to okf_list_concepts, plus a 'Don't use when' exclusion with a named alternative. This gives clear guidance on when to choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations (readOnlyHint, idempotentHint) by detailing the full-text search behavior, the return object shape, and error behavior when no matches are found. It also clarifies defaults for limit and response_format, adding genuine behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Description, Args, Returns, Examples, Error Handling). Every section is concise and informative; there is no fluff or repetition of schema fields that are already self-explanatory.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description provides a full return shape, making it self-contained. It also covers edge cases (no matches) and offers concrete usage examples. Given moderate complexity and rich sibling context, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds extra semantic nuance: 'Absolute paths are safest' for bundle_path, 'markdown' for reading vs 'json' for machine processing, and the 1-200/1-50 ranges in Args. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Full-text search over a bundle's concepts'. It lists the exact scopes (titles, ids, types, tags, descriptions, bodies) and clearly differentiates from sibling tools like okf_get_concept by explicitly stating when not to use it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use when' and 'Don't use when' guidance, naming the alternative tool (okf_get_concept) and the rationale (it is cheaper). This is exactly the kind of practical selection guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe, read-only idempotent operation. The description adds substantial behavioral context: the distinction between errors and warnings, the tolerance of warnings per spec §11, the conformance rules themselves, and error handling for missing paths. This goes far beyond the annotations and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (intro, errors/warnings, args, returns, examples, error handling). Every part earns its place; no fluff or redundancy. It's longer than average, but the complexity of the tool justifies it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully documents the return object with field names, types, and meanings. It also covers error handling for missing paths. Given the tool's complexity (conformance logic, multiple response formats), this is a complete and self-contained description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that bundle_path is a directory containing the bundle and that response_format is 'markdown' for reading vs 'json' for machine processing, reinforcing and expanding on the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: 'Check a bundle against the OKF v0.2 specification.' It clearly identifies the resource (bundle) and verb (check/validate), and distinguishes itself from sibling okf_health_report by focusing on conformance rather than quality signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance with 'Use when' and 'Don't use when' sections. Directly names an alternative tool (okf_health_report) for non-conformance use cases, making it easy for an agent to decide when to select this tool.
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:

[![okf-mcp-server MCP server](https://glama.ai/mcp/servers/lorsabyan/okf-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/lorsabyan/okf-mcp-server)

Score Badge

Copy to your README.md:

[![okf-mcp-server MCP server](https://glama.ai/mcp/servers/lorsabyan/okf-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/lorsabyan/okf-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lorsabyan/okf-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server