Server Quality Checklist

Tool Scores

• get_graph_statsC
  2.8/5.0
  Behavior1/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden of disclosing behavior. It only says 'Retrieve statistics' without mentioning side effects, permissions, cost, or what the returned statistics contain. This is a significant gap for a tool with no structured metadata.

  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, front-loaded sentence with no excessive wording. It earns its place by stating the core purpose, though it could be slightly more informative without becoming 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?

  Given there is no output schema and no annotations, the description is the only source of guidance. It is vague about what 'statistics' include, leaving the agent uncertain about the response format and content. The description is too thin for a tool that presumably returns a nontrivial set of metrics.

  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 input schema has zero parameters, so there is nothing to explain. The baseline of 4 applies because no parameter information is needed; the description adds no parameter semantics but also has no deficiency.

  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 retrieves statistics about the knowledge graph, with a specific verb and resource. It is distinguishable from sibling tools like search_entity or get_pending_verifications, though it does not explicitly differentiate itself.

  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, nor does it provide context or exclusions. The usage is only implied by the purpose statement, which is insufficient for an agent to decide between this and similar retrieval tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_rulesB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description should disclose the safety profile and any behavioral nuances. It implies a read-only operation through the verb 'Lists,' but it does not explicitly state that it is non-destructive, nor does it mention whether it includes disabled rules or any system-wide restrictions. It also omits the optional source filter, which could limit the 'all' scope.

  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 of 11 words. It efficiently communicates the core purpose and return value without extraneous 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 covers the basic purpose and mentions that sources and status are returned, which is helpful given no output schema. However, it fails to clarify the filtering capability (covered by schema), differentiate from related rule-listing tools, or assert read-only behavior, leaving some gaps for an agent relying on this description alone.

  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% (the 'source' parameter has a description: 'Filter rules by source.'). The tool description adds no extra parameter semantics, so the baseline of 3 is appropriate because the schema already fully documents the parameter.

  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 is specific: 'Lists all available SPARQL inference rules, their sources, and their status.' It clearly identifies the verb (Lists), the resource (SPARQL inference rules), and the scope (all available), and distinguishes from sibling tools that load, suggest, approve, or reject rules.

  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 given on when to use this tool versus alternatives like get_pending_rules or get_pending_verifications. The description simply states what it does; it does not mention when not to use it or how it differs from other rule-management tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• load_custom_ruleA
  3.5/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden. It does disclose the useful behavior that PREFIX declarations are optional and auto-added. However, it does not explain key behaviors like whether the rule is immediately active, whether it is persisted, if it overwrites existing rules, or if it requires approval (given siblings approve_rule/reject_rule exist). This is ambiguous for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with the main purpose. It includes a necessary explanation of the rule format, a useful note about prefixes, and a concrete example. It is not overly verbose, though the example could be seen as extra, it earns its place.

  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?

  Given the tool has no output schema and no annotations, the description should explain what happens after loading, e.g., whether the rule is activated immediately, goes to a pending state for approval, or how errors are handled. The lack of such details is a significant gap, especially with sibling approve_rule/reject_rule suggesting a workflow.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, providing a baseline of 3. The description adds meaning beyond the schema by explaining that rule_content should be a SPARQL CONSTRUCT query, showing an example, and clarifying that prefixes are optional. This helps an agent construct valid input.

  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 'Loads a new custom SPARQL CONSTRUCT rule from text' with a specific verb and resource. The example rule content and explanation about inferences distinguish it from siblings like list_rules or approve_rule.

  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: use this when you have a custom SPARQL CONSTRUCT rule to load. It gives guidance on the rule format (SPARQL CONSTRUCT query, optional prefixes) but does not explicitly mention when to use this versus alternatives like suggest_rule or 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.

