Search, install and submit Markdown skills for AI agents; private Brain files when signed in.
Read one Brain file by name (e.g. coding-conventions.md), across your brains and brains shared with you. Needs your agent bearer token.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | File name including .md | |
| brain | No | Optional brain to read from (owner-handle/name for shared brains). Omit to search all your brains. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the operation type ('Read'), the scope ('across your brains and brains shared with you'), and the auth requirement ('Needs your agent bearer token'). It does not mention potential ambiguity when the same file name exists in multiple brains, but for a simple read it is fairly transparent.
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 action and example are front-loaded, and the auth note is one short clause. Every sentence contributes a distinct piece of 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 two-parameter read tool with no output schema and no annotations, the description covers what it does, the scope, and required auth. It lacks details on return format or error behavior, but these are not essential to selecting and invoking the 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?
Schema description coverage is 100%, so the schema already documents both 'name' and 'brain'. The description adds a concrete file-name example and clarifies scope across shared brains, but this is modest added value beyond the structured 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 uses a specific verb ('Read'), a clear resource ('one Brain file by name'), and a concrete example ('coding-conventions.md'). It differentiates from siblings by emphasizing exact-name lookup rather than listing or searching, so an agent can tell it apart from brain_list and brain_search.
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 the tool is for reading a known file name across all accessible brains, and mentions the auth requirement. However, it does not explicitly state when to prefer this over brain_search or brain_list, nor does it describe exclusions or prerequisites beyond the token.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the files in your Brains (named sets of private Markdown memory), including brains shared with you. Needs your agent bearer token. Returns the brain, your role in it, name, folder, size, whether the file is in the agent context and shared with members, and when it changed.
| Name | Required | Description | Default |
|---|---|---|---|
| brain | No | Optional brain name; for a brain shared with you, owner-handle/name (e.g. jan/Team). Omit to list every brain. | |
| folder | No | Optional folder filter, e.g. Engineering. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the authentication requirement and enumerates the complete return field list (brain, role, name, folder, size, context membership, sharing status, change time). The read-only nature is implied by 'List'. It omits potential pagination/limit behavior but covers the essentials.
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, front-loaded with the primary action and scope, followed by the auth and response details. Every clause carries information; there is no filler or repetition of schema content.
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?
Although there is no output schema, the description explains what a Brain is, defines the list scope, states the auth requirement, and enumerates the returned fields. For a simple, zero-required-parameter listing tool, this is sufficient for correct invocation and interpretation of results.
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 both optional parameters (brain and folder) with format examples. The description adds no parameter-specific detail beyond the schema; the 'shared with you' mention echoes the schema's owner-handle/name format. 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 uses a specific verb and resource: 'List the files in your Brains', and further clarifies scope with 'including brains shared with you'. This clearly differentiates it from siblings like brain_get (single-item retrieval), brain_search (query), and brain_write (mutation) without needing to open 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?
The description provides clear usage context (listing files in personal and shared brains) and a key prerequisite (bearer token). It doesn't explicitly name alternatives or exclusion conditions, but the purpose is specific enough that an agent can infer when to choose this over a search/get/write tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this BEFORE answering anything about the user's own context — their projects, conventions, decisions, people, infrastructure, past work. Searches the user's Brain files (their brains plus those shared with them); every word of the query is matched on its own, case-insensitively, and files are ranked by how many words hit. Returns the matching files with the surrounding lines so you can decide what to brain_get. Needs a signed-in user.
| Name | Required | Description | Default |
|---|---|---|---|
| brain | No | Optional brain to search (owner-handle/name for shared brains). Omit to search all. | |
| query | Yes | Keywords to look for; each word is matched on its own, case-insensitively. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and it does well: it discloses word-by-word case-insensitive matching, ranking by hit count, return of surrounding lines, scope over owned/shared brains, and a signed-in user requirement. It omits failure modes and limits, but the behavioral detail is well above average.
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 front-loaded with the critical 'use before' guidance, then gives matching semantics, result shape, and a dependency in three compact sentences. Every sentence earns its place with no filler or repetition.
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 two-parameter search tool with no output schema, the description covers the trigger condition, scope, ranking behavior, return format, and authentication prerequisite. It does not mention pagination or limits, but nothing essential is missing for a simple search call.
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 baseline is 3. The description reinforces the query matching behavior but adds little beyond the schema's own parameter descriptions; the brain parameter also repeats what the schema already states. No harmful gaps, but no notable value added beyond the structured data.
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 resource: it searches the user's Brain files, including shared brains. It also distinguishes itself from brain_get by positioning search as the step that lets the agent decide what to retrieve. The resource is clear enough to separate it from sibling tools like search_skills.
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 'BEFORE answering anything about the user's own context' and lists concrete categories such as projects, conventions, decisions, people, infrastructure, and past work. It does not name alternative tools for exclusions, but the when-to-use guidance is strong and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update a Brain file. Writes to your default brain unless you name one; shared brains need editor access. Replaces the whole body (use mode "append" to add to the end); the previous body is kept as a version. Credentials are refused — the Brain is memory, not a vault. Needs your agent bearer token.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Markdown content. | |
| mode | No | replace (default) or append. | |
| name | Yes | File name ending in .md, e.g. customer-faq.md | |
| brain | No | Brain to write into (owner-handle/name for shared brains, needs editor access). Omit for your default brain. | |
| folder | No | Folder, e.g. Company. New files default to "Agent". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so impressively. It discloses that the whole body is replaced, the previous body is kept as a version, credentials are refused, bearer token auth is required, and editor access is needed for shared brains.
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?
Four dense sentences, each earning its place: purpose, default targeting and permissions, replacement/append semantics, and security. No filler or redundancy, and the most important behavioral 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?
For a write tool with no output schema, the description is complete: target selection, access prerequisites, mode behavior, versioning, and auth are all covered. An agent has enough to invoke the tool correctly without needing to open the schema.
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 baseline is 3. The description adds meaningful semantics beyond the schema: the default-brain behavior when 'brain' is omitted, the access requirement for shared brains, and the version-retention consequence of replace mode. This goes beyond simple restatement.
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-resource pair, 'Create or update a Brain file,' which clearly identifies the tool's function. It is immediately distinguishable from the read/search siblings like brain_get, brain_list, and brain_search.
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 provides clear usage context: writes to the default brain unless another is named, shared brains need editor access, and mode 'append' adds to the end while the default replaces. It doesn't explicitly contrast against read tools or say when not to use it, but the sibling names make the primary distinction obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Curated bundles of skills. Without an argument: list the available collections (slug, name, size). With a slug: the skills in that collection, in order — then call install_skill for each one the user wants (usually all).
| Name | Required | Description | Default |
|---|---|---|---|
| collection | No | Collection slug, e.g. laravel-starter. Omit to list all collections. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does well by explaining the no-argument vs. slug behavior and that skills are returned in order. It also implies this is a read-only lookup by instructing the agent to call install_skill separately for installation. It does not mention error behavior or edge cases, but for a simple get/list tool the core behavior is transparent.
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, front-loads the core concept, and uses a clear branching structure for the optional argument. Every phrase earns its place, including the practical 'usually all' guidance for follow-up installation.
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?
Since there is no output schema, the description adequately describes return content: collection lists include slug, name, and size; slug queries return ordered skills. It also provides the next logical action (install_skill). It could mention invalid-slug behavior or the full shape of a skill entry, but those are minor gaps for a tool this simple.
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%: the schema already documents the collection slug and that omitting it lists all collections. The description reinforces this behavior and adds the 'in order' detail for the resulting skills, but it does not significantly expand the parameter meaning beyond what the schema already provides.
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 specifies two concrete behaviors: listing all collections when no argument is given, and returning the ordered skills in a collection when a slug is given. This clearly identifies the tool's resource (skill collections) and distinguishes it from sibling tools like get_skill or search_skills.
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 clear conditional guidance: omit the argument to list collections, or pass a slug to view its skills. It also tells the agent to follow up with install_skill for each desired skill, which is strong usage direction. It does not explicitly contrast with get_skill or search_skills, so it misses full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a skill's Markdown to inspect it (does not install anything). To install, call install_skill — it returns the file plus the exact path to write it to. Pass version to pin one.
| Name | Required | Description | Default |
|---|---|---|---|
| skill | Yes | owner/name, e.g. opsmith/jira-ticket-scorer | |
| version | No | Pin a version number; omit for latest. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the full burden and does well by disclosing the read-only nature ('Read', 'does not install anything') and implying return content (the skill's Markdown). It does not describe error cases or invalid-version handling, which keeps it a step below 5.
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 with no wasted words: the core action is front-loaded, the safety distinction from install_skill is immediate, and the version note is included naturally. Each sentence contributes to correct tool selection or 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 simple two-parameter read tool, all needed context is present: what it reads, what it does not do, when to use the sibling instead, and how the version parameter behaves. The absence of an output schema is adequately addressed by the description's indication that the result is the skill's Markdown.
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 both the skill identifier format and the optional version pinning. The description restates the version pinning but adds no new semantic detail beyond what the schema provides, matching the baseline of 3.
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 and resource: reads a skill's Markdown for inspection. It clearly distinguishes itself from install_skill by explicitly noting that it does not install anything, so an agent can tell the tools apart 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?
Explicitly names install_skill as the alternative and the condition for choosing it ('To install'), including what install_skill returns. This leaves no ambiguity about when to use get_skill versus its sibling. Version usage is also briefly addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install a skill into the agent you are running in. Returns the complete skill file and the exact path to write it to — YOU must then create that file verbatim (Claude Code: .claude/skills//SKILL.md, so it becomes available as /; other agents: ./skills/.md) and tell the user where it is. Counts the install. Use target=hermes for Hermes Agent, target=generic for any other agent, scope=user to install for all Claude Code projects. When emdly agent hosting is enabled and you have a hosted agent, pass agent= to install there instead.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | No | Hosted agent name (only when emdly agent hosting is enabled and you have one). | |
| scope | No | Claude Code only: project (default, .claude/skills in the current project) or user (~/.claude/skills, every project). | |
| skill | Yes | owner/name, e.g. opsmith/jira-ticket-scorer | |
| target | No | Where the file goes: claude-code (default) → .claude/skills/<name>/SKILL.md; hermes → ~/.hermes/skills/<category>/<name>/SKILL.md; generic → ./skills/<name>.md. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the full burden, and it discloses a crucial non-obvious behavior: the tool does not write the file itself — 'YOU must then create that file verbatim.' It also reveals the side effect 'Counts the install' and specifies exact installation paths per target, which is more than most definitions provide.
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 dense but not bloated; every sentence contributes critical information. The core purpose is front-loaded, followed by the return contract and parameter routing. It is longer than average, but the complexity of the tool (multiple targets, follow-up write action) justifies the length.
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?
There is no output schema, so the description correctly explains return values (complete skill file and path) and the required post-call action. It covers all parameter scenarios and paths. Minor omissions like overwrite behavior, error cases, and more detail on 'Counts the install' prevent a 5.
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 baseline is 3. The description adds value by prescribing parameter choices for real-world scenarios: target=hermes, target=generic, scope=user for all projects, and agent= for hosted agents. This goes beyond the schema's field descriptions and helps the agent choose correct values.
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: 'Install a skill into the agent you are running in.' It goes on to describe the return contract (complete skill file and exact path) and the agent's required follow-up, which clearly distinguishes this from sibling tools like get_skill, search_skills, and submit_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?
The description provides explicit selection guidance for target ('Use target=hermes for Hermes Agent, target=generic for any other agent'), scope ('scope=user to install for all Claude Code projects'), and agent ('pass agent= to install there instead'). It does not explicitly contrast with alternative tools, but the parameter routing rules are concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this FIRST, before any non-trivial task, to find a ready-made skill in the emdly catalog (reviewed Markdown playbooks for AI agents). Query with 1–3 short keywords naming the kind of work (e.g. "code review", "jira", "seo audit"); words are matched independently, so a sentence works too. If the result is empty, retry with a single noun, or send an empty query for the top skills. Returns ranked skills with their owner/name id, category, description and install command.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 1–3 short keywords for the kind of work (each word is matched on its own against name, description, tags, category and author). Empty = the most popular skills. | |
| category | No | Optional category slug or name, e.g. code-review. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the full behavioral burden and it does reveal meaningful semantics: words are matched independently, empty queries return top skills, and results are ranked with specific fields. It does not explicitly state side-effect-free behavior, but for a search tool this is not a critical omission.
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?
Four sentences, each carrying a distinct purpose: guidance, query tips, empty-result fallback, and return shape. No filler or repetition, and the most actionable instruction is placed first.
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 two-param search tool with no output schema, this description is complete. It tells the agent when to invoke it, how to query, how to recover from empty results, and what the response will contain, which is everything needed 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?
Schema coverage is 100%, giving a baseline of 3; the description adds value beyond the schema by giving example keywords, explaining independent matching, and advising empty-query fallback behavior. It doesn't discuss the optional category filter, but the schema already covers it well.
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 searches for ready-made skills in the emdly catalog, using a specific verb and resource. However, it does not explicitly distinguish itself from siblings like get_skill or brain_search, so it lacks the full sibling differentiation required for 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?
Strong situational guidance is provided ('Use this FIRST, before any non-trivial task') along with concrete query and retry instructions. It lacks explicit exclusions, such as 'When you already have a skill ID, use get_skill,' so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a skill to emdly for review (needs sign-in). Creates it under your account — or a new version if you already own one with this name — runs the automated checks and the AI safety scan, and queues it for a human reviewer. Nothing is published by this tool; you get the check results back. The body must be a complete Markdown skill with a title and a "## License" section (MIT recommended).
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Full Markdown: # title, when to use, rules, output format, ## License | |
| name | Yes | kebab-case skill name, unique within your account | |
| note | No | Release note when submitting a new version of an existing skill. | |
| category | No | Category name; required for a new skill. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does well. It explicitly discloses that the tool creates content under the account, may create a new version, runs automated checks and an AI safety scan, queues for human review, and does not publish anything.
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, front-loaded with the core purpose and prerequisite, then expanding into effects and requirements. There is no filler or redundant repetition of schema fields.
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 description covers prerequisites, side effects, and the fact that check results are returned, which is strong given there is no output schema. Still, it could clarify what happens if checks fail and give slightly more detail about the returned check results.
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 baseline is 3. The description adds meaningful context beyond the schema by explaining versioning behavior for existing names and emphasizing body requirements. This helps an agent understand how the name, body, and note parameters interact.
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 ('Submit a skill to emdly for review'), a clear resource, and the expected outcome. It also distinguishes this tool from siblings like install_skill and search_skills by emphasizing review-only submission rather than publishing or retrieval.
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 clear context: sign-in is required, a new version is created if the name already exists, and the body must be complete Markdown with a title and License section. It does not explicitly name alternatives or say when not to use this tool, but the review-focused wording makes the intended use fairly obvious.
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.
brain_search1 field changedInput schema / properties / query / descriptionPrevious value: -"Case-insensitive phrase to look for."New value: +"Keywords to look for; each word is matched on its own, case-insensitively."search_skills1 field changedInput schema / properties / query / descriptionPrevious value: -"Free-text search over name and description."New value: +"1–3 short keywords for the kind of work (each word is matched on its own against name, description, tags, category and author). Empty = the most popular skills."get_collectionbrain_getbrain_listbrain_searchbrain_writeget_skillinstall_skillsearch_skillssubmit_skillClaiming 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!
Search your team's shared AI-skill library, get install commands, and save skills from your agent.
Search & install 6,500+ AI agent skills from skills-hub.ai inside any MCP tool.
Find, inspect and install reviewed reusable AI-agent capabilities from superskill.sh.
Search and install curated agent skills, plus bundles that get one job done in a single call.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: brain_get/brain_list/brain_search/brain_write cover memory operations, while get_collection/get_skill/install_skill/search_skills/submit_skill handle skill discovery, retrieval, installation, and submission. No two tools overlap in function; even the search vs get pairs are distinct.
The brain_* prefix provides a consistent pattern for memory tools, but the skill tools use mixed conventions: get_collection, get_skill, install_skill, search_skills, submit_skill — no shared prefix or uniform verb_noun structure. This inconsistency is noticeable but each name is still readable.
With 9 tools covering two domains (memory and skills), the count is well-scoped. Each tool earns its place, and the number is within the ideal range for a focused server.
The brain tools cover list, get, search, and write, but lack an explicit delete operation. The skill tools cover search, get, install, submit, and collection listing, but no uninstall. These are minor gaps that agents can work around; the core workflows are complete.
