@clikta/mcp-server

by rscoelho

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: navigation, recording control, interaction (click/type), annotation (note), capture (screenshot), and listing queries. There is no overlap or ambiguity between tool roles.
Naming Consistency5/5
All tools follow a consistent snake_case pattern, with verbs like start, finish, click, type, list, and screenshot. The clikta_ prefix unifies the namespace, and naming is predictable across the entire set.
Tool Count5/5
With 9 tools, the server is well-scoped for its purpose—recording browser sessions and generating guides. Each tool fills a necessary role in the workflow, with no clutter or redundancy.
Completeness4/5
The tool set covers the full lifecycle of creating a recording: start, navigate, interact, annotate, screenshot, and finish with publishing. Minor gaps exist, such as no update/delete for recordings, but these are not core to the stated purpose.
Average 4.2/5 across 9 of 9 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool captures the current page and saves to a library, and that it is ad-hoc. But it omits whether the screenshot captures the viewport or full page, any return value, or potential side effects beyond saving. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action and adds a clarifying parenthetical. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description conveys the main purpose and destination, but contextual gaps remain: the title parameter is undocumented, and behavior like viewport/full-page capture is unspecified. With no output schema or annotations, the description is sufficient for basic selection but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'title' is optional and has no schema description. The tool description never mentions the title parameter or its purpose, and schema coverage is 0%. The description does not compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Take an ad-hoc screenshot'), the target ('current page'), and the destination ('save it to the Clikta screenshot library'). It also differentiates from recording-related flows by explicitly noting it is not tied to a recording step, which distinguishes it from sibling automation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'ad-hoc' and 'not tied to a recording step' imply this tool is for standalone captures rather than screenshots embedded in recordings. However, no explicit alternatives or when-not-to-use scenarios are stated, leaving some ambiguity about when to prefer a recording-step screenshot.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that navigating will also log the action as a step, which is useful behavioral context. However, it does not mention prerequisites like whether an active recording must already exist, or what happens if navigation fails or times out.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the action, the scope, and the side effect in a compact manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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), the description covers the core action and logging side effect. However, it does not explicitly state the prerequisite of an active recording, which is important since sibling tools include start_recording and finish_recording. This prevents full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, 'url', with schema format 'uri' and no description. The tool description says 'to a URL', which confirms the url parameter's role as the navigation destination. This adds minimal semantic value beyond the schema, but with only one clearly-named parameter, it is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Navigate') with a clear resource ('the active recording's browser') and a specific target ('to a URL'), plus a consequence ('log it as a step'). This clearly differentiates it from sibling tools like click, type, or screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when the agent needs to navigate the active recording's browser to a URL. It does not explicitly name alternatives or state when not to use it, but the phrase 'active recording' and the action 'navigate' provide sufficient contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It adds that the action is 'logged as a step' and operates in the 'active recording's browser', which is useful. However, it omits potential side effects or failure modes (e.g., what happens if no recording is active or element not found).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. It conveys the core action, context, and side effect without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the schema covering all parameters, the description is mostly complete. It sets the context (active recording) and the side effect (logging). The only missing aspect is what the tool returns or prerequisites beyond an active recording, but this is a minor gap for an action tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add any additional meaning beyond the schema's parameter descriptions; it merely says 'fill a text field' without elaborating on locator parameters or the value input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fill') and resource ('text field in the active recording's browser') while also noting it logs the action as a step. This clearly distinguishes it from sibling tools like click or navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a text field needs to be filled, but it does not explicitly compare with alternatives (e.g., clikta_click) or mention when not to use it. The 'active recording' context is clear but no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey safety and behavior. It indicates a read-only listing operation ('List'), but does not discuss return format, pagination, or error cases. For a simple list tool, this is adequate but leaves room for more transparency about what the agent can expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource, then adds a purpose clause. Every word is useful, avoiding redundancy while conveying the tool's purpose and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is quite complete: it explains the tool's role within the recording workflow and the rationale for using it. It could be slightly more explicit about the return value (e.g., that it returns a list of tool IDs), but the purpose clause implies this, making the description strong for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides full coverage with no missing documentation. The description adds value by explaining the purpose of the list (obtaining a toolId to avoid duplicates), which helps the agent interpret the output. This meets the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List the products/tools already registered in the Clikta workspace' with an example ('Acme Dashboard'). It distinguishes itself from sibling tools by emphasizing that this list is used to attach a new recording via toolId, avoiding duplicates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete usage scenario: when you need to attach a new recording to an existing tool, list the registered tools to get a toolId. While it doesn't explicitly mention alternatives, the purpose clause clarifies when this tool is appropriate, and the sibling list shows it is not for listing recordings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. 'List' implies a read-only operation, but the description does not disclose details such as return format, ordering, pagination, or whether the list includes all recording types. It adds workspace scope and a purpose clause but little else beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, then adds a concise purpose clause. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema listing tool, the description is complete: it states the function, scope, and intended rationale. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for parameter semantics is 4. There are no parameter details to explain, and the description does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('existing recordings'), and the scope ('in the Clikta workspace'). It distinguishes this tool from siblings like clikta_start_recording (which creates recordings) and clikta_list_tools (which lists tools, not recordings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'so you can resume or avoid duplicating work' gives practical context for when to use the tool, implying use before starting a new recording. It does not explicitly mention alternatives or exclusions, but the intended use is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It transparently states that the tool stops recording, generates, publishes, returns a link, and closes the browser — including the significant side effect of closing the browser. It does not mention potential failures or irreversible actions, but the disclosed behaviors are clear and important.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with the primary purpose front-loaded and the consequential 'Closes the browser' stated separately for emphasis. Every word contributes meaning, making it appropriately concise without losing important behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters, no output schema, and is a terminal action in the recording workflow, the description covers the essential context: what it stops, what it generates, what it returns, and that it closes the browser. It could optionally mention that subsequent tool calls will fail because the browser is closed, but that is reasonably inferred from the explicit 'Closes the browser' statement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already conveys full parameter information. Per the rubric, a baseline of 4 applies for zero-parameter tools. The description adds value by explaining what the tool does with the existing recording context, so no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a strong verb phrase 'Stop the active recording' and clearly specifies the full outcome: generate an AI guide/demo, publish it, and return a shareable link. This distinguishes it unambiguously from sibling tools like clikta_start_recording or clikta_screenshot, which serve earlier or supporting steps in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Stop the active recording' implies the tool should be used after a recording has been started, giving clear context for when it applies. It does not explicitly name alternatives or state when not to use it, but the sequential relationship to sibling tools is evident and sufficient for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that clicks are logged as steps, that locator strategies are prioritized for resilience, and that the tool has a safety guardrail against destructive actions unless confirm:true. This goes well beyond a basic 'click' description, though it doesn't cover error handling or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose. The second sentence explains locator options, and the third covers the safety guardrail. Every sentence contributes value, with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5 parameters and no output schema, the description covers the main use case and key behaviors (locating, logging, destructive guardrail). It does not mention failure modes (e.g., element not found, timeouts) or what happens after a click, but these are not critical for basic usage and the sibling context helps fill the gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema's parameter descriptions. It explains that role and name are used together, text is an alternative, and selector is a last resort. It also clarifies the confirm parameter's role in overriding the destructive-action check. This directly informs parameter selection and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Click an element in the active recording's browser and log it as a step.' It uses a specific verb ('click') and resource ('element in active recording's browser'), and the sibling tools (type, navigate, screenshot) make the distinction obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use the tool (any time you need to click an element) and offers guidance on locator choice: 'role/text are more resilient than raw CSS.' It also explains the confirm override for destructive elements. However, it does not explicitly contrast with sibling tools (e.g., 'use this instead of clikta_type'), though the context implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a key non-obvious behavior: notes feed the AI guide generator and act like spoken narration. This implies the note is persisted and used as context, which adds transparency beyond a simple 'add note' tool. It doesn't detail return values or side effects, but for a simple note tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by value and usage guidance. Every sentence adds meaningful information without redundancy. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one simple parameter, no output schema, and no annotations, the description is remarkably complete. It explains what the tool does, why it matters, and how often to use it. It covers the essential context (integration with guide generation) without needing to mention return values or edge cases. This is a complete description for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'text' as a string with no description (0% coverage). The description compensates by explaining that the text should be the user's own explanation of an action. It defines the semantic purpose of the parameter well, though it doesn't specify format or length beyond minLength 1. This is sufficient for a free-text note parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Explain, in your own words, why you just did (or are about to do) something.' It identifies the resource as a note/explanation tool and distinguishes it from the action-oriented sibling tools (navigate, click, type). The purpose is specific and immediately understood.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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: after or before performing an action, to explain reasoning. 'Call it liberally' is explicit frequency guidance. It does not explicitly name alternatives, but the sibling list makes it obvious this is for narration, not actions. Slightly missing an explicit 'when not to use' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It discloses significant behaviors: creates a recording on the workspace, launches a real browser, and navigates to the URL. The warning about suspicious URLs is a nice touch. However, it does not mention whether authentication is required, if repeated calls are safe, or the asynchronous nature of browser launch/loading, which would be valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action, and every sentence contributes: what it does, when to call it, and a practical URL preference. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a workflow-initiating tool with no output schema, the description covers the core process but omits what the result object looks like (e.g., a recording ID). The mention of a warning hints at the result, but the full return value is unclear. This is a minor gap given the tool's complexity and the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 real value for toolUrl by explaining the navigation behavior and the staging preference, plus the warning condition. Other parameters (name, toolId, objective) are adequately covered by the schema, so the extra toolUrl context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb+resource: 'Start a new Clikta recording.' It goes on to explain the key actions (creates the recording, launches a real browser, navigates to toolUrl). This distinguishes it from sibling tools like clikta_click or clikta_finish_recording, which are obviously later steps in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Call this before any other clikta_* action tool,' providing unambiguous ordering guidance. It also advises preferring a staging/sandbox toolUrl over production, which is practical usage guidance beyond mere sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![clikta-mcp-server MCP server](https://glama.ai/mcp/servers/rscoelho/clikta-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/rscoelho/clikta-mcp-server)

Score Badge

Copy to your README.md:

[![clikta-mcp-server MCP server](https://glama.ai/mcp/servers/rscoelho/clikta-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/rscoelho/clikta-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rscoelho/clikta-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server