Read-only MCP for Electrik Slate: Blade component docs, blocks gallery, source, and llms.txt.
Fetch markdown documentation for a Slate component (e.g. button, dialog, input).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Component slug, e.g. button, alert-dialog, dark-mode-toggle |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it fetches markdown documentation (a read operation), but does not mention error behavior (e.g., missing component), rate limits, or other constraints. It adds only a minimal behavioral profile.
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?
Single sentence, front-loaded with the key action and resource, and includes a relevant example list. No wasted words.
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 one-parameter fetch tool, the description adequately covers purpose and parameter. No output schema exists, but the return type (markdown docs) is stated. It lacks error-handling or edge-case notes, but the simplicity of the tool keeps it mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter 'name' is well-documented with examples. The description repeats the same examples (button, dialog, input) without adding new meaning beyond the schema. 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 the verb 'Fetch' and the resource 'markdown documentation for a Slate component'. It distinguishes itself from siblings like get_component_source (source code) and get_docs_page (generic docs) by specifying the component doc target with examples.
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 (use for Slate component docs) but does not explicitly contrast with sibling tools or state when not to use. It implies usage by mentioning component names, but lacks explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the primary Blade source for a Slate component from the 3.x GitHub branch.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Component slug, e.g. button, dialog, toaster |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions fetching from a specific branch, but does not disclose output format, error behavior, or potential network/rate-limit considerations. Some context is added, but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that immediately conveys the action, target, and branch. Every word earns its place with no unnecessary filler.
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 tool with one parameter and no output schema, the description is sufficiently complete. It specifies what is fetched and from where, which is enough to guide 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 schema already fully describes the single parameter 'name' with examples. The description adds no additional semantic detail beyond what is in the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and clearly identifies the resource: 'primary Blade source for a Slate component from the 3.x GitHub branch.' This distinguishes it from sibling tools like get_component_docs and list_components.
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 context of fetching source is clear, but there is no explicit guidance on when to use this tool instead of get_component_docs or others. The distinction is implied by the term 'source' but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a docs markdown page by path (e.g. getting-started/installation, livewire, ai).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Docs path without leading docs/, e.g. getting-started/installation or design-tokens |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It states the tool fetches a markdown page, implying a read-only operationcolare. However, it does not mention potential error conditions (e.g., 404), return format specifics, or any prerequisites. For a simple read tool, this minimal disclosure is adequate but not thorough.
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 extremely concise, two phrases, front-loaded with the core action and path format examples. No wasted words.
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's simplicity, one parameter, no output schema, and full parameter documentation, the description is adequate. It could mention that the response is markdown content, but it's not critical for selecting this tool. A slight gap but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of the parameter, so the parameter already has full documentation. The description adds only examples but no extra semantic nuance, so a 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 clearly states the verb ('Fetch') and the resource ('a docs markdown page'), with concrete path examples (getting-started/installation, livewire, ai). It is easily distinguished from sibling tools like list_components or get_component_docs, which handle different kinds of content.
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 a clear action and example paths, but it does not explicitly state when to use this tool versus alternatives like get_component_docs or get_source. While the purpose implies usage for documentation pages, explicit guidance on exclusions or alternatives is missing, making it adequate but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch https://slate.electrik.dev/llms.txt — the curated AI index for Slate.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral transparency burden. Although 'Fetch' implies a read-only GET operation, it does not explicitly state side-effect freedom, potential errors, rate limits, or the nature of the response. The description lacks details about what the tool actually does beyond the URL.
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 a single concise sentence that communicates the essential action and resource. There is no fluff or redundancy, making it highly efficient.
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 is brief and mentions that the resource is a curated AI index for Slate, but it lacks context about the index's purpose, content structure, or expected output. Since there is no output schema, the description should offer more insight into what the tool returns, which it does not. This leaves some gaps in completeness.
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, so the schema fully covers parameter semantics. The description adds no parameter-related information, but none is needed. According to the baseline rule for 0 parameters, the score is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a specific URL and identifies it as a curated AI index for Slate. It distinguishes from sibling tools that focus on components or docs. However, it does not explain what 'Slate' is, leaving some ambiguity about the resource's context.
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 no guidance on when to use this tool versus alternatives. It does not mention scenarios where fetching the index is preferred, nor does it indicate any prerequisites or fallback options. This leaves the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List electrik/slate-blocks (curated Blade sections on the docs gallery).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It conveys that this is a non-mutating 'List' operation and adds domain context, but it does not mention anything about response shape, ordering, or whether the listing is complete or paginated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence which states the action, target, and clarifying context without any filler. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument listing tool, the description is nearly complete. It could add a little more detail about what output the caller should expect, such as a list of block names or paths, but the current wording conveys the core intent adequately.
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, so there are no parameter semantics for the description to explain. The schema already confirms the empty parameter set, and the baseline for a zero-parameter tool is appropriately strong.
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 ('List') and resource ('electrik/slate-blocks'), and clarifies what that resource is with the parenthetical 'curated Blade sections on the docs gallery'. This makes the tool's purpose immediately clear and distinguishes it from the component-oriented siblings like list_components.
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 for when to use the tool: when listing curated Blade sections from the docs gallery. It does not explicitly exclude alternatives or name when-not-to-use conditions, but for a simple zero-parameter list tool the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List shipped Electrik Slate Blade components with docs URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions 'with docs URLs' which implies the output includes URLs, but it does not disclose other behaviors like read-only safety, pagination, or whether internal components are excluded. For a simple list tool, this is minimal but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded verb, zero filler. Perfectly concise and to the point.
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 tool with no parameters and no output schema, the description fully covers its purpose and the key output detail (docs URLs). It is a simple list operation and nothing more is needed.
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?
Tool has zero parameters, and schema coverage is 100% (trivially). The description does not need to explain parameters, and the baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'List' and resource 'shipped Electrik Slate Blade components' with an additional detail about docs URLs. This distinguishes it from siblings like get_component_docs and get_component_source, which focus on individual components rather than a list.
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 purpose implies when to use it (to obtain a list of all components), which is clear context. However, it does not explicitly mention when not to use it or suggest alternatives, such as using get_component_docs for detailed documentation of a specific component.
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.
get_component_docsget_component_sourceget_docs_pageget_llms_indexlist_blockslist_componentsClaiming 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!
Public read-only MCP for products, frameworks, guides, methodology, and blog metadata.
Read-only MCP connector serving the Run It on AI book; index and Implementation Blocks are free.
Read-only MCP server for Flamel.ai's public content: company overview, blog, case studies, FAQs.
Read-only MCP for identity resolution and write guardrails.
Add one secure layer between your agents and this server.
Most tools are clearly distinct: component docs, component source, docs pages, and index browsing each target a specific need. The only potential confusion is between get_component_docs and get_docs_page, since component docs are a subset of docs pages, but the descriptions clarify the intended usage.
All tool names follow a consistent verb_noun pattern (get_* and list_*), with clear and predictable object nouns. This makes it easy to infer what each tool does before reading its description.
Six tools is well-scoped for a documentation and component lookup server. Each tool covers a distinct need—listing, fetching docs, fetching source, and browsing pages—without unnecessary duplication.
The core workflows of exploring components, fetching component docs, and retrieving source code are well covered. A minor gap is that blocks can only be listed, with no corresponding block detail or source tool, and there is no search capability beyond the llms.txt index.
