mcptix

by ownlytics

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: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity: add_comment, create_ticket, delete_ticket, get_stats, get_ticket, list_tickets, search_tickets, and update_ticket all target specific actions on tickets or related data. The descriptions reinforce distinct roles, such as list_tickets for listing with filters versus search_tickets for searching based on criteria.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, such as create_ticket, get_ticket, and update_ticket. This uniformity makes the tool set predictable and easy to understand, with no deviations in naming conventions across the eight tools.
Tool Count5/5
With 8 tools, the count is well-scoped for a ticket management system, covering essential operations without bloat. Each tool earns its place, providing a balanced set for CRUD operations, commenting, statistics, listing, and searching, which aligns perfectly with the server's purpose.
Completeness5/5
The tool set offers complete CRUD/lifecycle coverage for ticket management: create_ticket, get_ticket, update_ticket, and delete_ticket handle the core lifecycle, while add_comment supports interaction, and list_tickets, search_tickets, and get_stats provide comprehensive querying and analytics. No obvious gaps exist for the domain.
Average 2.7/5 across 8 of 8 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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 Business Source License 1.1.
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

Behavior1/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 but provides none. 'Create a new ticket' doesn't indicate whether this is a mutating operation (it clearly is), what permissions might be required, whether there are rate limits, what happens on success/failure, or what the response contains. For a creation tool with complex nested parameters, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three words, this is a case of under-specification rather than effective brevity. The description is too minimal for a tool with 5 parameters including a complex nested object with 16 sub-properties. Every sentence should earn its place, but here the single 'sentence' fails to provide necessary context for proper tool selection and use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters with nested objects), absence of annotations, and lack of output schema, the description is completely inadequate. A creation tool with sophisticated complexity metrics and status tracking needs far more context about system behavior, success conditions, error handling, and relationships to other tools. The current description provides none of this necessary context.
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?
The schema description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds zero additional parameter information beyond what's already in the structured schema. However, since the schema does the heavy lifting with detailed descriptions for each property, the baseline score of 3 is appropriate - the description doesn't help but doesn't need to given the comprehensive schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new ticket' is a tautology that essentially restates the tool name. While it does specify the verb 'create' and resource 'ticket', it provides no differentiation from sibling tools like 'update_ticket' or context about what constitutes a ticket in this system. It's minimally informative but doesn't go beyond restating the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. There are multiple sibling tools (add_comment, delete_ticket, update_ticket, get_ticket, list_tickets, search_tickets) but no indication of when this creation tool is appropriate versus updating existing tickets or other operations. No context about prerequisites, timing, or relationships to other tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It states 'Get statistics', which implies a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns aggregated data, or details about output format. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently states the tool's purpose without unnecessary words. However, it could be more front-loaded with key details like the aggregation aspect, but it's appropriately sized for its limited content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose (statistics retrieval) and lack of annotations and output schema, the description is incomplete. It doesn't explain what statistics are returned, in what format, or any behavioral traits like data freshness or access requirements. For a tool with no structured support, more descriptive context is needed.
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?
The input schema has 100% description coverage, clearly documenting the 'group_by' parameter with enum values. The description doesn't add any meaning beyond the schema, as it doesn't mention parameters at all. With high schema coverage, the baseline score of 3 is appropriate since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Get statistics about tickets in the system', which provides a basic purpose (verb+resource) but lacks specificity about what kind of statistics or scope. It doesn't distinguish from sibling tools like 'list_tickets' or 'search_tickets' that also retrieve ticket information, making it somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_tickets' or 'search_tickets'. The description implies it's for aggregated statistics, but it doesn't explicitly state this or mention prerequisites, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Delete' implies a destructive mutation, but the description doesn't specify whether this is permanent, requires special permissions, triggers notifications, or returns confirmation. For a destructive operation with zero annotation coverage, this is a significant gap.
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 extremely concise at three words with zero wasted language. It's front-loaded with the core action and resource. While it's under-specified, this dimension scores conciseness, not completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is inadequate. It doesn't address critical context like irreversible consequences, permission requirements, error conditions, or what happens upon success. The agent lacks sufficient information to use this tool safely and effectively.
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% (the 'id' parameter is documented as 'Ticket ID'), so the schema already provides parameter meaning. The description adds no additional context about parameter format, validation, or where to obtain the ID. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Delete') and target resource ('a ticket'), which provides a basic understanding of purpose. However, it lacks specificity about what constitutes a ticket in this system and doesn't differentiate from sibling tools like 'update_ticket' or 'create_ticket' beyond the obvious verb difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing ticket ID from get_ticket/list_tickets), irreversible consequences, or when deletion might be inappropriate versus updating or archiving.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. 'Update' implies a mutation, but it doesn't disclose any behavioral traits such as required permissions, whether updates are partial or full, error handling, or side effects. This is a significant gap for a mutation tool with zero annotation coverage.
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, efficient sentence with zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly. Every word earns its place without redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters including nested objects, no output schema, and no annotations), the description is incomplete. It doesn't address key aspects like what fields are updatable, how partial updates work, or what the tool returns. For a mutation tool with rich input schema but no annotations or output schema, this leaves significant gaps.
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?
The schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly, including nested objects and enums. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain parameter interactions or constraints). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing ticket' clearly states the action (update) and resource (ticket), which is better than a tautology. However, it doesn't specify what aspects can be updated or differentiate this from sibling tools like 'add_comment' or 'create_ticket' beyond the basic verb. It's vague about scope and distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an existing ticket ID), when not to use it (e.g., for creating new tickets), or refer to sibling tools like 'create_ticket' or 'delete_ticket' for different operations. Usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. 'Add a comment' implies a write/mutation operation, but the description doesn't specify permissions required, whether comments are editable or deletable, rate limits, or what happens on success/failure. This leaves critical behavioral traits unaddressed for a mutation tool.
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, clear sentence with zero wasted words. It's front-loaded with the core purpose and efficiently communicates the essential action without unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns, error conditions, or side effects. For a tool that modifies data, more context about behavioral expectations is needed to guide safe and effective use.
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?
The description adds no parameter semantics beyond what the input schema provides. With 100% schema description coverage, all parameters (ticket_id, content, author, status, type) are documented in the schema with descriptions, defaults, and enums. The baseline score of 3 is appropriate as the schema does the heavy lifting, but the description doesn't enhance understanding of parameter usage or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a comment') and the target resource ('to a ticket'), which is specific and unambiguous. However, it doesn't differentiate this tool from potential sibling tools like 'update_ticket' that might also handle comments, so it doesn't fully distinguish itself from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With siblings like 'update_ticket' that might modify tickets, there's no indication of whether this is the primary method for adding comments or if other tools should be preferred in certain contexts. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden but adds minimal behavioral context. It states 'Get' which implies a read operation, but doesn't disclose traits like whether it requires authentication, returns full or partial data, handles errors, or has rate limits. This is inadequate for a tool with zero annotation coverage.
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 extremely concise ('Get a ticket by ID'), front-loaded with the core action, and wastes no words. Every part of the sentence is essential, making it efficient and easy to parse, though it may be overly brief for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple parameter, the description is incomplete. It doesn't explain what the tool returns (e.g., ticket details, status), error conditions, or behavioral aspects. For a basic read tool, this leaves significant gaps in understanding its full context and usage.
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%, with the parameter 'id' documented as 'Ticket ID' in the schema. The description adds no additional meaning beyond this, such as format examples (e.g., numeric vs. string) or constraints. Baseline 3 is appropriate since the schema does the heavy lifting, but no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a ticket by ID'), making the purpose understandable. It distinguishes from siblings like list_tickets (multiple tickets) and search_tickets (filtered search), though not explicitly. However, it lacks specificity about what 'get' entails (e.g., retrieve details vs. status), preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't clarify that this is for retrieving a single known ticket ID, whereas list_tickets returns multiple tickets or search_tickets filters by criteria. The description implies usage by mentioning 'by ID' but offers no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It mentions 'based on various criteria', which hints at filtering, but fails to detail key behaviors such as pagination handling (implied by limit/offset), authentication needs, rate limits, or what the search returns. This leaves significant gaps for a tool with 7 parameters.
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, efficient sentence with no wasted words. It's appropriately sized and front-loaded, directly stating the tool's action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the return format, error handling, or how search criteria combine, leaving the agent with insufficient context to use the tool effectively beyond basic parameter input.
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?
The description adds minimal meaning beyond the input schema, which has 100% coverage with detailed parameter descriptions. It implies filtering via 'various criteria', but doesn't elaborate on syntax or interactions between parameters. Given the high schema coverage, a baseline score of 3 is appropriate as the schema does most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('search') and resource ('tickets'), making the purpose evident. However, it doesn't distinguish this tool from its sibling 'list_tickets', which might also retrieve tickets, leaving room for ambiguity in sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'list_tickets' or 'get_ticket'. It lacks explicit context, exclusions, or prerequisites, offering minimal usage direction beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'optional filtering, sorting, and pagination' but lacks critical behavioral details: it doesn't specify default behavior beyond what's in the schema (e.g., default sort order), doesn't mention rate limits, authentication needs, or what happens with invalid parameters. For a list operation with 7 parameters, this leaves significant gaps in understanding how the tool behaves in practice.
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, efficient sentence that front-loads the core purpose ('List tickets') and succinctly lists key features. Every word earns its place with no redundancy or fluff, making it easy for an agent to parse quickly while covering essential aspects.
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 moderate complexity (7 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic action and features but lacks details on behavioral traits, output format, or error handling. Without annotations or output schema, the agent is left with incomplete context for reliable invocation, though the schema provides solid parameter documentation.
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 schema fully documents all 7 parameters. The description adds minimal value beyond the schema by summarizing the optional features (filtering, sorting, pagination), but doesn't provide additional context like parameter interactions or usage examples. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'tickets', making the purpose unambiguous. It distinguishes from siblings like 'get_ticket' (singular) and 'search_tickets' (implied broader search), though it doesn't explicitly differentiate from 'search_tickets' which might have overlapping functionality. The description is specific about the action but could be more precise about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_tickets' or 'get_ticket'. The description mentions optional filtering, sorting, and pagination, but doesn't specify contexts or exclusions. Without explicit usage rules, the agent must infer based on tool names alone, which is insufficient for reliable selection.
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:

[![mcptix MCP server](https://glama.ai/mcp/servers/ownlytics/mcptix/badges/card.svg)](https://glama.ai/mcp/servers/ownlytics/mcptix)

Score Badge

Copy to your README.md:

[![mcptix MCP server](https://glama.ai/mcp/servers/ownlytics/mcptix/badges/score.svg)](https://glama.ai/mcp/servers/ownlytics/mcptix)

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/ownlytics/mcptix'

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