okf-mcp

by mfdaves

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation4/5
Most tools target distinct resources (concepts, bundles, graph, validation, computation), and descriptions clarify their specific scope. However, list_bundles and list_remote_bundles overlap since the former already includes remote bundles, and several validation tools have similar names. Overall, an agent can usually select correctly with clear descriptions.
Naming Consistency3/5
The naming mixes conventions: many tools use verb_noun patterns (list_, get_, validate_), but some have an okf_ prefix (okf_get_proposal, okf_validate_concept) and graph_summary is a noun phrase. This inconsistency reduces predictability, though the overall style is still readable.
Tool Count2/5
With 28 tools, the server exceeds the 25-tool threshold, making the set feel heavy. While the domain is complex, many listing and validation tools could be consolidated or generalized, and the count is high enough to overwhelm agents navigating the surface.
Completeness4/5
The tool surface is comprehensive for a read-only, validation, and graph-analysis server: it covers listing, querying, validating, and graph traversal. Missing create/update/delete operations appear out of scope, and minor gaps like no get_bundle or get_tag are workable. Overall, the domain is well-covered.
Average 3.8/5 across 28 of 28 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 18 commits in the last 12 weeks
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds 'bounded' indicating limits, but does not elaborate on default behavior, truncation semantics, or return structure. No contradiction 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, front-loading the main action and resource. It is concise and easy to parse, though it could be slightly richer without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 should compensate by explaining the expected return shape or typical use cases. It only offers a generic statement about bounded nodes/edges and filters, leaving important operational details unaddressed for a tool with 9 parameters.
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?
Schema coverage is 100% since every parameter has a description in the input schema. The description's phrase 'optional concept filters' is a high-level grouping that adds no additional semantics beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return' and clearly identifies the resource as 'a bounded set of OKF graph nodes and edges' with optional concept filters. It conveys the core function but does not differentiate from sibling tools like get_subgraph or graph_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use get_graph versus alternatives. There are no scenarios, prerequisites, or exclusions mentioned, making it difficult for an agent to select this tool over graph-related 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?
Annotations already declare the tool as readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering core safety traits. The description adds the term 'compact metadata' which hints at a filtered response, but does not detail return format, ordering, or potential pagination limits. With annotations present, this is adequate but not rich.
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 a single short sentence (6 words) that is well front-loaded and avoids verbosity. It could benefit from slightly more context without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with only two optional parameters, the description is minimal. It does not explain what 'compact metadata' means, the structure of the response, or whether results are ordered or limited. Given the lack of output schema and absence of such details, completeness is low.
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?
Schema description coverage is 100% (both 'bundle' and 'status' have descriptions in the schema). The description does not add additional semantics beyond the schema; the phrase 'compact metadata' does not elaborate on parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List compact metadata for stored authoring proposals' clearly identifies the verb (list) and resource (proposals) with a qualifier on the output style. However, it does not explicitly differentiate from sibling tool 'okf_get_proposal', which likely provides full details, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like list_bundles or search tools. There is no mention of context, prerequisites, or exclusions, forcing the agent to rely solely on the tool name and schema.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe read operation. The description adds that results are 'compact summaries', which implies a limited set of fields. This is a minor behavioral addition, but there is no mention of rate limits, pagination behavior beyond offset/limit, or other traits.
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 a single sentence that is front-loaded with the verb 'List' and resource 'OKF concept summaries'. Every word earns its place; there is no redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and filter parameters, but does not describe the return format (e.g., what fields a 'compact summary' contains) or any edge cases. With no output schema, the description could be more complete to set expectations for the agent.
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?
Schema description coverage is 100%, so each parameter already has a description. The tool description merely restates the filter types (bundle, type, tag, text) without adding new semantic meaning. This meets the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists compact OKF concept summaries with optional filters, which is specific and distinguishes it from get_concept. However, it does not explicitly differentiate from sibling tools like search_concepts, which might provide similar functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It lists filters but lacks explicit context for when each filter is appropriate or how this tool differs from other list/search tools in the sibling set.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the notion of rendering the 'current' graph, which is consistent, but does not disclose behavior on large graphs, output size limits, or any side effects. With strong annotation coverage, this is acceptable but not enriched beyond the structured data.
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?
A single sentence that is concise, front-loaded with the action verb 'Render', and lists the output formats without padding. Irrelevant details are absent, earning a top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, a rich schema, and strong annotations, the description is almost sufficient. It lacks a mention of what the output looks like (e.g., a string), but this is reasonably implied by 'JSON, Graphviz DOT, or Mermaid text' and the absence of an output schema. Overall, it is complete enough for straightforward use.
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?
Schema description coverage is 100%, with each of the six parameters well described (format enum, maxNodes/maxEdges limits, edgeKinds filter, includeAssets/includeExternal flags). The tool description itself does not add meaning beyond the schema, matching the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders the current OKF graph into JSON, DOT, or Mermaid text, identifying the specific verb ('Render'), resource ('current OKF graph'), and output formats. It does not explicitly differentiate from similar sibling tools like get_graph or graph_summary, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling graph-related tools (get_graph, get_subgraph, graph_summary), the description offers no exclusions or preferred usage context, leaving the agent to infer from the name alone.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds scope ('current OKF graph') but no additional behavioral traits beyond what annotations provide.
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?
Single sentence with no wasted words. The description is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description does not specify the output format (e.g., count number or list of types). Given no output schema and many siblings, more detail would improve completeness.
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?
No parameters are defined, and schema coverage is 100%. The description could elaborate on what 'typed relations' means, but the zero-parameter case earns a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool counts typed relations in the current OKF graph. However, the tool name 'list_relation_types' suggests listing rather than counting, causing minor inconsistency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like 'list_concepts' or 'get_graph'. No prerequisites 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, so the description only adds 'bounded' to indicate limits. It does not describe what happens when no path exists, path ordering, or performance characteristics, providing minimal additional behavioral context beyond 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 a single sentence with no extraneous words, directly stating the tool's purpose. It is perfectly front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description does not specify the return structure (e.g., list of paths with nodes/edges). The 'bounded' qualifier is vague without details on limits or edge cases. While annotations and schema cover safety and parameters, this gap prevents a higher score.
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 input schema provides 100% coverage with descriptions for all four parameters (source, target, maxPaths, edgeKinds). The description's phrase 'bounded relationship paths' loosely maps to maxPaths and edgeKinds but adds no new meaning 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 (Find) and resource (bounded relationship paths between two OKF concepts), clearly differentiating it from sibling tools like get_neighbors (immediate neighbors) or get_subgraph (subgraphs). It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention scenarios like multi-hop traversal or contrast with get_neighbors, leaving the agent to infer usage from context.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the qualifier 'safe,' which implies a behavioral guarantee (e.g., collision-free path generation), but it does not explain what 'safe' entails or any other behavioral details such as dependencies or error conditions.
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 a single, clear sentence that immediately states the tool's purpose with no filler or redundancy. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 should clarify what the tool returns (e.g., a string path) and any caveats about 'safe.' It covers the core function but leaves the return format and the meaning of 'safe' ambiguous. However, the tool is simple and all parameters are well-documented, so the gaps are not severe.
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 input schema has 100% description coverage for all 4 parameters, so the schema provides full parameter documentation. The description only repeats 'concept type and title' without adding new semantic meaning, so it does not enhance the schema's already adequate parameter 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 clearly states the tool's function with a specific verb ('suggest') and resource ('safe bundle relative Markdown path'), and identifies the inputs ('concept type and title'). It is distinguishable from sibling tools like get_concept or read_bundle_asset, which focus on other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or exclusions, leaving the agent to infer the use case from the tool 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds the scope 'standard semantic and extension' and 'count' but provides no additional behavioral details such as return format or potential limitations. This meets the baseline but doesn't go beyond 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 a single, well-structured sentence that fronts the verb and object. It contains no fluff and earns every word, making it highly concise and easy to parse.
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 simplicity (no parameters, no output schema) and the strong annotation coverage, the description is sufficient. It clearly states what is counted and in what scope, making the tool's behavior complete for an agent to use effectively.
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?
The tool has zero parameters, so the schema description coverage is trivially 100%. The description doesn't need to explain parameters, and the baseline for zero parameters is 4. No additional parameter semantics are necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Count' and the resource 'edge kinds' with scope 'current graph', which conveys the tool's primary function. However, it does not explicitly distinguish itself from the sibling tool 'list_relation_types', which could be seen as overlapping, so it's not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 like 'list_relation_types' or 'list_types'. The description gives no context about use cases or exclusions, leaving the agent without decision guidance.
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?
Annotations already declare readOnlyHint, idempotentHint, and no destructiveness. The description adds the behavioral context of 'currently loaded', but otherwise doesn't reveal additional traits beyond 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?
Single concise sentence that front-loads the verb and resource. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description provides sufficient context for a simple list operation. It could hint at the return format (e.g., 'returns an array of bundle metadata objects') but is adequate.
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?
No parameters, schema coverage 100%. Baseline is 3 per high coverage. Description adds no parameter info, which is acceptable.
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 specific verb 'List' with resource 'remote bundles' and adds context 'currently loaded into the server', clearly distinguishing it from siblings like 'list_bundles'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus 'list_bundles' or other sibling tools. The description does not mention exclusions or alternatives.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds 'bounded' and 'outward' which give context about traversal behavior, but it does not disclose additional traits like return format, pagination, or performance implications. It does not contradict 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 a single sentence with no filler. It is front-loaded with the verb 'Traverse' and includes essential qualifiers ('bounded', 'outward', 'one or more seed concepts'). Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderate parameter count and no output schema, so more detail about the return value could be helpful. However, the name and description clearly indicate a subgraph traversal, and the annotations and full schema cover safety and parameter semantics. It is adequate but leaves the exact output structure to inference.
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?
Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema, but the schema fully documents all five parameters including defaults and constraints, making further elaboration unnecessary.
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 a specific action (traverse) on a specific resource (bounded OKF subgraph) with a direction (outward from seed concepts). This clearly distinguishes it from siblings like get_graph (whole graph), get_neighbors (immediate neighbors), or find_paths (paths between nodes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a graph traversal from seeds is needed, but it does not explicitly state when to prefer this over alternatives or mention any exclusions. It is a clear purpose but lacks explicit when-to-use or when-not-to-use guidance.
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?
Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds that it returns both incoming and outgoing relationships, which is useful, but it does not disclose any additional behavior like pagination limits or handling of external resources beyond what the schema parameters indicate.
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 a single sentence, concise and front-loaded with the verb and key details. Every word adds value, with no redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with strong annotations and full schema coverage, the description is largely sufficient. It clearly states the core function, though it omits any detail about the output format or potential limitations, which would be helpful in the absence of an output schema.
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?
Schema description coverage is 100%, with all four parameters having clear descriptions. The tool description adds no additional semantics beyond what the schema already provides, so the baseline score of 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 uses a specific verb ('Return') and resource ('incoming and outgoing graph relationships') clearly scoped to 'one OKF concept'. This distinguishes it from sibling tools like get_graph or get_subgraph, which operate on broader graph contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving immediate relationships of a single concept, but it does not explicitly state when to use this tool versus alternatives such as get_subgraph or find_paths. There is no mention of exclusions or preferred scenarios.
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?
Annotations already declare it read-only, idempotent, and non-destructive, lowering the burden. The description adds a key behavioral trait: it does not fetch external resources, which is valuable context. This goes beyond the annotations without contradicting them.
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 a single, directly worded sentence that immediately conveys the tool's core function and key constraint. It is well front-loaded and contains no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only trace tool with a well-documented schema and safety annotations, the description is adequate. It communicates the essential scope and external-fetch behavior, though it could optionally mention the return shape, but this is not critical given no output schema 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?
The input schema covers all four parameters with clear descriptions, so schema coverage is 100%. The tool description itself does not add parameter-specific information beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Trace' and names the resource 'normalized source provenance', making the tool's purpose clear. It also mentions 'through internal concepts' and 'without fetching external resources', which hints at its scope relative to external-fetching tools, though it doesn't explicitly name 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for tracing provenance within the internal concept graph without external fetches, which gives context. However, it offers no explicit guidance on when to prefer this over alternatives like get_graph or inspect_attested_computation, nor does it state when not to use it.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds the key behavioral detail that results are 'ranked summaries' rather than full concept objects. It does not disclose pagination behavior, ranking algorithm, or how filters combine, but given strong annotations this is acceptable.
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 a single, front-loaded sentence with no wasted words. It communicates the core action, resource, output type, and filter categories efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 22 parameters and no output schema, a one-sentence description is insufficient. It mentions 'ranked summaries' but does not explain what a summary contains, how pagination works, or important behaviors like default limits or that results are filtered by all specified criteria. The schema covers parameters, but the return format and search semantics remain largely underspecified.
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?
Schema description coverage is 100%, so the schema fully documents all 22 parameters. The description only adds the generic context of 'text and structured filters', which does not enrich the meaning of any specific parameter beyond what the schema already provides.
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 ('search') with a clear resource ('OKF concepts') and outcome ('return ranked summaries'), and differentiates the tool from siblings like list_concepts or get_concept by emphasizing text and structured filtering with relevance ranking.
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 implies when to use this tool: when you need to search concepts with text or structured filters and get ranked results. However, it does not explicitly state when not to use it or name alternative tools, so it stops short of the explicit 'use X instead' guidance 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds the counting behavior beyond annotations (readOnlyHint, idempotentHint), but lacks details on scope, performance, or other traits.
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?
Single sentence is perfectly concise with no wasted words, earning a top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter count tool, the description is adequate but does not specify the return format, which would be helpful for an agent.
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?
No parameters exist, so baseline score of 4 is appropriate; description does not need to add param meaning.
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 verb 'Count' and the resource 'tags present on concepts in the current OKF index,' making the tool's purpose specific and distinct from 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives; usage is implied by its unique function of counting tags, but no exclusions or context are provided.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds the context of counting within the current index, but does not disclose output format or any additional behavioral traits beyond what annotations indicate.
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?
Single sentence with no superfluous words; front-loaded with the core action and resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with annotations, the description is mostly adequate. However, it ambiguously says 'Count' while the tool name is 'list_types', leaving output format unclear (number vs list). No output schema exists to clarify.
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?
No parameters exist in schema (0 params, 100% coverage). Baseline is 4; description does not add parameter info but correctly implies no user input needed, aligning with the empty 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?
Description clearly states the verb 'Count' and resource 'concept types' with scope 'current OKF index'. It distinguishes from sibling tools like list_concepts (lists individual concepts) and list_relation_types (lists relation types).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance, but the scope 'concept types' implies it is for counting types rather than listing concepts or relation types, providing implicit usage context.
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?
The annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by specifying 'without fetching' and the requirement for an 'explicitly mapped' checkout or bare repository, which are not captured in 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 a single, front-loaded sentence with no unnecessary words. It effectively communicates the core purpose in 14 words, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description should clarify what is returned (likely the blob content). It mentions maxContentBytes but does not explicitly state the return type or behavior on edge cases, leaving some gap. The 'without fetching' and mapping constraints are useful, but return semantics are missing.
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?
Schema coverage is 100%, so the baseline is 3. The description adds slight extra meaning by referencing 'pinned sources[].git entry', which aligns with the sourceId parameter but does not substantially go beyond the schema's own descriptions for concept and sourceId.
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 action (read), the specific resource (pinned sources[].git entry), and the context (explicitly mapped checkout or bare repository). It distinguishes itself from sibling tools like read_bundle_asset or get_concept by focusing on git source entries without fetching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (reading a git blob from a mapped checkout or bare repo without network operations) but does not explicitly state when to use this tool over alternatives. No exclusions or alternative tool references are provided, making it more implied than explicit.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds minimal new behavioral detail beyond the read-only intent ('Analyze... without creating proposals or writes'), but it does not disclose other behaviors like required permissions, rate limits, or result format. Since annotations cover the core safety traits, a 3 is appropriate.
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 a single, information-dense sentence that front-loads the action and purpose. Every clause earns its place: 'local or remote,' 'safe staged OKF v0.2 migration,' and 'without creating proposals or writes' all add distinct value. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only three optional parameters, full schema documentation, and comprehensive annotations. The description covers the tool's core purpose and its key non-destructive constraint. Since there is no output schema, it could have explained return format, but for a read-only analysis tool, the description is sufficiently complete given the other structured metadata.
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?
Schema description coverage is 100%, so the schema already documents all three parameters clearly. The description adds no parameter-specific information (e.g., how bundle, actorMappings, and generatedPaths interact with the migration analysis). This is a baseline 3 because the schema carries the meaning.
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 'Analyze a local or remote bundle' – a specific verb and resource – and clearly states the goal of 'safe staged OKF v0.2 migration.' It explicitly mentions 'without creating proposals or writes,' which differentiates it from tools that do create proposals, such as okf_get_proposal or okf_list_proposals.
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 states when to use this tool: when analyzing a bundle for migration safety. It also provides a key exclusion ('without creating proposals or writes'), implying alternatives that do create writes. However, it does not explicitly name alternative tools like validate_bundle or okf_validate_concept, so the guidance is clear but not fully exhaustive.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description doesn't need to restate safety. It adds value by disclosing the return composition (frontmatter, Markdown body, links), which is not covered by annotations. It doesn't mention error behavior, but the annotation coverage lowers the burden.
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 a single sentence, front-loaded with the core action ('Read one valid OKF concept') and followed by the relevant output details. No wasted words, every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with only four parameters, full schema coverage, and informative annotations, the description is sufficient. It clarifies the conceptual resource and return contents. It doesn't detail response format, but the absence of an output schema makes a slight extra detail desirable; still, the core context is complete.
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?
Schema description coverage is 100%, so the schema fully documents all four parameters, including the anyOf selection logic. The description adds no parameter-specific meaning beyond that, so it receives the schema-covered baseline of 3.
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 the specific verb 'Read' and names the resource 'OKF concept', making it clear this tool retrieves a single concept's full content. It distinguishes itself from sibling list_concepts and search_concepts by explicitly targeting one concept, and mentions the returned components (frontmatter, Markdown body, links), which adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading a single concept by its ID or URI, but it does not explicitly contrast with alternatives like get_neighbors or get_subgraph, nor does it mention when not to use this tool. The context signal of many sibling tools makes the lack of explicit alternative guidance a noticeable gap.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds valuable behavioral context by stating that the tool returns candidate content and validation result, which goes beyond the annotations. No contradictions.
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 a single, 11-word sentence that is front-loaded and efficiently communicates the tool's purpose and output. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 required param, no output schema, annotations provided), the description adequately covers what the tool returns. It could mention that it retrieves the current proposal state or that it requires a valid proposalId, but it is sufficient for an agent to understand core functionality.
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?
Schema coverage is 100% for the single parameter proposalId, which is described as 'Identifier returned when the proposal was created.' The description does not add further semantics beyond what the schema already provides. Baseline score of 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?
Description clearly states the action ('Read') and the resource ('one authoring proposal'), and specifies what is included ('candidate content and validation result'). This differentiates it from siblings like okf_list_proposals which lists proposals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. While the context of sibling tools implies this is for reading a specific proposal rather than listing, the description does not explicitly mention alternatives or prerequisites.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds valuable context: 'non-executing' clarifies the tool does not run the computation, and 'without echoing parameter values' highlights a privacy and security behavior not evident from annotations. This goes beyond the structured hints.
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 a single, focused sentence that begins with the action and states the key output. Every word contributes meaning; there is no fluff or verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity, no output schema, and annotations covering safety/idempotency, the description adequately covers the tool's purpose, its non-executing nature, and its privacy behavior. It lacks details on output format or freshness evaluation, but those are secondary and partially captured by the schema's 'asOf' parameter.
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?
Schema description coverage is 100%, so parameters are already well documented. The description's mention of 'declared parameters' aligns with the schema's 'keyed only by declared names', but adds no new syntax or format details. It earns the baseline 3 because the schema does the heavy lifting.
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 specific verbs 'Check' and 'produce', names the resource 'Attested Computation', and clearly states the output ('non-executing digests'). This distinguishes it from sibling tools like inspect_attested_computation by emphasizing that it prepares rather than inspects and that it does not execute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to validate declared parameters and obtain a digest without executing the computation. However, it does not explicitly state when to use this tool over alternatives like inspect_attested_computation, nor does it mention any exclusions or prerequisites.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool reports conformance and diagnostics, which is consistent but adds little beyond annotations. No contradiction.
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 a single, well-structured sentence that immediately states the core actions. There is no redundant or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is reasonably complete. It mentions the main outputs (conformance, validity, diagnostics). However, it lacks detail on the format or specifics of 'structured diagnostics,' which could be clarified.
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?
The tool has zero parameters, so schema description coverage is 100%. The description does not need to add parameter-level meaning, and a baseline score of 4 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 tool's purpose: reporting OKF conformance, project validity, and structured diagnostics for the entire project. It uses specific verbs and resources, and distinguishes itself from sibling tools like validate_bundle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking the complete project, but provides no explicit guidance on when to use it versus alternatives (e.g., validate_bundle). It does not mention when not to use it or suggest conditions.
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 adds the strong behavioral guarantee 'never execute it' and clarifies the scope ('indexed inert artifacts'), which goes beyond the generic readOnlyHint and idempotentHint annotations. This provides meaningful context about safety and side-effect absence.
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 a single, front-loaded sentence with no filler words. It delivers the core purpose and key constraint efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the well-documented schema and clear annotations, the description provides sufficient context for a read-only inspection tool. However, with no output schema, it does not hint at the return format or shape of the result, which is a minor gap.
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 input schema already documents all four parameters with 100% coverage, so the baseline is 3. The description does not add any parameter-specific semantics beyond what the schema provides (e.g., it doesn't explain how 'asOf' or 'includeComputation' influence the inspection).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('statically inspect') on a specific resource ('Attested Computation contract and indexed inert artifacts'), and adds 'never execute it' to clarify non-execution. However, it does not explicitly distinguish this from sibling tools like 'check_computation_receipt' or 'prepare_attested_computation', so it lacks explicit sibling differentiation.
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 implies this tool is for inspection without execution, and the 'never execute it' phrase provides a clear when-not context. However, it does not explicitly name alternative tools or define when to use them instead, so it stops short of full usage guidance.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds the context that the tool validates a 'proposed new' concept, which is beyond the annotations. It also restates 'without writing a proposal or concept file,' reinforcing the read-only behavior. No additional behavioral traits (e.g., error handling) are disclosed, but the added context justifies a score above baseline.
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 a single sentence that is directly front-loaded with the action and resource, and every word contributes to the purpose. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate given the rich schema and annotations, but it lacks details about the validation result (e.g., return format, success/failure behavior). Since no output schema exists, the description should have mentioned what the tool returns or how the validation outcome is expressed. This is a noticeable gap for a validation tool.
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?
Schema description coverage is 100%, so the parameters are fully documented in the input schema. The description itself does not add any parameter-level semantics beyond what the schema already provides, so the baseline of 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 verb 'validate' and the resource 'proposed new OKF concept', and the phrase 'without writing a proposal or concept file' adds a unique scope that distinguishes it from sibling tools like validate_project or validate_bundle. This is a specific and unambiguous purpose.
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 implies usage context: validating a proposed new concept before any files are written. It clearly indicates this is a pre-write validation tool, but it does not explicitly name alternatives or exclusion scenarios. Still, the context is clear enough for an agent to decide when to use it.
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?
Annotations already indicate read-only and idempotent behavior. The description adds meaningful behavioral detail: it does not attest, echo values, or persist the receipt. This goes beyond what annotations provide and clarifies the tool's side-effect-free nature.
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?
A single, front-loaded sentence that states the main purpose and then lists explicit exclusions. Every clause earns its place, with no redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two well-described parameters and no output schema, the description and schema together cover the tool's behavior, side effects, and return shape (field names only). It could explicitly state the return format as a list, but the schema's 'only its field names are returned' is sufficient for this simple check tool.
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 input schema fully describes both parameters, including that the receipt is ephemeral and only field names are returned. The description adds no additional parameter-specific meaning beyond reinforcing the 'no echo values' behavior, so the baseline of 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 uses a specific verb ('check') and identifies the exact object ('receipt field presence'), while explicitly excluding attestation, echo, and persistence. This clearly differentiates it from sibling tools like prepare_attested_computation and inspect_attested_computation.
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 gives explicit negative guidance ('never attest, echo values, or persist'), which tells the agent when not to use this tool. However, it doesn't explicitly name alternative tools or describe a positive 'use when' scenario, so it falls just short of a 5.
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?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds that it summarizes counts, which is consistent and provides minimal additional behavioral context beyond 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 a single concise sentence that is front-loaded with the key action and entities. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is complete enough for a simple summary tool. It could be improved by clarifying what 'graph health counts' entails, but it is adequate.
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?
The tool has zero parameters, and the input schema has 100% description coverage. According to guidelines, baseline is 4 for 0 parameters, and the description does not need to add parameter 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 the tool summarizes counts of bundle, concept, edge, type, tag, and graph health. This is a specific verb-resource pair that distinguishes it from sibling tools like list_bundles or list_concepts which return items rather than summaries.
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 implies usage for obtaining summary statistics rather than full lists, providing clear context. However, it does not explicitly state when not to use it or mention alternatives, leaving some ambiguity for agents.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds meaningful behavior beyond annotations: 'digest verification and byte bounds' indicating integrity checks and content size limits, which helps the agent anticipate side effects or constraints.
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 a single, front-loaded sentence with no fluff. It packs the verb, resource, key qualifiers, and two behavioral notes into a compact structure that is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with strong annotations and fully documented parameters, the description covers the essential purpose and behavioral traits. However, since there is no output schema, the description would benefit from briefly stating what is returned (e.g., asset content or metadata), making that the only minor gap.
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?
Schema description coverage is 100%, so all parameters (uri, path, bundle, maxContentBytes) are already documented with their own descriptions. The tool description only re-emphasizes the reference modes and byte bounds, adding no new semantic meaning beyond what the schema provides.
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 ('Read') and resource ('bundle asset'), with qualifiers 'explicitly referenced, already indexed' that clearly distinguish it from sibling listing or validation tools. It is unambiguous and directly tied to the tool's function.
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 phrase 'explicitly referenced, already indexed' establishes a clear precondition: this tool is for reading known assets, not for discovery. While it does not explicitly name alternative tools for searching/listing, the context implies when it should be used 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?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that bundles are 'currently loaded', which is useful behavioral context. No contradictions.
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?
Single sentence with all essential information, no waste.
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 tool simplicity (no params, no output schema, annotations present), the description is complete. It specifies what is listed (bundles), scope (local/remote), and state (currently loaded).
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?
No parameters, so schema coverage is 100%. The description does not need to add parameter info. Baseline for 0 params is 4.
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?
Description clearly states 'List the local and remote OKF bundles currently loaded by the server', using specific verb 'list' and resource 'bundles', and specifies scope (local/remote). It distinguishes from sibling 'list_remote_bundles' by including 'local'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The description implies it is the tool for listing all bundles, but does not mention alternatives like 'list_remote_bundles'.
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?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds context beyond annotations by explaining the tool reports two separate aspects (OKF conformance and project validity) and operates on either a single bundle or the full index, which is useful 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 a single sentence with no superfluous words. It front-loads the core action and scope, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description covers the main functionality and scope adequately. However, it does not describe the structure of the returned report (e.g., formats or fields), which could be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the parameter 'bundle' is described in the schema as 'Optional bundle id to validate in isolation', the tool description adds critical context: if omitted, it validates the full current index. This clarifies the optional behavior 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 specific verbs ('Report') and resources ('OKF conformance', 'project validity') and clearly distinguishes from sibling tools like 'validate_project' by mentioning separate reporting. It also specifies the scope ('one bundle or the full current index').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (for OKF conformance and project validity reports) but does not explicitly state when not to use or provide alternative tool recommendations. The distinction from 'validate_project' is implied but not directly stated.
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 MCP server](https://glama.ai/mcp/servers/mfdaves/okf-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mfdaves/okf-mcp)

Score Badge

Copy to your README.md:

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

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/mfdaves/okf-mcp'

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