Shared private memory layer for AI agents. Write context once, carry it across Claude, ChatGPT, Grok, Cursor, Replit, Bolt, Lovable, Devin, v0 and more. Supports reusable SKILL.md bundles for agent skills discovery. OAuth 2.1 + API key auth.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 10 tools
Most tools have clearly distinct targets: get_cluster vs list_clusters, get_skill vs get_skill_resource, and write_observation vs search_memory. However read_context overlaps with list_clusters, get_cluster, and search_memory by also returning clusters and memories, and export_all broadly overlaps with all read tools.
All names use snake_case with a leading verb (get_, list_, read_, search_, upload_, write_, export_) and consistently place the resource after the verb. The pattern is predictable across the set.
10 tools is well within the appropriate range for a memory/context/skill server and each tool covers a distinct operation instead of fragmenting the surface.
There are significant lifecycle gaps: no update/delete for memories, no create/update/delete for clusters, and no enable/disable/delete for skills. In particular, upload_skill creates a disabled skill but there is no way to enable it, creating a dead end.
Return all user memories and clusters as a structured data-portability export.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| clusters | Yes | |
| exported_at | Yes | |
| total_memory_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only the 'data-portability export' framing and the completeness scope ('all'), with no mention of payload size, ordering, or whether filtering is possible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with the scope front-loaded ('all user memories and clusters') and no filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value detail is not required, and the zero-parameter, read-only nature is fully captured by the annotations. For a simple export tool the description is nearly complete, though a note that this is the unfiltered full dump versus the search/list siblings would close the remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there are no parameter semantics to document and the baseline is 4. The description adds nothing here because there is nothing to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Return all user memories and clusters') plus the output framing ('structured data-portability export'). The word 'all' implicitly separates it from search_memory and list_clusters, though it never names an alternative, so the differentiation is inferable rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus siblings like search_memory, list_clusters, or get_cluster. The 'all' scope hints at a full-dump use case, but no condition, prerequisite, or exclusion is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return metadata and memories for one named project cluster.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact cluster name using letters, numbers, or hyphens. | |
| limit | No | Maximum number of memories to return from the cluster. |
| Name | Required | Description |
|---|---|---|
| cluster | Yes | |
| memories | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered elsewhere. The description adds that the result includes both metadata and memories, which is modest context but does not mention error behavior for a missing cluster.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that names the action, the payload (metadata and memories) and the scope (one named cluster). Nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering read-only semantics, the description needn't explain returns. It is nearly complete, though it omits any note about unknown cluster names or the relationship to list_clusters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both the exact-name constraint and the limit/default are fully documented in the schema. The description adds no meaning beyond that, making the baseline 3 correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Return) and resource (metadata and memories for one named project cluster), and 'one named' implies single-cluster lookup versus the sibling list_clusters. It does not explicitly name or contrast with list_clusters, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance and no mention of the alternative list_clusters for discovering valid names, nor any exclusion. Usage is only implied by the required 'name' parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return an enabled SKILL.md and its supporting resource index by slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Slug identifying the enabled skill to return. |
| Name | Required | Description |
|---|---|---|
| skill | Yes | |
| resources | Yes | |
| instructions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the meaningful constraint that only *enabled* skills are returned and that the payload includes a resource index, but it says nothing about failure behavior for missing or disabled slugs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with zero filler, front-loaded with the action and the two things returned. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool with full annotations, complete schema coverage, and an output schema covering the return shape, the description is sufficient. Only the not-found/disabled-slug behavior is left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a single, fully documented slug parameter (pattern, length bounds, meaning), so the schema does the heavy lifting. The description adds only the 'enabled' qualifier, which is marginal beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Return') and resource ('SKILL.md and its supporting resource index') plus the lookup key ('by slug'). It is clearly distinct from list_skills and get_skill_resource, though it never explicitly contrasts itself with those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer you call this to fetch a skill's content once you know its slug. No when-to-use condition, prerequisites, or alternative (e.g., get_skill_resource for individual files) is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one supporting file from an enabled Sutra skill by slug and path.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Relative resource path exactly as returned by get_skill. | |
| slug | Yes | Slug of the enabled skill that owns the resource. |
| Name | Required | Description |
|---|---|---|
| path | Yes | |
| content | Yes | |
| encoding | Yes | |
| size_bytes | Yes | |
| content_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds the 'enabled skill' precondition, which is useful, but says nothing about error behavior for missing slugs/paths or the resource size limits beyond the 300-char path constraint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler. Everything an agent needs for a first-pass read is present and nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and annotations carry the safety profile. The description covers purpose and the enabled-skill precondition, but a brief note on the get_skill dependency for obtaining the path would have made it fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented, including the important detail that path must match what get_skill returned. The description only names slug and path without adding format, constraint, or dependency detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Return') and resource ('one supporting file from an enabled Sutra skill'), which cleanly separates it from the sibling get_skill that returns the skill itself. It does not name a sibling explicitly, so it falls short of the 5 tier, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a prerequisite ('enabled' skill) but gives no explicit when-to-use guidance, no when-not-to-use, and no reference to the alternative get_skill for retrieving the skill definition itself. The agent must infer that it should call get_skill first to discover the path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return project cluster names, descriptions, and memory counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| clusters | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, covering the whole safety profile. The description adds no behavioral context beyond that (no scope limits, pagination, or ordering), and the returned fields it names are already covered by the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; verb, resource, and payload are all present in one clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema defining the return shape, rich read-only annotations, and no parameters, the description covers what an agent needs to call it. It could be slightly stronger by noting that the listing is unfiltered/all clusters, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline for a parameterless tool is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list/return) and resource (project clusters) plus the fields returned (names, descriptions, memory counts), so the agent knows exactly what the tool produces. It does not explicitly contrast with the sibling get_cluster (single-cluster retrieval), so differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this versus get_cluster or the other list_* siblings, nor any stated prerequisites. Usage is only implied by the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return metadata for reusable skills the user has enabled in Sutra.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| skills | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is fully covered elsewhere. The description adds one piece of genuine context – that only enabled skills are returned, not all skills – which is meaningful but modest given no parameters and a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. The scope qualifier ('enabled in Sutra') is placed where it will be read first, and nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, full annotation coverage, and an output schema that defines the return shape, the description need only state what is listed. It does so adequately, though it could note that skills are returned as metadata objects rather than full content (contrasting with get_skill).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline of 4 applies. Nothing in the description is needed to clarify parameter usage, and it introduces no misleading parameter implications.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Return metadata') and resource ('reusable skills') with a clear scope qualifier ('the user has enabled in Sutra'). It does not explicitly distinguish itself from the sibling get_skill, but the plural/collection framing makes the distinction reasonably inferable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like get_skill or get_skill_resource. The 'enabled' qualifier implies a filtered listing but the description never states when this is the right call or what it excludes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the user's shared identity context, project clusters, and memories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| clusters | Yes | |
| memories | Yes | |
| display_name | Yes | |
| last_updated | Yes | |
| total_memory_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured fields. The description adds the content scope (identity context, clusters, memories) but says nothing about size, caching, or freshness of the returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. Every word contributes to describing the return scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value detail need not be in the description, and the annotations carry the safety profile. The one gap is the absence of any routing guidance versus the many sibling read tools, but as a parameterless aggregate read it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline is 4 per the rubric. The description correctly implies a parameterless, scope-free read, matching the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb (return/read) and resource (shared identity context, project clusters, memories), which is clearer than the bare tool name. It does not, however, differentiate itself from siblings like get_cluster or search_memory, though the scope (aggregate context) is implied to be broader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no mention of alternatives such as search_memory or get_cluster. The agent must infer that this is a bulk/aggregate retrieval versus the more targeted sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return memories matching case-insensitive keywords and optional cluster filters.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Short, specific keywords describing the memories to find. | |
| top_k | No | Maximum number of matching memories to return. | |
| cluster | No | Optional cluster name to restrict the search. |
| Name | Required | Description |
|---|---|---|
| memories | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so safety is covered. The description adds the useful behavioral detail that matching is case-insensitive, but says nothing about ranking, relevance, or how results are ordered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero waste. The core action and its modifiers are stated immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and annotations cover the safety profile. The only real gap is routing guidance versus sibling retrieval tools, which is minor for a straightforward search.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents query, top_k, and cluster. The description restates keywords and cluster filters without adding format or syntax meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (return/search) and resource (memories) with scope detail (case-insensitive keywords, cluster filters). This distinguishes it from read-only siblings like get_cluster or list_clusters, though it doesn't explicitly name an alternative search path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this over alternatives such as read_context or get_cluster, nor any prerequisites or exclusions. The agent must infer the search-vs-fetch distinction from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a user-authorized SKILL.md and optional text resources in a disabled state.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Human-readable skill name containing at least one letter or number. | |
| skill_md | Yes | Complete UTF-8 SKILL.md text with YAML frontmatter; maximum encoded size is 256 KB. | |
| resources | No | Optional map of up to 50 relative file paths to UTF-8 text contents; total upload limit is 512 KB. | |
| description | No | Optional short description of the skill's purpose. |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| message | Yes | |
| version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds two genuinely non-structured facts: the input must be user-authorized (an auth precondition) and the upload lands 'in a disabled state' (not immediately active). That extra behavioral context is valuable and above the annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the verb first and no filler. Every word carries meaning and nothing needs trimming.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and annotations carry the safety profile. The description covers the input material and the resulting disabled state, which is enough to call it correctly; only edge behavior (duplicate names, overwrite handling) is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents name, skill_md, resources, and description with constraints (size limits, path map, maxProperties). The description mentions SKILL.md and text resources but adds no syntax, format, or default detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (upload) and resource (a user-authorized SKILL.md plus optional text resources) with a clear end state (disabled). It is easy to distinguish from read-side siblings like get_skill and list_skills, though it does not explicitly name an alternative. Clear but no sibling differentiation by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no conditions for choosing this over siblings, and no exclusions. 'User-authorized' hints at a precondition but the agent is left to infer usage entirely from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a user-authorized preference, decision, correction, pattern, or project fact.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional search tags; at most 10 tags, each no longer than 30 characters. | |
| cluster | No | Destination cluster name using letters, numbers, or hyphens. | general |
| content | Yes | The preference, decision, correction, working pattern, or project fact to remember. | |
| importance | No | Memory importance from 1 (low) to 5 (critical); use 3 by default. |
| Name | Required | Description |
|---|---|---|
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the agent knows this is a non-destructive but non-idempotent write. The description adds the user-authorization constraint, which is useful, but says nothing about duplicate handling, whether existing memories are modified, or how the target cluster affects storage — notable given idempotentHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with the action front-loaded and zero filler. It is well-sized for the tool, though the brevity leaves room that could have carried useful behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be described, and the annotations carry the safety profile. Still, for a memory-writing tool whose effects persist across the workspace/cluster model, the description is thin on what a saved observation affects and how the cluster and importance parameters shape the outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so tags, cluster, content, and importance are all fully documented in the schema. The description's enumeration of savable content types roughly mirrors the content parameter and adds no additional syntax, format, or constraint detail, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ("Save") and enumerates the resource types being persisted (preference, decision, correction, pattern, project fact), so the tool's role is legible at a glance. It is distinguishable from the read-oriented siblings (search_memory, read_context), though it never names the "observation" resource the title uses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "user-authorized" is a meaningful gating condition, implying the agent should only persist content the user has endorsed. However, there is no explicit when-to-use versus alternatives guidance and no statement of prerequisites, so usage is only implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_skill1 field changedInput schema / properties / slug / descriptionPrevious value: -"Slug of an enabled skill, usually obtained from list_skills."New value: +"Slug identifying the enabled skill to return."export_all3 fields changedOutput schema / additionalPropertiesRemoved value: -trueOutput schema / propertiesAdded value: +{
+ "clusters": {
+ "items": {
+ "properties": {
+ "created_at": {
+ "type": "string"
+ },
+ "description": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "is_default": {
+ "type": "boolean"
+ },
+ "memories": {
+ "items": {
+ "properties": {
+ "cluster": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "content": {
+ "type": "string"
+ },
+ "created_at": {
+ "type": "string"
+ },
+ "importance": {
+ "type": "integer"
+ },
+ "source_agent": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "content",
+ "source_agent",
+ "importance",
+ "created_at",
+ "tags"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "memory_count": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "description",
+ "is_default",
+ "created_at",
+ "memory_count",
+ "memories"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "exported_at": {
+ "type": "string"
+ },
+ "total_memory_count": {
+ "type": "integer"
+ }
+}Output schema / requiredAdded value: +[
+ "exported_at",
+ "total_memory_count",
+ "clusters"
+]get_cluster8 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum number of memories to return from the cluster."Input schema / properties / name / descriptionAdded value: +"Exact cluster name using letters, numbers, or hyphens."Input schema / properties / name / maxLengthAdded value: +50Input schema / properties / name / minLengthAdded value: +1Input schema / properties / name / patternAdded value: +"^[A-Za-z0-9-]{1,50}$"Output schema / additionalPropertiesRemoved value: -trueOutput schema / propertiesAdded value: +{
+ "cluster": {
+ "properties": {
+ "created_at": {
+ "type": "string"
+ },
+ "description": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "is_default": {
+ "type": "boolean"
+ },
+ "memory_count": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "description",
+ "is_default",
+ "created_at",
+ "memory_count"
+ ],
+ "type": "object"
+ },
+ "memories": {
+ "items": {
+ "properties": {
+ "cluster": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "content": {
+ "type": "string"
+ },
+ "created_at": {
+ "type": "string"
+ },
+ "importance": {
+ "type": "integer"
+ },
+ "source_agent": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "content",
+ "source_agent",
+ "importance",
+ "created_at",
+ "tags"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+}Output schema / requiredAdded value: +[
+ "cluster",
+ "memories"
+]get_skill7 fields changedInput schema / properties / slug / descriptionAdded value: +"Slug of an enabled skill, usually obtained from list_skills."Input schema / properties / slug / maxLengthAdded value: +100Input schema / properties / slug / minLengthAdded value: +1Input schema / properties / slug / patternAdded value: +"^[a-z0-9]+(?:-[a-z0-9]+)*$"Output schema / additionalPropertiesRemoved value: -trueOutput schema / propertiesAdded value: +{
+ "instructions": {
+ "type": "string"
+ },
+ "resources": {
+ "items": {
+ "properties": {
+ "content_type": {
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ },
+ "size_bytes": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "path",
+ "content_type",
+ "size_bytes"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "skill": {
+ "properties": {
+ "created_at": {
+ "type": "string"
+ },
+ "description": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "file_count": {
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "source_agent": {
+ "type": "string"
+ },
+ "total_bytes": {
+ "type": "integer"
+ },
+ "version": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "slug",
+ "name",
+ "description",
+ "version",
+ "source_agent",
+ "file_count",
+ "total_bytes",
+ "created_at"
+ ],
+ "type": "object"
+ }
+}Output schema / requiredAdded value: +[
+ "skill",
+ "instructions",
+ "resources"
+]get_skill_resource10 fields changedInput schema / properties / path / descriptionAdded value: +"Relative resource path exactly as returned by get_skill."Input schema / properties / path / maxLengthAdded value: +300Input schema / properties / path / minLengthAdded value: +1Input schema / properties / slug / descriptionAdded value: +"Slug of the enabled skill that owns the resource."Input schema / properties / slug / maxLengthAdded value: +100Input schema / properties / slug / minLengthAdded value: +1Input schema / properties / slug / patternAdded value: +"^[a-z0-9]+(?:-[a-z0-9]+)*$"Output schema / additionalPropertiesRemoved value: -trueOutput schema / propertiesAdded value: +{
+ "content": {
+ "type": "string"
+ },
+ "content_type": {
+ "type": "string"
+ },
+ "encoding": {
+ "enum": [
+ "utf-8",
+ "base64"
+ ],
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ },
+ "size_bytes": {
+ "type": "integer"
+ }
+}Output schema / requiredAdded value: +[
+ "path",
+ "content_type",
+ "size_bytes",
+ "encoding",
+ "content"
+]list_clusters3 fields changedOutput schema / additionalPropertiesRemoved value: -trueOutput schema / propertiesAdded value: +{
+ "clusters": {
+ "items": {
+ "properties": {
+ "created_at": {
+ "type": "string"
+ },
+ "description": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "is_default": {
+ "type": "boolean"
+ },
+ "memory_count": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "description",
+ "is_default",
+ "created_at",
+ "memory_count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+}Output schema / requiredAdded value: +[
+ "clusters"
+]list_skills3 fields changedOutput schema / additionalPropertiesRemoved value: -trueOutput schema / propertiesAdded value: +{
+ "skills": {
+ "items": {
+ "properties": {
+ "created_at": {
+ "type": "string"
+ },
+ "description": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "file_count": {
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "source_agent": {
+ "type": "string"
+ },
+ "total_bytes": {
+ "type": "integer"
+ },
+ "version": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "slug",
+ "name",
+ "description",
+ "version",
+ "source_agent",
+ "file_count",
+ "total_bytes",
+ "created_at"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+}Output schema / requiredAdded value: +[
+ "skills"
+]read_context3 fields changedOutput schema / additionalPropertiesRemoved value: -trueOutput schema / propertiesAdded value: +{
+ "clusters": {
+ "items": {
+ "properties": {
+ "created_at": {
+ "type": "string"
+ },
+ "description": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "is_default": {
+ "type": "boolean"
+ },
+ "memory_count": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "description",
+ "is_default",
+ "created_at",
+ "memory_count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "display_name": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "last_updated": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "memories": {
+ "items": {
+ "properties": {
+ "cluster": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "content": {
+ "type": "string"
+ },
+ "created_at": {
+ "type": "string"
+ },
+ "importance": {
+ "type": "integer"
+ },
+ "source_agent": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "content",
+ "source_agent",
+ "importance",
+ "created_at",
+ "tags"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total_memory_count": {
+ "type": "integer"
+ }
+}Output schema / requiredAdded value: +[
+ "display_name",
+ "clusters",
+ "memories",
+ "total_memory_count",
+ "last_updated"
+]search_memory9 fields changedInput schema / properties / cluster / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 50,
+ "minLength": 1,
+ "pattern": "^[A-Za-z0-9-]{1,50}$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / cluster / descriptionAdded value: +"Optional cluster name to restrict the search."Input schema / properties / query / descriptionAdded value: +"Short, specific keywords describing the memories to find."Input schema / properties / query / maxLengthAdded value: +2000Input schema / properties / query / minLengthAdded value: +1Input schema / properties / top_k / descriptionAdded value: +"Maximum number of matching memories to return."Output schema / additionalPropertiesRemoved value: -trueOutput schema / propertiesAdded value: +{
+ "memories": {
+ "items": {
+ "properties": {
+ "cluster": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "content": {
+ "type": "string"
+ },
+ "created_at": {
+ "type": "string"
+ },
+ "importance": {
+ "type": "integer"
+ },
+ "source_agent": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "content",
+ "source_agent",
+ "importance",
+ "created_at",
+ "tags"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+}Output schema / requiredAdded value: +[
+ "memories"
+]upload_skill12 fields changedInput schema / properties / description / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 500,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / description / descriptionAdded value: +"Optional short description of the skill's purpose."Input schema / properties / name / descriptionAdded value: +"Human-readable skill name containing at least one letter or number."Input schema / properties / name / maxLengthAdded value: +80Input schema / properties / name / minLengthAdded value: +1Input schema / properties / resources / anyOfPrevious value: -[
- {
- "additionalProperties": {
- "type": "string"
- },
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "maxProperties": 50,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / resources / descriptionAdded value: +"Optional map of up to 50 relative file paths to UTF-8 text contents; total upload limit is 512 KB."Input schema / properties / skill_md / descriptionAdded value: +"Complete UTF-8 SKILL.md text with YAML frontmatter; maximum encoded size is 256 KB."Input schema / properties / skill_md / minLengthAdded value: +1Output schema / additionalPropertiesRemoved value: -trueOutput schema / propertiesAdded value: +{
+ "message": {
+ "type": "string"
+ },
+ "status": {
+ "const": "disabled",
+ "type": "string"
+ },
+ "version": {
+ "type": "integer"
+ }
+}Output schema / requiredAdded value: +[
+ "status",
+ "version",
+ "message"
+]write_observation12 fields changedInput schema / properties / cluster / descriptionAdded value: +"Destination cluster name using letters, numbers, or hyphens."Input schema / properties / cluster / maxLengthAdded value: +50Input schema / properties / cluster / minLengthAdded value: +1Input schema / properties / cluster / patternAdded value: +"^[A-Za-z0-9-]{1,50}$"Input schema / properties / content / descriptionAdded value: +"The preference, decision, correction, working pattern, or project fact to remember."Input schema / properties / content / maxLengthAdded value: +2000Input schema / properties / content / minLengthAdded value: +1Input schema / properties / importance / descriptionAdded value: +"Memory importance from 1 (low) to 5 (critical); use 3 by default."Input schema / properties / tags / descriptionAdded value: +"Optional search tags; at most 10 tags, each no longer than 30 characters."Output schema / additionalPropertiesRemoved value: -trueOutput schema / propertiesAdded value: +{
+ "status": {
+ "enum": [
+ "saved",
+ "duplicate"
+ ],
+ "type": "string"
+ }
+}Output schema / requiredAdded value: +[
+ "status"
+]export_allget_clusterget_skillget_skill_resourcelist_clusterslist_skillsread_contextsearch_memoryupload_skillwrite_observation
Add one secure layer between your agents and this server.