• get_pending_verificationsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description must carry the burden of behavioral disclosure. It does add useful context: the list contains inferred triples with confidence scores and source rules, and it implies this is a read-only listing since it defers accept/reject to another tool. However, it never explicitly states that this operation has no side effects or requires any special permission, which would be valuable for safe invocation.

  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 three short, front-loaded sentences. The first sentence states the purpose, the second explains the return content, and the third points to the next step. There is no filler or repetition; every sentence earns its place.

  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 tool with one optional parameter and no output schema, the description is quite complete: it defines what pending verifications are, what the output includes, and what tool to use next. It falls short only by not explicitly stating that this is a read-only operation, but the overall context is sufficient for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers the single 'limit' parameter with a clear description and default value, so the schema alone provides full parameter semantics. The description adds no extra meaning about the parameter and even says 'all', which could be slightly misleading given the limit parameter. Baseline 3 is appropriate 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 clearly states the tool's primary action ('List all pending verifications') and defines the resource ('uncertain inferences that need user confirmation'). It also specifies the return contents (inferred triples, confidence scores, source rules), and explicitly distinguishes itself from the sibling 'verify_inference' tool by pointing to it for accept/reject actions. This makes the purpose unmistakable.

  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 a clear usage context: call this tool to see pending verifications, then use 'verify_inference' to act on them. It provides a directional alternative but does not explicitly contrast with similar listing tools like 'get_pending_rules' or state when not to use this tool. Overall, it offers enough guidance for an agent to decide when to invoke it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• search_entityA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must fully disclose behavior. It states the tool returns matching entities with types and key properties, adding some value. However, it does not mention whether the operation is read-only, how search matching works (exact/fuzzy), or any pagination or permission details, leaving significant behavioral gaps.

  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 front-loads the action and resource. It contains no fluff or redundant information, earning a perfect score for conciseness.

  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 simplicity and full schema parameter coverage, the description provides sufficient context for basic use. It could be improved by mentioning result ordering or relevance, but for a low-complexity search tool, it is largely 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 coverage is 100%, with each parameter described (search_term, limit, entity_type). The description adds no further parameter-specific meaning 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 clearly states the tool searches for entities in the knowledge graph by name or label, specifying the resource and action distinctly. It also mentions the return of types and key properties, making its purpose unambiguous and distinct from sibling tools like query_memory or load_document.

  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: searching for entities in the knowledge graph. However, it does not explicitly provide alternatives or exclusions, such as 'use query_memory for memory entries instead.' Thus it has clear context but lacks explicit 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.

