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.
Export all user memories as structured JSON for data portability.
Call only when the user explicitly requests a complete export or backup. This returns potentially sensitive data from every cluster; do not call it merely to answer a question, search memory, or inspect one cluster.
| 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 cover read-only, idempotent, non-destructive behavior. The description adds meaningful context: the exported data is potentially sensitive and spans every cluster, which is important behavioral information an agent should know before invoking. It does not contradict annotations.
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?
The description is two sentences, with the main purpose in the first sentence and usage guidance in the second. Every sentence contributes essential information, and there is no redundancy.
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?
The tool is simple (no parameters), annotations fully cover safety traits, and an output schema exists to define return values. The description covers invocation criteria, scope, and sensitivity, leaving no material gap for an agent to call it correctly.
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?
This tool has zero parameters, so the schema leaves nothing to document. The description appropriately focuses on invocation semantics rather than parameter details, matching the baseline for no-parameter tools.
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 uses a specific verb ('Export') and clearly identifies the resource ('all user memories') and format ('structured JSON'). It also states the purpose ('data portability'), which distinguishes this tool from sibling tools like search_memory or get_cluster.
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?
It explicitly states when to call ('only when the user explicitly requests a complete export or backup') and when not to call ('do not call it merely to answer a question, search memory, or inspect one cluster'). This gives the agent clear criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get memories and metadata for one known project cluster.
Use list_clusters first if the cluster name is unknown. Do not use this for a keyword search across clusters; use search_memory instead.
| 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, and destructiveHint, so the safety profile is covered. The description adds that this operates on a single known cluster with exact-name lookup, which is useful but not deep. It does not mention limit behavior, error handling, or response shape, but output schema reduces that burden.
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?
Two sentences, no filler. The main purpose is front-loaded, and the usage guidance is compact and actionable.
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 read-only lookup with two well-documented parameters and an output schema, the description covers the essential behavior and selection criteria. Nothing critical 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?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no extra parameter semantics beyond restating that the cluster name must be known, which is already implied by the schema's exact-match pattern.
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 uses a specific verb and resource: 'Get memories and metadata for one known project cluster.' It clearly differentiates this lookup tool from list_clusters (which lists clusters) and search_memory (which searches across clusters).
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 explicitly instructs to use list_clusters first when the name is unknown and warns against using this for keyword search, directing to search_memory instead. This is clear when-to-use and when-not-to-use guidance that references siblings directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load an enabled SKILL.md and its supporting resource index.
Use after list_skills identifies a relevant skill. Load individual resources with get_skill_resource only when the skill instructions require them.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Slug of an enabled skill, usually obtained from list_skills. |
| 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 the tool read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond annotations: it loads both the SKILL.md and its supporting resource index, only works on enabled skills, and clarifies that resources should not be loaded eagerly unless the skill instructions require them.
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?
The description is two sentences with no redundant wording. It front-loads the core action, then immediately provides the necessary sequencing and alternative-tool guidance.
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?
Given the tool has one well-documented parameter, strong safety annotations, an output schema, and a clear sibling distinction, the description is complete. An agent has everything needed to decide when and how to call this tool correctly.
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 schema already provides a complete description for the single parameter, slug, including format constraints and the hint that it usually comes from list_skills. The tool description adds no additional parameter-level meaning, so the baseline score of 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 action and object: 'Load an enabled SKILL.md and its supporting resource index.' It also distinguishes itself from the sibling get_skill_resource by noting that individual resources should be loaded separately only when instructions require them.
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 explicitly says to use this tool after list_skills identifies a relevant skill, and directs when to prefer get_skill_resource instead. This is clear, actionable usage guidance with a named alternative and a selection condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one supporting file from an enabled Sutra skill.
Use only for a path listed by get_skill and only when needed for the current task. Do not guess paths or load every resource preemptively.
| 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=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral constraints: the tool reads exactly one file, requires the skill to be enabled, and expects the path to come from get_skill. These are not visible in the annotations and help the agent anticipate failure modes.
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?
Three short sentences carry a complete and scannable message: what the tool does, when to use it, and what to avoid. No filler or repetition; the purpose is front-loaded.
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 read tool with two fully described parameters, an output schema, and annotations covering safety, the description covers the essential operational constraints (enabled skill, path from get_skill, single-file read, no preemptive use). Nothing critical is missing for correct invocation.
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 params (path and slug) are already documented accurately. The description reinforces the path parameter's origin ('exactly as returned by get_skill') but adds no new semantic detail beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Read one supporting file from an enabled Sutra skill.' It clearly distinguishes itself from sibling tools like get_skill (which lists paths) and upload_skill/write_observation (which write). The singular 'one' also differentiates it from bulk-loading tools.
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 explicitly says when to use the tool: 'only for a path listed by get_skill and only when needed for the current task.' It also provides exclusions: 'Do not guess paths or load every resource preemptively.' This gives clear decision guidance with reference to the alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List project clusters with descriptions and memory counts.
Use this to discover a cluster name before get_cluster. It does not return the memories stored inside each cluster.
| 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, and destructiveHint, so no contradiction exists. The description adds value beyond those by specifying the return scope: descriptions and memory counts, not the memories themselves. This helps the agent predict behavior and avoid a mistaken follow-up.
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?
The description is two sentences with no filler. The first sentence states the core function and output, and the second provides essential usage context and a limitation. Every sentence earns its place, and key information is front-loaded.
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?
Given the tool has no parameters, a rich annotation set, and an output schema, the description is sufficiently complete. It tells the agent what the tool returns, what it does not return, and when to use it relative to get_cluster. No critical information is missing for correct invocation.
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 has zero parameters, and the input schema confirms no arguments are needed. With 0 parameters, the baseline is 4, and the description does not need to explain parameter semantics. The description's focus on output and usage is 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 clearly states the tool's purpose: listing project clusters with descriptions and memory counts. It also distinguishes itself from get_cluster by explicitly noting it does not return the memories stored inside each cluster. This provides a specific verb and resource with clear differentiation from 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?
The description gives direct usage guidance: use this tool to discover a cluster name before calling get_cluster. It also explains a key limitation, that it does not return cluster contents, so an agent knows not to use it for retrieving stored memories. This is explicit, actionable context for selecting the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List reusable skills the user has explicitly enabled in Sutra.
Use this to discover an enabled skill slug before get_skill. It returns metadata, not the skill instructions or resource contents.
| 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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint). The description adds meaningful behavioral context by disclosing that the output is metadata only and excludes skill instructions and resource contents, which is not visible from the annotations alone and prevents an agent from expecting full content.
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?
Two sentences cover function, usage, and output scope with zero waste. The core purpose is front-loaded, and the second sentence adds only high-value routing and exclusion information.
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 parameterless listing tool with a rich output schema and clear annotations, the description provides everything an agent needs to call it correctly: what it lists, when to use it, and what it does not return. No important contextual gap is apparent.
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 has zero parameters and schema description coverage is 100%, so the schema leaves no ambiguity. The description has no parameter details to add; a baseline of 4 is appropriate since there is nothing for it to explain.
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 uses a specific verb ('List') and a well-defined resource ('reusable skills the user has explicitly enabled in Sutra'). It also differentiates the tool from siblings by stating it returns metadata, not skill instructions or resource contents, so an agent can immediately distinguish it from get_skill and get_skill_resource.
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?
'Use this to discover an enabled skill slug before get_skill' explicitly states the intended workflow and the relationship to an alternative. The clause about returning only metadata also implies when not to use this tool, giving an agent clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load the user's shared Sutra identity context.
Call this before answering broad questions about the user's preferences, history, projects, or prior decisions. The result can contain sensitive personal data, so use only the details needed to answer the user's current request. For a targeted lookup, use search_memory instead.
| 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 cover read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations: the result may contain sensitive personal data and advises using only needed details. This behavioral caution is useful and not redundant.
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?
The description is three sentences with no fluff: the primary action is front-loaded, usage guidance follows, and the alternative is named in the final sentence. Every sentence contributes to correct invocation.
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 zero-parameter read-only tool with an output schema, the description covers the essential operational context: what it returns, when to use it, its sensitivity implications, and when to use the sibling instead. Nothing critical 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 has zero parameters and schema coverage is 100% vacuously. Baseline for 0 params is 4, and the description appropriately avoids inventing parameter information. It offers no param semantics to add because there are none.
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 opens with a specific verb and resource: 'Load the user's shared Sutra identity context.' It clearly distinguishes itself from the targeted search_memory sibling by framing itself as the broad-context load, so an agent can select it correctly without opening schemas.
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?
Explicit when-to-use guidance is given: 'Call this before answering broad questions about the user's preferences, history, projects, or prior decisions.' It also states the alternative use case with search_memory, providing a clear selection boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for targeted memories using short, specific keywords.
This uses case-insensitive plain-text matching. For broad personal questions, call read_context first. If this returns no results, call read_context before concluding that nothing relevant is known. Do not use this to enumerate all user data; use export_all only when the user explicitly requests an export.
| 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 declare read-only and idempotent behavior, and the description adds non-obvious behavioral detail: case-insensitive plain-text matching and a fallback recommendation when no results are found. It does not discuss result ordering or error cases, but the output schema exists and the safety profile is already covered by annotations, so the additional context is valuable 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly packed sentences front-load the core purpose, then give matching behavior, and then provide exclusions and fallback guidance. There is no filler or redundant restatement of the title.
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?
The full parameter schema, output schema, annotations, and sibling routing together cover everything an agent needs to select and invoke this tool correctly. The only potential nuance (cluster scope) is already described in the schema, so no meaningful gap remains.
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 coverage is 100%, so the schema already documents all three parameters including descriptions for query, top_k, and cluster. The description mainly restates the 'short, specific keywords' guidance already present in the query parameter schema and adds no extra semantic detail beyond what is structured.
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 uses a specific verb and resource ('Search for targeted memories') and immediately clarifies the matching method ('case-insensitive plain-text matching'). It also distinguishes itself from siblings by explaining that read_context is for broad questions and export_all is for explicit exports, so an agent can differentiate the tools.
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 gives explicit when-to-use guidance: call read_context first for broad personal questions, call read_context if search returns no results before concluding nothing relevant is known, and avoid enumerating all user data with this tool, using export_all only on explicit user request. This is clear routing across alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a SKILL.md and optional text resources when the user explicitly asks.
Do not create or upload a skill based on inference or without clear authorization. The new version remains disabled until the user enables it in the dashboard.
| 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 mark this as a non-read-only, non-idempotent mutation. The description adds a key behavioral consequence not in metadata: 'The new version remains disabled until the user enables it in the dashboard.' This is useful, though it doesn't clarify whether an existing active skill is replaced immediately.
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?
Three sentences with no filler; the main action and condition are front-loaded, followed by a guardrail and a post-upload consequence. Each sentence adds distinct value.
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?
Given full schema descriptions and an output schema, the description covers the essential selection criteria (explicit user request), the authorization boundary, and the unexpected disabled-by-default state. It is complete enough for an agent to invoke the tool correctly; the destructiveHint=false annotation further implies existing versions remain intact.
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 name, skill_md, resources, and description. The description's mention of 'SKILL.md and optional text resources' aligns with those fields but adds no parameter details beyond the 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?
The description opens with 'Upload a SKILL.md and optional text resources,' which is a specific action and resource. It also adds the condition 'when the user explicitly asks,' making the tool's scope immediately distinct from sibling read/export tools like list_skills or get_skill.
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?
It states exactly when to use the tool: when the user explicitly asks, and explicitly forbids inference-based or unauthorized uploads. This gives an agent a clear go/no-go condition, even though it doesn't name sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save one durable memory only after the user clearly asks or agrees to save it.
Use for stable preferences, decisions, corrections, working patterns, or project facts. Do not store inferred traits, secrets, transient conversation, or information the user did not authorize Sutra to retain.
| 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 only indicate a non-read, non-idempotent, non-destructive write. The description adds meaningful behavior: it saves durable memory only after explicit user agreement and defines what must not be retained. This is substantive disclosure beyond the structured annotations.
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?
Three sentences with the most important constraint front-loaded and no wasted words. The consent requirement, content scope, and exclusions each have their own sentence, making it easy for an agent to parse.
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 four-parameter write tool with a rich input schema and output schema, the description covers the essential policy and safety context needed to invoke it correctly. It does not need to explain return values because the output schema exists.
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 content length, tags limits, cluster pattern, and importance range. The description mostly repeats the content categories already in the schema and adds little parameter-level detail.
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 opens with a precise action — save one durable memory — and clearly ties it to user consent. It lists concrete content categories (preferences, decisions, corrections, working patterns, project facts), and the write semantics distinguish it from the read/export sibling tools.
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?
It gives explicit positive use cases and even clearer negative cases (no inferred traits, secrets, transient conversation, unauthorized information), plus the consent precondition. It does not name a read/search sibling as the alternative when the desired information should not be stored, so the routing guidance is not fully explicit.
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. Dates show when Glama detected each change.
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_observationClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool has a clearly scoped purpose, and the descriptions include explicit usage rules that prevent overlap. Memory retrieval is split into read_context, search_memory, get_cluster, and export_all with distinct trigger conditions, so agents can reliably choose the right tool.
All tools use a consistent lower_snake_case verb_noun pattern such as list_clusters, get_skill, search_memory, write_observation, and upload_skill. The naming is predictable and uniform across the entire set.
Ten tools is well-scoped for a personal memory and skills server: it covers memory access, skill access, discovery, writing observations, and export. Each tool earns its place without the set feeling bloated or thin.
The server covers discovery, retrieval, saving observations, and uploading skills, but it lacks update/delete operations for memories and skill management beyond upload. This leaves a notable lifecycle gap: incorrect or obsolete saved observations cannot be removed or corrected in place.