Seamless
Server Quality Checklist
Latest release: v0.4.11
- Disambiguation5/5
Each tool targets a distinct resource and action. Although there are many memory/note tools, descriptions clearly separate them (e.g., memory_edit for in-place search/replace vs memory_write for full-body updates, memory_append for adding to existing), and gardener tools are well-differentiated (request creates proposals, proposals lists, apply resolves, split handles project splits). No two tools appear to do the same thing.
Naming Consistency4/5The vast majority follow a resource_action pattern (tasks_add, notes_read, memory_write, project_list, session_start). A few deviations exist: usage_summary (noun-noun), capture_url (verb-noun), favorite_set (noun-verb), and recall (bare verb). The overall pattern is still predictable and readable, so the minor inconsistencies do not cause confusion.
Tool Count3/5With 30 tools, the server is on the heavy side. The broad domain (memories, notes, tasks, projects, sessions, gardener, etc.) justifies many of them, but some could be consolidated—e.g., memory_edit vs memory_write, notes_edit vs notes_update—which would reduce surface area. The count is not extreme enough for a 2, but it exceeds the comfortable 3-15 range.
Completeness5/5The tool surface provides full CRUD and lifecycle coverage for all core entities: memories (write, read, append, edit, delete), notes (create, read, update, append, edit, delete), tasks (add, list, claim, release, update, ready), projects (create, list), and sessions (start, update, end). Additional features like recall, capture_url, favorite_set, gardener, and usage_summary fill out the system with no obvious dead ends.
Average 4.5/5 across 30 of 30 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 457 commits in the last 12 weeks
- Last stable release on
- 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.
Tools from this server were used 6 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation appends to the body and preserves the id. Annotations show no readOnly or destructive hints, but the description adds value by stating the id is kept. It does not cover what happens if the memory does not exist or potential limits, but is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words. The purpose is front-loaded and every sentence contributes essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple append tool with no output schema, the description is reasonably complete. However, it could mention error behavior (e.g., if memory doesn't exist) and provide more guidance against similar tools like notes_append, given the large sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the schema already thoroughly describes each parameter. The description only repeats 'markdown' from the body parameter description, adding no new semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool appends markdown to an existing memory's body, identifies that the memory keeps its id, and distinguishes it from memory_write for creation. This is specific and differentiates from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when not to use (for creation, use memory_write) and implies that this tool is for existing memories. However, it does not contrast with notes_append or other append-like tools, but the memory vs notes domain is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is idempotent, not read-only, and not destructive. The description adds value by specifying that starring never bumps an item's updated time and explaining where the flag is stored (frontmatter for memories/notes). This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core action, the second explains effects and details. Every part is relevant and there is no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and 4 parameters, the description covers the primary effects (sorting, pinning, boost, no time bump) but does not explain the 'project' parameter or return value. For a simple toggle tool this is mostly complete, but minor gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so baseline is 3. The overall description provides context for the action but does not add specific meaning to individual parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('star or unstar') and resource ('item'), and further clarifies the action by listing kinds of items in the schema. It distinguishes from sibling tools, as no other sibling tool handles favoriting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to toggle favorite status) but does not provide explicit context on when to use it versus alternatives or when not to use it. No exclusions or comparisons with sibling tools are given.
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?
Annotations already indicate idempotent and non-destructive; description adds 'interim progress' nuance but no new behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key action and scope, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers purpose, default behavior, and parameter guidance for a simple update tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds no additional parameter meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the verb 'Record interim progress' and the resource 'current session', distinguishing it from sibling tools like session_start and session_end.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly explains default binding and when to explicitly pass session parameter, though no explicit when-not or alternatives.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description reinforces with 'Read-only.' It does not add deeper behavioral details beyond the list of proposal kinds, but given the read-only nature already annotated, no additional disclosure is needed. No contradictions detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action 'List pending gardener proposals' and then provides a parenthetical list of examples. It is longer than minimal but every example adds context; however, the list could be trimmed for brevity without losing key meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and only one optional parameter, the description covers the tool's purpose, examples of proposal types, and the follow-up action (gardener_apply). It could mention default behavior when no 'kind' is specified (that is in the schema) but is otherwise sufficient for an agent to understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single 'kind' parameter with a basic description. The tool description enriches the parameter semantics by explaining many proposal kinds (e.g., 'merge/consolidate duplicate memories' maps to 'merge'/'consolidate', 'archive stale memories' maps to 'archive'), giving agents a better understanding of valid filter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List pending gardener proposals' with a specific verb and resource, and enumerates proposal types (merge, archive, digest, etc.) that distinguish it from sibling tools like gardener_apply (which acts on proposals) and gardener_request (which creates them).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance by stating 'Review, then apply, dismiss or hide each with gardener_apply', which tells the agent when to use this tool (to list) and what to do next. It also gives examples of proposal kinds that signal when to check this tool, though it doesn't explicitly contrast with gardener_request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While the description is exceptionally transparent about error semantics and slot defaults, it directly contradicts the idempotentHint=true annotation. It states 'an existing slug is an error, not an update' meaning a second identical call with the same slug would fail, which is the opposite of idempotent behavior. Per the rule, a description that contradicts annotations receives a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence adds value: the opening states the core operation, then the rarity is conveyed, then specific usage guidance, then failure mode, then alternative, then slug rules. It is front-loaded with the most critical information and contains no fluff or redundancy. The length is justified by the number of important caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite missing an output schema, the description covers all relevant context: why you rarely need it, when to reach for it, prerequisites (project_list), failure modes (duplicate slugs), reserved names, isolation constraints, and the fact that it never renames/edits existing projects. No important context is missing for a creation tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all parameters, but the tool description adds meaningful context beyond the schema: the slug defaults to a slugified name, 'global' and 'all' are reserved, and an existing slug causes an error rather than an update. These details help the agent understand parameter behavior that isn't in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Register a project up front, with a human-readable name and an optional description.' It clearly distinguishes this from sibling tools by explaining that memory_write, notes_create, tasks_add, capture_url, and trial_record auto-register projects, and that gardener_split handles project division. The purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when NOT to use this tool ('You rarely need this'), provides the exact condition for using it ('only to give a project a proper name and description BEFORE anything is written into it, or to create one you will not write to yet'), and directs users to call project_list first to avoid duplicate slugs. It also names gardener_split as the alternative for subdividing projects.
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 is consistent with annotations (idempotentHint=true, readOnlyHint=false). It adds that findings are persisted but doesn't disclose that the session becomes inactive or cannot be resumed. With annotations present, it provides adequate but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently cover the primary action and key nuance about bound session. Every sentence adds value, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and no output schema, the description covers the main purpose but omits what happens after completion (e.g., session state change). It could be more complete for a termination action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaningful context beyond schema, especially for 'mishaps' (self-report and linking to memory) and 'session' (default behavior). It enhances understanding of parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool completes the current session and persists findings. It distinguishes itself from siblings like session_start and session_update by using specific verbs and mentioning bound session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to end a session), clarifies the bound session default, and warns about ambiguity when multiple agents are active. It could explicitly state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive operation. The description adds the SSRF guard detail and the notion of 'readable content', which are useful behavioral disclosures beyond the annotations. It doesn't contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the action, safety constraint, output, and return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and moderate complexity, the description covers the main behavior, the SSRF guard, the output, and the note-creating side effect. It does not explain the project parameter behavior, but the schema fully covers that, so the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description is not required to elaborate on parameters. The description adds the return value ('Returns the new note's id') which is valuable but not parameter-specific. It meets the baseline for fully documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('a web page') and states the outcome ('save its readable content as a note'), clearly distinguishing it from sibling tools like notes_create. It also mentions returning the note's id, which is a unique functional signature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly communicates when to use this tool: whenever you need to fetch a URL and capture its content as a note. It gives clear context (SSRF guard, saving as a note) but does not explicitly mention alternatives or when not to use it, leaving room for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. The description adds value by explaining the fallback behavior to global note and the default project context, providing additional behavioral understanding beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured 18-word sentence that immediately conveys the core functionality without any extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 annotations covering safety and idempotency, the description adequately covers the main use cases. However, it omits error behavior (e.g., not found) and response format, though no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover each parameter fully (100% coverage), but the main description adds the crucial constraint 'pass exactly one of id or slug' and explains the slug's alias, enhancing the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and the resource ('note'), and distinguishes two lookup methods (by id or by slug within project), which differentiates it from sibling tools like notes_create or notes_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use id vs slug but does not explicitly compare to other tools. It lacks guidance on when to use notes_read over memory_read or recall, which are also read-oriented siblings.
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 adds that it reopens and clears claim, complementing annotations (idempotentHint, destructiveHint). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with essential information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers effects and constraint adequately for a release action without output schema. Could mention error cases, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description doesn't add param-level meaning beyond existing schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (release), resource (task), and effect (reopens, clears claim). It distinguishes from sibling tools like tasks_claim and tasks_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
States prerequisite 'Only the current holder may release', implying when to use. Lacks explicit when-not-to-use or alternatives, but the constraint is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so read-only nature is clear. The description adds the resolution fallback behavior (project then global), which is beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no waste. Front-loaded with the core action 'Read a memory'. Every part is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering safety and idempotency, and full parameter documentation, the description is fairly complete. It explains the resolution fallback. No output schema, but the return type (memory) is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 the constraint 'pass exactly one of name or id', which is not enforced by the schema (both are optional), clarifying the intended usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a memory by name or id, with specific resolution behavior. It distinguishes from sibling tools like memory_write, memory_delete, memory_append.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the two lookup modes (by name with project fallback, or directly by id). However, it does not explicitly state when to choose one over the other or mention when not to use this tool.
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?
The description adds meaningful behavioral details beyond the annotations: it explains the fused search mechanism ('by meaning and keyword'), the project-plus-global scope, and the browse behavior when kind is set without a query. These are not visible in the annotations and help the agent predict the tool's behavior. It doesn't describe return format, but annotations already cover safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise, information-dense sentences. It front-loads the core action, states the tool's unique position, and covers the key alternate mode without any wasted words. Every sentence contributes essential context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 5 optional params and no output schema, the description covers the main modes (search and browse) and scope behavior. It omits the edge case of having neither query nor kind, which might be an error or default behavior, but overall the description is sufficiently complete for an agent to invoke the tool correctly in typical scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying the interplay between query and kind (the browse mode) and the 'current project plus global items' scope, which enriches the meaning of the project parameter. This goes beyond the schema's field-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly identifies the tool as the search entry point for memories and notes, combining meaning and keyword matching. It also differentiates by scoping to the current project plus global items and mentions a distinct browse mode, making it clear what this tool does versus others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states 'This is the single search entry point,' indicating when to use this tool for search. It also specifies the browse mode when kind is set without a query, providing a clear usage context. It does not explicitly exclude alternatives, but the 'single entry' phrasing is strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint true and destructiveHint false. The description adds valuable context: session binding to connection, scope inheritance, and project briefing return. No contradictions are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff: first sentence states core function, second provides crucial context about scope inheritance. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description explains return value and scope inheritance, it lacks details on resume-specific behavior (e.g., what happens when name matches an existing session). Schema partially fills this, but description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with detailed descriptions. The tool description does not add significant meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool begins or resumes an agent work session and binds it to the connection, returning the project briefing. It distinguishes itself from sibling tools like session_end and session_update by focusing on session initiation/resumption.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains that memory/recall/notes calls inherit scope from this session, providing implicit guidance on when to call (before those operations). However, it does not explicitly mention when not to use or list alternatives, leaving some gap.
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?
Adds behavioral details beyond annotations: permanent, no pointer left, reserved for disposable notes. No contradiction with annotations (destructiveHint=true, idempotentHint=true).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and is well-structured, but slightly wordy. Each sentence adds value, but could be trimmed slightly without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers action, consequences, appropriate use, and alternatives. Lacks return value info, but for a simple destructive tool with no output schema, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter 'id' is already fully described in the schema ('note id (ULID)'). The description does not add new semantic info beyond the schema, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a note by id' and elaborates on the permanent removal of the file and index row. It distinguishes from sibling tools notes_update and notes_append by specifying 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (duplicates, wrong project, agent's scratch) and when not to use (content fixes should use notes_update, additions use notes_append). Also warns about notes linked to plans.
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?
Beyond annotations (destructiveHint=true, idempotentHint=true), describes exact consequences: file deletion, index row removal, no provenance left. No contradiction 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with action and implications. While slightly verbose, every sentence adds value (warnings, alternatives, consequences). Still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description covers return behavior (nothing left behind), error-avoidance, and context for a destructive operation. Fully adequate for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameters are fully covered by the schema (100% coverage). Description does not add significant extra meaning beyond what 'memory name' and 'project slug' imply. Adequate but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Delete a memory by name' and distinguishes from memory_write and gardener operations, making the specific action 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises against use ('Prefer nearly anything else') and details alternatives: memory_write for superseding, gardener archive for stale data. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clarifies the additive nature explicitly ('Appending only ever adds'), which aligns with the annotations (destructiveHint=false). It adds the detail of UTC-timestamping, which is not captured in annotations or schema, and explains that appending preserves the note's id/slug/place, preventing fragmentation. This behavioral context is valuable given the annotations only provide basic hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet thorough: it states the action, provides usage context, distinguishes from related tools, and explains how to obtain the required parameter. Every sentence is informative, and the structure logically flows from purpose to guidance to parameter sourcing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple append operation with two parameters, the description covers the core behavior, usage guidelines, and parameter context. It does not mention return value or error handling, but given the lack of output schema and the straightforward nature of the operation, these omissions are acceptable. The description is comprehensive enough to enable correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers both parameters with descriptions (100% coverage). The description adds meaningful context for the id parameter by explaining its source (notes_create, briefings, plan compositions, notes_read), which helps the agent construct a valid call. For the body parameter, no additional detail is provided, but the schema description is sufficient. Overall, the description enhances understanding of parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Append a UTC-timestamped line to an existing note's body, by id.' It further distinguishes itself from sibling tools notes_update and notes_create, preempting confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states appropriate usage scenarios and directly compares with notes_update (for correction/restructuring) and notes_create (for new artifacts). It also explains where to obtain the required id parameter, providing comprehensive usage guidelines.
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?
Annotations declare readOnly, idempotent, non-destructive. The description adds behavioral details: the ordering (oldest first), the inclusion of blocked tasks with their blockers, and the default exclusion of plan-step tasks. It adds significant context beyond the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines the core functionality and ordering, second explains the plan parameter behavior. Every sentence is necessary and no redundant information. Efficiently packed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately hints at the return format (list of ready/blocked tasks). It covers inputs and core behavior. Missing details like pagination or limits, but these are reasonable omissions for a simple list tool. Overall sufficient for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes both parameters with 100% coverage. The description adds meaning by explaining the effect of the plan parameter (include plan steps instead of default) and that project defaults to the bound session. This enhances understanding but is not strictly necessary given the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists actionable (ready) tasks for a project, defines 'ready' as open tasks with no unfinished blocker, specifies ordering (oldest first), and distinguishes from the default non-plan tasks vs plan-step tasks via the plan parameter. This is specific and differentiates from siblings like tasks_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the plan parameter (to get plan-step tasks) and that by default plan steps are excluded. However, it does not directly contrast with alternatives like tasks_list, leaving some ambiguity about when to prefer this tool over listing all tasks.
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?
Beyond annotations (idempotentHint=true, destructiveHint=false), the description adds critical behavioral details: status transitions to done/dropped close the task and unblock dependents, and locked tasks fail with an error. This gives the agent a clear understanding of side effects and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences only: the first states the main capabilities, the second covers the critical lock behavior. No fluff, front-loaded, and every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and no output schema, the description covers the primary update types and the locking mechanism. It does not explain the return value or all edge cases (e.g., adding dependencies to a closed task), but the information provided is sufficient for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 status enum values, the comma-separated string acceptance for add_depends_on, and the condition for using the session parameter. It does not elaborate on every parameter (e.g., project, session_id precedence) but provides sufficient context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a task' and enumerates specific fields (status, title, body, dependencies). It distinguishes from siblings like tasks_add and tasks_claim by focusing on updates and mentioning lock behavior unique to this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to update task fields) and notes that attempting to update a locked task fails. It provides guidance on when the session parameter is needed. However, it does not explicitly mention alternatives (e.g., using tasks_release to unlock) or when not to use this tool.
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?
It discloses a key behavioral nuance beyond the annotations: the named memory lists are fenced under project isolation and may be shorter than counts imply. The description also states it is read-only, consistent with annotations but reinforcing the non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main content front-loaded in the first sentence. The trailing 'Read-only' slightly redundantly repeats the annotation, but it is a minor redundancy in an otherwise well-structured two-sentence description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters or output schema, the description provides a thorough inventory of the returned metrics and explains the important fencing caveat. It fully covers what the agent needs to know about the tool's output and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific details, but none are needed since the schema already shows an empty properties object. The lack of parameters is implicitly supported by the description's focus on global, caller-independent counts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports a 'roll-up of activity' and enumerates specific metrics (memory/note/session/task counts, retrieval totals, gardener proposals, events by kind). This distinguishes it from sibling tools that handle individual items, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a machine-wide summary of activity, with the note that counts are identical for every caller suggesting a global overview. It does not explicitly state when to use it over alternatives or provide exclusions, but the context is clear.
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?
Annotations already mark destructiveHint=true and readOnlyHint=false; the description goes further by detailing exactly what destructive effects occur per action (e.g., 'retire the memory', 'discards this proposal and the evidence behind it', 'blocks the pattern permanently'). It also states both dismiss and hide are reversible by the owner, adding context not available from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place. It uses semicolons to compactly list the many apply sub-actions, and the dismiss/hide contrast is explained in two sentences without fluff. The structure moves from general purpose to specific actions to preference guidance, which is organized and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with no output schema, the description thoroughly covers the tool's effects across all actions and gives reversal guidance. However, it does not state what the tool returns on success (e.g., the resolved proposal, a confirmation, or the updated proposal list), which leaves a small gap given there is no output schema to fill it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with basic descriptions, but the description expands the 'action' enum by explaining what each action does (apply with its sub-cases, dismiss meaning discard evidence and re-raise on recurrence, hide meaning permanent block). This gives the model semantic understanding of the parameter values beyond the schema's one-line notes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Resolve a gardener proposal' and then enumerates every action variant with concrete effects (archive->retire, merge->supersede, etc.), clearly distinguishing this from sibling tools like gardener_proposals (list) and gardener_request. The verb 'Resolve' is specific to acting on an existing proposal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Prefer dismiss unless the suggestion is wrong in principle rather than wrong for now', giving a decision rule for reject options. It also distinguishes apply vs dismiss vs hide by their consequences. While it doesn't name alternatives like gardener_proposals, it clearly implies this tool is the resolution step after viewing proposals, so the usage context is well defined.
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?
Even with annotations (readOnlyHint false, destructiveHint true, idempotentHint true), the description adds substantial behavioral detail: all-or-nothing atomic application, exact/uniqueness matching, failed match changes nothing, metadata-only path, tags_remove as the only way to clear a tag, and a unified diff plus content_hash in the return. No contradiction 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then logically expands into matching rules, metadata-only capability, return value, and usage boundaries. Every sentence adds distinct value; no fluff or redundancy. Length is justified by the tool's nuanced behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description covers the return value (unified diff + content_hash). It also handles edge cases (metadata-only edits, tag clearing, meaning changes) and explains when to prefer memory_write. Combined with the detailed input schema, this is a fully self-contained description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minor practical guidance like 'include surrounding lines to make it unique' and reiterates matching semantics, but the parameters are already thoroughly documented in the schema. The description doesn't significantly elevate parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Edit an existing memory in place with exact search/replace,' immediately distinguishing it from memory_write and memory_append. It clearly states scope (existing memory, in-place) and mechanism (search/replace), and the sibling context confirms this is a unique editing 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use: 'corrections that do not change what the item CLAIMS: typos, broken formatting, a stale path or command, a stage's Status flip, metadata.' Also gives a clear exclusion: 'If the MEANING changes ... use memory_write with supersedes.' This is exemplary guidance that prevents mis-selection among sibling tools.
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?
All annotations are false/neutral, so the description carries the transparency burden. It adds meaningful behavioral context: auto-tagging ('Auto-tagged created-by:agent'), plan-joining semantics, and project creation behavior (unknown slug creates a project; project=global is special). It doesn't cover every edge case, but it discloses important side effects 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Although dense, every sentence earns its place. The description front-loads the core purpose, then uses semicolons and parallel structure to deliver usage, alternatives, and parameter nuances without redundancy. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no output schema, the description covers purpose, usage boundaries, parameter semantics (especially project/plan), and important edge cases (ambiguous session, confidential projects). It leaves little practical doubt about how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 significant value beyond the schema for 'project' (defaults, creation, global semantics, rejection conditions) and 'plan' (joins composition, surfaces on Plans screen), and clarifies tags format (comma-separated string accepted). This uplifts the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Create a work note') and enumerates concrete examples (research finding, decision record, meeting summary). It clearly distinguishes this from sibling tools like notes_append and memory_write, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance: it contrasts with memory_write ('put the write-up here and the one-line lesson there'), warns against duplicating repo/AGENTS.md/current conversation content, and directs users to notes_append for extending existing notes. This is exemplary alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavior beyond annotations: the exact/uniqueness match requirement, replace_all option, atomic all-or-nothing application ('all edits apply together or none do'), failure mode ('a failed match changes nothing'), and return value ('unified diff... plus the new content_hash'). These add significant context not present in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: first states the action, second details constraints and atomicity, third gives use case, alternatives, and output. Front-loaded with the core purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description states the return value (diff + content_hash). It covers use case, failure behavior, atomicity, and sibling relationships. The expect_hash parameter is documented in the schema, so not repeating it in the description is acceptable. The tool is complex but the description is complete for an agent to select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with detailed descriptions, including exact matching, whitespace sensitivity, uniqueness, replace_all, and expect_hash. The description adds little beyond the schema, mostly restating atomicity and uniqueness. Baseline 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Edit an existing note in place with exact search/replace, by id' and differentiates it from notes_update ('instead of resending its whole body') and notes_append ('only ever adds'). It names the specific method and resource, making it 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'This is the tool for correcting or restructuring part of a long note' and contrasts with alternatives: 'notes_append only ever adds, and notes_update replaces the whole body.' This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false, destructiveHint=false), but the description adds rich behavioral context: atomicity, lease mechanism, refusal causes (already claimed, blocked, closed), heartbeat effect, lease expiration, and that session_end releases all claims. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but well-structured: core action first, then refusal details, then reclaim/release behavior. Every sentence adds necessary information. A slight redundancy in the refusal explanation 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with full schema coverage, no output schema, and minimal annotations, the description is highly complete. It covers lifecycle (claim, reclaim, release), edge cases (expired leases, refusal), and relationships with sibling tools. Could optionally describe the return value, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all 4 parameters described. The description adds value beyond the schema by explaining the purpose of the 'session' parameter (defaults, ambiguity when multiple agents) and the 'lease_seconds' default (900). It also contextualizes the 'id' parameter within refusal scenarios.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Atomically claim a task for the current session, moving it to in_progress with a lease.' It uses specific verbs (claim, moves) and resources (task, session, lease). It distinguishes from siblings like tasks_release, tasks_update, and session_end by mentioning them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance. It explains that re-claiming refreshes the lease, expired leases can be reclaimed, and tasks should be released via tasks_release or closed via tasks_update. It also describes refusal scenarios, helping the agent decide when to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly states 'It NEVER mutates memories: it only creates pending proposals', which adds crucial context beyond annotations (readOnlyHint=false). Also mentions returning guidance for split operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with purpose upfront, followed by examples and usage notes. Slightly lengthy but each sentence adds value; could be more concise without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (natural language processing, proposal creation), the description covers input, output (pending proposals), workflow (review with gardener_proposals, apply with gardener_apply), and special cases (split guidance). No output schema, but return behavior is adequately described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are already comprehensive (100% coverage). Description adds value by giving examples of what the 'request' parameter should contain (e.g., 'fold duplicates', 'retire stale'), illustrating the plain language format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly defines the tool as the natural-language entry point for reorganizing memory, listing concrete examples like folding duplicates, retiring stale, and moving memories. It distinguishes from sibling tools like gardener_apply, gardener_proposals, and gardener_split.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('whenever the user describes how they want their knowledge organized') and when not to (if ambiguous, ask clarifying question; if splitting into new child projects, use gardener_split). Also notes the workflow after creating proposals.
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?
Annotations provide minimal info (readOnlyHint=false, destructiveHint=false). Description fully compensates: explains it only creates reviewable proposals (not actual changes), details output structure (one 'split' setup proposal plus one 'reproject' per memory under plan 'split-<source>'), and notes it never creates or moves memories directly. No contradiction 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and usage. All sentences contribute meaningful information, though length could be slightly tighter. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites (LLM chat client, known slug), explains output structure in lieu of output schema, and differentiates from multiple sibling tools. No gaps identified for a planning-level tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds value by reiterating that 'source' is a project slug and linking to project_list for discovery, and that 'instruction' is optional for guiding children/shared parent. This provides context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('divide') and resource ('project split'), clearly distinguishes from siblings like project_create and gardener_proposals, and gives a concrete example. It explicitly states the tool does not create or move projects/memories, only pending proposals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('break one project into several'), mentions that gardener_request routes here via splitSource, and provides a clear workflow: propose via this tool, review with gardener_proposals, apply with gardener_apply. It also clarifies prerequisites (LLM chat client, known source slug).
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?
Beyond the annotations (readOnlyHint=false, etc.), the description discloses key behaviors: dependencies must exist and be acyclic, done/dropped unblocks, and the task becomes ready once no blockers remain. This adds valuable context about side effects and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, each sentence providing essential information: the action, dependency semantics, and ready condition. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (dependencies, project scoping, plan integration), the description covers the core behavioral rules sufficiently. No output schema exists, but the description explains the primary success condition (task becomes ready) and dependency constraints, making it complete for an agent to reason about.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to depends_on by specifying validation rules (existence, cycle prevention) and the unblocking condition, which the schema does not cover. It also clarifies the 'ready' state relative to depends_on, enriching the schema's generic parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Add a task to the dependency-aware ready queue.' It clearly distinguishes this from sibling tools like tasks_update (modify) and tasks_claim (claim), focusing on creation with dependency semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when adding a task with dependencies that participates in the ready queue. It also explains the 'ready' condition and plan-step exclusion, but does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses ordering ('newest first'), default exclusion of plan-step tasks, and the special behavior of id lookup (ignores project/status/plan, no session scope). Annotations already declare readOnlyHint, idempotentHint, destructiveHint; description adds valuable behavioral nuance without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. Each sentence conveys a distinct mode of operation. Main purpose is front-loaded. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all three invocation patterns and ordering, but doesn't mention result format, pagination, or limits. Given no output schema and moderate complexity, it is nearly complete; a minor gap keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds context beyond the schema: for id, explains it performs a direct lookup; for plan, explains it lists step tasks; and implies the default behavior when plan is absent. The ordering information is not tied to a parameter but adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists a project's tasks with optional filters, including plan-step tasks and single-task lookup by id. Verb 'list' plus resource 'tasks' plus specific behaviors (newest first, exclusion of plan-steps) distinguish it from sibling tools like tasks_add or tasks_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use default (non-plan tasks), when to pass plan (to list plan steps), and when to pass id (to load a single task ignoring project/status/plan). Also implies 'when not' by noting that id lookup ignores other parameters. Provides clear alternatives within the same tool's interface.
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?
Beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true), the description discloses rich behavioral details: updating an existing name in place with stable id, the advisory similarity hint on new names, the withheld hint due to project fencing, supersedes marking the old memory invalid while keeping it readable, and the fallback when superseding fails. These add significant context that annotations alone don't provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is long, every sentence carries essential information. It is front-loaded with the core purpose, then systematically covers update semantics, similarity hints, fencing, supersedes, and error recovery. There is no fluff or repetition; the density is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, rich annotations, and no output schema, the description covers the key behavioral aspects: update-in-place, advisory hints, fencing, supersedes, and error handling. It also mentions response markers (withheld hint, error retry) that help the agent interpret outcomes. Combined with the schema, this is highly complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% parameter coverage, so the baseline is 3. The description adds extra meaning for 'name' (update-in-place semantics), 'supersedes' (index behavior, pointer, failure fallback), and 'project' (fencing and unknown slug creation), which goes beyond the schema descriptions and helps the agent use these parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create or update a durable memory' — a specific verb and resource — and immediately distinguishes itself from siblings: 'Long-form write-ups belong in notes_create; put the one-line lesson here.' It clearly scopes the tool to compact, must-not-miss knowledge and differentiates from memory_append, memory_edit, and notes_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: it tells the agent to use this for one-line lessons and points to notes_create for long-form content. It also explains a specific scenario for supersedes (replacing a different outdated memory) and notes the failure behavior, giving clear decision criteria versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds significant behavioral context: each row's isolation state (open/confidential/sealed), what that means for cross-project reads and writes, and that it returns identity not contents. No contradiction with annotations; the description genuinely extends beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each pulling weight: purpose, when-to-use, when-not-to-use, and output semantics. Front-loaded with 'List every project'. No redundancy or fluff; every sentence contributes to tool understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully covers return shape, isolation semantics, and usage boundaries. For a zero-parameter list tool, this is complete and self-sufficient—the agent knows what to expect and how to act on it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters and schema coverage is 100%, so there are no parameter semantics to clarify. Per rubric, baseline for zero params is 4; the description provides no unnecessary param details, appropriate for this case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'List every project (slug, name, description, isolation)', a specific verb+resource with return fields. It clearly distinguishes from sibling tools like recall (searches contents) and project_create (creates projects), making the tool's unique 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: before a cross-project write or project_create to verify slugs and to see if work already has a home. It also says when NOT to use it—for normal scoping because memory/note/task calls inherit the session binding—and directs to recall for content search. This is a model of usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, but the description adds crucial behavioral details: omitted fields are untouched, slug/id stay stable, body replaces the whole body, and tag operations apply in a specific order. It also explains the meaning of expect_hash and the empty-list trap for tags, going far beyond the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then expands into necessary caveats. Every sentence adds value: concurrency control, tag semantics, and ordering rules. Though long, the density of information justifies the length, with no redundant or filler phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and complex tag/body semantics, the description covers all critical edge cases and alternatives. It explains the concurrency model, tag replacement risks, and clear strategies (expect_hash, notes_append, tags_remove). This is more than complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description enriches parameter semantics substantially. It clarifies that body has aliases (content, text), tags accepts a comma-separated string, tags_add/tags_remove are applied in sequence relative to tags, and expect_hash acts as a concurrency guard. This guidance is not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and object: 'Update a note's fields by id (title, description, body, project, tags).' It clearly defines the tool's scope and differentiates from siblings like notes_append and notes_read, which are explicitly referenced for alternative operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: when appending instead of replacing the body, use notes_append; for tags, prefer tags_add/tags_remove over replace to avoid clobbering other agents' changes. It also explains when to use expect_hash for concurrency safety, providing clear when-to and when-not-to scenarios.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/0spoon/seamless'
If you have feedback or need assistance with the MCP directory API, please join our Discord server