hypotree

by tygryso

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.6.0-release
Disambiguation4/5
Most tools have clearly distinct purposes: creation vs. evidence vs. status vs. topology. However, `verify_upstream` and `invalidate_upstream` are closely related (opposite actions on ancestors), and `update_status` could be seen as a general-purpose override that overlaps with the more targeted status-changing tools, though the descriptions help differentiate them.
Naming Consistency4/5
The majority of tool names follow a verb_noun pattern (e.g., create_hypotheses, add_edges, record_evidence). A few exceptions like `what_would_change_my_mind` and `get_dag_context` break the pattern but are still understandable. The inconsistency is minor but noticeable.
Tool Count5/5
With 20 tools covering a complex domain (hypothesis management, evidence, claims, conflicts, and workspace introspection), the count is justified. Each tool serves a distinct operational need, from low-level CRUD (create_hypotheses, add_edges) to high-level analysis (what_would_change_my_mind, generate_learning_path). The set is comprehensive without being bloated.
Completeness5/5
The tool surface covers the full lifecycle: creating hypotheses, managing evidence, handling leases, updating statuses, resolving conflicts, and reporting goal progress. Critical gaps like missing delete operations are intentionally avoided (hypotheses are retained for auditability), and read-only introspection tools provide a complete view of the belief state.
Average 3.9/5 across 20 of 20 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 27 commits in the last 12 weeks
- Last stable release on August 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must bear the full burden of disclosing side effects. It reveals a mutating operation (status flip) and a depth cap, but omits critical details: how non-IN_PROGRESS ancestors are handled, whether the child_id itself is modified, side effects on already-VERIFIED nodes, and error conditions. This is insufficient 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?
One short sentence with a compact verb phrase; no filler or redundant content. The key elements (traversal direction, status change, depth limitation) are packed efficiently, making it easily scannable.
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 single-parameter mutation tool with no annotations or output schema, the description is minimal. It explains the algorithm but misses context like what the function returns, whether it is idempotent, how depth is determined, and what conditions might cause failure. An agent would be under-informed for safe invocation.
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 schema provides only the parameter name 'child_id' with no description (0% coverage). The description never explicitly connects child_id to the walking operation. While inferable from the tool name and 'ancestors', the semantics are not stated, leaving ambiguity about whether child_id is the starting node or something else.
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 ('Walk') and resource ('REFINEMENT ancestors') with an explicit status transition ('flip IN_PROGRESS → VERIFIED'). This clearly differentiates it from sibling tools like invalidate_upstream and generic update_status.
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 information about when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or contextual triggers such as 'use when a claim's upstream dependencies need batch verification.' The depth-capped hint is a constraint, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full behavioral burden. It does disclose the core effect (status transition from VERIFIED to NEEDS_REVISION) and scope (walking ancestors). However, it leaves ambiguity about whether the leaf itself is affected, what happens to non-VERIFIED ancestors, and whether the operation is reversible or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the object (dependency ancestors) and the action (flip status). Every word earns its place, with no filler or redundancy. It is a model of efficiency.
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 is relatively simple with one parameter and no output schema, but the description still leaves critical context missing. It does not mention return values, error behavior (e.g., missing leaf_id, no ancestors), or whether the leaf itself is affected. More detail about the traversal and status update semantics would make the description 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?
The schema only provides the parameter name leaf_id with no description, and schema coverage is 0%. The description implicitly suggests that leaf_id is the starting point for walking ancestors, but it never explicitly defines the parameter, expected format, or its relationship to the dependency graph. This is insufficient for a tool with one required parameter.
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: walk dependency ancestors and flip their status from VERIFIED to NEEDS_REVISION. It distinguishes itself from sibling verify_upstream, which likely does the opposite. However, it does not explicitly frame the purpose around 'invalidation' beyond this status transition, which leaves a bit of ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like update_status or verify_upstream. The description is purely action-oriented and does not mention the context in which invalidation is appropriate (e.g., when a dependency is outdated) or any preconditions.
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. It discloses the ordering behavior ('newest-first') and implies a read-only operation via 'return', but it does not specify pagination semantics, error handling, or any access requirements. These gaps are moderate for a read 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?
The description is a single, front-loaded sentence that directly states the tool's purpose and ordering without unnecessary words. It is concise and well-structured.
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 3 parameters with 0% schema coverage and no output schema, so the description must provide context. It states the primary action and ordering but omits return format, pagination behavior, and parameter roles, leaving significant gaps for an agent to invoke 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 does not explain any of the three parameters (node_id, limit, offset). It only mentions 'node' generically, failing to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('return') and resource ('evidence trail for a node'), and adds ordering information ('newest-first'), clearly distinguishing it from sibling tools like get_active_claims or get_conflicts. It precisely states what the tool does.
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, such as when to audit evidence history versus viewing active claims or conflicts. There is no mention of prerequisites, use cases, or exclusions.
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 disclose behavior on its own. It does reveal that rendering is bounded by depth/width and that nodes may be elided, which gives some insight into output shaping. However, it does not mention side effects, error behavior, or the exact nature of the output beyond being a Mermaid flowchart, leaving some behavior implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. Every phrase ('Mermaid flowchart', 'depth+width bounding', 'elision') adds distinct value, making it concise and appropriately sized for the tool's complexity.
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 4 parameters, no output schema, and no annotations, but the description is very brief. It does not clarify whether node_id is required or what happens if omitted, nor provide examples or usage context. While it conveys the core purpose, it leaves too many operational details unresolved for confident 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 only 25% (only hide_statuses has a description). The tool description partially compensates by linking 'depth+width bounding' to max_depth and max_children, and 'elision' to hide_statuses. However, node_id is left without explanation, and the relationship between the bounding/elision terms and specific parameters is not explicit.
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 ('Render a Mermaid flowchart') and adds key differentiators ('depth+width bounding + elision'). It clearly indicates this tool produces a visual rendering rather than a raw data list, which helps distinguish it from siblings like list_nodes or get_dag_context, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical scenarios, or cases where another tool would be preferable. The description only states what the tool does, not when it should be used.
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?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states the return value, but does not mention that this is a read-only operation (though implied), nor does it explain the nature of 'credible intervals' or any side effects/limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key action and bounds without unnecessary words. Every word 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?
There is no output schema, so the description should explain the return format and semantics. It does not define 'credible intervals' or what nodes/edges are included, leaving significant ambiguity for an agent without prior context.
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 description maps 'depth+width-bounded' to max_depth and max_children, giving them meaning. However, node_id is not explicitly explained, and with 0% schema coverage, it does not fully compensate for all parameter details such as defaults or how the bounds are applied.
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 identifies the action (Return), the resource (subgraph), and the specific parameters (depth+width-bounded) that distinguish it from sibling tools like render_dag_map or list_nodes. The mention of credible intervals adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a local, bounded view of a DAG around a node, which is distinct from siblings like get_conflicts or generate_learning_path. However, it does not explicitly state when to use this tool over alternatives or any exclusions.
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 disclosure burden. It provides one important guarantee: all IDs are validated before any changes, preventing partial updates. However, it does not disclose other relevant behaviors such as whether the override is reversible, whether it affects dependent nodes, or what permissions are required. This is helpful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the core action. The second sentence adds a key safety behavior without unnecessary verbosity. Every word earns its place, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, no output schema, no annotations), the description covers the basic purpose and a key behavioral guarantee, but it omits usage context, parameter details, and what the agent should expect in return. It is enough for simple invocation but leaves gaps for an agent navigating among many related sibling tools.
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 for explaining parameters. It indirectly covers node_ids and new_status via 'status of nodes', but the 'reason' parameter is completely unmentioned. The new_status enum is self-explanatory, but the description adds no additional meaning or context for the parameters beyond what the schema already shows.
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 ('override') and resource ('status of nodes'), clearly distinguishing it from sibling tools that perform narrower status changes like 'verify_upstream' or 'invalidate_upstream'. The qualifier 'manually' further clarifies that this is a direct, user-driven action rather than an automated process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many sibling tools that also alter node state. The word 'manually' implies a fallback for when automated flows are not appropriate, but this is not explicit. There is no mention of prerequisites, alternatives, or exclusions.
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 must carry the full transparency burden. It fails to state whether the tool is read-only, what permissions are required, or any side effects. It only lists output contents without behavioral caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that starts with the action verb and enumerates the four report components. Every word contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description gives a reasonable idea of the report contents but does not explain the response structure, error cases, or whether the report includes all goals by default versus the optional filtering. It is adequate but lacks depth for a tool with zero annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for goal_id explaining the filtering behavior and default scope. The tool description itself adds no param-specific details, but the schema already provides sufficient semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Report' and enumerates the exact resources: goal nodes, target metrics, progress counts, and global stop status. This clearly distinguishes it from sibling tools like get_workspace_info or list_nodes by focusing on goal-level status tracking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking goal status but does not provide explicit when/when-not guidance or mention alternatives. The schema's goal_id description adds some usage context by allowing filtering to a single objective, but this lives outside the main description.
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 must carry the full burden. It discloses the internal decision logic (re-test conflict suspect at depth, otherwise closest alternative), which is good, but it does not state whether the tool is read-only, has side effects, or what the output format is. Since 'suggest' implies non-mutating, the description is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately states the purpose and then specifies the decision rule, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description does not explain what the agent will receive (e.g., a string, a structured object) or any prerequisites. However, it gives a clear decision rule for a zero-input tool, so it is reasonably complete for its simplicity but leaves return-value expectations open.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is vacuously 100%. The baseline for 0 params is 4, and the description adds no parameter-specific detail because none exist. The description's context about conflict resolution complements the empty schema without redundancy.
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 ('Propose') and resource ('the single most informative next experiment'), with a clear decision rule distinguishing it from generic tools. However, it does not explicitly contrast with sibling tools like get_next_targets, so differentiation is only 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 implies when to use (when you need to select the next experiment) and even provides algorithmic guidance, but it does not state explicit alternatives or when not to use the tool. Sibling comparisons would strengthen this.
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 transparency burden. It goes beyond a simple imperative by explaining the output structure (which members are exonerated vs. suspects) and implies a read-only operation via 'List'. This provides meaningful behavioral context, though it stops short of disclosing details like ordering or pagination, which would be nice but are not critical for a simple list 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?
The description is a single, efficiently written sentence. It opens with the action ('List recorded conflicts') and follows with a clarifying clause. No redundant words or filler, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional parameter, no output schema, no annotations), the description provides sufficient context. It explains the concept of conflicts and hints at the return content. It could mention that it only lists open conflicts by default, but that is covered in the schema, so the overall package is reasonably 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?
The input schema already fully describes the sole parameter (open_only) with a clear description. The tool description does not add any further meaning about the parameter, so it does not need to compensate. Baseline 3 is appropriate since schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function ('List recorded conflicts') and provides a precise definition of what a conflict is ('sets of assumptions that cannot all hold together'). It also distinguishes this tool from siblings by focusing on conflicts and their outcome (exonerated vs. suspects), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like get_active_claims or suggest_discriminating_experiment. It does not mention any prerequisites or scenarios where this tool is preferred, nor does it exclude cases where other tools would 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?
With no annotations, the description carries the behavioral burden and does usefully disclose batch atomicity: 'The whole batch is validated before anything is written, so a rejected call creates nothing.' It also reveals dependency handling ('Parents may be created by the same call in any order'). This is solid but does not cover permissions, reversibility, or return 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?
Three sentences, front-loaded with the core purpose, and every sentence earns its place: what it adds, how to express a single creation, and the safety-relevant atomicity guarantee. No redundant phrasing or 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 complex creation tool with nested policies (if_exists, is_goal, exclusion groups) and no output schema, the description covers the core operation and atomicity but omits return shape and decision points not already in the schema. The schema's field descriptions help compensate, so this 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds useful parameter-level meaning beyond the raw schema: it explains list cardinality ('Pass a list of one') and parent-edge ordering behavior. The schema itself already contains rich nested descriptions for fields like is_goal, if_exists, parent_ids, and exclusion_group, so the description does not need to repeat them, though top-level schema coverage is low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Add one or many hypothesis nodes (with optional parent edges).' It clearly distinguishes this from sibling tools like add_edges by scoping the action to creating hypothesis nodes, and clarifies the one-or-many behavior.
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 operational guidance like 'Pass a list of one to create a single hypothesis' and notes that parent edges can be included in the same call, implying when this tool is useful. However, it never explicitly contrasts with sibling tools such as add_edges or states when NOT to use it, so guidance is only implied.
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 discloses a key behavior: releasing without recording a result. However, it does not mention whether the action is reversible, any side effects on related data, or permissions. This is adequate but leaves some uncertainty about consequences.
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 main action and purpose. Every word earns its place, with no fluff or redundancy that isn't already present in the schema (which is acceptable).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description gives sufficient context to understand what it does and when to use it. It lacks a description of return values, but for this simple action that is not a significant 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 already explains the claim_ids parameter and its omission behavior, and the tool description merely repeats the same information ('Omit claim_ids to release everything you hold'). Since schema coverage is 100%, the description adds no additional semantic 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 clearly states the action ('hand leased nodes back') and distinguishes it from recording results, explicitly contrasting with tools like record_evidence. It also gives specific scenarios (work not run, context reset) that clarify its 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?
The description provides clear when-to-use guidance ('for work you have decided not to run, or for resuming after a context reset you cannot report on'). It does not explicitly name alternatives or exclusions, but the context is strong enough to guide an agent in selecting this tool over siblings like record_evidence or renew_claim.
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 disclosure burden. It explains the lease mechanism (work recovery after caller vanishes) and the downside of long TTLs, which is useful context. However, it does not mention failure modes, idempotency, or what happens with invalid claims, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that are dense with meaning. The first sentence states the action and condition; the second provides the alternative and rationale. No wasted words, and the key information is 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 tool with two params, no output schema, and no annotations, the description explains the core concept well but omits parameter semantics and expected return values. It is adequate for a simple renew operation but leaves important operational details unspecified.
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 either parameter (claim_id, lease_ttl_s). The names hint at their roles, but the description provides no units, defaults, or behavior for lease_ttl_s, nor does it clarify how the lease is identified. It fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action: 'Restart a live lease's clock because the experiment is still running.' It clearly distinguishes this from siblings like release_claims or invalidate_upstream by framing it as a renewal operation for an ongoing lease.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (while experiment is still running) and provides an alternative ('Use this instead of a very long TTL') with a strong rationale that explains the trade-off in lease recovery time. This is concrete, actionable 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 fully discloses behavioral traits: it explicitly states 'Read-only — it issues no lease and changes nothing,' and it explains the ranking logic (beliefs confirmed by elimination rank first regardless of confidence). This goes beyond basic safety and provides insight into the tool's 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 is front-loaded with the core purpose and efficiently covers key aspects, but it includes some rhetorical phrasing like 'Answers the question a reviewer actually asks' and the explanatory third sentence. While all sentences add value, a more streamlined version could reduce wordiness without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with two parameters and no output schema, the description covers the essential context: what it does, the ranking principle, and its side-effect-free nature. It lacks explicit mention of the response format, but that is not required given the simplicity and the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already describes both parameters ('How many beliefs to return, most fragile first' and 'Restrict to one objective. Omit for every goal.'). The description adds little beyond the schema's parameter details, so it meets the baseline without further 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 clearly states the tool names the cheapest experiments that would overturn a goal's conclusion, specifying the verb 'Name' and the resource 'cheapest experiments' within the goal context. It distinguishes itself from siblings by answering the reviewer's question — 'not what do you believe, but what would it take to be wrong' — which sets it apart from other analysis 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 provides clear context: it is for identifying weak beliefs and cheap ways to falsify them, framing it as what a reviewer would ask. However, it does not explicitly mention when not to use this tool or directly name alternatives, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses validation behavior (unknown nodes, goal as parent, cycles refused before writing, existing edge no-op) and the semantic nuance that adding a dependency edge tightens the condition due to AND logic. With no annotations provided, the description carried the full transparency burden and did so comprehensively.
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 consists of three sentences, each serving a distinct purpose: core action, usage scenario, and behavioral/validation details. It is front-loaded with the primary verb and resource and avoids redundant phrasing.
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 covers purpose, usage, validation, and idempotency, which is strong. It lacks an explicit statement about the success return value, but the behavioral details (no-op on existing edge, refusal on invalid input) give the agent sufficient expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-documented with direction and type. The description adds context about pipeline dependencies and edge direction but does not elaborate on the 'type' enum or parameter format beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Wire hypotheses that already exist, without recreating either,' clearly identifying the action (adding edges) and the resource (existing hypotheses). It distinguishes itself from creation tools like create_hypotheses by explicitly stating no recreation. The 'grow a graph forward' phrase adds specificity about the intended use.
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 provides a concrete scenario—when a pipeline gains a stage and the goal must depend on the new last stage—and explains the AND semantics for not needing to remove old edges. It implicitly contrasts with creation by saying 'without recreating either,' but does not explicitly name alternative tools or a when-not-to-use case, so it falls 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the filtering behavior ('unconsumed, unexpired') and implies a read-only operation via 'Return'. For a tool with no parameters and no side effects mentioned, this is reasonably transparent, though it doesn't describe error scenarios or the return envelope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loads the verb and object, and every word earns its place. No fluff or repetition; it states what it returns, the filter criteria, and the purpose in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and a simple read-like behavior, the description is sufficient. It explains the tool's core function and filter criteria. The presence of sibling tools like renew_claim and release_claims fills in the broader context of what 'claims' are, so the description doesn't need to define the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to explain. The baseline for 0 parameters is 4, and the description adds no extraneous parameter info. It correctly focuses on the tool's semantics instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('live claims') with precise qualifications ('unconsumed, unexpired') and a clear purpose ('for resuming work'). This distinguishes it from siblings like renew_claim or release_claims, which handle different aspects of claim management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for resuming work' clearly implies the use case: fetching current active claims when a user wants to pick up where they left off. While it does not explicitly name alternatives or exclusions, the context is unambiguous enough for an agent to select this tool over renew_claim or release_claims.
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 full burden. It discloses claiming semantics (reservation until result recorded), the negative consequence of holding without reporting ('work nobody can do'), that a batch never contains competing answers, and that entries may include min_depth under conflict review. It also mentions stale lease reclamation and TTL behavior. Some side-effect details (e.g., exact state changes to claims) are implied but not fully spelled out.
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 sentences, each earning its place: purpose, usage rule, batch property, and return format. The most important information is front-loaded in the first sentence. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description covers the return format (list, optional min_depth). It also explains edge-case behavior (goal_scope_empty) and claim lifecycle. It lacks explicit details on error responses or authentication, but for a tool with 4 optional params and no output schema, it is reasonably 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 100%, so the baseline is 3. The description adds context beyond the schema: it reinforces the count parameter with the 'only ask for what you will probe' rule and explains the goal_scope_empty reason for goal_id. It also ties lease_ttl_s to renew_claim. This extra context elevates the score above 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 opens with a specific verb+resource: 'Reclaim stale leases and select the next target(s).' This clearly states the tool's core function and distinguishes it from siblings like get_active_claims (which lists claims) or renew_claim (which extends TTL). It further differentiates by mentioning batch semantics and conflict-review context.
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 actionable guidance: 'ask only for what you will probe before your next call' sets a clear usage rule, and the schema description for lease_ttl_s explicitly mentions calling renew_claim as an alternative. The dry_run parameter description clarifies when to peek without claiming. However, it does not explicitly compare to list_nodes or get_active_claims, missing some sibling differentiation.
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 adds valuable nuance, especially around `stale_only=true`, explaining that stale confirmations are 'not refuted, but nothing has re-established them since the code moved.' It also defines the view presets. This goes beyond basic query semantics, though it does not cover pagination or side-effect-free guarantees explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 80 words) and front-loaded with the core purpose, followed by the view guidance and then the stale_only nuance. Every sentence adds value, and there is no fluff or repetition of schema details.
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 an 8-parameter tool with no output schema and no annotations, the description covers the key decision points (view vs manual filter) and the nuanced stale semantics. It does not explain pagination behavior, but that is partially inferable from the limit/offset defaults. The return format is specified as a Markdown table, which is sufficient.
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 50%, so the description must compensate. It does so for the two most complex parameters: 'view' (with named presets and meanings) and 'stale_only' (with a detailed explanation). The remaining parameters (limit, offset, order_by, ascending) are straightforward and have enum/default metadata in the schema, so the lack of extra description is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Query/filter/sort nodes and return a Markdown table.' It uses a specific verb and resource, and the output format is explicit. This distinguishes it from sibling tools that have more specialized purposes (e.g., get_active_claims, get_evidence_history).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on using the 'view' parameter instead of hand-assembling status filters, saying 'Use `view` for the questions actually worth asking... rather than assembling a status filter by hand.' This gives clear contextual direction, though it does not directly reference sibling tools as alternatives.
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 and does disclose key behaviors: auto-captures git context when unset, refuses evidence against goals, and corrupts confirmations for premises assumed corrupt. It also explains the order-of-application for batch results. Minor gap: does not disclose that it mutates state, but the verbs 'record' and 'update' imply it.
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 sentence adds value: batch guidance, auto-capture, hypothesis targeting rule, and a concrete example of batch usage. It's front-loaded with the core action and quickly moves to important constraints.
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 15 parameters, low schema coverage, and no output schema, the description covers the most decision-relevant parameters but not all (e.g., error_type, metrics, attestation_id are not explained). Since the schema covers those partially, this is acceptable; however, for a complex tool, more coverage would improve completeness. The absence of an output schema is noted, but the description doesn't need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (53%), so the description must add meaning. It explains the critical `results` parameter (batch usage), the `claim_id` parameter (optional vs. lease release), `duration_s` (for ranking), `source_ref` (provenance value), and `count_next_targets` (top-up semantics). This goes beyond the schema with actionable context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary action ('Record one result, or many in one call') and the resource (evidence) and explicitly includes the belief state update. It distinguishes from siblings by focusing on recording evidence versus creating hypotheses or managing claims.
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 explicit guidance on when to use the batch mode ('Ran several experiments this turn? Report them together') and clarifies the rule about which hypothesis to record against. However, it does not mention when NOT to use this tool compared to siblings like get_evidence_history or update_status.
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 burden. It discloses important behavioral traits: separating experiment-paid facts from engine-inferred ones, calling out withdrawn beliefs, and clarifying that it shows provenance rather than current state (implying a read-only 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 is two sentences with the main action front-loaded. The second sentence is long but packs in use cases and a parameter note without wasted words. It could be slightly more structured, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers purpose, use cases, and key parameter behavior thoroughly. It does not specify the return format, but for a narration tool this is likely prose and not a critical omission.
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?
All 4 parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds extra meaning for `since` by framing it as 'a diff' and tailoring it to standup/PR needs, going beyond the schema. Other parameters rely on schema, which is adequate.
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 'Narrate' and clearly defines the resource: what has been settled, in order, and how. It distinguishes itself from sibling tools by noting that 'the other read tools show the current state, this one shows how it was arrived at'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool: 'to brief a human, to write a summary, or to re-orient yourself after a context reset'. It contrasts with alternatives ('other read tools') and gives a specific use case for `since` as a diff for standups or PR descriptions.
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 context. It discloses what is reported (including database existence and resolution layers), implying a read-only operation. It stops short of explicitly stating side effects or failure modes, but the disclosed behavior is sufficient for a get-info 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 sentences front-load the purpose and then give usage guidance. Every clause adds value: what is reported, why it matters, and when to call. No filler or redundancy.
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 parameterless tool with no output schema, the description fully covers what the tool returns, the meaning of 'belief state', and typical usage scenarios. It leaves no major gaps for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific meaning, but none is needed. It instead explains the context and outputs, which aligns with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'reports' and clearly identifies the resource (workspace info), listing concrete outputs (workspace id, resolution layer, database location, existence). It distinguishes this tool from siblings by focusing on workspace identity rather than claims, graph, or hypotheses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call it when the graph is unexpectedly empty or two clients disagree about what has been established' and provides the likely cause. This gives clear when-to-use guidance and implicitly distinguishes it from alternatives that operate on graph content.
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:

[![hypotree MCP server](https://glama.ai/mcp/servers/tygryso/hypotree/badges/card.svg)](https://glama.ai/mcp/servers/tygryso/hypotree)

Score Badge

Copy to your README.md:

[![hypotree MCP server](https://glama.ai/mcp/servers/tygryso/hypotree/badges/score.svg)](https://glama.ai/mcp/servers/tygryso/hypotree)

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/tygryso/hypotree'

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