linklore

Official

by linklore

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools have distinct purposes, but a few overlap conceptually, such as 'doc_flow' vs 'doc_map' for document link viewing, and 'show' vs 'brief' vs 'status' for display. However, detailed descriptions help agents differentiate.
Naming Consistency3/5
Tool names consistently use snake_case but mix verbs (e.g., push, pull) and nouns (e.g., config, doc_flow). The pattern is not strictly verb_noun, but the naming is readable and predictable given the domain.
Tool Count3/5
With 24 tools, the server covers a broad scope (CRUD, linking, sharing, diagnostics). While this is on the high side, it is justified by the feature set, but could potentially be streamlined.
Completeness4/5
The tool surface covers most lifecycle operations for lore/documents, linking, sharing, and project management. Minor gaps exist, such as no explicit rename tool, but the core workflows are supported.
Average 3.6/5 across 24 of 24 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on August 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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?
The only behavioral hint is '[read-only]', but without annotations, this is insufficient. No disclosure of side effects, permissions, or output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise to the point of being cryptic. While brief, it sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, 0% schema coverage, and no annotations, the description is severely incomplete. It does not explain the output schema or how to effectively use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It provides shorthand syntax for period and sort, but does not explain the meaning or constraints of parameters like id, max, help. Missing semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'log()' without specifying what kind of log (e.g., system log, error log). The parameters list is cryptic and does not clarify the purpose. It fails to differentiate from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use 'log' vs alternatives. No context about appropriate scenarios 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?
With no annotations provided, the description carries the full burden. It only declares '[read-only]' but does not disclose other behavioral traits such as required permissions, side effects, or what 'duplicate candidates' means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one line) but at the cost of clarity. The notation is compact and front-loaded with '[read-only]', but key information is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and an output schema, the description is insufficient. It does not explain the purpose, return value, or how this tool fits among 23 siblings. Minimal context provided.
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 0%, so description must compensate. It lists defaults and hints at allowed values for 'type' (lore|doc), but does not explain the meaning of 'threshold', 'status', or 'help'. Some added value but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description fails to specify a clear action verb. It states 'cleanup - duplicate candidates' but does not indicate whether the tool lists, identifies, or removes duplicates. The '[read-only]' prefix hints at no mutation, contradicting the typical meaning of 'cleanup.'
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 on when to use this tool versus siblings like 'doctor', 'show', or 'status'. The description only lists parameter defaults without any contextual advice.
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 burden. It lists actions like 'sources/option/sync/forget/whoami/version/pin/unpin/sessions/projects/delete_project' but does not explain what these actions do, whether they are read or write operations, or what side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat fragmented: it starts with a clear purpose sentence, then adds a note about sharing, then lists actions with an instruction about help. It is not overly long but could be more structured and focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 12 parameters and multiple actions, the description is incomplete. It lacks details on how to use the tool, what each action does, and what outputs to expect, despite the presence of an output schema.
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?
The input schema has 12 parameters with 0% description coverage. The description only mentions the 'help' parameter ('help=true for details') and does not describe the purpose or usage of any other 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 states that the tool manages 'Project settings (openbox source options) + identity + session pin,' which gives a clear high-level purpose. However, it is not a single concise verb+resource statement, and the list of actions adds some clarity but also complexity.
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 provides guidance on when not to use this tool by noting that sharing is handled by separate tools (send/import, member). However, it does not explicitly state when to use this tool versus its siblings, nor does it provide clear use cases.
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 must disclose behavioral traits. It only states read-only nature, lacking details on side effects, permissions, or output behavior. This is insufficient for a tool with no annotation safety net.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one line, front-loading the read-only hint. However, it sacrifices necessary parameter explanations, making it too brief for full understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of parameter descriptions in the schema and no annotations, the description fails to provide complete context. The output schema exists but isn't leveraged in the description. The tool's role among 23 siblings requires more detail.
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 the 'help' or 'oneline' parameters beyond mentioning 'oneline' in parentheses. No clarity on their effects or valid values is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for an 'overview of the full doc link network' with a verb-like 'doc_map' and indicates it is read-only. However, it does not explicitly differentiate from sibling tools like doc_flow or doc_rollup.
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 '[read-only]' prefix implies safe usage for reading, but there is no guidance on when to use this tool versus alternatives such as doc_flow or doc_rollup. No exclusions are mentioned.
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?
The description includes '[read-only]' which signals no side effects, and 'renders' implies a read operation. With no annotations provided, this is adequate but minimal. It does not disclose potential error handling, permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the read-only hint and function signature. It contains no redundant information and is efficient for its length.
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?
Despite having an output schema, the description is too brief to provide sufficient context for an AI agent. It does not explain what a 'flowLink chain' is or how this tool fits among the many sibling tools like link, unlink, and doc_rollup.
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%. The description only implies the 'id' parameter via the function signature but does not explain the 'help' parameter or provide any additional meaning beyond the schema's bare names. This is insufficient for a tool with undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'renders' and the resource 'doc's flowLink chain', and specifies it's a journey view. However, it does not explicitly distinguish from sibling tools like doc_map or doc_rollup, which may have overlapping purposes.
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. The phrase 'journey view' gives a vague hint, but there are no explicit when-to-use or when-not-to-use instructions, nor are alternatives mentioned.
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 partially covers behavioral traits (e.g., linking behavior, batch nudges, level effects). However, it omits details on parameters like tags, status, and relates, and does not clarify side effects or permission needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense paragraph filled with abbreviations and jargon (e.g., 'dc/lr id', 'box', 'nudges'). It lacks clear structure or front-loading, making it hard to parse quickly.
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 complexity (12 parameters, no annotations), the description covers core functionality but leaves gaps (tags, status, relates) and relies on domain familiarity. The output schema exists but isn't referenced.
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?
With 0% schema description coverage, the description explains 9 of 12 parameters (type, title, msg, links, push_to, items, level, flow, help), but ignores tags, status, and relates. The explanations are dense and assume prior knowledge.
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 indicates the tool adds 'lore' or 'doc' entries, defining each type (lore=journal entry/decision, doc=spec/plan). However, the phrasing is domain-specific and could be more intuitive for new users.
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 provides context on when to use batch creation over single calls and mentions checklist usage, but does not compare with sibling tools like 'link' or 'doc_map', nor does it specify when NOT to use the tool.
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?
The description claims '[read-only]' but also mentions options 'dismiss' and 'undismiss' which imply state changes, creating ambiguity. No behavioral traits like permissions, side effects, or limits are disclosed, and annotations are absent.
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 concise at two lines plus a third for options, with the main purpose front-loaded. Some phrasing is cryptic (e.g., 'import(openbox=)'), but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a dashboard tool with three parameters and no annotations or output schema details, the description leaves many questions unanswered: what the dashboard displays, the nature of nudges, and how to handle the external source. It is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to 'dismiss' ('turn off a nudge') and 'undismiss' ('restore it'), but does not explain 'help' or the 'external source' reference. With 0% schema description coverage, the description provides only partial parameter clarity.
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 it is a 'project dashboard' meant to be called at the start of every session, clearly indicating a read-only overview. However, it does not differentiate from sibling tools like 'status' or 'show', lacking specificity on what the dashboard contains.
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?
Explicitly instructs to 'call at the start of every session', providing a clear usage context. However, it does not mention when not to use it or alternatives among sibling tools.
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?
The description declares the tool as read-only, providing a key behavioral trait. However, it does not explain whether the summary draft is persisted, how AI is invoked, or any side effects, leaving ambiguity.
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 extremely concise: a single sentence with a function signature. Every part serves a purpose, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters and an output schema, the description omits explanation of the 'help' parameter and the nature of 'lore' or 'AI-summary draft'. It is incomplete for a tool with no annotations or further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only hints at 'id' in the signature but provides no explanation of its meaning or the 'help' parameter. The description adds minimal value 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 uses a specific verb ('collects') and resource ('lore linked to a doc'), clearly stating the action and result ('AI-summary draft'). The '[read-only]' prefix distinguishes it from sibling tools that may modify data.
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 lacks any guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, 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 fully disclose behavior. It mentions recovery and listing trash, but does not cover safety, permissions, side effects (e.g., whether recovery removes from trash), or success/failure responses.
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 concise with one sentence, front-loading the core purpose. However, it omits the 'help' parameter, so some conciseness is at the cost of completeness.
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 simplicity and the presence of an output schema, the description covers the main functionality but lacks details on the 'help' parameter and output behavior. It 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds meaning for the 'id' parameter (optional, lists trash if omitted) but completely ignores the 'help' parameter, leaving its purpose unexplained.
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 'recover' and the resource 'trashed lore/doc', and explains the behavior when no id is provided (lists trash). This distinguishes it from sibling tools like 'rm' (remove) and 'cleanup' (delete trashed).
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 recovering trashed items and lists trash when no id is given, but does not explicitly state when to use this tool versus alternatives or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States '[read-only]' upfront, indicating no mutation. No annotations are provided, so the description carries the burden. However, it lacks details on authentication, rate limits, or side effects beyond the read-only hint.
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?
Extremely concise, single line, well-structured with delimiters. Every element provides value without repetition.
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 15 optional parameters and no schema descriptions, the description offers a high-level overview but lacks completeness. An output schema exists, reducing the need to explain return values, but missing parameter details and usage context hurt completeness.
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 0%; the description groups parameters (target/scope, filters, result shape, mode, plumbing) and adds format hints for 'period'. This compensates partially, but individual parameter meanings (e.g., 'query', 'openbox') remain unclear.
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 indicates a read-only operation for displaying items with filters and options. It specifies targets, filters, and result shape, distinguishing it from sibling tools by its generic listing role.
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 on when to use this tool versus alternatives like 'brief' or 'report'. The description only lists parameters without context for selection.
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 notes that using project_dir does not change the session's base project, which is a behavioral caveat. But it does not disclose side effects, error cases, or resource impact (e.g., file creation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat unstructured, mixing usage patterns and parameter notes. It is not overly verbose but could be more streamlined. The front-loaded purpose is clear.
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 presence of an output schema, return values are covered. However, the description lacks completeness on prerequisites, error handling, or how init fits into the larger tool ecosystem. It gives enough for basic use but not full operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining blueprint (applies a blueprint) and project_dir (sets up in another folder, boundary effect). It omits the help parameter, but the other two are clarified beyond schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool initializes .linklore and starts local footprint memory. It provides usage patterns (basic and with blueprint). However, it does not explicitly distinguish from sibling tools, but the unique function is evident.
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 mentions that setting up in another folder via project_dir is init-only and that to persist working there one should use config(action='pin'). However, it lacks explicit when-to-use or when-not-to-use guidance relative to siblings like config or doc_setup.
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 reveals key behavioral traits: works offline, attaches identity when logged in but never forced. This adds value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste, front-loaded with action. Concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is mostly complete for a simple feedback tool, but the omitted parameter semantics for 'help' and lack of return value context (despite output schema existing) leave gaps.
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%, but the description only mentions 'msg' without explaining its purpose. The 'help' boolean parameter is not mentioned at all, leaving its meaning unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends feedback or a bug to the team. It uses a specific verb and resource, though it does not explicitly differentiate from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use (anytime, regardless of login) and behavior for logged-in users, but does not mention when not to use or alternatives among sibling tools.
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 provided. Description discloses symmetric behavior with link() and file path acceptance. But lacks details on destructiveness, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus parenthetical. Front-loaded function signature. No wasted words.
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?
Output schema exists, but tool is a mutation with no annotations. Description fails to mention prerequisites, exact behavior, or what 'disconnect' entails. Incomplete for a mutation tool.
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?
With 0% schema coverage, description must compensate. It explains a, b, and action (default, 'flow') but omits 'help' parameter. Adds some meaning but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'disconnect two items' which is a specific verb+resource. However, it does not differentiate from sibling tools like 'rm' or 'cleanup' that might also remove connections.
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?
Mentions symmetry with link() and action defaults, implying when to use versus link. But no explicit exclusions or guidance on alternatives among siblings.
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, so description carries full burden. Discloses git-diff based detection and parameter behavior changes (removed dead params, ack='all' workaround). Does not mention side effects, auth needs, or granular behavior, but drift detection is understood as read-only.
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?
One line for purpose, then a list of parameters, and a note about removed params. Front-loaded and relatively concise. The parenthetical note adds necessary context but is slightly cryptic.
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 5 parameters and existence of output schema (per context signal), description gives minimal context beyond purpose and parameter options. Could explain what the tool returns or how to interpret results, but output schema likely covers return values.
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 has 0% description coverage, so description must compensate. Adds meaning for action, ack, reset by listing options and explaining ack='all'. Leaves 'since' and 'help' unexplained. Partially compensates for missing 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 clearly states it detects code↔doc sync drift using git-diff, distinguishing it from show()/brief() for reading content. Specific verb and resource with sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says not for reading lore/doc content and points to show()/brief() as alternatives. Also mentions action parameter options and ack='all' behavior. Could be more explicit about when to use each action, but provides good context.
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?
The description discloses the read-only vs. repair behavior, but lacks details on what repairs entail, side effects, or reversibility. With no annotations provided, this is adequate but not comprehensive.
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 (two lines), front-loads the purpose, and avoids waste. 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 the tool's diagnostic nature, the description covers key aspects, but it does not mention return values or output, even though an output schema exists. It is minimally 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 explains the 'action' parameter (default read-only, 'fix' repairs), adding value over the schema. However, the 'help' parameter is not described, and schema coverage is 0%, so the description partially compensates.
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 checks project data integrity and lists specific aspects (oldId/newId, files[] paths, link targets). It distinguishes between default read-only diagnostics and a fix action, setting it apart from siblings like status or cleanup.
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 explains when to use each mode (default for checks, action='fix' for repairs) but does not explicitly exclude alternatives or mention prerequisites.
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 reveals key behaviors: overwrite keeps old body in history (recoverable via log), supersede creates a new id, and section mode errors if the heading is missing. It also notes that marking as dropped still shows in search. This covers the major behavioral traits, though it omits authorization or rate limit details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with bullet points and examples, making it easy to parse. It front-loads the core concept ('4 write modes') and then details each. Some redundancy exists (e.g., supersede mentioned twice), but overall it is efficient for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 params, multiple modes) and the absence of annotations, the description covers the main use cases and behaviors. However, it leaves some nuances unclear, such as how non-action parameters interact with different modes (e.g., are tags ignored when appending?). The presence of an output schema reduces the need to explain return values, but the description could further clarify overall effects.
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 no descriptions (0% coverage), so the description compensates by explaining most parameters: id, msg, action, section, status, level, tags, items, links. It provides concrete examples for each action. However, 'flow' and 'help' are not explained, and 'title' is only briefly mentioned. The description adds significant meaning 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 that 'edit' modifies existing content with four distinct write modes (append, section, overwrite, supersede). Each mode is explicitly described with verb+resource (e.g., 'appends to the end of body'). The tool's purpose is unambiguous, and the modes differentiate it from siblings like 'add' or 'rm'.
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 provides within-tool guidance on which action mode to use for specific edits (e.g., append for adding, section for partial edit, overwrite for full replace). It also mentions alternatives like 'rm' for permanent delete and 'link' for supersede. However, it does not explicitly tell when to use 'edit' versus other sibling tools like 'add', 'config', or 'status', leaving some ambiguity for cross-tool decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains symmetric linking, directional flow, and replacement semantics for supersede. It also describes auto-classification of non-id values and the undo behavior. No contradictions with annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet-like lines and front-loads the core function. It is somewhat lengthy but every sentence adds value. A slight reduction could improve conciseness, but it is not overly verbose.
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 complexity (multiple action modes, parameter auto-detection), the description covers most aspects. However, it lacks explanation of the 'help' parameter, default values, output format, and potential error conditions. The existing output schema mitigates some return value ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain parameters. It describes 'a' and 'b' as items, file paths, or titles, and details the 'action' parameter's three modes. The 'help' parameter is not mentioned, but it is a minor omission.
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: 'connect two items'. It specifies the types of items (dc↔lr, etc.) and mentions prefix matching and auto-detection. It distinguishes the tool from sibling 'unlink' by explicitly naming it as the inverse operation.
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 explains the three action modes (related, flow, supersede) and provides guidance on when to use each. It also notes that the default action is 'related' and that the inverse is 'unlink'. However, it does not compare to other sibling tools like 'add' or 'edit'.
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 informs about behavioral traits: it 'refreshes the cache' and 'absorbs into the home base with new local id and provenance metadata'. It also notes the alias. Lacks detail on idempotency or overwrite behavior, but covers core behavioral aspects well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with example invocations and a warning. It uses bullet points and code formatting for clarity. Slightly verbose but every sentence adds value. Could be tighter but still effective.
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 0% schema coverage, no annotations, but output schema exists, the description adequately explains tool behavior and parameters. It covers the two modes of operation and key constraints. Lacks return value details, but output schema presumably covers that. Overall sufficient for an AI agent.
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 0%, but description explains `id`, `openbox`, `space` alias with usage examples. It clarifies `space=` is alias for `openbox=`. The `help` parameter is not described, but it's self-explanatory. Overall adds significant meaning 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?
The description clearly states the tool's purpose: 'bring an openbox's footprints into the home base' with two distinct use cases (cache refresh vs full import). It distinguishes from sibling tool `local()` for intra-workspace moves, achieving high specificity.
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?
Provides explicit when-to-use guidance: for cache refresh without home base change, and for full import with provenance. It also tells when not to use: 'moving items between local projects/workspaces is local(), not import()'. This is exemplary.
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?
Since no annotations are provided, the description must compensate. It explains the tool's behavior well: it restores from server to local (like git pull), handles conflicts (skips if local newer, shows conflict otherwise), and works across devices. However, it does not explicitly state whether the operation is destructive or if authentication is required, though the comparison to git pull and conflict handling imply safety mechanisms.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: opening with purpose, then sibling differentiation, conflict handling, and usage examples. Each sentence adds value. It could be slightly more concise, but overall it is efficient and clear.
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 two parameters, no annotations, and an output schema (not shown), the description covers core functionality, conflict handling, and parameter usage. It explains what happens with different invocations (whole server vs selection). It does not detail return values, but output schema presumably covers that. The description is fairly complete for understanding the tool's behavior.
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 0%, so the description must add meaning. It explains the 'id' parameter with examples ('pull(id='lr-x'|'dc-x')'), showing it's optional and can select specific items. The 'help' parameter is not explained, but its meaning is conventional. The description adds significant value beyond the schema's bare types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('restore the home base from my server') and compares it to 'git pull', which is a familiar concept. It also distinguishes from sibling tools 'import' and 'local', providing specific when-to-use guidance. The verb 'restore' and resource 'home base from server' are precise.
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 tells when to use this tool vs alternatives: 'To bring things from an openbox use import — pull is for my server only' and 'moving items between local workspaces is local(), not pull()'. It also explains behavior in conflict scenarios ('If local is newer/same it's skipped') and provides usage examples for different arguments.
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 discloses that the home base is untouched (copy), visible to others, supports batch, and aliasing. However, it does not mention permissions, rate limits, or error handling.
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 organized with a summary line, examples, contrasts, and alias note. It is slightly verbose but front-loads key info and uses bullet-point structure effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and an output schema existing, the description adequately covers main use cases, batch mode, and inverse operation. It lacks details on output format and edge cases but is complete enough for typical usage.
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 0%, so description must compensate. It explains id (with format examples), openbox (with examples), and space as alias. The help parameter is left unexplained, but overall adds significant meaning 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 states 'share a footprint to an openbox (visible to others)' with verb and resource clearly defined. It also distinguishes from sibling tools like push and rm.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use context, contrasts with push for backup, and mentions the inverse rm command. It also gives concrete examples showing both single and batch usage.
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 present, so the description carries the full burden. It discloses that the upload is to a personal server only, provides usage patterns, and clarifies limitations like no sharing. However, it does not mention behavior on conflicts or overwrites, which are minor gaps.
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 concise but uses bullet points and examples effectively. It front-loads the purpose and provides well-structured usage patterns. Minor redundancy could be trimmed, but overall 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 presence of an output schema, the description does not need to detail return values. It covers purpose, parameters, usage, and differentiation from siblings, making it fairly complete. Lacks only minor details like conflict handling.
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?
With 0% schema description coverage, the description excellently explains the 'id' parameter with concrete examples (single item, batch, whole), compensating fully for the schema's lack of documentation.
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 uploads the home base to 'my server' visible only to the user, and explicitly distinguishes itself from 'send' for sharing and 'local' for moving items, 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 on when to use this tool (push to own server) and when not (for sharing, use 'send'; for moving items, use 'local'), and even mentions the inverse operation 'rm'.
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 provided, so description carries full burden. Discloses behavioral traits: preview-only for 2+ items, need confirm=True, only between owned projects, no backend communication. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is dense but well-structured with bullet points for actions and cautions. Front-loaded function signature. Could be slightly more concise, but overall effective.
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 10 parameters, no annotations, and an output schema (not described), the description covers essential constraints, actions, and multi-item behavior. Still missing explanations for a few parameters like 'help'.
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 0%, so description must compensate. It explains action, id, to, from_dir, confirm, and pass-through parameters, adding meaning beyond schema. However, 'help' parameter is not explained, and default values are implied but not explicit.
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 it operates directly on another LinkLore project on the same disk, with actions move, copy, show. Distinguishes from sibling tools by specifying it is local-only and not for server/team sharing.
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 (local disk operations) and when not to use (use send/import for others' projects). Provides clear alternatives and context.
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 behavioral traits: owner-only operations, double confirmation for transfer, error on leave for owner (409), and side effects like session rotation on reissue.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with bullet points and clear sections. It could be slightly more concise, but every part adds value for the tool's complexity.
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 (11 parameters, multiple actions), the description covers all necessary context: openbox concept, action types, parameter usage, error conditions, and alternative tools. Output schema presumably covers 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?
The input schema has 0% description coverage, but the description defines all parameters via usage examples and explanations (e.g., action, openbox, role, kind, who, code, url). It fully compensates for missing 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 clearly states the tool handles openbox (shared space) members and permissions, with a one-line summary and detailed action list. It distinguishes the tool's scope from siblings by explicitly mentioning removal via 'rm' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance for each action, including when to delegate to the 'rm' tool for deletion, and lists prerequisites (e.g., owner-only for invite, transfer has double confirmation).
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 provided, so description carries full burden. It discloses recoverability of trash, unrecoverability of permanent delete, confirmation flow for openbox deletion, auto-detection of action, and that action='openbox' cannot combine with id=. No contradictions.
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?
Well-structured with headings and bullet points, front-loaded with core purpose. However, somewhat verbose; could be trimmed slightly without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (8 parameters, multiple operations) and lack of annotations, the description addresses all relevant aspects: use cases, parameter roles, behavioral nuances, and alternatives. Output schema likely covers return values, so omission is acceptable.
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 0%, but description thoroughly explains all parameters: id (string or list for batch), force (permanent delete), sent (take down), member (remove member), openbox/space (space alias), action (explicit alternative, auto-detected when omitted), help (likely debug). Adds meaning beyond schema titles.
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 'rm — unified delete' and explains multiple deletion contexts (items, sent items, members, openboxes). It distinguishes from sibling tools like edit, add, and restore by specifying when to use those instead.
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?
Provides explicit guidance for each scenario: trash vs permanent delete via force flag, batch delete with list, mark as dropped via edit, supersede via add, take down with sent and openbox parameters, remove member, and delete openbox with two-call confirmation. Also warns against combining action='openbox' with id=.
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:

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

Score Badge

Copy to your README.md:

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

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/linklore/linklore-mcp'

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