• verify_inferenceA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries full burden. It explains return behavior for proven vs not proven and shows a sample flow. However, it omits the 'action' parameter (accept/reject) present in the schema, which suggests the tool may also mutate pending verification states—a significant behavioral gap and potential source of confusion.

  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?

  Description is well-structured with distinct sections (WHEN TO USE, WORKFLOW, Returns, Example) and front-loaded with purpose. However, it is verbose—especially the workflow numbering and repeated examples—though every part contributes value for a key 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?

  The description covers purpose, usage, workflow, returns, and an example, providing a solid foundation. Yet it fails to address the 'action' parameter, its connection to pending verifications, or the tool's interplay with sibling tools like get_pending_verifications, leaving notable gaps given the tool's complexity.

  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% with each parameter described, so schema already provides meaning. The description adds a concrete example call but does not deepen semantic understanding beyond schema text. 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?

  Description clearly states the tool verifies if a fact is formally proven in the knowledge graph, using the specific verb 'verify' with a precise resource. It also emphasizes its role as 'THE KEY TOOL' for formal reasoning, distinguishing it from query or rule tools like query_memory and suggest_rule.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit 'WHEN TO USE' section lists critical use cases: before stating a deduction, when users ask 'Is X true?', after soft reasoning, and to distinguish intuition from proof. The workflow example further clarifies how to combine query_memory and verify_inference, and suggests suggest_rule as a follow-up, providing clear guidance against alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• load_documentA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses parsing, metadata storage, LLM-based rule extraction, and the creation of rules in 'PENDING' state. This is substantial behavioral context, though it does not mention behavior around extract_rules=false or failure modes.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a one-sentence summary, usage examples, a numbered process list, and an options section. Each section is purposeful and information is front-loaded; the length is justified by the tool's complexity.

  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 description covers inputs, processing steps, and the PENDING rule state, which is good for a tool with no output schema. However, it does not describe the return value or response format, and it omits the extract_rules toggle even though that is a significant behavior.

  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 adds usage examples for file_path/content and repeats store_content, but provides no additional semantics beyond the schema for extract_rules, prefix, url, or title.

  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 has a specific verb and resource: 'Load a document ... into the knowledge graph and automatically extract business rules.' It clearly differentiates the tool from siblings like load_custom_rule and add_memory by focusing on document ingestion and rule extraction.

  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 'Usage' section gives concrete examples for both file_path and content, and the 'What it does' section explains the pipeline. However, it does not explicitly mention when to prefer this tool over alternatives like load_custom_rule, so it stops short of full exclusionary guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• reject_ruleA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden of behavioral disclosure. It clearly states the effects: the rule will not be activated and will be removed from the pending list. It does not mention reversibility or error conditions, but for a simple reject operation this is adequate.

  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 two short sentences, front-loaded with the primary action 'Reject a pending rule.' Every word contributes meaning, with no redundancy or filler.

  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?

  This is a low-complexity tool with one required parameter and no output schema. The description adequately conveys the tool's purpose and outcome, making it complete for an AI agent to select and invoke correctly.

  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 documents the only parameter 'rule_id' as 'ID of the rule to reject', giving 100% schema coverage. The description adds no extra parameter semantics, so the baseline score of 3 applies.

  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 ('Reject'), the target ('a pending rule'), and the outcome ('will not be activated and will be removed from pending list'). It distinguishes this tool from its sibling 'approve_rule' by focusing on rejection and removal.

  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 clearly implies the tool is for pending rules only, stating 'Reject a pending rule' and noting it will not be activated. It does not explicitly name alternatives or when-not-to-use, but the context of sibling tools like 'approve_rule' and 'get_pending_rules' provides enough guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• add_memoryA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden. It discloses side effects: facts stored with confidence=1.0, SPARQL inference rules running automatically, and potential inferred facts requiring approval via get_pending_verifications(). This goes beyond the simple 'store a fact' statement, though it doesn't mention error cases or permission requirements.

  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 long but well-structured with clear headers, critical rules, an incorrect-vs-correct example, and a supported-predicates list. Every section serves a purpose (especially the anti-hallucination guidance), though it could arguably be tightened slightly without losing value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema and only one parameter, the description is remarkably complete. It covers the purpose, the exact input format with examples, when it should and shouldn't be used, what happens after invocation (confidence, inference), and related tools to check afterward. This fully equips an agent to use the tool correctly in context.

  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?

  Though the schema covers 100% of parameter semantics (the single 'input' parameter is described as an RDF triple), the description adds significant extra meaning: supported predicates (foaf:knows, schema:worksFor, rdf:type, custom), format examples, notes on the ':User' and ':' prefixes, and the triple structure. This meaningfully exceeds the schema's basic 'RDF triple: ':Subject predicate :Object''.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Store a fact in semantic memory using RDF triple notation.' It clearly differentiates from sibling tools like query_memory (retrieval) and forget_memory (deletion), and the RDF format is explicitly stated.

  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?

  Provides extensive when-to-use guidance through anti-hallucination rules: only add facts explicitly stated by the user, ask for clarification if unsure, and never add based on assumptions. It also instructs checking get_pending_verifications() after adding. However, it doesn't explicitly contrast with alternative tools (e.g., 'use search_entity for retrieval'), though the sibling names make that reasonably clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• approve_ruleA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses the key side-effect (rule activates and starts inferring facts immediately) and an important behavioral rule (cannot approve own rules, must be human-approved). This is strong transparency for a mutation tool, though it could mention additional details like reversibility 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 concise, with no filler. The first sentence states the action and consequence; the second paragraph delivers the essential human-in-the-loop instructions. Every sentence contributes critical guidance.

  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 significant operational constraints, the description is quite complete. It covers purpose, side-effects, and the approval workflow. It does not explain error handling or what happens if the rule is not pending, but given the simple parameter set and no output schema, the description provides sufficient context to use the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema is 100% covered with 'ID of the rule to approve'. The description adds context about the rule being pending and displayed via suggest_rule, which enriches the meaning of rule_id. However, it doesn't add specific syntax or format details, so the baseline of 3 for high schema coverage 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: approve a pending rule and activate it in the inference engine. It uses a specific verb ('approve') and resource ('rule'), and the mention of immediate fact inference distinguishes it from related tools like reject_rule or suggest_rule.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage guidelines: do not call automatically, wait for user input, cannot approve own rules, display the rule via suggest_rule, and only proceed after user explicitly says 'Approved' or 'Yes'. It also implicitly contrasts with reject_rule for rejection. This fully satisfies the when/when-not/alternatives criterion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_pending_rulesA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full transparency burden. It clearly states what the tool returns and implies a read-only operation through 'Get'. It adds behavioral context by specifying the source ('proposed by the LLM') and the pending status. It does not mention side effects, but for a getter this is sufficient.

  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 two sentences: the first states the purpose, the second gives usage guidance. No filler words, information is front-loaded and every word earns its place.

  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 parameterless list tool without an output schema, the description explains what is retrieved and when to call it. It could specify the structure of the returned rules or behavior when no rules are pending, but the scope is clearly defined and sufficient for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the input schema is an empty object. The baseline for 0 params is 4, and no further parameter explanation is required.

  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 'Get list' and clearly identifies the resource as 'rules proposed by the LLM that are awaiting user approval'. This distinguishes it from sibling tools like list_rules (all rules) and approve_rule/reject_rule (actions).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an explicit when-to-use: 'Use this after suggesting a rule to show the user what needs approval.' This ties it to the suggest_rule workflow and gives clear context. It does not mention explicit alternatives or when-not-to-use, but the guidance is concrete.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• forget_memoryA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It details exactly what happens when a fact is forgotten: the triple is removed, provenance reification nodes are removed, and dependent facts are NOT automatically removed. It also warns about the need to check for dependent facts first. This is comprehensive transparency for a destructive operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with a clear one-sentence summary, followed by critical rules, behavioral details, and examples. Every section earns its place: the critical rules prevent misuse, the behavioral list explains side effects, and the examples disambiguate syntax. No unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive tool with no annotations and no output schema, the description is remarkably complete. It covers preconditions (user confirmation, checking dependencies), side effects (provenance removal, dependent facts persistence), and exact input syntax. An agent can safely and correctly invoke this tool based solely on the description.

  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 documents the only parameter as 'RDF triple to remove: Subject predicate :Object', achieving 100% schema description coverage. The description repeats this format and adds examples, but does not introduce new semantic details beyond what the schema already provides. Therefore, 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 tool's action: 'Remove a fact from semantic memory, including its provenance metadata.' It uses a specific verb (remove), identifies the resource (a fact in semantic memory), and distinguishes itself from sibling tools like add_memory and query_memory by focusing on deletion. The scope and format are also clarified with examples.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit when-to-use and when-not-to-use guidance: 'Use when user explicitly says forget, remove, that's wrong, delete that' and includes critical prohibitions about removing facts without explicit instruction or removing foundational facts before checking with query_memory. It also instructs the agent to always confirm with the user, making the usage context fully explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• suggest_ruleA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description fully carries the burden of behavioral disclosure. It explicitly states that user approval is required before calling, that the tool puts rules into a pending state, previews inferences, and that the user must approve via approve_rule (which the LLM cannot call). It also warns 'Rule goes to PENDING - User must approve!' This is thorough and transparent about the tool's behavioral implications.

  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 lengthy but well-structured with headers (CRITICAL WORKFLOW, WHEN TO USE, WORKFLOW EXAMPLE, etc.) and front-loads the most critical warning ('**IMPORTANT: USER APPROVAL REQUIRED**'). Some redundancy exists, such as repeated warnings about user approval and bypassing, but each section earns its place and the structure is clear. It could be tightened, but it is not excessive.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 4 parameters, no output schema, and no annotations, the description is exceptionally complete. It covers the full workflow, prerequisites, user approval steps, best practices, and expected outcome (previews inferences, adds to pending approval). It even provides example phrases in French and English. All essential context for invoking the tool correctly is present.

  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 input schema already provides 100% coverage of all three required and one optional parameter, so the baseline is 3. The description adds valuable beyond-schema guidance: 'Use descriptive rule_id (snake_case)', 'SPARQL must be CONSTRUCT query', and 'Set confidence < 1.0 for uncertain rules'. These are practical semantics that improve parameter use beyond the schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the tool's purpose: 'Allows the LLM to propose SPARQL rules to formalize reasoning patterns.' It uses a specific verb (propose) and resource (SPARQL rules), and distinguishes it from siblings like approve_rule by emphasizing the rule goes to PENDING and the user must approve via approve_rule, which the LLM cannot call. This clearly differentiates it from related tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit WHEN TO USE criteria (e.g., after verify_inference returns 'not proven', when user states a rule) and explicit DO NOT BYPASS constraints (never edit .rq files directly, never create rules outside this workflow). It also outlines the step-by-step workflow with EXAPLAN AND ASK, WAIT, SUGGEST, CONFIRM, making it clear when and how the tool should be used.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• query_memoryA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries full burden. It discloses that only formally proven facts are returned, distinguishes soft deductions, mentions auto-injected LIMIT (max 1000), and describes output formats for different SPARQL query types.

  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 long but well-structured with bold headings and examples. It is front-loaded with the core purpose. The example workflows are somewhat verbose, but they serve the guidance purpose; still, a few sentences could be trimmed without loss.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (SPARQL over a semantic graph) and the absence of an output schema, the description fully covers return value formats (SELECT, ASK, CONSTRUCT/DESCRIBE), query scoping, prefixes, and limits, making it self-sufficient for an AI 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?

  Schema coverage is 100%, but the description adds significant meaning: auto-added SPARQL prefixes, default output format behavior, and query scoping guidelines with namespace prefix examples. This goes well beyond the schema fields.

  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 'Query the semantic memory graph using SPARQL' with a specific verb and resource. It is distinct from siblings like search_entity and verify_inference by emphasizing formal proof and SPARQL execution.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Contains an explicit 'When to use' section and provides alternatives: if not proven, use verify_inference() then suggest_rule(). Example workflows illustrate when to query vs when to verify or suggest rules.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.