Knavigator MCP v2

• knav_field

  554454A4.6

  This is a well-crafted tool description that clearly defines the tool's purpose and differentiates it from siblings, with strong usage guidelines. The schema provides thorough parameter semantics, and the description adds value without redundancy. Minor gaps in behavioral transparency (e.g., return format) are acceptable given the readOnlyHint annotation and the tool's straightforward nature.

  5

  Purpose Clarity · 25%The description clearly states the tool's purpose: to describe a field's definition and usage total, covering type, object, connection, equation, settings, and usage count. It explicitly distinguishes itself from sibling tools by naming knav_uses, knav_rank, and knav_ripple for related but different queries, making it easy for an agent to select the right tool.

  5

  Usage Guidelines · 20%The description provides explicit guidance on when to use this tool versus alternatives: use knav_uses for itemized usage locations, knav_rank for cross-field usage comparison, and knav_ripple for downstream recalculation. This clear differentiation helps the agent choose the correct tool for the task.

  4

  Behavioral Transparency · 20%The readOnlyHint annotation already indicates a safe read operation, and the description adds context about the tool's scope (single field definition and usage total) without contradicting the annotation. It does not detail return format or potential errors, but given the annotation coverage, the description provides sufficient additional context.

  4

  Parameter Semantics · 15%The schema covers all parameters with detailed descriptions, including the target parameter's resolution rules and app_id's importance. The description adds value by explaining the tool's focus on a single field, but the schema already provides comprehensive parameter semantics, so the description's contribution is moderate.

  5

  Conciseness & Structure · 10%The description is concise, front-loaded with the core purpose, and uses a clear structure: first defining what the tool does, then listing related tools for alternative use cases. Every sentence adds value without redundancy, making it efficient for an agent to parse.

  4

  Contextual Completeness · 10%Given the tool's moderate complexity (4 parameters, no output schema), the description is complete enough: it explains the tool's scope, differentiates from siblings, and the schema covers parameter details. It could mention return format, but the lack of output schema and the tool's read-only nature make the current description adequate.

  params

  4 (1 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  1

  bytes

  1926

  hash

  14ff306e98e6a0d5

• knav_uses

  554454A4.6

  The tool description is well-crafted, clearly distinguishing its scope from sibling tools and providing explicit usage guidance. It leverages the readOnlyHint annotation and schema descriptions effectively, with minor gaps in output format details. Overall, it scores high across all dimensions.

  5

  Purpose Clarity · 25%The description clearly states the tool's purpose: to show where a field is used, with specific groupings (Used In / Depended On By / Depends On) and screen-level grouping. It distinguishes from sibling tools by explicitly naming narrower neighbors and their specific scopes.

  5

  Usage Guidelines · 20%The description explicitly says 'Direct (depth-1) references only' and directs users to use knav_ripple for transitive chains. It also lists narrower alternatives (knav_editable, knav_display_rules, etc.) with their specific purposes, making it clear when to use this tool versus others.

  4

  Behavioral Transparency · 20%The description explains the output grouping (by screen, with three categories) and the depth limitation. It does not detail the exact output format or whether it returns raw data or a summary, but the readOnlyHint annotation covers side effects. The description adds value by clarifying the depth-1 scope and grouping behavior.

  4

  Parameter Semantics · 15%The schema already provides detailed descriptions for app_id and target, including format and required conditions. The description does not add much beyond the schema, but it reinforces the target as a field key or name. The refresh parameter is also well-described in the schema. Overall, the schema covers most semantics, so the description adds minimal extra value.

  5

  Conciseness & Structure · 10%The description is concise and well-structured, using semicolons and bullet-like separators to list alternatives. It avoids redundancy and focuses on key differentiators. The length is appropriate for the complexity of the tool's scope.

  4

  Contextual Completeness · 10%The description provides sufficient context for the tool's scope (depth-1, grouped by screen) and its relationship to siblings. It does not explain the output schema (since none is provided), but the description is complete enough for an agent to decide when to use it. The lack of output details is acceptable given the tool's read-only nature.

  params

  3 (1 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  1

  bytes

  1725

  hash

  ac7fb59c7003a865

• knav_editable

  554355A4.5

  This is a well-crafted tool description that clearly defines its purpose, distinguishes it from sibling tools, and provides explicit usage guidelines. The description adds value beyond the annotations and schema, making it easy for an agent to select and invoke correctly. Minor room for improvement exists in parameter semantics, but the schema already covers that.

  5

  Purpose Clarity · 25%The description clearly states the tool's purpose: to find views where a field is editable, specifically via [Editable] form inputs and [Inline Edit] table columns. It also distinguishes itself from sibling tools by explicitly contrasting with knav_uses and knav_writes, making its scope unambiguous.

  5

  Usage Guidelines · 20%The description provides explicit guidance on when to use this tool versus alternatives: 'For every reference (not just editable ones) use knav_uses; for every mechanism that sets the field, including record rules and tasks, use knav_writes.' This clearly delineates the tool's usage context and exclusions.

  4

  Behavioral Transparency · 20%The description adds behavioral context beyond the readOnlyHint annotation by specifying that it covers only user-driven edits, not other mechanisms like record rules or tasks. This clarifies the tool's scope and limitations, which is valuable for an agent deciding whether to use it. The annotation already indicates read-only, and the description reinforces and expands on that.

  3

  Parameter Semantics · 15%The input schema already provides detailed descriptions for all three parameters (app_id, target, refresh), covering 100% of the schema. The description does not add additional parameter semantics beyond what the schema provides, so a baseline score of 3 is appropriate.

  5

  Conciseness & Structure · 10%The description is concise and front-loaded, with the core purpose stated in the first sentence. It then provides necessary usage guidance in a single additional sentence. Every sentence earns its place, with no redundancy or fluff.

  5

  Contextual Completeness · 10%Given the tool's moderate complexity (3 parameters, no output schema), the description is complete. It explains the tool's scope, contrasts with siblings, and the schema covers parameter details. The description is sufficient for an agent to understand what the tool does and when to use it.

  params

  3 (1 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  1

  bytes

  1501

  hash

  9a4b57a1cca58ac7

• knav_display_rules

  544455A4.5

  This is a high-quality description: purpose is explicit with sibling differentiation, usage guidelines name alternatives, and parameter semantics are fully handled by the schema with helpful context from the description. The tool is read-only per annotations Echo, and the description does not contradict that. Slight improvements could come from addressing pagination or output format, but for a display/listing tool this is near-exemplary.

  5

  Purpose Clarity · 25%The description clearly states the tool displays rules referencing a field, including form/view display rules and conditional-format rules, with conditions. It specifies the resource (display rules) and the action (display), and distinguishes from sibling knav_conditional_rules. It also clarifies exclusions (page-level rules).

  4

  Usage Guidelines · 20%The description explicitly says what the tool does and what it does NOT include, explicitly naming the alternative for conditional rules and page-level rules. It gives a clear when-to-use context, but does not state when NOT to use it overall beyond the exclusions.

  4

  Behavioral Transparency · 20%Annotations provide readOnlyHint=true, which the description supports by indicating it only displays rules game, with no contradiction. The description adds context about what rules are included/excluded)Skip that a read-only display operation does not give many behavioral traits to disclose, so a 4 is justified.

  4

  Parameter Semantics · 15%Schema coverage is 100% with parameter descriptions. The description adds context about which field is targeted and the nature of the rules. The app_id parameter is well-covered by schema, so description does not need to repeat. The target parameter is clearly explained in the schema, but the description adds the relationship to knav_conditional_rules, which helps disambiguate.

  5

  Conciseness & Structure · 10%The description is two sentences: the first clearly states the purpose and scope, the second excludes related tools confirmation. Every sentence adds value, no filler. It is front-loaded with the core function and then provides necessary contrasts.

  5

  Contextual Completeness · 10%The tool has 3 params with 100% schema coverage)Skip the description adds clarity on scope, exclusions, and interplay with sibling tools. No output schema exists, but the description clarifies what rules are returned. For a read-only display rule listing, this is sufficiently comprehensive.

  params

  3 (1 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  1

  bytes

  1579

  hash

  2d32e7e3f756bebe

• knav_conditional_rules

  554454A4.6

  This is a high-quality description that clearly defines the tool's purpose, distinguishes it from siblings, and provides explicit usage guidance. It leverages the read-only annotation effectively and adds meaningful parameter context. Minor gaps in output format details prevent a perfect score, but overall it is exemplary.

  5

  Purpose Clarity · 25%The description clearly states the tool lists a field's own conditional (auto-set) rules with set-to values and trigger criteria, in builder order. It explicitly distinguishes from knav_display_rules and knav_writes, making its unique purpose unmistakable.

  5

  Usage Guidelines · 20%It provides explicit when-to-use guidance: use for a field's own auto-set rules, and explicitly says NOT for display rules (knav_display_rules) and for other setters use knav_writes. This is a model of clear usage direction.

  4

  Behavioral Transparency · 20%Annotations already declare readOnlyHint=true, so the description doesn't need to restate safety. It adds valuable context: the tool returns rule counts for objects, and the 'in builder order' detail. It could mention pagination or output format, but given the read-only annotation, this is sufficient.

  4

  Parameter Semantics · 15%Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the target parameter can be a field or object, and clarifies the app_id requirement context (multiple apps, entity key ambiguity). This elevates it above baseline.

  5

  Conciseness & Structure · 10%The description is two sentences, front-loaded with the core purpose, and every clause adds value. It efficiently contrasts with siblings and provides a usage pointer without fluff.

  4

  Contextual Completeness · 10%Given the tool's moderate complexity (3 params, no output schema), the description covers the key aspects: what it returns, how to use it, and when not to. It could detail the output structure for object queries, but the description is complete enough for an agent to select and invoke correctly.

  params

  3 (1 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  1

  bytes

  1749

  hash

  3aa318d547e21b87

• knav_emails_using

  433443A3.5

  The tool description is generally clear about its purpose and parameters, with good schema coverage. However, it could be more concise and provide additional behavioral details, especially regarding output, to fully guide the agent.

  4

  Purpose Clarity · 25%The description clearly states the tool's purpose: finding emails that reference a field, with the role the field plays. It distinguishes from sibling tools by mentioning 'knav_emails' for email-related queries and 'knav_uses' for non-email references, but the phrasing is somewhat convoluted.

  3

  Usage Guidelines · 20%The description provides some guidance on when to use this tool versus alternatives (e.g., 'For an object's email count or its full sender list use knav_emails; for the field's non-email references use knav_uses'), but it does not explicitly state when to use this tool over others or provide clear usage scenarios.

  3

  Behavioral Transparency · 20%The readOnlyHint annotation is present, but the description does not elaborate on behavioral aspects such as whether the tool returns a list, how it handles missing fields, or any side effects. The description focuses on the query semantics but lacks detail on output behavior.

  4

  Parameter Semantics · 15%The schema descriptions for parameters are detailed, explaining the app_id and target fields with examples and conditions. The refresh parameter is also described. However, the description does not add much beyond the schema, but the schema itself is comprehensive.

  4

  Conciseness & Structure · 10%The description is relatively concise, but the phrasing is repetitive and somewhat awkward (e.g., 'One field in, its emails out: each email named with where it is sent from and the role the field plays in it'). It could be streamlined for clarity.

  3

  Contextual Completeness · 10%The description provides enough context for the tool's purpose and relationships to sibling tools, but it lacks information about the output format or any constraints. Given the schema has no output schema, the description could be more complete about what the tool returns.

  params

  3 (1 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  1

  bytes

  1557

  hash

  6bbb6766f42cce8d

• knav_object

  554455A4.7

  This is an exemplary tool description. It clearly defines the tool's purpose, provides explicit usage guidance with named alternatives, and adds behavioral context beyond the annotations (e.g., caching behavior, flag semantics). The parameter semantics are well-supported by the schema, and the description is concise yet comprehensive, making it easy for an agent to select and invoke correctly.

  5

  Purpose Clarity · 25%The description clearly states the tool's primary purpose: 'Object summary' with optional flags to get fields, connections, or views. It explicitly distinguishes from siblings by naming knav_graph and knav_objects for app-wide queries, and mentions knav_views for the same list. The verb 'summary' and resource 'object' are specific and unambiguous.

  5

  Usage Guidelines · 20%The description provides explicit when-to-use guidance: 'Summary by default; set fields, connections or views to get the full field list...' and explicitly names alternatives: 'For the app-wide object-to-object graph or a path between two objects use knav_graph; for the app-wide object list use knav_objects.' This is a model of usage guidance.

  4

  Behavioral Transparency · 20%Annotations provide readOnlyHint=true, and the description does not contradict this. The description adds behavioral context beyond annotations: it explains the default behavior (summary) and the effect of flags, and mentions the refresh flag's caching behavior ('serve the cached snapshot, revalidated automatically when older than the freshness window (~30s)'). It does not detail return format, but given the read-only nature and the flag-based behavior, this is sufficient.

  4

  Parameter Semantics · 15%Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the flag semantics collectively: 'set fields, connections or views to get the full field list, this object's own inbound+outbound connections, or the views sourced on it' — this clarifies the relationship between flags and output, which the schema descriptions do not fully convey. It also clarifies the app_id requirement and the target flexibility, but those are already in the schema. The description adds moderate value beyond the schema.

  5

  Conciseness & Structure · 10%The description is a single, dense paragraph that front-loads the core purpose and then explains flags and alternatives. Every sentence earns its place: the first sentence states the default and flag options, the second explains the flag outputs, and the third directs to alternatives. No fluff or repetition.

  5

  Contextual Completeness · 10%Given the tool's complexity (6 parameters, 3 boolean flags, app_id requirement, target flexibility) and the absence of an output schema, the description is remarkably complete. It covers the default behavior, each flag's effect, the app_id requirement and its rationale, and the target formats. It also references sibling tools for related queries. The read-only annotation covers safety, and the description fills in all other behavioral gaps.

  params

  6 (1 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  1

  bytes

  2073

  hash

  1364dd3c07e192ab

• knav_objects

  554455A4.7

  This is a high-quality tool description that clearly defines the tool's purpose, provides explicit usage guidance with alternatives, and adds valuable behavioral context beyond the annotations. It is concise yet complete, with no contradictions. The only minor gap is that it doesn't explicitly state the read-only nature, but the annotation covers that.

  5

  Purpose Clarity · 25%The description clearly states the tool's purpose: 'App-wide object inventory: one row per object (key, name, role flag, field & task counts) plus app totals.' It specifies the resource (objects) and the scope (app-wide), and distinguishes it from siblings like knav_object (for one object in depth) and knav_roles (for login capability).

  5

  Usage Guidelines · 20%The description provides explicit usage guidance: 'Set roles to list only the role (profile) objects' and 'For one object in depth use knav_object.' It also clarifies when not to use it: 'for whether each role can actually log in use knav_roles.' This clearly differentiates from alternatives.

  4

  Behavioral Transparency · 20%Annotations include readOnlyHint: true, which the description does not contradict. The description adds behavioral context beyond the annotation: it explains the 'roles' flag behavior and the distinction between role flags and login capability. It also implies a read-only inventory operation, consistent with the annotation. No contradiction.

  4

  Parameter Semantics · 15%Schema description coverage is 100%, so the schema already documents all three parameters. The description adds value by explaining the 'roles' parameter's effect ('list only the role (profile) objects') and the app_id parameter's criticality (omitted or stale app_id yields wrong app). It also clarifies the refresh parameter's default behavior. This goes beyond the schema's basic descriptions.

  5

  Conciseness & Structure · 10%The description is concise and front-loaded: the first sentence states the core purpose, followed by usage guidance and cross-references. Every sentence adds value, with no fluff. It is well-structured for quick scanning.

  5

  Contextual Completeness · 10%Given the tool's moderate complexity (3 optional parameters, no output schema), the description is complete: it covers the tool's scope, parameter usage, and relationships to sibling tools. It also warns about the app_id pitfall, which is critical for correct usage. No output schema means the description doesn't need to explain return values, but it does mention the row contents.

  params

  3 (0 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  0

  bytes

  1512

  hash

  2fae0b94b7486974

• knav_view

  554344A4.3

  Well-structured description for a complex read-only view inspection tool, with strong sibling differentiation and parameter semantics. The description clearly explains the diff/clone-drift feature and disambiguates from related tools. Minor gap: doesn't state output structure, but the 100% schema coverage compensates.

  5

  Purpose Clarity · 25%The description opens with a specific verb+resource: 'A view's source object, rule blocks (record/inline-edit/display/submit/action-link/column-styling), field references, and emails it sends.' This clearly enumerates the scope and distinguishes it from siblings like knav_object (the object behind it) and knav_scene (the page). The mention of options like rules-summary and diff further sharpens purpose.

  5

  Usage Guidelines · 20%Explicitly states when to use and when not: 'For the OBJECT behind it use knav_object; for the PAGE it sits on use knav_scene; for the app-wide view census use knav_views.' Also gives a targeted use case: 'Set rules-summary for rule counts only; pass diff=<view> for a clone-drift audit.' This is excellent guidance for choosing between siblings.

  4

  Behavioral Transparency · 20%Annotations are null, so the description carries the full burden. It discloses that the tool returns source object, rule blocks, field references, and emails, describes the diff audit behaviorci, notes rules-summary only returns counts, and that diff accepts a second view. It does not mention any side effects (likely none, as a read tool), so a 4 is warranted – it's thorough on behavior but doesn't explicitly state read-only semantics beyond what annotations provide.

  3

  Parameter Semantics · 15%Schema description coverage is 100% so the baseline is 3. The description adds cross-references (diff, rules-summary) and clarifies behavior (rules-limit drops from structured output, include-body affectsonly text output), but the schema already documents each parameter thoroughly. The description's value is mostly in orchestration guidance (diff + full interplay) rather than parameter meanings themselves.

  4

  Conciseness & Structure · 10%The description is dense but front-loaded: the core purpose is stated unambiguously, and cross-tool references are packed into the final sentence. It could be slightly tighter (the app_id parameter discussion is lengthy) but remains efficient.

  4

  Contextual Completeness · 10%For a tool with 8 parameters sequel but 1 required, the description explains the diff workflow, counters it against rules-summary, and points to alternatives. It doesn't enumerate the exact output structure of the view description, but the output schema likely covers that. The description covers the key modality distinction (summary vs full) and the clone-drift audit use case.

  params

  8 (1 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  1

  bytes

  2443

  hash

  84a70a7f02efafd9

• knav_scene

  554354A4.4

  This is a well-crafted tool description that clearly states its purpose, provides explicit usage guidelines with alternatives, and leverages annotations effectively. It is concise and complete, with only minor gaps in behavioral detail (e.g., return format) that are acceptable given the read-only annotation and schema coverage.

  5

  Purpose Clarity · 25%The description clearly states the tool's purpose: to describe a page's path, live URL, builder link, login requirement, views, child pages, and page rules. It distinguishes itself from siblings by explicitly naming alternatives (knav_scenes, knav_view, knav_object) and specifying scope options.

  5

  Usage Guidelines · 20%The description provides explicit guidance on when to use this tool versus alternatives: 'For the whole page tree use knav_scenes; for one VIEW on the page use knav_view; for a data OBJECT use knav_object.' It also explains how to scope the output with flags like rules/views/children/entered-from, giving clear context for selection.

  4

  Behavioral Transparency · 20%Annotations include readOnlyHint=true, and the description does not contradict this. The description adds behavioral context beyond annotations by explaining the scoping flags and the default behavior (returning all sections unless scoped). It does not detail return format or pagination, but for a read-only tool with annotations, this is sufficient.

  3

  Parameter Semantics · 15%Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the scoping flags (rules/views/children/entered-from) and the target parameter's accepted formats (scene key, name, URL slug), but it does not add significant meaning beyond the schema's descriptions. Baseline 3 is appropriate.

  5

  Conciseness & Structure · 10%The description is concise, front-loaded with the core purpose, and every sentence adds value. It efficiently communicates the tool's scope, alternatives, and usage in two sentences without redundancy.

  4

  Contextual Completeness · 10%Given the tool's moderate complexity (7 params, 1 required, no output schema), the description is complete enough. It covers the tool's purpose, scoping options, and alternatives. The schema covers all parameters, and the description adds usage context. It could mention return format, but the lack of output schema and the read-only nature make this acceptable.

  params

  7 (1 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  1

  bytes

  1937

  hash

  caa9d98466dc4986

• knav_scenes

  554454A4.6

  This is a well-crafted description that clearly defines the tool's purpose, differentiates it from siblings, and provides essential usage guidance, especially for the app_id parameter. It leverages the readOnlyHint annotation while adding behavioral context about caching and tree expansion. The only minor gap is the lack of explicit return format details, but overall it is highly effective for an AI agent.

  5

  Purpose Clarity · 25%The description clearly states the tool's purpose: it provides an app-wide page (scene) tree with recursive subtree page counts, role restrictions, and orphaned-parent-slug warnings. It distinguishes itself from the sibling tool knav_scene by explicitly directing users to use knav_scene for one page's details, making the scope and differentiation clear.

  5

  Usage Guidelines · 20%The description explicitly states when to use this tool (for the app-wide tree) and when not to (for one page's details, use knav_scene). It also provides guidance on the 'tree' parameter to expand nested descendants, and the app_id parameter is thoroughly explained with conditions for omission and the need to call knav_apps first, offering clear usage context.

  4

  Behavioral Transparency · 20%The readOnlyHint annotation already indicates a safe read operation, and the description adds valuable behavioral context: it mentions the default flat root rollup, the ability to expand the tree, and the inclusion of orphaned-parent-slug warnings. It also explains the caching behavior with the refresh parameter, which is beyond the annotation's scope, though it doesn't detail the exact output structure.

  4

  Parameter Semantics · 15%The schema already provides 100% coverage with detailed descriptions for each parameter, so the baseline is 3. The description adds extra value by explaining the default behavior of the tree parameter (flat root rollup) and the implications of app_id (entity keys meaning different things in different apps), which enhances understanding beyond the schema's descriptions.

  5

  Conciseness & Structure · 10%The description is concise and well-structured, with a clear first sentence stating the tool's purpose, followed by a brief note on the tree parameter and a pointer to the sibling tool. The app_id parameter description is lengthy but necessary due to its complexity, and the overall text is front-loaded with the most critical information.

  4

  Contextual Completeness · 10%Given the tool's moderate complexity (3 parameters, no output schema), the description covers the key aspects: what the tool returns (tree with counts, restrictions, warnings), how to control expansion, and the critical app_id requirement. It lacks explicit details on the return format, but the absence of an output schema and the read-only nature make this acceptable, and the description is sufficient for an agent to use the tool correctly.

  params

  3 (0 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  0

  bytes

  1505

  hash

  847daca3bf3f963b

• knav_views

  554444A4.5

  This is a well-crafted description that clearly explains the tool's dual purpose, provides explicit usage guidance, and adds behavioral context beyond the annotations. It effectively differentiates from sibling tools and covers parameter semantics thoroughly. Minor room for improvement in conciseness, but overall it is a high-quality description.

  5

  Purpose Clarity · 25%The description clearly states the tool's dual purpose: an app-wide view inventory by type and a per-object view listing. It uses specific verbs ('list', 'census') and distinguishes from the sibling tool knav_view ('For ONE view use knav_view').

  5

  Usage Guidelines · 20%The description explicitly explains when to use this tool vs alternatives: 'For ONE view use knav_view' and mentions knav_apps for app_id resolution. It also clarifies the optional target and editable parameters, providing clear context for when to use them.

  4

  Behavioral Transparency · 20%Annotations provide readOnlyHint=true, and the description adds context about the cached snapshot and refresh behavior, which is beyond the annotation. It also explains the app_id requirement and potential pitfalls (omitted app_id yields wrong app), which is valuable behavioral transparency.

  4

  Parameter Semantics · 15%Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the purpose of each parameter in context (e.g., 'editable' for write-capability census, 'target' for object-specific listing). It also clarifies the app_id requirement and refresh behavior, which are not fully captured in the schema.

  4

  Conciseness & Structure · 10%The description is dense but well-structured, with clear sections for each mode. It is slightly long but every sentence adds value, and the key differentiator (knav_view) is mentioned early. The use of quotes and dashes helps readability.

  4

  Contextual Completeness · 10%Given the tool's complexity (multiple modes, optional parameters, app_id nuances) and the lack of an output schema, the description covers the essential aspects: what it returns (counts, lists), how to use it, and important caveats. It could mention return format details, but the description is sufficient for an agent to select and invoke correctly.

  params

  5 (0 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  0

  bytes

  2018

  hash

  7de2f5fedee93ae8

• knav_ripple

  555544A4.8

  This is a well-crafted, high-quality tool description. It clearly distinguishes knav_ripple from sibling tools like knav_uses and knav_formulas, provides detailed when-to-use guidance (including when app_id is required), and enriches parameter semantics with behavioral details. The only minor shortcoming is the slightly verbose app_id parameter explanation, but overall it excels across all dimensions.

  5

  Purpose Clarity · 25%The description clearly states the tool's purpose: it recalculates the transitive recalc chain across any number of depth levels when a field changes, including cross-object hops. It explicitly distinguishes itself from sibling tools knav_uses (depth 1) and knav_formulas (per-object catalogue), making it easy to select the right tool.

  5

  Usage Guidelines · 20%The description explicitly states when to use this tool, including the depth limitation of knav_uses and the per-object scope of knav_formulas negative examples. It also provides guidance on parameter usage like depth to cap the walkate and app_id requirements, including when app_id is required and what happens if omitted.

  5

  Behavioral Transparency · 20%The description goes beyond the readOnlyHint annotation by clarifying that the tool performs transitive analysis (a read-only query) and explains the scope of the walk (full chain unless depth is capped). It also discloses the behavior of app_id requirement and cache refresh behavior, which are not inferable from annotations alone. With readOnlyHint already present, the added context about scope and cross-object traversal is valuable.

  5

  Parameter Semantics · 15%Schema coverage is 100%, and the description enriches all parameters significantly. The depth parameter is described as a cap with default, app_id gets a full multi-sentence explanation including when it's required and why, target's purpose is clarified, and refresh is described with freshness semantics. This lifts the value beyond the schema's basic field-based descriptions.

  4

  Conciseness & Structure · 10%The description is front-loaded with the core purpose (transitive recalc chain) and quickly distinguishes from siblings. The parameter explanations are more extensive, so the overall description is moderately long, but each sentence adds meaning. Minor trimming of the parenthetical app_id details could tighten it, but it's structured logically.

  4

  Contextual Completeness · 10%With a readOnly annotation)SkipWait no output schema, and rich parameter descriptions, the description is quite complete. It clearly explains the tool's scope (transitive chains vs depth-1 direct references) and cross-object labeling. The description adds the cross-object hops labeling which isn't obvious from schema alone. It could mention what the return format looks like, but the absence of an output schema means the extra detail may not be critical.

  params

  4 (1 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  1

  bytes

  1665

  hash

  652ace8b5a47bbd9

• knav_formulas

  554455A4.7

  This is a high-quality tool description that clearly defines its purpose, differentiates from siblings, and provides rich parameter semantics. It leverages the readOnlyHint annotation while adding behavioral context about caching and return content. The description is concise, well-structured, and complete for the tool's complexity, earning top scores across all dimensions.

  5

  Purpose Clarity · 25%The description clearly states the tool's purpose: it returns all calculated fields on an object, including formula text, aggregate details, and source fields. It explicitly distinguishes itself from siblings by naming knav_ripple and knav_field for different use cases, and the phrase 'Per-object catalogue' reinforces its scope.

  5

  Usage Guidelines · 20%The description provides explicit guidance on when to use this tool versus alternatives: 'For the downstream chain from ONE field across objects use knav_ripple; for a field's own definition use knav_field.' It also implies the tool is for object-level queries, and the app_id parameter description includes clear instructions on when it is required and how to obtain it.

  4

  Behavioral Transparency · 20%The readOnlyHint annotation already indicates a safe read operation, and the description adds context about the tool's behavior: it returns a catalogue of calculated fields, including aggregates and source fields, and mentions the caching/refresh behavior in the refresh parameter. It does not contradict annotations, and the additional detail about what the tool returns goes beyond the annotation.

  4

  Parameter Semantics · 15%The schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the purpose of the tool in relation to parameters (e.g., 'target' is an object key or name, 'refresh' controls cache freshness), and the app_id parameter description is rich with usage context (when required, how to get it, and why it matters). This exceeds the baseline.

  5

  Conciseness & Structure · 10%The description is concise and front-loaded: the first sentence immediately states what the tool does and what it returns. It uses a clear structure with a summary, a quoted question, and explicit sibling references. Every sentence adds value, and there is no fluff or repetition.

  5

  Contextual Completeness · 10%Given the tool's moderate complexity (3 parameters, no output schema), the description is complete: it explains the return content (formula text, aggregates, source fields), the scope (per-object), and the relationship to sibling tools. The app_id parameter description covers a common pitfall (multiple apps), and the refresh parameter is explained. No critical information is missing.

  params

  3 (1 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  1

  bytes

  1604

  hash

  e279371fd41f96d3

• knav_writes

  553344A4.1

  The description is well-crafted, clearly stating the tool's purpose and usage guidelines, with explicit differentiation from sibling tools. It leverages the readOnlyHint annotation effectively and provides adequate parameter context. Minor gaps in behavioral transparency and return format details prevent a perfect score, but overall it is a strong, helpful definition.

  5

  Purpose Clarity · 25%The description clearly states the tool's purpose: it identifies what writes records into an object or what sets a field, with a specific verb ('writes') and resource ('object' or 'field'). It distinguishes itself from siblings by explicitly contrasting with knav_uses for read references and knav_editable for user-input-only mode.

  5

  Usage Guidelines · 20%The description provides explicit guidance on when to use this tool: to answer 'where do records of X come from?' or 'what writes this field?'. It also gives a clear exclusion: 'For READ references use knav_uses.' This directly addresses when not to use it and names the alternative tool.

  3

  Behavioral Transparency · 20%The readOnlyHint annotation is true, and the description does not contradict it; it describes a read-only analysis tool. The description adds context about the field mode being a superset of knav_editable, which is useful, but it does not disclose other behavioral aspects like caching behavior or potential performance implications. With annotations covering the safety profile, a score of 3 is appropriate.

  3

  Parameter Semantics · 15%The schema description coverage is 100%, so the schema already documents all three parameters. The description adds some context about the target parameter (object key/name or field key/name) and the refresh parameter's default behavior, but it does not add significant new meaning beyond what the schema provides. Baseline 3 is appropriate.

  4

  Conciseness & Structure · 10%The description is a single, dense paragraph that front-loads the core purpose and then adds important nuances. It is efficient with no wasted words, but the density might make it slightly harder to parse quickly. Still, it earns a high score for being concise and structured.

  4

  Contextual Completeness · 10%Given the tool's moderate complexity (two modes: object and field), the description covers the key aspects: what it does, how it differs from siblings, and the field mode's relationship to knav_editable. It lacks details on return format, but since there is no output schema, the description could have been more explicit about what the response contains. However, the description is sufficient for an agent to understand the tool's scope and use it correctly.

  params

  3 (1 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  1

  bytes

  1717

  hash

  54cc01ccbdb7d6c9

• knav_emails

  544454A4.4

  The tool description is well-crafted, clearly distinguishing it from sibling tools and providing detailed parameter semantics. It is concise and transparent, with no contradictions. Minor gaps include lack of explicit default behavior for views and output format details, but overall it is highly effective.

  5

  Purpose Clarity · 25%The description clearly states the tool counts emails per object, split by source, and distinguishes it from the sibling tool knav_emails_using which filters by field. It also explains the two modes (per-object vs app-wide) and the optional view enumeration.

  4

  Usage Guidelines · 20%The description explains when to use the tool (for email counts per object or app-wide inventory) and contrasts with knav_emails_using for field-specific queries. It does not explicitly state when not to use it, but the sibling distinction provides clear guidance.

  4

  Behavioral Transparency · 20%The description explains the behavior of the 'views' parameter (enumerate senders) and the 'app-wide' parameter (sweep all objects), and notes that include-body affects text output. It does not detail default behavior when views is false, but the annotation readOnlyHint=true is consistent and no contradiction.

  4

  Parameter Semantics · 15%The schema descriptions for app_id, target, views, app-wide, and include-body are detailed and add context beyond the parameter names. The app_id description includes important guidance about exact matching and calling knav_apps, which is valuable. The target description is clear but could be slightly more explicit about case-insensitivity.

  5

  Conciseness & Structure · 10%The description is concise, using parallel structure and bolded keywords to highlight key distinctions. It avoids redundancy and packs essential information into a few sentences.

  4

  Contextual Completeness · 10%The description provides sufficient context for the tool's purpose and parameters, including the relationship to sibling tools. It does not describe the output format in detail, but since there is no output schema, the description's mention of 'text output' and 'structured rows' gives a reasonable expectation.

  params

  6 (0 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  0

  bytes

  1963

  hash

  8128d2aa81b7f699

• knav_task

  543354A4.0

  The description is clear and concise, effectively distinguishing this tool from its sibling knav_tasks. It leverages the readOnlyHint annotation well and relies on the schema for parameter details, which is appropriate given the high schema coverage. Minor gaps exist in usage guidelines and behavioral transparency, but overall it is a well-crafted tool description.

  5

  Purpose Clarity · 25%The description clearly states the tool's purpose: to describe a scheduled task's full configuration, listing the key aspects (schedule, conditions, field updates, email settings, field references). It also distinguishes itself from the sibling tool knav_tasks, which lists tasks on an object, making the purpose unambiguous.

  4

  Usage Guidelines · 20%The description explicitly says to use knav_tasks for the list of tasks, providing a clear alternative. However, it does not explicitly state when NOT to use this tool beyond that, nor does it mention any prerequisites or context for when to use it, but the sibling differentiation is strong.

  3

  Behavioral Transparency · 20%The readOnlyHint annotation already indicates this is a read-only operation, so the description doesn't need to repeat that. The description adds context about what the tool returns (full config details) but does not disclose any other behavioral traits like caching behavior or potential side effects. Since annotations cover the safety profile, a score of 3 is appropriate.

  3

  Parameter Semantics · 15%The schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 is correct.

  5

  Conciseness & Structure · 10%The description is a single, concise sentence that packs in the tool's purpose and key details, followed by a clear pointer to the sibling tool. Every word earns its place, and it is front-loaded with the most important information.

  4

  Contextual Completeness · 10%Given the tool's moderate complexity (3 parameters, no output schema), the description is sufficient to understand what the tool does and how to use it. The schema covers parameters, and the description clarifies the scope. It could mention the return format, but since there is no output schema, the description could be slightly more complete, but it is still adequate.

  params

  3 (1 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  1

  bytes

  1392

  hash

  663965f0238df139

• knav_tasks

  543354A4.0

  The description is clear and concise, effectively distinguishing this tool from its sibling knav_task. It leverages the schema's detailed parameter descriptions and the readOnlyHint annotation, so it doesn't need to repeat that information. The only minor improvement would be to explicitly state when not to use this tool, but overall it is well-crafted.

  5

  Purpose Clarity · 25%The description clearly states the tool lists tasks on an object, equivalent to the builder's Tasks tab, and specifies the included fields (name, action, run status, cadence). It also distinguishes from knav_task, which provides full config for a single task, making the purpose unambiguous.

  4

  Usage Guidelines · 20%The description implies usage for listing tasks on an object and explicitly points to knav_task for full config of a single task, providing a clear alternative. However, it does not explicitly state when not to use this tool or mention other sibling tools like knav_objects, but the context is clear enough.

  3

  Behavioral Transparency · 20%The readOnlyHint annotation already indicates this is a read-only operation, so the description doesn't need to repeat that. The description adds context about the scope (tasks on an object) and the fields returned, but does not disclose any additional behavioral traits such as pagination, sorting, or potential errors. With the annotation covering safety, a score of 3 is appropriate.

  3

  Parameter Semantics · 15%Schema description coverage is 100%, so the schema already documents all three parameters in detail. The description adds minimal extra meaning beyond the schema, only clarifying the scope of the tool. Since the schema does the heavy lifting, the baseline of 3 is appropriate.

  5

  Conciseness & Structure · 10%The description is extremely concise, consisting of two short sentences that convey the purpose and the key distinction from knav_task. Every word earns its place, and it is front-loaded with the core purpose.

  4

  Contextual Completeness · 10%Given the tool's simplicity (listing tasks on an object) and the rich schema descriptions, the description is complete enough. It does not need to explain return values since there is no output schema, but the description covers the essential scope and points to the sibling for more detail. The only minor gap is not mentioning any filtering or sorting options, but that is not critical for this tool.

  params

  3 (1 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  1

  bytes

  1350

  hash

  7f7927f8c3da76d8

• knav_graph

  554454A4.6

  This is a well-crafted description that clearly explains the tool's three modes of operation, distinguishes it from sibling tools, and provides critical guidance on app_id usage. It leverages the schema for parameter details while adding valuable context about combinations and caching. Minor gap: no return format description, but overall it is highly effective for agent selection and invocation.

  5

  Purpose Clarity · 25%The description clearly states the tool's purpose: it provides connection adjacency, reachable sets, or shortest paths depending on arguments. It explicitly distinguishes from sibling knav_object by noting that for a single object's own inbound/outbound list, knav_object with connections:true should be used.

  5

  Usage Guidelines · 20%The description provides explicit usage scenarios: no args for whole-app adjacency, from for one object's neighbours and reachable set, from+to for shortest path. It also gives a clear alternative (knav_object) for a different use case, and the app_id parameter description includes when to use it and when it can be omitted.

  4

  Behavioral Transparency · 20%Annotations only provide readOnlyHint=true, which the description does not contradict. The description adds behavioral context beyond annotations: it explains the three modes of operation, the meaning of 'reachable set', and the caching behavior (refresh parameter, ~30s freshness window). It does not detail output format, but given the read-only nature and no output schema, this is adequate.

  4

  Parameter Semantics · 15%Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the combinatorial semantics (from alone vs from+to) and the app_id requirement nuance (exact name matching, multiple apps). It does not repeat schema details, but the added context is meaningful.

  5

  Conciseness & Structure · 10%The description is concise and front-loaded: the first sentence summarizes the three modes, followed by a brief explanation of each. It avoids redundancy with the schema and includes only essential guidance. The app_id parameter description is longer but necessary due to its criticality.

  4

  Contextual Completeness · 10%Given the tool's moderate complexity (three modes, optional parameters, no output schema), the description covers the key usage patterns and the critical app_id caveat. It does not describe the return format, but since there is no output schema, that could be a gap; however, the description's focus on usage and disambiguation is sufficient for an agent to select and invoke correctly.

  params

  4 (0 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  0

  bytes

  1772

  hash

  88fc8f8c3dbfa56a

• knav_rank

  555445A4.8

  This is an exemplary tool description that excels in all dimensions. It clearly defines the tool's purpose, provides explicit usage guidance with alternatives, and transparently discloses critical behavioral traits (performance, caching, request limits) that annotations alone cannot convey. The parameter semantics are enriched with practical context, and the description is dense but well-organized. It sets a high bar for MCP tool descriptions.

  5

  Purpose Clarity · 25%The description clearly states the tool ranks fields by total usage, combining view/rule usage with schema roles, and explicitly distinguishes it from knav_field (for one field's own count). It also specifies the default ordering and key options, making the purpose unambiguous.

  5

  Usage Guidelines · 20%The description provides explicit guidance on when to use this tool (ranking fields by usage) and when not to (for a single field's count, use knav_field). It also warns about performance limitations and recommends using 'least' for retirement censuses, and suggests passing 'object' for large apps to avoid request refusal.

  5

  Behavioral Transparency · 20%The description goes far beyond the readOnlyHint annotation by disclosing that the tool is the slowest, results are not cached, and the whole-app sweep may be refused on large apps. It also clarifies that 'limit' does not reduce work, and that 'least' returns all unused fields, which is critical behavioral context.

  4

  Parameter Semantics · 15%The schema already provides detailed descriptions for all parameters (100% coverage), but the tool description adds crucial context about how parameters interact (e.g., 'limit' does not reduce work, 'least' returns all unused fields, 'object' scopes the sweep). This adds value beyond the schema, though the schema itself is already rich.

  4

  Conciseness & Structure · 10%The description is dense but well-structured, front-loading the core purpose and then covering key caveats. It is longer than ideal but every sentence adds critical information (performance, caching, parameter semantics, alternatives). No fluff, but could be slightly tightened.

  5

  Contextual Completeness · 10%Given the tool's complexity (6 parameters, no output schema, performance pitfalls), the description is remarkably complete. It covers usage, performance, parameter interactions, and alternatives, leaving little ambiguity for an agent. The lack of an output schema is compensated by the detailed behavioral notes.

  params

  6 (0 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  0

  bytes

  2590

  hash

  1d06a794cf28b78a

• knav_ktl

  544444A4.3

  This is a well-crafted, thorough description that clearly explains the tool's purpose, usage modes, and critical parameter semantics (especially the app_id caveat). It adds substantial value beyond the schema by providing concrete examples and when-to-use guidance, and it remains concise. The only minor gap is that it doesn't explicitly exclude cases where knav_uses or knav_grep would be more appropriate, but overall it's highly effective.

  5

  Purpose Clarity · 25%The description clearly states that this tool lists KTL keyword index entries, with a specific verb 'Lists' and a specific resource 'KTL keyword index'. It explicitly distinguishes three modes of use (all keywords, keywords on one entity, or every use of one keyword), which differentiates it from siblings like knav_uses and knav_grep by focusing on KTL directives. The opening line gives a clear domain-specific definition.

  4

  Usage Guidelines · 20%The description provides clear guidance on when to use the tool: to list KTL keywords in use. It does not explicitly mention alternatives or when not to use it, but the sibling tools like knav_uses and knav_grep may be alternatives, and the description doesn't contrast them. It does give usage context for the target parameter (omit for full index), which helps the agent decide how to invoke it.

  4

  Behavioral Transparency · 20%Annotations only include readOnlyHint: true, which is confirmed by the description's 'Lists' wordingestrategy. The description adds important behavioral context: that 'Each hit names the keyword and the entity carrying it', the meaning of an empty index, and the default behavior of the refresh parameter (cached snapshot with ~30s freshness). It does not describe response format or pagination, but for a read-only listing tool this is adequate.

  4

  Parameter Semantics · 15%The description adds meaning beyond the schema's parameter descriptions by explaining the three usage modes of 'target' (keyword, entity key, or omitted for full index), and by explicitly stating that 'field_/view_ keys' can be used. The description also clarifies the semantics of 'app_id' with examples and the safety implication of omitting it. Since schema coverage is 100% and the description's param details are supplementary, a score above baseline is warranted.

  4

  Conciseness & Structure · 10%The description is compact and front-loaded, with the core purpose in the first sentence and subsequent details in a logical flow. It covers purpose, usage, and refresh behavior without excessive verbosity. Slightly longer than strictly necessary due to the entity_key warning, but that earns its place.

  4

  Contextual Completeness · 10%With 100% schema coverage, a readOnlyHint annotation, and no output schema, the description covers the three parameters and the key behavioral aspects. It explains the tool's scope (only KTL keywords, not all keywords), the modes (all, per-entity, per-keyword), and the edge case when the index is empty. It also warns about the app_id pitfall, which is critical for correctness. The lack of a mention of the return value structure is acceptable given the description of hit contents ('Each hit names the keyword and the entity carrying it').

  params

  3 (0 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  0

  bytes

  1640

  hash

  db3b4f1bea676ef7

• knav_search

  554455A4.7

  This is an exceptionally well-crafted tool description. It clearly defines the tool's purpose, differentiates it from siblings, provides explicit usage guidelines, and discloses critical behavioral nuances (truncation, caching, app_id ambiguity) beyond the annotations. The parameter semantics are enriched with interaction details, and the description is concise yet comprehensive. It sets a high standard for MCP tool descriptions.

  5

  Purpose Clarity · 25%The description clearly states the tool resolves a name/slug fragment to entity keys, with a specific verb ('Resolve') and resource ('field/object/view/scene keys'). It distinguishes itself from siblings by explicitly mentioning knav_grep and knav_names, and the scope (names/slugs only) is clear.

  5

  Usage Guidelines · 20%The description provides explicit when-to-use guidance: it says to use knav_grep for raw values and knav_names for id-to-name conversion. It also explains the behavior of the 'all' and 'type' parameters, and the app_id requirement is detailed with a clear directive to call knav_apps first. This is exemplary usage guidance.

  4

  Behavioral Transparency · 20%Annotations only provide readOnlyHint: true, which the description does not contradict. The description adds significant behavioral context: the 40-row cap, the lifting behavior with 'all' and 'type', the case-insensitive substring matching, the caching and refresh behavior, and the critical warning about app_id and multi-app scenarios. It does not mention return format, but given the readOnlyHint, this is sufficient.

  4

  Parameter Semantics · 15%Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the interaction between 'all', 'type', and 'limit' (e.g., type-narrowed lists never truncate), and the app_id parameter's critical context (multi-app ambiguity). It also clarifies the 'target' parameter's scope (names/slugs only). This goes beyond the schema's basic descriptions.

  5

  Conciseness & Structure · 10%The description is concise and front-loaded with the core purpose, then provides essential usage details in a structured manner. Every sentence adds value, and the use of semicolons and parentheses keeps it compact without losing clarity. It is not overly verbose despite covering complex behaviors.

  5

  Contextual Completeness · 10%Given the tool's complexity (6 parameters, no output schema, but rich annotations and schema descriptions), the description covers all critical aspects: purpose, usage boundaries, parameter interactions, caching behavior, and the app_id pitfall. It is complete for an agent to select and invoke correctly, especially with the sibling differentiation.

  params

  6 (1 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  1

  bytes

  1958

  hash

  e92724b7fb1926d2

• knav_grep

  554455A4.7

  This is an exemplary tool description. It clearly defines the tool's purpose, differentiates it from siblings, provides explicit usage guidelines, and adds substantial behavioral context beyond the annotations. The parameter semantics are well-covered, and the description is concise yet comprehensive, making it a high-quality reference for an AI agent.

  5

  Purpose Clarity · 25%The description clearly states the tool performs full-text search on a raw snapshot, specifying the types of values searched (recipients, criteria, URLs, etc.) and the output (owning entity + JSON path per hit). It distinguishes itself from siblings by explicitly naming knav_search and knav_hosts as alternatives for different use cases.

  5

  Usage Guidelines · 20%The description provides explicit guidance on when to use this tool versus alternatives: 'for resolving a NAME to an entity key use knav_search; for a URL census grouped by host use knav_hosts.' It also explains key behavioral options (case sensitivity, 50-location cap, all flag) and the app_id requirement, making usage conditions clear.

  4

  Behavioral Transparency · 20%Annotations only provide readOnlyHint: true, which the description does not contradict. The description adds significant behavioral context beyond annotations: it explains the default 50-location cap, case-sensitivity default, the effect of flags (i, all, full, exact, group, limit, max-len, names-only), and the caching/refresh behavior. It also warns about the app_id pitfall, which is valuable for correct usage. However, it does not detail the exact output format beyond 'owning entity + JSON path per hit', but that is sufficient given the read-only nature.

  4

  Parameter Semantics · 15%Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the default behavior (case-sensitive, 50-location cap) and the interaction between parameters (e.g., 'limit' ignored when 'all' is set, 'max-len' for snippet context). It also clarifies the app_id requirement and its criticality, which is not fully captured in the schema. This goes beyond the baseline of 3, earning a 4.

  5

  Conciseness & Structure · 10%The description is concise and front-loaded: the first sentence states the core purpose and output, followed by key behavioral defaults and alternatives. It uses clear, direct language without redundancy. Every sentence adds value, and the structure is easy to scan.

  5

  Contextual Completeness · 10%Given the tool's complexity (11 parameters, no output schema), the description is remarkably complete. It covers the search scope, output format, default behaviors, parameter interactions, and critical usage warnings (app_id). The absence of an output schema is compensated by the description's clarity on what is returned. The description is sufficient for an agent to use the tool correctly in most scenarios.

  params

  11 (1 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  1

  bytes

  2431

  hash

  bbaffdd55aaf30dc

• knav_roles

  545544A4.6

  This is a high-quality MCP tool description. It clearly defines the tool's purpose (per-role access rollup), distinguishes it from the sibling knav_objects tool, provides important usage disclaimers (exact app name matching, cross-app key danger), and explains all parameters. The description does not contradict the readOnly annotation)SkipEven though it could enrich the context further with return structure details, it is comprehensive, concise, and well structured.

  5

  Purpose Clarity · 25%The description clearly states the tool's purpose: a per-role access rollup that reports which logins admit each role, counts of those logins, reachability, and reference counts of the role's profile key. It explicitly distinguishes from knav_objects with roles:true, preventing confusion among sibling tools.

  4

  Usage Guidelines · 20%The description provides clear context on when to use this tool (for access analysis) and explicitly contrasts it with knav_objects, but does not enumerate all alternative tools or exhaustively specify when not to use it (e.g., when only simple role lists are needed). Still, the exclusion is clear enough for most scenarios.

  5

  Behavioral Transparency · 20%Annotations include readOnlyHint:true, so the read-only nature is already covered, but the description goes beyond by detailing exactly what is computed: reachability definition, counting logic, and the 'unreachable' flag behavior. It also explicitly warns against using this tool for plain role lists, adding significant behavioral context beyond annotations.

  5

  Parameter Semantics · 15%All four parameters are described in detail, with explanations of their effects (e.g., logins names the admitting views, unreachable filters to roles not admitted). The app_id parameter gains crucial behavioral nuance: exact name matching, app ambiguity with multiple registrations, and cross-app entity key implications, which goes beyond mere schema definitions.

  4

  Conciseness & Structure · 10%The description is dense but organized, front-loaded with the core purpose and then covering usage details. It could be slightly restructured for readability, but every sentence adds value with minimal fluff.

  4

  Contextual Completeness · 10%The description effectively communicates support for various use cases (reachability, unreachable filter, login page details, refresh behavior) with no output schema to rely on. It doesn't fully document response shape or edge cases around logins=true, but the core behaviors are well covered.

  params

  4 (0 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  0

  bytes

  1646

  hash

  797f0e59d254b0ab

• knav_hosts

  554454A4.6

  The description is well-crafted, clearly stating the tool's purpose, usage guidelines, and key behavioral details like row caps and caching. It effectively differentiates from sibling tools and provides parameter semantics beyond the schema. Minor gap: no explicit return format, but overall it is a strong, actionable description.

  5

  Purpose Clarity · 25%The description clearly states the tool's purpose: an app-wide inventory of external hosts from http(s) URLs in the raw snapshot, grouped by host with counts and referencing entities. It distinguishes itself from siblings by mentioning knav_grep for exact location searches and knav_uses for entity references, and it specifies the alternative 'urls' mode.

  5

  Usage Guidelines · 20%The description provides explicit guidance on when to use this tool vs alternatives: 'For one known URL or host string with its exact locations use knav_grep.' It also explains the 'urls' option for listing distinct URLs, and the 'all' and 'limit' parameters for controlling output size. This is clear and actionable.

  4

  Behavioral Transparency · 20%The readOnlyHint annotation is present, and the description does not contradict it. The description adds behavioral context beyond the annotation: it mentions the default cap of 50 rows, the caching behavior (served from snapshot, revalidated ~30s), and the 'all' flag to override the cap. It does not detail pagination or exact return structure, but given the annotation, this is sufficient.

  4

  Parameter Semantics · 15%Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the purpose of the 'urls' flag (list each distinct URL instead of per-host rollup) and the 'all' flag (show every row, overriding the cap). It also clarifies the 'target' parameter as a host filter. This goes beyond the schema's basic descriptions.

  5

  Conciseness & Structure · 10%The description is concise and front-loaded: the first sentence states the core purpose, followed by a brief note on the 'urls' alternative, the row cap, and a pointer to knav_grep. Every sentence adds value, and there is no fluff or repetition.

  4

  Contextual Completeness · 10%Given the tool's moderate complexity (6 parameters, no output schema), the description covers the key aspects: purpose, output mode, row limits, and alternative tools. It does not describe the exact return format, but since there is no output schema, a bit more detail on the response structure could be helpful. However, the description is sufficient for an agent to select and invoke the tool correctly.

  params

  6 (0 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  0

  bytes

  1736

  hash

  f89717043e9f0ae5

• knav_names

  554455A4.7

  A strong description: it clearly defines the tool's purpose and differentiates from knav_search, includes critical usage guidance about app_id to prevent wrong-app results, and provides a detailed parameter breakdown. The only minor gap is that the behavioral transparency dimension could be higher if annotations were lacking, but the readOnlyHint and the description's mention of no writes make it sufficient.

  5

  Purpose Clarity · 25%The description clearly states it performs 'Bulk id → name resolution' with specific output format (key<TAB>name<TAB>context). It distinguishes from siblings by explicitly saying 'Ids only, never names — to go from a name to a key use knav_search.'

  5

  Usage Guidelines · 20%The description explicitly says when to use (when you have ids and need names) and when not to (when you have names, use knav_search). It also provides batch usage and notes that unknown ids are handled per-line. The app_id parameter description gives extensive guidance on when it's required and how to avoid wrong results.

  4

  Behavioral Transparency · 20%Annotations provide readOnlyHint=true, which is consistent with the description's focus on name resolution. The description adds that unknown ids are reported per-line and never fail the batch, and that the tool does not accept names. It also transparently warns about stale app_id leading to wrong app results, which is valuable behavioral context beyond the annotation.

  4

  Parameter Semantics · 15%Schema coverage is 100% with detailed parameter descriptions. The description adds aggregate context (per-line unknown id handling, app_id ambiguity) but mostly echoes the schema. Since schema already documents each parameter well, the description adds marginal value, but the app_id explanation is richer in the description than the schema, warranting a 4.

  5

  Conciseness & Structure · 10%The description is a single focused paragraph, immediately stating the operation and format. The app_id warning is included in the schema, not duplicated in the description. Every sentence adds value: purpose, format, id-only constraint, and sibling differentiation.

  5

  Contextual Completeness · 10%Given the tool's moderate complexity (3 params, all documented at 100% schema coverage), the description is complete. The readOnlyHint annotation covers behavioral transparency, the app_id caveat covers the main operational nuance, and the output format is described (per-line context). No output schema exists, but the description explicitly says how unknown ids are handled, which is the key uncertainty.

  params

  3 (1 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  1

  bytes

  1593

  hash

  372d913d7f727812

• knav_app

  543444A4.1

  A well-structured description that clearly defines the tool's purpose, distinguishes it from a sibling, and provides valuable agent guidance (especially the app_id requirement due to entity-key ambiguity). Minor gaps exist in detailing when refresh is needed and the exact behavior of the cache, but these are acceptable given the annotations and schema both provide a baseline. Overall, a strong high-tier description (average ~4.0).

  5

  Purpose Clarity · 25%The description clearly states this tool provides app-level metadata including a detailed list of fields (id, slugs, region, counts, security settings). It explicitly distinguishes itself from knav_apps, which lists registered apps. The specificity and contrast with the sibling tool make the purpose unmistakable.

  4

  Usage Guidelines · 20%The description includes a clear 'NOT' warning against confusing it with knav_apps, which resolves ambiguity. It also gives usage context regarding when to use it. However, it does not explicitly state when NOT to use it or recommend alternatives beyond the direct sibling comparison.

  3

  Behavioral Transparency · 20%Annotations only provide readOnlyHint=true, which the description implicitly matches. The description adds substantial detail about the data returned but does not disclose the behavior of serving a cached snapshot, when it is revalidated, or the impact of the 'refresh' parameter. The description says it will serve the cached snapshot but doesn't detail how staleness is handled or under what conditions a refresh occurs. This is a gap given the annotation is minimal.

  4

  Parameter Semantics · 15%The input schema covers 100% of parameters with rich descriptions. The description adds meaning by explaining the caching mechanism and 'refresh' behavior, beyond just the schema's parameters. It also clarifies the critical app_id requirement (that entity keys are app-specific), which is valuable agent guidance. No additional parameter details are missing.

  4

  Conciseness & Structure · 10%The description is moderately long but front-loaded with the key purpose and structure. It uses bullets for the metadata list, improving readability. Every sentence adds value, including the distinction from knav_apps. The description of parameter semantics is dense but not verbose.

  4

  Contextual Completeness · 10%Given the tool's complexity (many metadata fields, security settings, urgency score for app_id), the description covers the important aspects, including parameter descriptions. There is no output schema, so the description adequately describes what the tool returns. The tool could mention caching behavior and the 'refresh' parameter more explicitly, but overall it's complete for a query tool with 2 parameters and no nested objects.

  params

  2 (0 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  0

  bytes

  1535

  hash

  c3143c44db394c1d

• knav_code

  554454A4.6

  This is a well-crafted description that clearly defines the tool's purpose, provides explicit usage guidance, and adds valuable context beyond the schema and annotations. The app_id parameter explanation is particularly strong, preventing common mistakes. Minor gaps include lack of output format details, but overall it's a high-quality description.

  5

  Purpose Clarity · 25%The description clearly states the tool reports metadata about custom JavaScript and CSS (stored, enabled, size, hash) and explicitly notes the source is never printed. This distinguishes it from sibling tools like knav_app or knav_objects, which focus on app structure or other aspects.

  5

  Usage Guidelines · 20%The description explicitly says to use it to confirm custom code presence/enabled state or detect changes via hash comparison. It also warns against using it to retrieve source code ('The source itself is never printed'), which is a clear exclusion. The app_id parameter description provides detailed guidance on when to pass it and when it can be omitted, including a call to knav_apps first.

  4

  Behavioral Transparency · 20%Annotations declare readOnlyHint=true, and the description reinforces this by stating it only reports metadata and never prints source. It adds context about the cached snapshot and refresh behavior, which is not in annotations. However, it doesn't detail what happens if no custom code exists or the exact response format, but given the read-only nature and annotation coverage, this is adequate.

  4

  Parameter Semantics · 15%Schema coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the app_id requirement in depth (exact name matching, multi-app scenarios, risk of wrong app) and the refresh default behavior. This goes beyond the schema's basic descriptions, though it doesn't add much for css/javascript booleans beyond what the schema says.

  5

  Conciseness & Structure · 10%The description is concise and front-loaded with the core purpose. It uses a single paragraph with clear sentences, no fluff, and the app_id parameter description is detailed but necessary for correct usage. Every sentence adds value.

  4

  Contextual Completeness · 10%Given the tool's moderate complexity (4 optional params, no output schema), the description covers the key aspects: what it returns, what it doesn't, when to use it, and the critical app_id caveat. It doesn't explain the output structure, but since there's no output schema, a brief note on return format could help, but the description is still sufficient for an agent to decide and invoke correctly.

  params

  4 (0 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  0

  bytes

  1519

  hash

  b28214b41723cee0

• knav_apps

  554455A4.7

  This is an excellent tool description. It clearly states the purpose, provides explicit usage guidance (call once per session, pass app_id to other tools), and distinguishes itself from the sibling knav_app. The description adds value beyond the readOnlyHint annotation by explaining the output fields and the session-level usage pattern. It is concise, well-structured, and complete for a zero-parameter list tool.

  5

  Purpose Clarity · 25%The description clearly states the tool lists Knack apps with specific fields (id, name, status, ownership-verification freshness) and explicitly distinguishes it from knav_app, which describes one app's metadata. The verb 'List' and resource 'Knack apps' are specific and unambiguous.

  5

  Usage Guidelines · 20%The description provides explicit usage guidance: 'Call it once per session, then pass the chosen app id as app_id on every other tool.' It also names the alternative tool (knav_app) and explains the difference, making it clear when to use this tool versus the sibling.

  4

  Behavioral Transparency · 20%The readOnlyHint annotation already indicates a safe read operation, and the description adds the behavioral detail that it should be called once per session, implying it returns a list that is stable. It also mentions the output includes ownership-verification freshness, which is a useful behavioral trait not in the schema. No contradiction with annotations.

  4

  Parameter Semantics · 15%The tool has zero parameters, so the description doesn't need to explain parameters. The baseline for 0 params is 4, and the description adds value by explaining the output fields (app id, name, status, freshness) and how the output is used (pass app_id to other tools), which is more than just the schema provides.

  5

  Conciseness & Structure · 10%The description is two sentences, front-loaded with the core purpose, and every sentence earns its place. The first sentence states what it does and what it returns; the second gives usage guidance and distinguishes from a sibling. No wasted words.

  5

  Contextual Completeness · 10%Given the tool has no parameters, no output schema, and a simple list operation, the description is complete. It covers the purpose, the output fields, the usage pattern, and the distinction from a similar tool. There is no missing information that would prevent an agent from using it correctly.

  params

  0 (0 required, 100% described)

  annotations

  readOnly=true

  output schema

  no

  cost

  0

  bytes

  519

  hash

  5b8fc0082b70ec31

• infoknav_field no-output-schemaknav_field has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_uses no-output-schemaknav_uses has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_editable no-output-schemaknav_editable has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_display_rules no-output-schemaknav_display_rules has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_conditional_rules no-output-schemaknav_conditional_rules has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_emails_using no-output-schemaknav_emails_using has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_object no-output-schemaknav_object has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_objects no-output-schemaknav_objects has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_view no-output-schemaknav_view has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_scene no-output-schemaknav_scene has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_scenes no-output-schemaknav_scenes has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_views no-output-schemaknav_views has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_ripple no-output-schemaknav_ripple has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_formulas no-output-schemaknav_formulas has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_writes no-output-schemaknav_writes has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_emails no-output-schemaknav_emails has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_task no-output-schemaknav_task has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_tasks no-output-schemaknav_tasks has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_graph no-output-schemaknav_graph has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_rank no-output-schemaknav_rank has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_ktl no-output-schemaknav_ktl has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_search no-output-schemaknav_search has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_grep no-output-schemaknav_grep has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_roles no-output-schemaknav_roles has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_hosts no-output-schemaknav_hosts has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_names no-output-schemaknav_names has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_app no-output-schemaknav_app has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_code no-output-schemaknav_code has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.
• infoknav_apps no-output-schemaknav_apps has no output schema, so the description has to explain return values itself. Providing one lets the description spend those words elsewhere.

The badge shows the overall tier and score, and links here. The JSON is the same report the CLI's hosted mode prints.

[![TDQS](https://tdqs.dev/reports/xve3caobgi/badge.svg)](https://tdqs.dev/reports/xve3caobgi)

The same check from a terminal, a CI job or a script, with an API key from your account. Submitting spends one of the account's daily calls; reading the result spends nothing.

export TDQS_API_KEY=tdqs_...

# exit code 1 below B, so the command is the gate; uvx runs the same command from PyPI
npx mcp-tdqs score --file tools.json --hosted https://tdqs.dev --fail-under B

curl https://tdqs.dev/api/v1/reports \
  -H 'Authorization: Bearer tdqs_...' \
  -H 'Content-Type: application/json' \
  -d @tools.json

# poll the report it names until "status" is "completed"; this one is
curl https://tdqs.dev/api/v1/reports/xve3caobgi \
  -H 'Authorization: Bearer tdqs_...'

import { requestHostedReport } from 'mcp-tdqs';

const report = await requestHostedReport({
  apiKey: 'tdqs_...',
  hostedUrl: 'https://tdqs.dev',
  serverName: 'Knavigator MCP v2',
  tools, // the tools/list result
});

if (report.score === null || !['A', 'B'].includes(report.score.serverScore.overallTier)) {
  throw new Error(`TDQS ${report.score?.serverScore.overallTier ?? 'failed'}: ${report.url}`);
}

from tdqs import parse_tool_definitions, request_hosted_report

parsed = parse_tool_definitions(tools_list)  # the tools/list result
report = request_hosted_report(
    api_key="tdqs_...",
    hosted_url="https://tdqs.dev",
    server_name="Knavigator MCP v2",
    tools=parsed.tools,
)
tier = report.score.server_score.overall_tier if report.score is not None else None

if tier not in ("A", "B"):
    raise SystemExit(f"TDQS {tier or 'failed'}: {report.url}")