waypath

by TheStack-ai

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation5/5
Each tool has a clearly distinct purpose. For example, waypath_recall is for free-text search while waypath_graph_query is for entity-based traversal; waypath_promote, waypath_review, and waypath_review_queue form a distinct workflow. Descriptions clearly differentiate overlapping tools.
Naming Consistency4/5
All tools start with 'waypath_' and use snake_case. Most follow a verb_noun pattern (e.g., refresh_page, resolve_contradiction), but a few like session_start and source_status are noun_verb or noun_noun. Overall consistent enough for predictable navigation.
Tool Count5/5
With 11 tools, the set is well-scoped for a knowledge management system. It covers query, search, page generation, promotion workflow, health checks, and session context without being bloated or too sparse.
Completeness4/5
Major workflows are covered: submit candidates (waypath_promote), review (waypath_review, waypath_review_queue), retrieve (waypath_recall, waypath_graph_query), and page synthesis (waypath_page, waypath_refresh_page). Minor gaps include no explicit delete tool, but rejection and superseding serve similar purposes.
Average 4.6/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 17, 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

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 WRITE nature, idempotency, and that it does not call external services. This is clear behavioral transparency, though additional details like error handling or required permissions could improve 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 three sentences, front-loaded with purpose and usage, and contains no unnecessary words. Every sentence adds value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema, no annotations), the description is complete. It covers purpose, when to use, idempotency, and external service behavior, leaving no obvious gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (pageId) already described. The description adds context about the parameter's source ('as returned by waypath_page or waypath_review_queue'), which is helpful but not extensive. Since schema already provides most semantics, the description adds moderate value, earning a baseline 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 clearly states the tool's purpose: 'rebuild an existing knowledge page against the current store state and update its cached summary/markdown.' It specifies the action (rebuild and update) and the resource (knowledge page), distinguishing it from sibling tools by mentioning when to use it.
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 usage scenarios: 'Use on pages flagged "stale" by waypath_review_queue, or after a large batch of promotions that should be reflected in a briefing page.' It also mentions idempotency, but lacks explicit when-not to use or alternatives, so not a perfect 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?
No annotations exist, so the description carries full burden. It clearly labels the operation as 'WRITE' and 'destructive', and states that non-kept preferences are no longer returned by waypath_recall. However, it does not mention return value or error cases.
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 very concise (4 sentences), front-loaded with the action, and structured logically: purpose, usage, consequences, optional notes. Every sentence 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?
Given no output schema and no annotations, the description adequately explains purpose, usage, and destructive nature, but does not specify return value or error conditions, leaving some gaps.
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 baseline is 3. The description adds workflow context (e.g., key must match review_queue output) but does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'resolve' and the resource 'contradiction between preferences', and explicitly distinguishes its role from siblings like waypath_review_queue and waypath_recall.
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 tells when to use the tool (after reviewing queue), provides the prerequisite step (use waypath_review_queue first), and describes the intended scope (user/project-scoped collisions).
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 clearly states the tool is a write operation ('WRITE:'), creates a candidate in a local SQLite queue, and requires human or authorized agent review. It does not mention edge cases like duplicate detection, but the core behavior is transparent. A minor gap for a score of 5.
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, each adding distinct value. Starts with an action label ('WRITE:'), then explains the asynchronous nature, then provides usage guidance. No unnecessary words, highly 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 the simplicity (one parameter, no output schema) and the availability of sibling tools, the description is nearly complete. It covers purpose, usage, and behavior. A minor omission is what the tool returns (e.g., candidate ID), but the context suggests the agent can infer it from the schema or review queue. Highly adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds that the subject is stored verbatim and shown to the reviewer, which adds some value beyond the schema's constraints but is not essential. No additional parameter semantics are needed.
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 it creates a candidate row in a review queue for promotion, not an immediate promotion. It uses a specific verb ('submit') and resource ('candidate for promotion'), and distinguishes from siblings like waypath_review and waypath_review_queue by name.
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 when to use this tool ('persist a decision, preference, or fact') and when not ('does NOT promote immediately'), and directs to sibling tools (waypath_review_queue to list, waypath_review to act). This provides excellent guidance for an agent.
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 provided, so description carries full burden. It explicitly states 'Read-only probe', 'Does not write', 'Does not hit the network', and 'Takes no parameters'. Missing error handling details, but sufficient for intended use.
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 no wasted words. Every sentence adds value: first explains purpose and output, second gives usage and safety info.
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?
No output schema, but description covers return values ('availability, last-scan timestamp, configuration errors'). Complete for a diagnostic probe tool given its simplicity.
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?
Input schema has zero parameters and schema coverage is 100%. Description adds 'Takes no parameters' to confirm, which is clear and sufficient 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 it is a 'read-only probe of the local source adapters' and specifies it returns 'availability, last-scan timestamp, and any configuration errors'. It is distinct from sibling tools like waypath_recall or waypath_graph_query, and explicitly links to diagnosing recall issues.
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: 'Use to diagnose why is my recall empty or before running a large ingest.' It does not explicitly state when not to use, but implies safe and lightweight behavior.
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?
Description explicitly states it is read-only and does not write to the database, which is key behavioral information. However, it could mention any rate limits or permissions, but given the read-only nature, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a usage note. Every sentence adds value, no redundancy. Highly concise and front-loaded with key information.
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?
Description mentions return types (neighbors, edges, related facts) and traversal patterns. Without an output schema, it could benefit from more details about the result structure or limits, but it covers the essential aspects.
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 already provides detailed descriptions for both parameters (100% coverage). The tool description adds value by summarizing the traversal patterns and their purposes, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (read-only traversal), resource (Waypath knowledge graph), and output (neighbors, edges, related facts). It also distinguishes from the sibling waypath_recall by specifying it requires a resolved entity id.
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 (when you have a resolved entity id from waypath_recall or prior context) and when not to (use waypath_recall for free-text lookup). Provides clear 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?
Declares read-only nature and safety to call any time, listing checks performed. Without annotations, description carries full burden; missing specification of return format (e.g., JSON status object) is a minor 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, front-loaded with purpose, no fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, safety, and sibling distinction. However, given no output schema, description could specify what the tool returns (e.g., a status object). Still adequate for a simple health check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. Baseline set at 4. Description confirms zero parameters but adds no extra value beyond 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?
Clearly states it is a read-only health check listing specific components (SQLite, FTS5 sync, source adapters, truth-kernel row counts). Distinguishes from sibling waypath_source_status by noting it's a single diagnostic entrypoint vs adapter-specific detail.
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 'Safe to call any time and from any context' and 'Use as a single diagnostic entrypoint before opening a support issue; for adapter-specific detail call waypath_source_status.' Provides clear when and when-not to use.
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 full burden. It clearly states read-only behavior ('Does not write to the database') and no network access. Also mentions automatic FTS5 escaping. Could add more detail on concurrency limits or performance expectations, but sufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: functional definition, usage guidance, and behavioral clarification. No redundant or extraneous text. Efficient and front-loaded.
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 parameter and no output schema, the description covers purpose, usage, behavior, and parameter hints. It mentions output format ('ranked entries with source, score, and snippet') which is adequate. Could specify result limit or ordering, but not critical.
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 schema covers the single parameter 'query' with constraints and description. The description adds value by noting automatic token escaping and advising use of specific nouns/project names ('auth service rollout plan' beats 'that thing'), which helps the agent formulate better queries.
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 performs a 'Read-only hybrid search' over a SQLite memory store using FTS5 and RRF, specifying outputs (ranked entries with source, score, snippet). It distinguishes from sibling waypath_graph_query by noting it is for free-text queries rather than known entity IDs.
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: 'before answering any question that may depend on prior decisions, preferences, or project facts'. Also provides a direct alternative: 'call this instead of waypath_graph_query when you have a free-text query rather than a known entity id'.
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?
Discloses read-only nature ('Does not write to the database') and overall optionality of parameters, but lacks detail on output structure since no output schema is provided.
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 concise sentences efficiently cover purpose, function, behavioral note, and parameter guidance with no 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?
Adequately covers usage, read-only nature, parameter optionality, and sibling distinctions; minor gap in output format description but mitigated by low complexity and schema coverage.
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?
Adds value beyond schema by explaining fallback behavior ('omitted fields fall back to project defaults') and usage context for seedEntities, despite 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'assembles' and resource 'context pack builder', and explicitly distinguishes from siblings by naming alternatives (waypath_recall, waypath_graph_query) for different use cases.
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 call ('once per session before substantive work'), provides alternatives for mid-session lookups, and clarifies read-only behavior.
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?
Without annotations, the description carries full burden. It discloses the effects of each status (e.g., 'accepted promotes into truth-kernel so it becomes visible to waypath_recall', 'rejected discards permanently', 'superseded marks as replaced'). It also warns that this is a governance gate. However, it does not mention potential side effects like idempotency or whether the action is reversible, but the key consequences are 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 a single well-structured paragraph with no wasted words. It front-loads the purpose and provides essential details efficiently. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 3 parameters, no output schema), the description covers the prerequisites (call review_queue first), all status effects, and the source of candidateId. It is sufficiently complete 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 baseline is 3. The description adds value by explaining the meaning of each status beyond the enum values, recommending notes for certain statuses, and specifying the origin of candidateId. This enriches the schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'WRITE: decide the fate of a pending promotion candidate' and distinguishes its role from siblings by explicitly mentioning 'governance gate between waypath_promote and durable memory.' It uses specific verbs and resources, making the 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Call waypath_review_queue first to list candidates and their ids' and 'do not accept without evidence.' It also explains when each status is appropriate, including terminal vs. non-terminal states, which helps the agent decide when to use this tool vs. 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?
Discloses read-only nature ('Read-only snapshot') and no-parameter requirement. Without annotations, description carries burden; it sufficiently conveys safety but could add details about data freshness or access permissions.
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 concise sentences: function, usage guidance, parameters. Every sentence adds value with no 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?
Given the tool's simplicity (no params, no output schema), the description fully covers purpose, contents, usage context, and follow-up actions.
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 has 0 parameters, description correctly states 'Takes no parameters.' Baseline 4 for no-param tools; no additional semantics needed.
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?
Clearly states it's a read-only snapshot of pending items (promotion candidates, stale pages, contradictions), and distinguishes from sibling tools by naming them as follow-up actions.
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 advises use at start of review/maintenance sessions and names specific alternatives (waypath_review, waypath_refresh_page, waypath_resolve_contradiction).
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 fully discloses behavior: deterministic, no LLM/network call, read-only regarding promoted memory, may cache artifacts. This is comprehensive for a tool of this complexity.
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, no filler. First sentence captures main action and output. Second sentence adds key traits. Third sentence gives usage guidance. Information density is optimal.
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 clear output description and behavior, the description covers everything an agent needs. No missing information.
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% and schema already describes the parameter with min/max length. Description adds value by giving concrete examples (entity id format, natural-language subject) and emphasizing it is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Synthesize', 'aggregating', 'summarizing') and clearly identifies the resource ('knowledge page about a subject'). It also distinguishes from the sibling tool 'waypath_recall' by contrasting use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use for briefings or handoffs when a recall result would be too fragmented; for targeted lookup use waypath_recall instead.' Clearly states when and when not to use.
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:

[![waypath MCP server](https://glama.ai/mcp/servers/TheStack-ai/waypath/badges/card.svg)](https://glama.ai/mcp/servers/TheStack-ai/waypath)

Score Badge

Copy to your README.md:

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

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/TheStack-ai/waypath'

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