brainlehr

by 3lehr

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools fall into recognizable domain clusters (knowledge_*, lesson_*, project_*, session_*, annahme_*), and the detailed descriptions often explicitly separate near-neighbors. However, several abstract project-lifecycle tools (project_boundary, project_actor_boundary, project_commit_gate, project_runtime_evidence, project_commit_ack, project_change) are hard to distinguish by name alone, and freigabe_setzen vs. knowledge_freigeben use overlapping 'release' vocabulary for different operations.
Naming Consistency3/5
The server uses useful prefixes like knowledge_, project_, session_, and lesson_, but mixes English verbs (knowledge_add, lesson_record) with German verbs (knowledge_zurueckziehen, session_checkpoint_setzen) and inconsistent noun/verb structures (annahme_liste, freigabe_setzen, knowledge_trust_score). The pattern is readable but not predictable enough for an agent to guess tool names reliably.
Tool Count2/5
45 tools is far above the well-scoped 3-15 range and even above the 16-25 'heavy' band. While the overall domain is broad and each tool seems specialized, the surface would be much more navigable if project lifecycle/evidence tooling and knowledge statistics/reporting were consolidated or split into separate sub-servers.
Completeness4/5
The knowledge tree, relations, lessons, assumptions, sessions, project evidence, and setup each have reasonable lifecycle coverage, including nuanced operations like withdrawal, re-release, trust scoring, and curator runs. The main gaps are minor but real: no way to update an assumption after creation, no node move/reparent operation, and no catalog removal tool.
Average 3.8/5 across 45 of 45 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1490 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that a selection is made, but does not reveal what happens after the selection, whether state is mutated, what the output is, or any side effects. This is a significant gap for a tool with 8 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the main verb. However, it is under-specified for the tool's complexity and lacks any structured detail about parameters or outputs, making it more sparse than appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no annotations, and no output schema, yet the description provides only a bare high-level statement. An agent cannot determine valid values for task_type, the meaning of the boolean flags, or what the tool returns, so the description is far from complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not compensate at all. It never mentions task_type, risk, or any of the boolean parameters, leaving an agent with no semantic understanding of how to fill them. The only values mentioned (off, light, strong) do not appear in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Waehlt' selects) and a resource (off/light/strong for evaluation, ranking, or decision), making the core action clear. However, it does not differentiate this tool from siblings like prompt_invarianz_pruefen, nor does it mention the 'planen' (planning) aspect implied by the name.
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 provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or related sibling tools that might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description does useful behavioral disclosure: it says the call is 'bounded ephemeral WORKING impact' and lists what it does NOT return ('no prompt, summary, raw code, database write, or receipt'). This is genuine transparency about side effects and return behavior. However, it does not explain what 'WORKING impact' means concretely or whether any state is mutated, so it is not a full 5.
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 compact sentence that front-loads the action and immediately states key constraints and exclusions. It is concise and every phrase carries information. Minor clarity issues ('WORKING', 'receipt') are present, but the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, 0% parameter coverage, and 43 sibling tools, this description is too thin for an agent to call the tool correctly. It explains the result's general shape but not parameter semantics, prerequisites, or when it applies; the exclusion list helps but does not compensate for the missing core usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the six parameters. The name hints at batch completion, and the schema defines fields, but an agent gets no guidance on the meaning of 'now', 'mode', 'event_source', 'batch_id', or 'agent_owned_untracked_paths', nor on their relationships. With 0% coverage and no compensating prose, this is a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a verb ('Queue') and a resource ('client-neutral completed-edit event'), which is clearer than a tautology. However, 'completed-edit event' is niche jargon and the tool name edit_batch_complete already conveys the same idea, so the description mostly restates the name rather than explaining what the tool actually does or what a caller should expect. It does not distinguish itself from siblings such as project_change or session_checkpoint_setzen.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use guidance, prerequisites, or alternatives. The phrase 'client-neutral' implies a constraint but not when an agent should choose this over related project_* or session_* tools. With 43 siblings and no usage direction, an agent is left to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It does convey that this is a read operation and adds a useful behavioral trait by labeling the recommendation 'deterministisch.' However, it does not describe what happens when the checkpoint is missing, what the returned recommendation contains, or how determinism is achieved.
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 efficient sentence with the core action front-loaded and no filler. It is appropriately sized for a simple tool, though a short parameter or output note would make it more useful.
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 no annotations, no output schema, and no parameter descriptions, this tool is under-documented. An agent cannot reliably know what to pass for the optional fingerprint or what shape the returned checkpoint and chat-switch recommendation take.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention session_id or current_topic_fingerprint. The word 'optional' hints at some optionality, but an agent cannot determine which parameter is optional or how to populate current_topic_fingerprint.
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 action ('Liest einen Checkpoint') and the distinctive secondary output ('gibt optional eine deterministische Chatwechsel-Empfehlung'), so an agent can tell this is a checkpoint-read tool. It does not explicitly contrast with sibling tools, but no direct checkpoint-reading sibling appears in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as prompt_invarianz_pruefen or the knowledge/project tools. The chat-switch recommendation hints at one use case, but conditions, prerequisites, and exclusions are not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It provides some useful traits: the checkpoint is temporary and no model/recall/free-text processing occurs. But it omits side effects such as whether an existing checkpoint is overwritten, persistence behavior, or prerequisites for the session.
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 compact sentence with no filler. Every clause adds value: it identifies the action, the object, the temporary nature, and what the tool does not do.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex: 9 parameters, 5 required, no schema descriptions, and no output schema. The description does not explain required fields, array semantics, or invocation context, leaving the agent without enough information to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter-level meaning. Required fields like context_fraction, topic_fingerprint, and next_authorized_action remain completely unexplained, so the agent cannot infer what values to supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Setzt') and resource ('temporären technischen Sitzungscheckpoint') and clarifies scope by excluding Freitext, Recall, and Modellaufruf. It is clearly distinguishable from reading or closing checkpoints, though it does not explicitly name sibling alternatives.
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 'ohne Freitext, Recall oder Modellaufruf' clause implies this is for low-level technical state capture rather than semantic or model-driven operations. However, there is no explicit when-to-use guidance or comparison to siblings like session_checkpoint_lesen or session_checkpoint_schliessen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It openly states privacy-relevant behavior: it never captures prompt/thinking, never stores a user profile, and treats cwd/repository/manifest alone as unknown. It also discloses the core decision rule for automatic code detection. It does not describe side effects or error behavior, but the disclosed invariants are meaningful and specific.
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 compact: three sentences, each adding information about the tool's purpose, privacy guarantees, and decision rule. It is front-loaded with the core purpose. Minor jargon like 'request boundary' reduces immediate readability, but there is no fluff or repetition.
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?
The tool has no output schema, no annotations, and low schema coverage, so the description must provide substantial context. It explains privacy guarantees and the staged-tree rule, but it omits what the returned boundary contains, what the operation parameter means, how the mode enum values differ, and what the tool should be used for in practice. This is incomplete for an agent that must call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the description does not compensate for the missing parameter details. The enum values for mode, phase, and operation are not explained beyond the phase list in the purpose statement and the 'Explicit mode wins' rule. Only project_root receives meaningful description, both in the schema and briefly in the tool description, leaving three parameters under-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Return') and identifies the resource ('one token-capped request boundary') and the scope of phases it applies to (plan/read/edit/build/test/commit). It is reasonably clear, though the term 'boundary' itself is not defined and the description does not explicitly distinguish this tool from related siblings like project_actor_boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool versus alternatives, and no sibling or alternative tool is mentioned. Some usage behavior is implied through mode resolution ('Explicit mode wins; only a non-empty staged tree is an automatic code signal'), but there is no direct guidance such as 'use when...' or 'if you need X, use Y instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds useful behavioral constraints: exactly one result, bounded, tree-hash-bound, and a clear list of rejected artifact types. However, it does not disclose side effects, persistence semantics, error behavior, idempotency, or return value, which would matter for a registration-style 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no filler. The primary action and resource are front-loaded, and the rejection criteria are expressed compactly. Every sentence 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?
For a mutation-like registration tool with no annotations and no output schema, the description is too thin. It does not define what makes an evidence tool 'available', what qualifies as a valid bounded result, what the tool returns or does on failure, or how the tree-hash-bound format should be supplied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not directly explain 'artifact' or 'project_root'. It indirectly characterizes the artifact as a bounded, tree-hash-bound result, but an agent still lacks guidance on the expected object shape, how project_root should be formatted, or how the tree hash should be represented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action ('Register'), a concrete resource ('tree-hash-bound result from an available manifest evidence tool'), and adds explicit exclusions ('No raw code, prompt, transcript, database write or durable receipt is accepted'). It is distinct from the sibling knowledge and project tools, though 'available manifest evidence tool' is somewhat underspecified, so it misses a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you have a bounded, tree-hash-bound result from a manifest evidence tool. It also provides negative guidance by listing accepted input categories, but it never names an alternative tool or explicitly states what to use for raw code, prompts, transcripts, database writes, or durable receipts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool checks something, but it does not disclose whether the operation is read-only, whether it has side effects, how threshold or high_risk influence behavior, or what the output looks like. This is a significant gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no filler words and the main verb placed upfront. It is efficient and easy to parse, though the lack of supporting detail limits its overall usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no annotations, and no output schema, this description is incomplete. It does not explain how the parameters interact, what constitutes a valid run, what the stability check returns, or whether any permissions or prerequisites are needed. An agent would likely need to inspect the schema or make assumptions to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It offers some semantic signal by linking 'Vergleichslaeufe' to the 'runs' parameter and 'evidenzbelegt' to the required 'evidence' field, but it says nothing about 'high_risk' or 'threshold'. These parameters remain essentially undocumented from a behavioral standpoint.
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 names a specific verb ('Prueft') and a specific resource ('evidenzbelegte Vergleichslaeufe'), and specifies what is being tested ('Stabilitaet und Reihenfolgeeffekte'). This clearly differentiates it from the sibling 'prompt_invarianz_planen', which is about planning rather than checking invariance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when evidence-backed comparison runs need to be checked for stability and order effects. However, it does not explicitly state when not to use it, nor does it name alternatives such as 'prompt_invarianz_planen', leaving the usage guidance largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It does transparently explain the sorting behavior and its rationale, which is genuinely useful context. However, it does not disclose the result shape, whether the operation is read-only (only implied by 'auflisten'), what 'schlechtest belegt' means operationally, or pagination/limits behavior.
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?
A single dense sentence with the core function front-loaded, followed by ordering criteria and a short justifying rationale. Every clause earns its place, though the philosophical tail could be tightened without losing decision-relevant meaning.
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?
This is a 5-parameter list tool with no output schema and no annotations, so the description should compensate by describing what each returned assumption entry contains and how parameters like max_results and status interact. It covers only scope and ordering, leaving an agent guessing about the return format and the operational meaning of 'belegt'.
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 60% (actor, model, and session are documented; status and max_results are not). The description reinforces the status='offen' default by scoping the tool to open assumptions, which adds marginal meaning. But it adds nothing about the other enum values (bestaetigt, widerlegt) or how max_results behaves, so it sits at the baseline 3.
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 opens with a specific verb+resource pair ('Offene Annahmen auflisten' = list open assumptions) and adds precise ordering criteria (worst-documented and oldest first). It implicitly distinguishes itself from assumption-manipulation siblings like annahme_erfassen and annahme_entscheiden, though it never names an alternative explicitly.
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 rationale clause ('was am laengsten unwidersprochen weitergetragen wurde, ist am tiefsten in spaeteren Entscheidungen verbaut') implies the tool is for triaging which assumptions are most dangerous to downstream decisions, giving an agent a sense of when it matters. But there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as knowledge_search or knowledge_read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses important behaviors: idempotency, delegation through project_ensure, the recording of a lifecycle witness, and explicit non-destructive guarantees. It does not cover permissions or error conditions, but the core side-effect profile is clearly visible.
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?
Two tightly written sentences with no filler. The first sentence fronts the core action and mechanism, and the second earns its place by adding safety-relevant non-destructive guarantees.
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?
Adequate for a straightforward attach tool: an agent can infer the non-destructive, idempotent behavior and likely call it with project_root and actor. However, there is no output schema, no annotations, and no explanation of how this relates to project_ensure and project_detach, leaving lifecycle semantics under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no direct parameter-level meaning. The required 'actor' is only defined by minLength in the schema and is never explained, while project_root and project_id are already documented in the schema, so the description does not compensate for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('attach'), identifies the resource ('a local Git project'), and adds meaningful qualifiers: idempotent, via project_ensure, and records a revision-bound lifecycle witness. It is clearly distinct from detach, but it does not explicitly differentiate itself from the sibling project_ensure, so it stops short of 5.
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 explains what the tool does but gives no guidance on when to choose it over project_ensure or project_detach, and no when-not-to-use conditions. The intended operation is stated, but the alternatives are left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral disclosure burden. It adds useful behavior beyond the schema: the optional 'query' performs a hybrid keyword-and-meaning search across specific fields. However, it does not disclose result limiting behavior, ordering, or the fact that status defaults to 'active' (though that is visible in the schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. The main purpose is front-loaded, followed by the filtering options and the special hybrid search behavior. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter query tool with no output schema and no annotations, the description covers the main filters and the hybrid search but omits max_results behavior and the response shape. The default status is provided by the schema, but the overall context is adequate yet not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, so the description must compensate. It explains type, project, status, and query semantics, including the hybrid search targeting description/root_cause/prevention. Only max_results is left to the schema, which is largely self-explanatory given the parameter name and default.
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 a specific verb and resource: "Query lessons learned." It also lists the main filter dimensions (type, project, status), making the tool's purpose plain. It does not explicitly differentiate from sibling tools like knowledge_search, but the lesson-specific scope is evident enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given for when to use this tool versus alternatives such as knowledge_search or lesson_record/lesson_update. The usage context is only implied by the verb 'Query' and the mentioned filter fields, with no exclusions or routing hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states what the tool never does: it never stores or reads prompts, responses, hidden thinking or transcripts, and never spawns an agent. This is specific and useful. It does not disclose whether the tool mutates checkpoint state or how recommendations are delivered, but the core privacy and side-effect boundaries are well covered.
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 tight sentences with no filler. The first sentence leads with the action and decision options; the second adds valuable boundary constraints. Every sentence earns its place, though the term 'refresh-delta' is assumed to be domain-known.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, five required, no output schema, and no annotations, the description covers intent and safety but leaves critical operational gaps: parameter meanings are unexplained, and the structure of the returned recommendation is not described. An agent would struggle to construct a correct call solely from this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the six parameters. Some names like session_id and project_id are self-evident, but task_fingerprint, role_capability, source_revision, and independent_review are left entirely unexplained. The description fails to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Recommend') and names the concrete decision outcomes: reuse, refresh-delta, or a fresh agent from compact technical checkpoint state. It clearly distinguishes this as a recommendation-only tool by saying it never spawns an agent, but it does not explicitly differentiate itself from the session_checkpoint_* siblings or other session-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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when an agent-reuse decision is needed based on checkpoint state, and the mention of 'reuse, refresh-delta or a fresh agent' covers the decision space. However, it gives no explicit guidance on when to use this tool versus checkpoint read/write tools or other sibling tools, and it provides no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses two meaningful behaviors: summary-only returns for token efficiency and the default exclusion of reference material. It does not cover other observable behaviors (hybrid keyword+embedding matching, expired-norm ranking/marking, lesson dropping under time filters), though the comprehensive parameter schema fills much of that gap.
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?
Three sentences with no waste: purpose first, then return-type tradeoff, then the default-scope caveat. Each sentence carries distinct information and the most decision-relevant fact (default scope) is stated up front.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with no annotations and no output schema, the description is adequate but lean: it covers return type and default scoping, and the 100%-covered parameter schema handles the details. However, with no output schema, the response structure beyond 'summaries' is never described, and no example or result-metadata hint is given, which is a meaningful gap at this complexity level.
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 top-level description adds little beyond the schema: its nachschlagewerk explanation largely repeats the parameter's own description regarding the 85% reference-material exclusion and default False behavior. No syntax or format details are added for query or date parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('full-text search across knowledge') and adds a distinguishing behavior: it 'returns summaries (not full content)', which separates it from content-retrieval siblings like knowledge_read. However, it never names a sibling explicitly, so differentiation is implicit rather than direct.
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 gives clear scope guidance for the main toggle ('searches Arbeitsbestand only by default; set nachschlagewerk=True to include reference material'), which tells the agent when to configure a parameter. But it offers no when-to-use vs. alternatives guidance (e.g., when to prefer knowledge_browse or knowledge_read), leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It meaningfully discloses that the acknowledgement binds actor, base commit, staged/untracked digest, and reason; that editing invalidates it; and that the reason must be non-secret. It does not mention permissions or return behavior, but the disclosed invalidation and secrecy rules are substantive.
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 compact sentences with the action front-loaded and no redundant phrasing. Every clause adds information: scope, binding semantics, invalidation behavior, and the non-secret constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-required-parameter operation with no annotations and no output schema, the description covers core semantics well. However, it leaves gaps around usage alternatives, explicit parameter mapping, and what a successful call returns, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the bare parameter names. It directly maps actor and acknowledgement_reason, implies signature via 'signed', and loosely ties project_root to 'current staged tree', but it does not define expected formats or the exact use of project_root and signature in the binding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Append'), a specific resource ('one signed local acknowledgement'), and a scope ('current staged tree'), so an agent can understand the core operation. It does not explicitly distinguish itself from related commit workflow siblings like project_commit_gate, which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives such as project_commit_gate or project_change. The description implies a context ('current staged tree') and gives one content constraint ('Reason must be non-secret'), but it does not tell the agent when to choose this tool or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it does so well: it states the operation is read-only, explains that the gate is opt-in, and clarifies that absence of configuration means no enforcement. It also warns that a local hook is not a security boundary, which is valuable context beyond a simple status check. It does not describe the return format or possible outcomes, but the core behavioral traits are disclosed.
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 with no fluff. The core purpose is front-loaded, and the second sentence adds high-value interpretive and security guidance that earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but there is no output schema and no annotation coverage, so the description must explain both the input expectation and the return value. It explains the gate's semantics well but omits what 'check' returns and what project_root semantically requires, leaving an agent partially underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter, project_root, with 0% schema description coverage, so the description must compensate by explaining what value should be passed. The description does not mention project_root at all, leaving the agent to infer its meaning from the name alone. No additional semantic value is added beyond the schema.
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 identifies a specific action ('check') and a specific resource ('opt-in staged-tree gate'), and the 'read-only' qualifier differentiates it from mutation-style siblings like project_commit_ack and project_change. However, it does not explicitly contrast itself with any sibling tool, so it stops short of full differentiation.
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 this is the tool to use when you need to determine whether the opt-in staged-tree gate is enabled, and it gives useful interpretive context about what a missing gate means. It does not explicitly state when to prefer this tool over alternatives or when not to use it, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states it lists only explicit knowledge edges, but does not mention pagination, ordering, default scope behavior, whether the node parameter filters incoming/outgoing edges, or what an empty result looks like. As a read-only tool, safety is implied but not stated.
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?
Two sentences, front-loaded with the core behavior ('List only explicit knowledge edges') and then optional filters. No filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with optional filters and no output schema, the description is mostly complete but lacks edge-case behavior: what happens when node is invalid, whether filtering by scope is a security boundary, and what count/format is returned. Given sibling tools related to knowledge relations, a sentence about this being the read counterpart to knowledge_relation_add/update/remove would strengthen routing.
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 covers node, actor, model, session, relation_type with descriptions, leaving scope with only a default and no detailed semantics. The description adds the concept of filtering by relation type/scope, but scope remains underspecified beyond 'all'. With 67% schema coverage, description does not need to repeat all params, yet adds value by framing the node as optional and the operation as filtered.
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?
Description names a specific verb ('List') and resource ('explicit knowledge edges'), and further clarifies scope: optionally incident to one node, filtered by relation type/scope. However, it does not explicitly distinguish itself from sibling link-related tools like knowledge_relation_add/update/remove beyond phrasing, though 'canonical link-read path' hints at read purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says it is the 'canonical link-read path,' which implies it is the default for listing explicit knowledge edges. It does not explicitly state when to use alternatives like knowledge_search or knowledge_browse, but the 'only explicit knowledge edges' phrase helps differentiate from other read paths. Lack of explicit exclusions keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does add a meaningful guarantee—exactly one edge is removed and nodes are never deleted—but it does not mention irreversibility, error behavior for invalid IDs, idempotency, or successful response details.
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?
Two tight sentences with no filler: the action and target come first, and the safety qualifier follows immediately. Every word contributes to understanding the operation and its limits.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter, the description covers the core operation and a key safety property. However, without an output schema or annotations, it leaves the agent uninformed about expected return values and failure modes, making it merely adequate rather than 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 75%, so most parameters are already described. The description confirms relation_id as the edge identifier that drives the removal, adding modest meaning beyond the schema, consistent with the high-coverage baseline.
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 ('Remove') and a precise target ('exactly one explicit edge by relation ID'), clearly identifying the resource and operation. The added clause 'Nodes are never deleted' reinforces the scope and distinguishes it from node-level removal tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: remove a relation when you know its ID. The 'Nodes are never deleted' statement gives a when-not hint, but the description does not explicitly name alternatives or conditions for choosing this over siblings like knowledge_relation_update or knowledge_update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure, and it does meaningfully: 'Fail-closed' is a strong behavioral signal that the tool returns denial/negative results when the check cannot be satisfied, and 'Remote requests are denied as a tenant/auth coverage gap' explains why and how a class of inputs is treated. It does not disclose output shape, error behavior, or side effects, but for a validation/boundary check the fail-closed semantics are the most important behavior and are clearly stated.
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?
Two sentences with high information density and no filler. The fail-closed behavior is front-loaded, and the remote-request policy follows immediately. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple local boundary check, the description captures the critical policy behavior but leaves important context unstated: no output schema exists, and the description does not say what the check returns or what an agent should do after a denial. Given the low schema/annotation richness and the fact that an agent must invoke this correctly among 40+ siblings, the absence of a stated return/response contract or parameter rationale makes it merely adequate rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not define any of the four parameters. The names 'actor' and 'project_id' are self-explanatory enough, and 'remote' plus 'requested_project' are inferable as part of a boundary check, but the description adds no explicit meaning to the parameters. With no schema descriptions and no parameter explanation in prose, the agent is left to infer the semantics of 'remote' and 'requested_project' from the tool name and the remote-denial sentence alone, which is a real gap.
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's first clause, "Fail-closed local actor/project check," clearly identifies the verb (checks) and resource (actor/project) and distinguishes it from likely sibling tools like 'project_boundary' by emphasizing 'local' and the fail-closed boundary behavior. The second half adds a specific policy detail (remote requests denied) that reinforces what this check is for. It does not fully spell out a distinct operation name, but it is far from vague and does differentiate from the project-commit and session-family siblings.
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 makes the intended usage context explicit: this is a local actor/project authorization or boundary check that should fail closed, and remote requests are explicitly treated as a denied 'tenant/auth coverage gap.' This tells an agent when to reach for this tool (local actor/project checks) and gives exclusion logic (remote requests are not handled here). It does not name a specific alternative sibling, but it does convey a clear when/why distinction that is sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure, and it does: bounded result sizes (five summaries, eight Git hits), a precondition for deeper modes, and side-effect constraints ('never recursively loads a branch', 'never stores raw source automatically'). It could add more about return shape and error behavior, but the core safety and sequencing traits are explicit.
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?
Three dense sentences, all load-bearing, with the most important operational rule (summary-first) front-loaded. No repetition of schema or annotation content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-output-schema, no-annotation tool with eight parameters and high complexity, the description gives a usable high-level protocol but omits the return contract details and several advanced parameters. 'Mandatory next-choice contract' is named but not explained, and there is no output schema to fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description must compensate. It adds real meaning for depth and selected_node_ids (summary-first contract, up to three IDs) and bounds max_results, but it leaves evidence_witnesses, selected_witness_ids, and capability_config_hash entirely unexplained, which is a significant gap at this coverage level.
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 opens with a clear verb and object ('Load task context progressively') and explains what the tool returns: bounded summaries, Git hits, references, and a next-choice contract. It does not explicitly differentiate itself from sibling tools like project_boundary or knowledge_read, so it misses the full 5.
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 strong mode-ordering guidance: first call must be depth=summary, and deeper modes are only valid with up to three selected node IDs from that same result. It also states two absolute prohibitions (no recursive branch loading, no automatic raw-source storage). It stops short of naming alternative sibling tools for when project_context should be skipped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses that the server sets the Pruefzeitpunkt, that the database rejects calls without Beleg and Pruefer, and why tatsaechliche_kosten matters for 'widerlegt'. It does not describe return values or all side effects on the assumption record, but the disclosed constraints are substantive and useful.
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 compact and front-loaded: it states the purpose in the first sentence and then adds only high-value constraints and rationale. Despite covering nine parameters, there is no filler or repetition of schema details.
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 core call contract, mandatory fields, server behavior, and the conditional actual-cost field. However, it does not mention what happens if annahme_id is missing or invalid, what the tool returns, or how belegrang should be used in practice. Given no annotations and no output schema, the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, and the description adds meaning where the schema is thin: it ties geprueft_von to the mandatory Pruefer requirement, explains tatsaechliche_kosten as the comparison enabling evaluation of the original estimate, and clarifies why no caller-provided timestamp exists. The remaining parameters already have schema descriptions.
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 opening phrase 'Eine Annahme bestaetigen oder widerlegen' names a specific action and resource, clearly indicating this tool confirms or refutes an assumption. It is distinct from siblings like annahme_erfassen or annahme_liste, but no sibling is explicitly named, so differentiation is implicit rather than stated.
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 gives actionable usage context: 'Beleg und Pruefer sind Pflicht' and the server-set timestamp clarify how to call the tool correctly, while 'Bei status='widerlegt' gehoert ... tatsaechliche_kosten dazu' adds a conditional rule. However, it never explicitly says when to choose this tool over alternatives such as annahme_erfassen or annahme_liste, so usage guidance is implied rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden. It does disclose that the tool returns only titles and summaries, which is a meaningful behavioral trait and implies a read-only, token-conscious operation. It does not explicitly state the absence of side effects or discuss access/auth behavior, but for a simple browse operation the disclosed behavior is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences and every clause earns its place: the action, the return shape, the token-efficiency rationale, and the root-path usage hint. It is front-loaded and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity browse tool, the description covers the key operational facts: what is browsed, what is returned, and how to target the root. The absence of an output schema is partially mitigated by the explicit 'titles+summaries' return note. Minor gaps like whether children are immediate-only or recursive are not stated, but they are not essential for basic invocation.
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 already documents all 5 parameters with 100% coverage, so the description needs to add little. The only added guidance, 'Use "/" for root,' largely repeats the schema default for path. The description adds no new meaning to actor, model, session, or project_filter beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Browse') and resource ('children of a knowledge tree node'), and further clarifies the return payload is 'titles+summaries only.' This distinguishes it from siblings like knowledge_read or knowledge_search, which presumably return full content or search results.
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 gives a concrete usage hint ('Use "/" for root') and implies the tool is for lightweight tree navigation by mentioning token-efficiency. However, it does not explicitly state when to prefer this over knowledge_read, knowledge_search, or the other knowledge siblings, so the selection logic is left mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It does state the primary mutation effect and that endpoints are preserved, which is meaningful. It omits what happens to unspecified fields, failure behavior, permissions, or idempotency, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the update target and ends with a valuable constraint. Every word earns its place; there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter mutation tool with no annotations and no output schema, one sentence is insufficient. An agent is left without guidance on return values, failure modes, or the exact roles of several parameters, so the description is not complete enough on its own.
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 only 33%, so the description must compensate. It gives update roles to relation_id, evidence, weight, and relation_type, and 'provenance' loosely covers actor/model/session/source. It does not clearly clarify confidence or source, so compensation is incomplete.
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 names a specific action (update), a specific resource (evidence/provenance/weight/type of an edge), and a key constraint (by relation ID; endpoints stay stable). This clearly distinguishes it from knowledge_relation_add, knowledge_relation_remove, and knowledge_update without needing to open sibling schemas.
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?
It conveys clear context: use this when an explicit relation already exists and you have its relation_id to revise metadata, not to change endpoints. However, it does not explicitly name alternative tools such as knowledge_relation_remove or knowledge_relation_add for endpoint restructuring, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond a simple 'get statistics' by explaining the semantics of the anlass_by split: selbst/betreiber are self-reported and only as reliable as the caller, hook/skript are objective, and unbekannt is the default for older entries. It also explicitly instructs readers not to treat the categories as equally trustworthy. It does not explicitly state read-only behavior, but the word 'statistics' strongly implies a non-mutating operation.
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 consists of two sentences, with the core purpose front-loaded in the first sentence and the necessary trustworthiness caveat in the second. There is no filler. The second sentence is dense and somewhat convoluted with nested parentheses and slashes, but every part serves a purpose.
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 no parameters, no output schema, and no annotations, the description covers the essential return semantics: the types of statistics and the meaning of the anlass_by categories. The main omission is an explicit statement that the operation is read-only, but this is reasonably inferable from 'statistics'. The description handles the most confusing part of the output (trust levels of categories) very well.
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?
This tool has zero parameters, so there is no parameter ambiguity to resolve. The description adds no parameter-level details, and none are needed. The baseline of 4 for zero-parameter tools applies.
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 identifies the tool as providing overview statistics of the knowledge database and enumerates concrete metrics: node counts, lesson counts, access patterns, and anlass distribution. This positions it as an aggregate/analytics tool, distinct in likely purpose from sibling tools like knowledge_search or lesson_query. However, it does not explicitly name alternatives or state what it is not, so sibling differentiation remains implicit.
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 offers no explicit guidance on when to choose this tool over siblings. It does provide a strong interpretive caveat about the anlass_by fields – warning that the four categories are not equally trustworthy – but that is guidance for reading output, not for selecting the tool. When-to-use vs. alternatives is only implied by the tool's name and aggregate framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It explicitly discloses that the operation is scoped to the active local project association and that knowledge, sources, receipts, capsule history, and project files remain unchanged, which reduces the risk of assuming a destructive teardown. It does not detail side effects like reversibility or whether the actor association is cleared.
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 entire description is one front-loaded sentence that states the action, scope, and exclusions. Every phrase adds information; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter operation the description is adequate, but with no output schema and no annotations it omits the result/return behavior and does not clarify the role of actor. It also leaves prerequisites implicit (e.g., a currently attached active local project).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (project_root is described as 'Any path inside the Git project'), but the description adds no parameter-level meaning and the required actor parameter is left undefined. At this coverage level, the description should compensate, and it does not.
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 names a specific verb ('Detach') and a specific scope ('the active local project association'), and further clarifies boundaries by listing what is left unchanged. This distinguishes it from destructive or broader project operations among the siblings, notably project_attach.
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?
Usage is implied: call it to remove the active local project association. However, there is no explicit when-to-use/when-not-to-use guidance, no mention of project_attach as the inverse, and no conditions such as 'only when a project is currently attached.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full disclosure burden and handles it well: it reveals partial-update semantics ('Only given fields are changed'), data normalization behavior ('unmangles field-tag corruption'), and the destructive delete path. It omits return shape, reversibility, and error behavior, but the highest-risk traits are disclosed.
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?
Two dense sentences with zero filler: purpose first, then scoping behavior, then delete usage. Each clause earns its place and the structure is well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter mutation tool with no annotations and no output schema, the description covers the essential semantics (what changes, corruption handling, deletion) but leaves gaps: no return-value description, no behavior for a nonexistent lesson_id, and no statement about update reversibility.
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 only 42%, so the description must compensate. It adds crucial semantics: partial-update means all non-lesson_id fields are optional and only provided ones take effect, and delete:true is the deletion switch. However, the undocumented enums (status, severity) and content fields (root_cause, resolution, prevention, projects) get no elaboration, though their names are self-explanatory.
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 names specific verbs ('Correct or delete') and a specific resource ('a recorded lesson'), adding meaning beyond the tool name. It is immediately distinguishable from sibling lesson_record (creation) and lesson_query (reading) as the mutation path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('delete a bad entry', 'Use delete:true to remove a bad entry') and ties behavior to lesson_record, but never explicitly states when to prefer this tool over knowledge_update, lesson_record, or lesson_query. No exclusions or alternative routing are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and handles it well: it promises no mutation on argument-less calls, spells out the confirmed=true requirement on non-empty inventories, and explains that catalogs are imported as 'nachschlagewerk' without diluting hit rates. Minor gaps remain around exact write behavior when setup does run and around error reporting.
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 dense and mostly front-loaded, with no wasted sentences: the safety-critical no-argument behavior comes first, followed by the confirmed=true guard and catalog semantics. The first sentence is long and dash-heavy, which slightly reduces readability, but 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 tool with no annotations and no output schema, the description provides substantial context: safe invocation mode, state-dependent behavior, the confirmed=true prerequisite, and catalog handling. It does not specify the exact return format or error behavior, but it is sufficient for an agent to decide whether and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description goes beyond the schema by grouping parameters into the four wizard questions and by adding the non-obvious behavioral effect of catalogs on retrieval quality. It also maps 'language' to 'Sprache des eigenen Materials' and 'profile' to the einzelplatz/unternehmen choice.
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 identifies the tool as a first-start assistant (BDW-P11) and explains its core behavior: without arguments it delivers only the current situation and four questions, and changes nothing. It does not explicitly distinguish itself from sibling tools, so it misses the highest bar for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage conditions: no arguments yields a read-only prompt; on an empty inventory answers may run immediately; on a grown or already configured inventory nothing changes unless confirmed=true. This is clear context, though it does not explicitly name alternative tools or state when to prefer another sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden and does well: it states the operation creates exactly one edge, requires existing endpoints, never infers links from tags/text, and validates scope, type, confidence, and duplicates. It does not cover authentication, response format, or failure behavior, but the core mutation semantics and validation constraints are disclosed.
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?
One dense sentence front-loads the primary purpose, then adds two high-value constraints without filler. Every clause 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 create-edge tool with no output schema, the description covers purpose, endpoint existence requirement, evidence requirement, and validation behavior, which is the core calling contract. It omits explicit return/error semantics and usage alternatives, but the parameter schema complements it well.
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 73%, and the schema already describes most parameters; the description adds the important contextual point that source_node/target_node must be existing IDs or paths and that edges are explicit and evidenced. It does not name or explain all optional parameters, but the schema handles that burden.
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 ('Create') and a precise resource ('one explicit evidenced knowledge edge'), with clear scope: only existing node IDs or paths. This distinguishes it from knowledge_relation_update/remove/list and from knowledge_add, so an agent can identify it without opening the schema.
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 its use case: add an edge between already-existing nodes when evidence is present, and never for inference-based linking. It does not explicitly name alternatives or state when not to use it, though sibling names make some of this inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and meets it well: it explicitly declares the operation is read-only, states it only lists and never mutates, and adds purposeful context about the evaluation workflow. Minor gaps remain around output shape or size, but core behavioral disclosure is solid.
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 compact and front-loads the most important behavioral fact ('Read-only'). It packs in scope, purpose, and a key exclusion in one sentence. The parenthetical 'Auftrag 2026-08-06' is slightly opaque but does not harm overall clarity.
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, safe behavior, and the single parameter well. However, with no output schema, an agent is left without a sense of the response structure or whether pagination/limits apply. For a listing tool used in evaluation, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter already has a clear description with examples. The tool description reinforces that 'session' identifies the writer, adding mild contextual meaning, but does not materially improve on the schema's own explanation.
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 'Read-only' and states a specific action: 'list every knowledge node and lesson written by one session.' It identifies the scope (session actor/writer) and frames it as the evaluation path for isolating entries, clearly distinguishing it from write/modify tools like knowledge_update and knowledge_zurueckziehen.
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 explains when to use this tool: when evaluating or isolating one writer's entries, e.g. before deciding whether to retract them. It also explicitly says the tool never withdraws or deletes. It does not explicitly name an alternative for other filtering scenarios, but the intended usage context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, and it does reveal meaningful behavior: partial-update semantics ("Only given fields change"), the conditional requirement that norm_entschieden_grund becomes mandatory when norm_entscheidung is given, and the side effect that betreiber_weisung "records the operator as decision-maker." However, for a mutation tool it omits standard behaviors an agent needs — reversibility, response/error shape, permissions — and does not say whether updates ripple into related entities like trust scores.
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 core purpose is front-loaded in the first clause and every subsequent clause carries a distinct constraint or dependency — there is no filler or repetition of the schema. It is, however, one dense run-on paragraph built on em-dashes and parentheticals, which taxes careful reading and slightly hurts scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter mutation tool with no output schema and no annotations, the description covers the convoluted norm_entscheidung conditional thoroughly, which is the highest-risk part of calling this tool. But it omits the return value, failure/validation behavior, and broader side effects, so an agent cannot predict what a successful call returns or what else changes downstream.
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 description coverage is 80% (nearly all parameters documented, with the three bare ones being self-explanatory tags/summary/content), so the baseline is 3. The description earns the extra point by adding cross-parameter meaning: it groups the mutable field families, defines partial-update semantics, explains the gilt_bis/norm_entscheidung contradiction rule, and states the norm_entschieden_grund dependency — relationships the flat schema cannot express.
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?
Opens with the specific verb+resource pairing "Update an existing knowledge node" and enumerates exactly which aspects change (title, summary, content, tags, Normschicht fields). It differentiates from the sibling knowledge_add by targeting existing nodes and even cross-references knowledge_add for field meanings, so an agent can route correctly without opening either schema.
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 update-vs-create context is clear from "existing knowledge node" and the explicit contrast "unlike knowledge_add" for norm_entscheidung. Cross-parameter when-conditions are precise, e.g. "only needed when the change would otherwise contradict the node's existing decision" with a concrete gilt_bis example. It stops short of stating exclusions (e.g., don't use this for creation) or alternatives for node-vs-relation updates, so the guidance is context-rich but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so exceptionally well. It discloses that an unknown same_as ID 'is an error, never a silent new entry,' that similar_lesson_hint is 'a hint only — never auto-merged,' and that an unknown anlass value is 'rejected with the allowed list, nothing is written.' It also reveals subtle side effects such as occurrence increments, escalation to rule at 3+, and that the Stop-hook never directly calls this tool, making 'hook' only self-reported. This level of disclosure goes far beyond what structured fields could provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense block of text with long run-on sentences and no section breaks or bullet points. Every sentence does carry substantive edge-case information, so there is little filler, but the lack of structure makes it harder to parse quickly. The all-caps instruction 'SET beinahefehler=true' is attention-grabbing yet clutters the flow, and the text is arguably longer than necessary for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 16-parameter tool with no annotations and no output schema, the description covers the core workflow, duplicate handling, near-miss semantics, and many error conditions. However, it does not describe the return value or output shape (e.g., what a successful response contains, how similar_lesson_hint is structured, or what the 'rule' escalation returns). The parameter-name mismatch also leaves the near-miss/caught_by flow ambiguous. The description is substantial but not fully complete for an agent to confidently invoke the tool in all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for same_as, occasion (anlass), near_miss (beinahefehler), and caught_by (bemerkt_woran), including the byte-identical duplicate rule and the mandatory nature of caught_by for near misses. However, it systematically uses parameter names that do not exist in the input schema: 'anlass' vs. 'occasion', 'beinahefehler' vs. 'near_miss', and 'bemerkt_woran' vs. 'caught_by'. This mismatch can lead an agent to construct invocations with invalid keys, which is a serious flaw that significantly undermines the semantic value of the description.
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 'Record a lesson learned,' a precise verb+resource statement that clearly identifies the tool's function. The subsequent details about same_as handling, duplicate detection, and near-miss recording make it unmistakably distinct from sibling tools like lesson_update or knowledge_add. Even though sibling tools are not named, the operational specifics fully differentiate this tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit conditions for when to pass same_as ('when this is a repeat of an already-recorded lesson') and for near misses ('Record it in the same flow, do not wait for the end of the session'). It also explains when same_as should not be used and how merging should be done. However, it does not explicitly compare against alternative tools like lesson_update or lesson_query, so the guidance is context-rich but lacks sibling exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It explicitly states 'Read-only' and 'Never withdraws or deletes anything itself,' which is critical behavioral disclosure. It also reveals the returned columns (actor/session/model) and the evaluation intent, adding context beyond the schema.
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 front-loaded with the most important facts: read-only, what is listed, and the filtering criterion. The dash-separated rationale ('isolates one model's entries to judge its quality') is useful but slightly dense with the parenthetical ticket reference. No wasted words overall.
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 list tool with one required parameter and no output schema, the description conveys the operation, the purpose, and the safety guarantee. It does not mention pagination or output format, but the low complexity and self-contained scope make the description sufficient for correct invocation.
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% and the single parameter 'model' is already described with examples. The tool description reinforces that the model filters the entries, but adds no new semantic detail beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'list every knowledge node and lesson written by one model.' It also includes the key filter (model) and explicitly declares read-only behavior, which distinguishes it from mutation siblings like knowledge_update or knowledge_zurueckziehen. The parenthetical columns further clarify the output scope.
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 clear context: the tool is used to isolate one model's entries and judge its quality by outcome. This implies a use case (evaluation) without naming alternative tools explicitly, but the purpose is evident enough that an agent can decide when to invoke it rather than siblings like knowledge_search or knowledge_stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: idempotency ('idempotently adopt or initialize'), non-copying of source code ('never copies raw source code'), and deduplication of existing knowledge ('adopted, not duplicated'). This goes well beyond what the schema states.
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?
Four purposeful sentences, each carrying a distinct point: purpose, artifact creation and non-copying, adoption semantics, and tool-reference statuses. No filler, front-loaded with the main action, though the final sentence could arguably be merged.
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 only three parameters and no output schema, the description covers purpose, side effects, and important behavioral constraints (idempotency, no source copying). Preconditions like being a Git repository are implied by 'Git project' and the project_root description. Slight gap: no explanation of what happens on first run versus subsequent runs beyond idempotency.
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 already provides meaningful descriptions for all three parameters (coverage 100%), including 'Any path inside the Git project' and 'Project-specific capability references to merge'. The description adds context about Git facts and entry points but not parameter-level syntax, so baseline 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 verb 'adopt or initialize' with the resource 'Git project for Brainlehr' clearly states the action and scope, and the description further specifies concrete outputs (.brainlehr.json capsule, project knowledge root). It is distinct from sibling tools like project_attach or project_boundary, so an agent can tell it apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are named; usage must be inferred from 'adopt or initialize'. The description implies this is the setup/ensure tool for Git projects but doesn't state when to choose it over related project tools such as project_change or project_attach.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals meaningful behavior: direct children are returned but only as title+summary, recursion is explicitly excluded, and branch nodes usually have empty own-content with substance in children. This goes well beyond the input schema, though it does not cover failure modes or response formatting details.
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?
Two compact sentences, each earning its place. The core operation is front-loaded, and the important non-recursive and branch-behavior caveats are packed efficiently into the first sentence. The usage note is a single clear directive.
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 supplies enough for an agent to select and invoke safely: it explains what is returned, that traversal is one level, and that browse/search should precede this call. Since there is no output schema, the description at least narrates the return content, though it does not describe exact JSON shape or error 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 schema fully documents parameters. The description's 'by ID or path' restates the node_id schema description rather than adding new semantics. The actor/model/session params are unchanged and add no additional parameter insight.
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: 'Read full content of a knowledge node', then clearly defines the exact scope: full content plus title+summary of direct children, one level, not recursive. It also distinguishes itself from browse/search by noting that this tool reads a known node rather than discovering one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: 'Use browse/search first to find the right node,' which tells the agent to use discovery tools before invoking this one. It implies read is for after node discovery, but it does not explicitly spell out when to choose this tool over knowledge_update, knowledge_browse, or knowledge_search beyond that context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses receipt storage, transitive consumer-chain computation, max_distance truncation with lazy loading, the distinction between import dependency and runtime data flow, and the uncovered non-Python case. It does not mention failure modes or permission requirements, but the disclosed semantics are substantial.
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?
Four dense sentences with no filler; the primary purpose is front-loaded and each sentence adds distinct information about behavior, limits, semantics, and edge cases. This is appropriately concise for 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 the core behavior, truncation and lazy loading, the meaning of import edges, and the non-Python limitation—strong coverage given no annotations and no output schema. It still leaves the exact response envelope and the verification array semantics unspecified, so a perfect score is not warranted.
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 only 40%, so the description must compensate. It does clarify max_distance (return truncation) and implies verification via 'verified commit,' but it does not explain what verification items should contain or how project_root is used. The schema already describes base_commit and semantic_summary, so the description adds only partial parameter value.
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 names specific actions: storing a compact change receipt and computing the complete transitive chain of statically proven Python import consumers. This clearly distinguishes the tool from generic project or knowledge tools and gives an agent an unambiguous sense of what it does.
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 precondition 'After a verified commit' gives clear context for when the tool applies, and the max_distance/lazy-loading explanation clarifies how results are scoped. It does not explicitly name sibling alternatives or state when not to use it, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It explicitly discloses idempotency ('idempotent'), a valuable behavioral trait meaning repeated calls are safe. It also clarifies the checkpoint is temporary, mitigating destructive concerns; however, it does not mention other side effects or return/error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded German sentence that states action, object, condition, and behavior with zero filler. Every word carries meaning and no unnecessary information is included.
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 one-parameter idempotent deletion tool, the description covers the essential information: what is deleted, under what session condition, and that it is safe to repeat. It could add return or error behavior, but given the tool's simplicity and the explicit idempotency disclosure, this is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only gives session_id as a string with 0% description coverage. The description's phrase 'einer beendeten Sitzung' implies session_id refers to a session that has already ended, which adds some meaning. But it does not specify the ID format or its relationship to the checkpoint set/read siblings, so compensation for the schema gap is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Löscht' (deletes) with a precise resource, 'den temporären Checkpoint einer beendeten Sitzung', making the operation unmistakable. This clearly distinguishes it from the sibling checkpoint tools setzen and lesen, which set or read checkpoints rather than deleting them.
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?
It states the relevant context: the checkpoint belongs to a 'beendeten Sitzung' (ended session), which tells an agent when the tool applies. It does not enumerate alternatives or exclusions, but for a simple checkpoint-deletion tool the condition is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a rejection rule ('belegrang='gemessen' ohne nicht leeren 'beleg' wird abgelehnt'), the permanent initial state ('beginnt immer auf status='offen''), and the workflow boundary (confirmation/refutation goes through annahme_entscheiden). It does not mention whether the write is idempotent or whether it triggers side effects, but the disclosed validation and status behavior is strong context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, each earning its place: what the tool is for, why the two params matter, the validation rule, and the workflow boundary. The most important constraint is front-loaded, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter write tool with no output schema and no annotations, the description covers the essential decision logic and the two required fields. It gives enough to call the tool correctly, though it says nothing about return values, which are absent from the output schema and could matter for confirming the created assumption.
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 58%, so the description should add meaning for the least-documented parameters. It does add crucial semantics for belegrang and kosten_wenn_falsch, and it explains the dependency between belegrang and beleg. However, it leaves the purpose of several other parameters (kategorie, notizen, node_path, projects) entirely to their bare type names, and the schema itself provides descriptions for the important ones. This is adequate but not fully compensating for the coverage gap.
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 names the specific verb and resource ('Eine ANNAHME festhalten'), and immediately distinguishes its purpose: recording an assumption while it is still recognizable as an assumption, not after it has proven wrong. It also separates this tool from the sibling annahme_entscheiden by stating that confirmation/refutation only happens there.
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 explicitly frames when to use the tool: record assumptions while still assumptions, before they are confirmed or refuted. It also names the sibling tool annahme_entscheiden as the only path for bestaetigt/widerlegt, and it states the rule that belegrang='gemessen' requires a non-empty beleg, otherwise the entry is rejected. That is clear when-to-use and 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals the network side effect, the local-directory destination, and the no-guessing behavior when quelle.art='keine', including the geholt=false result and reason. It does not mention all possible side effects like directory creation or overwriting, but adds meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the purpose, the allowed catalog values, the network-access constraint, and the special failure case in a single dense sentence. Every clause contributes useful information without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and an output schema, the description covers the main invocation context, the critical network-vs-setup distinction, and one important edge case. It does not describe the successful return shape or the exact default destination, but it provides enough for an agent to select and call 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?
Schema coverage is approximately 50% because ziel has a description but name only has an enum. The description adds the mapping between catalog names and the enum values, and clarifies that the target is a local directory. However, it does not explain the actual default for ziel or further detail the meaning of each 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 uses a specific verb ('Holt') and identifies the resource ('einen der von einrichtung_starten vorgeschlagenen Kataloge') with explicit catalog names (bsi, nasa-llis, wcag). It also distinguishes itself from the sibling einrichtung_starten by stating that network access happens here and not there.
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 explicitly says network access is done only here and never via einrichtung_starten itself, giving a clear when-to-use and when-not-to-use instruction. This effectively routes the agent to the correct tool for downloading catalogs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly: it discloses rejection behaviors (unknown parent_path, empty source, inconsistent norm fields, unknown occasion values), confirms nothing is written on validation failure, states that similar-node hints are never auto-merged, and even flags the self-reported/unverified nature of 'hook'/'selbst' triggers. This goes far beyond what annotations could supply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is dense and largely valuable, but it is delivered as one long unstructured paragraph with an embedded JSON example and a philosophical aside about why no default exists. It is front-loaded with the core purpose, but a structured format would make the many constraints easier to consume; not every sentence is strictly necessary.
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 21-parameter tool with no output schema and no annotations, the description covers an exceptional amount: required fields, validation, derivation, occasion semantics, similar-node hint behavior, and an end-to-end example. It is not a 5 because the general success return value is never described (only similar_node_hint is mentioned) and the anlass/occasion naming inconsistency creates ambiguity.
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 90%, so the baseline is 3; the description adds meaningful cross-field semantics — the norm_entscheidung consistency rules, requirement that norm_entschieden_grund is mandatory, gilt_bis/gilt_ab ordering, and the example of a full valid payload. It loses a point because it refers to the schema's 'occasion' parameter as 'anlass', which could cause an agent to pass the wrong key.
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 first sentence states a specific action and resource — adding a new knowledge node to the tree — and the rest confirms this is a creation tool. It clearly distinguishes itself from siblings like knowledge_update, knowledge_read, and knowledge_relation_add without needing their schemas.
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?
It clearly frames when to call it (new node creation) and specifies strong preconditions: parent_path must exist or neuer_ast must be true, source must be non-empty, and norm_entscheidung/norm_entschieden_grund are mandatory with no default. It does not explicitly name sibling alternatives, so it falls short of a 5, but the context is much stronger than mere implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does well: it discloses that only visibility is flipped, that content/summary remain empty, and that the node reappears in search/recall. It does not cover error cases, permissions, or the exact success response, but the core side-effect profile is clearly stated.
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?
Two compact sentences, no fluff, and the most important behavioral distinction ('undo withdrawal', 'only flips visibility') is front-looed. Every clause 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 state-flipping operation with no annotated safety profile or output schema, the description covers purpose, expected effect, and key limitation. It leaves out a note on whether success confirmation or errors are returned, but the tool is simple enough that the provided information is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents every parameter including the 'exactly one of node_id/path required' constraint and the fallback values for actor/model/session. The description adds no parameter-level meaning beyond the schema, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with an explicit verb and target: 'Undo a knowledge_zurueckziehen', and names the observable effect ('the node reappears in knowledge_search/recall'). It distinguishes itself from its sibling inverse by clarifying exactly what it does and does not do, so an agent can tell it apart from knowledge_zurueckziehen and knowledge_update.
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 gives a clear usage context: this is the inverse of knowledge_zurueckziehen, used to reverse a withdrawal. It also states when not to expect more ('Restores nothing'), preventing misuse as a content-restoration or editing tool. This is sufficient guidance relative to the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses non-persistence, the saturating tanh, diminishing returns, kind-specific weighting, the never-firing lesson path, and the exists flag that distinguishes typos from neutral defaults. This is far beyond a one-line summary.
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 dense and technically thorough rather than short, but every clause adds semantic value about weighting, range, or output disambiguation. It is front-loaded with the core definition and uses structural detail effectively, despite relying on a 'see docstring' reference.
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 no annotations, it fully specifies return contents (score, raw counts, exists flag), the neutral value, formula behavior, and edge cases. The only minor gap is explicit usage policy, but the invocation semantics and outcome are well covered.
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 only 50%, but the description compensates by explaining how kind changes the weighted inputs (nodes-only reads and rejected writes, lessons-only re-occurrence) and how ref maps to node/lesson references. It does not formally spell out parameter semantics, but the behavior is clear enough to invoke correctly.
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 names a concrete operation — computing a trust score — and specifies the value range, neutral default, and that it is never stored. It also explicitly distinguishes the concept from norm_rang and confidence, preventing confusion with sibling or related concepts.
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?
It gives rich context about what kind-specific weights apply and what the tool returns, but it never states when to call this tool versus other knowledge tools or when not to use it. The intended use is inferable from the behavior, but no explicit usage direction or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and delivers: it discloses the non-mutating guarantee ('Never changes the stored ketten_hash; the break stays visible, this only records who/when/why next to it'), the error-rejection behavior, the dry-by-default network behavior ('dry by default, no network without an explicit anker_kwargs override'), and the side-effect timing ('that backlog only ever changes at this moment'). This is exemplary behavioral disclosure for a tool with zero annotation coverage.
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 dense paragraph, but every clause earns its place: purpose, rejection conditions, non-mutation guarantee, anchoring behavior, and return-value nuance. Core purpose is front-loaded before operational details. It is longer than ideal but not bloated; minor structural improvement via separate sentences would be possible without adding content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no annotations and no output schema, the description covers an unusually large surface: error behavior, side-effect profile, optional anchor flow, and the return field for the anchor case. The only notable gap is the return format when anker is not set -- the agent never learns what a successful explanation record looks like. The reference to 'anker_kwargs override' without that parameter appearing in the schema is also slightly opaque, though it reads as an environment-level override.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds genuine meaning beyond the schema: it clarifies access_log_id must reference a broken row (tying to the fabrication-rejection behavior) and substantially enriches the anker parameter by explaining anchor construction via ankerverfahren.py, the dry default, and the anker_rueckstand return behavior. The actor/model/session params correctly need no extra elaboration.
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 names a specific verb ('Explain'), a precise resource ('broken audit-chain link (access_log.ketten_hash)'), and a concrete triggering scenario ('sanctioned rewrite of an already-logged row -- e.g. a migration that corrected a field'). This is far more specific than the tool name alone and leaves no ambiguity about what the tool is for, while being clearly distinct from the knowledge_/project_/annahme_ sibling families.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use context (broken chain caused by a sanctioned rewrite) and explicit rejection conditions ('Rejects with an error if access_log_id has no break (gespeichert==erwartet) or does not exist -- an explanation for a healthy row would itself be a fabrication'). It does not name an alternative tool, but the domain is unique among the siblings, so the guidance is functionally complete. A 5 would require naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It clearly discloses that the default writes nothing, that scharf=True performs actual withdrawals, that actions are returned with ausgefuehrt=false in dry-run mode, that only injection_suspects at sicherheit='hart' and kind='node' are touched, and that lessons lack a withdraw mechanism. It also characterizes the action as a reversible visibility toggle, not permanent deletion.
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 dense and long, but nearly every sentence carries a meaningful constraint: dry-run behavior, safe boundary, category handling, node-only action, and audit-row explanation. Some references such as Hermes curator.py and knowledge_lint.py add context without bloating the core semantics. It is packed rather than padded, and the most important purpose and safety frame appear first.
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 complex tool with no output schema and no annotations, the description covers the main operational details: what is report-only, what can act, when writes happen, and what outputs are returned. It does not fully describe the audit row structure or list all 15 report-only categories, but it points to _KURATOR_KATEGORIEN_OHNE_HANDLUNG for the latter. The agent can invoke it correctly with the dry-run default and scharf switch.
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 already 100%, so the baseline is 3. The description adds significant meaning for scharf by explaining that false means no writes and every potential action is returned with ausgefuehrt=false, while true means actual withdrawal with a stated grund in the audit row. It does not add actor/model/session details, but those are adequately documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific agent role and action: a cleanup curator that ACTS via knowledge_zurueckziehen() for only injection_suspects at sicherheit='hart' and kind='node'. It explicitly distinguishes itself from knowledge_lint.py by saying it acts rather than only reports, and it names the human-only alternative endgueltig_entfernen.py. This gives a clear, differentiated purpose beyond the tool name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage context: the default is a dry run, scharf=True is the explicit switch to actually withdraw, and only certain categories/conditions are ever acted upon. It names the human-only removal alternative and explains why lessons are never acted on. It does not explicitly enumerate all when-not-to-use cases, but the safe-boundary and dry-run instructions are strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and delivers: ambiguous ids are rejected rather than guessed, comma-separated lists or wildcards are refused rather than split up, the way back from 'offen' to 'intern' is explicitly allowed (reversibility), and access_log side effects are disclosed. This exceeds what a normal description discloses 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense paragraph that is front-loaded with the core purpose and the three states, then moves to edge cases, reversibility, and logging. Every sentence earns its place; the migrate_freigabe.py aside is the only optional element and it still adds routing context.
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 mutation tool with no annotations and no output schema, the description is nearly complete: it covers side effects (access_log), reversibility, default state, and rejection edge cases. The only absent detail is the success/error response shape, which matters little for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds genuine value beyond the schema: for eintrag_id it explains ambiguous-id rejection and wildcard refusal (schema only says 'no list, no pattern'), and for stufe it clarifies that 'intern' is the default state.
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?
States a specific verb ('Decide') plus resource (visibility level for ONE entry) with three named states ('offen', 'intern', 'gesperrt'). The explicit 'ONE entry' scope and the contrast with a binding 'norm decision' distinguish it from decision-related siblings like annahme_entscheiden or knowledge_freigeben.
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?
Clearly frames when it applies: single lesson or node entry, individual decisions only, with lists/wildcards refused rather than split. The non-binding note and migrate_freigabe.py reference imply bulk or binding decisions belong elsewhere, though no alternative sibling is named by tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden, and it delivers richly: the PIN is one-time, issued by an authorized human, the secret is returned exactly once, it is never logged, and this is the only tool callable without a credential. These are important security-relevant behaviors well beyond any schema information.
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?
Three sentences with no filler. The core action is front-loaded, followed by the security rationale, and the critical restriction about credential-less invocation comes last. Every sentence contributes useful, non-redundant information.
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 single-parameter tool with no output schema and no annotations, this description is complete: it explains what the tool does, when it is usable, how the PIN is obtained, what the caller receives, and how the secret is handled. No important operational gap remains.
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 covers the parameter purpose ('the one-time PIN you were given'), so the baseline is 3. The description adds meaning by clarifying that the PIN is an invitation code issued by a human, is one-time, and counts as proof of human handover, which helps the agent understand the trust semantics of 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 states a specific verb ('Redeem'), a specific resource ('one-time invitation PIN'), and the outcome ('receive your own credential'). It also distinguishes this tool by noting it is the only one callable without a credential, setting it apart from all sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is clear that this tool is for the sign-in scenario where the caller has no credential yet. It also implies a when-not-to-use condition: any other tool should not be used before this one in this state. However, it doesn't explicitly name alternatives, so it falls short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden, and it does so well. It reveals that numbers are measured at call time and never maintained, that it counts what currently exists, and that it does not assess correctness. It also explains the historical motivation, which helps set expectations about freshness and accuracy.
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 front-loaded with the core definition and includes a clear usage directive early. It is somewhat verbose due to the anecdotal backstory about the foreign client, but that narrative reinforces why live measurement beats memory and documentation. Minor redundancy keeps it from a perfect conciseness score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers what the tool reports, when to use it, and what it does not guarantee. It stops short of describing the exact return shape or format, which is a gap given that no output schema is provided. Overall it is still sufficiently complete for an agent to decide when and why to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain about inputs. The description still adds context about what the call-time report covers, which is the relevant semantic content. Baseline 4 is appropriate for a parameterless tool.
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 that the tool reports what brainlehr currently is by measuring live sources (sqlite_master, tool registry, requirements.txt) at call time. It uses specific verbs like 'measures' and 'counts,' and it distinguishes itself from documentation- or memory-based answers. The purpose is unambiguous and distinct from the sibling knowledge 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?
It explicitly instructs when to use the tool: 'Call this instead of relying on documentation or memory when asked what brainlehr is or can do.' It also adds a clear when-not-to-use boundary by stating it does not verify correctness and that validity, rank, and release live on individual entries. This gives an agent actionable selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so exceptionally well. It discloses that the text is irretrievably lost with no backup, that the row remains for traceability, that the node leaves search and recall, and that an empty grund causes rejection with no changes.
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 dense but every clause earns its place: core effect, audit retention, search impact, reversibility, comparison with permanent deletion, and validation behavior. It is front-loaded with the main outcome and contains no filler or redundant restatements of the tool name.
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 six-parameter tool with no annotations and no output schema, this description is unusually complete. It covers what changes, what persists, what disappears, how reversal works, which alternative is unavailable, and the key validation rule, leaving no critical ambiguity for an agent invoking it.
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 description coverage is 100%, so the schema already documents all six parameters and the node_id/path exclusivity. The description adds extra meaning by stating that grund is mandatory and that an empty grund is rejected with no changes, which is a behavioral constraint not fully captured in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Withdraw a node') and enumerates exactly what is cleared versus what is kept, making the tool's function unmistakable. It also distinguishes itself from related operations like knowledge_freigeben and the permanent endgueltig_entfernen.py, so an agent can tell it apart from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not literally say 'use when...' but provides strong routing context: it clarifies that this tool empties content while preserving the audit row, that knowledge_freigeben restores only visibility, and that permanent deletion is reserved for a separate human-only tool. This is sufficient practical guidance for choosing it over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![brainlehr MCP server](https://glama.ai/mcp/servers/3lehr/brainlehr/badges/card.svg)](https://glama.ai/mcp/servers/3lehr/brainlehr)

Score Badge

Copy to your README.md:

[![brainlehr MCP server](https://glama.ai/mcp/servers/3lehr/brainlehr/badges/score.svg)](https://glama.ai/mcp/servers/3lehr/brainlehr)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/3lehr/brainlehr'

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