trdizin-mcp

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: search by entity type (publications, journals, authors, institutions), retrieval by standard identifiers (DOI, ORCID, ISSN), and analytical tools (trending topics, author comparison). There is no overlap between searching and direct lookup.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case: search_* for searches, get_* for identifier-based lookups, and compare_authors for analysis. This makes predictions easy.
Tool Count5/5
Nine tools form a well-scoped set for a bibliographic database server. The count is within the ideal range and each tool serves a distinct, necessary function.
Completeness5/5
The surface covers all major entities (publications, journals, authors, institutions), provides both search and identifier-based retrieval, and includes analytical tools. No obvious dead ends or missing operations for the domain.
Average 3.3/5 across 9 of 9 tools scored. Lowest: 2.4/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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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. It only states a generic search capability, omitting any details about pagination, filtering, sorting options, or the nature of results. The agent has no information about response format or operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, so it is brief, but it is under-specified. It captures the core purpose but lacks any structural elaboration that would help the agent, making it more under-specified than concisely informative.
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?
For a tool with 6 parameters (including enums for sorting and language) and no output schema, the description is inadequate. It provides only a high-level purpose and none of the necessary operational context, leaving the agent to guess about filtering, pagination, and result structure.
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?
Schema description coverage is 33%, and the description fails to compensate for the remaining undocumented parameters. It adds no meaning beyond the schema's own field names and minimal descriptions, leaving the agent without guidance on how to use 'page', 'limit', 'order', or 'language'.
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 searches academic journals ('akademik dergi ara') within TR Dizin. This distinguishes it from sibling tools like search_publications and search_authors, making the resource scope explicit.
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. There is no mention of when to prefer journal search over publication/author search, nor any exclusions or prerequisites.
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, the description must carry the behavioral disclosure burden, but it only says 'search'. It does not mention pagination, sorting, result limits, or any other behavioral traits, offering little beyond the raw action.
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 efficient sentence with no filler, front-loading the main purpose. However, it is extremely brief, bordering on under-specification, though it remains appropriately concise for a simple search intent.
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 7 parameters and no output schema, a single generic sentence is insufficient. It lacks context about expected return values, pagination behavior, or how the search scope relates to the available filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 57%, and the description adds no parameter-level detail. It does not clarify the query format, filter semantics, or meaning of page/limit/order beyond what the schema already provides.
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 states a specific search action ('ara' = search) targeting universities and research institutions in TR Dizin. It is clear about the resource and domain, but it does not distinguish itself from sibling search tools beyond the entity type.
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 on when to use this tool vs. search_publications, search_journals, or search_authors. It lacks workflow context, prerequisites, or explicit exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'search' without disclosing behavior such as pagination, ordering, authentication needs, or rate limits. It does not even clarify whether the search is read-only or if any side effects exist. This is a significant gap for an agent relying on the description.
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, concise sentence that states the core purpose without any unnecessary overhead. Every word contributes to understanding, making it appropriately sized and front-loaded.
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 there is no output schema, no annotations, and minimal parameter descriptions, the description is far too sparse. It does not mention response format, pagination behavior, ordering options, or any additional context needed for correct invocation. The tool is simple, but the description still leaves major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 25%, with only 'query' having an explanation (author name). The tool description adds no parameter information, so the agent must infer meaning for page, limit, and order. While the enum for order provides some clues, the lack of compensation from the description is a clear deficiency.
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: searching academicians and authors in TR Dizin. It uses a specific verb ('ara') and resource ('akademisyen ve yazar'), distinguishing it from sibling tools that search publications, journals, or institutions.
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 the tool is for searching authors by name, but provides no explicit guidance on when to use it versus alternatives like get_author_by_orcid or search_publications. Context (TR Dizin scope) is given, but no exclusions or alternative recommendations are offered.
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, the description must fully disclose behavioral traits. It only states the high-level purpose and does not explain output format, how top_n is applied, default database behavior, or what is returned when both topics and institutions are requested.
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 directly and efficiently conveys the core action and scope, with no redundant words or filler.
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?
The tool is moderately complex (3 params, no output schema, no annotations), but the description only covers the basic purpose. It fails to specify what the returned data looks like, how the two analysis dimensions combine, or any operational details needed for correct 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?
Schema coverage is 100% with clear descriptions for year, top_n, and database, so the baseline is 3. The tool description adds no extra parameter context beyond what the schema already provides.
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 identifies the action ('analyze'), the resource ('TR Dizin'), and the specific outputs ('most studied topics and most productive institutions') for a given year. This distinguishes it from sibling search/retrieval tools by focusing on aggregated analysis.
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 siblings like search_publications or compare_authors. The description implies usage for trend analysis but does not state any exclusions or alternatives.
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. It only states the tool performs a search, without mentioning any behavioral traits such as result format, pagination behavior, error handling, or performance characteristics. This is a significant gap for a tool with 12 parameters and no output schema.
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, concise sentence that states the tool's purpose and key search options without any filler. Every word serves a purpose, making it highly efficient and appropriately sized for the tool's complexity.
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?
Despite having 12 parameters and no output schema, the description provides minimal context. It fails to explain how results are returned, how pagination works, or how the search interacts with filters. The one-sentence description is insufficient to fully understand and correctly invoke the tool in all contexts.
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 already explains all parameters, giving a baseline of 3. The description's mention of subject, author, journal, and keyword adds no semantic value beyond the schema, as these are already exhaustively described in the parameters.
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 searches for articles and publications in TR Dizin, using a specific verb and resource. It distinguishes from sibling tools like search_journals and search_authors by focusing on publications, making the purpose unambiguous.
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 context by listing searchable fields (subject, author, journal, keyword), guiding when to apply it. However, it does not explicitly state when not to use it or reference alternative tools for other resource types, leaving room for clearer differentiation.
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 only states 'get author info,' which implies a read operation, but does not mention any error behavior, response format, required permissions, or whether the ORCID must be exact. This is insufficient 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 a single, front-loaded sentence that directly states the tool's purpose without any filler or repetition. It earns its place with zero wasted words.
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 one-parameter getter with no output schema or annotations, the description gives the core function and parameter meaning, but lacks details about the response content (e.g., what fields are included) or any special conditions. It is minimally adequate but not rich enough for 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?
The input schema fully describes the 'orcid' parameter with type and example, achieving 100% schema coverage. The description does not add additional semantic details beyond the schema, so the baseline score of 3 is appropriate.
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: get author info in TR Dizin by ORCID. The verb 'getir' (get) and resource 'TR Dizin'deki yazar bilgilerini' are specific, and the ORCID parameter distinguishes it from sibling tools like search_authors or get_publication_by_doi.
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?
Usage is implied by the description: use this tool when you have an ORCID and need author details. However, there is no explicit comparison to alternatives (e.g., search_authors) or guidance on when not to use this tool, so the guidance is only implicit.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the action and resource, but does not clarify that it's a read-only operation, what happens if the journal is not found, whether both ISSN and eISSN can be supplied together, or what fields are returned. This is a notable 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 a single, clear sentence with no redundancy. It front-loads the action ('getir') and includes the key condition ('ISSN veya e-ISSN numarasıyla'), making it both concise and well-structured.
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?
The tool is a simple identifier lookup with full schema coverage, but the description omits the return structure, required-parameter constraints, and not-found behavior. Given the lack of annotations and output schema, a more detailed description would improve completeness, though it is minimally adequate for a basic lookup.
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 already documents both parameters with descriptions and examples, giving 100% coverage. The description adds the relationship that either ISSN or eISSN can be used, but does not clarify whether at least one is required or how conflicts are resolved if both are provided. Baseline 3 for high schema coverage is appropriate.
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 the specific verb 'getir' (get), identifies the resource as journal information in TR Dizin, and states the lookup method (by ISSN or e-ISSN). This clearly distinguishes it from sibling tools like search_journals, which perform broad searches rather than exact identifier lookups.
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 for direct identifier-based lookup, but it does not explicitly say when to use this tool versus search_journals, nor does it mention whether at least one of the parameters is required. The 'veya' (or) hints at alternative parameters but provides no formal guidance on selection.
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 must carry the full burden of behavioral disclosure. It only states that the tool gets information, without mentioning what happens if the DOI isn't found, whether authentication is required, or any rate limits. For a read operation, more detail would be expected.
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 redundancy. It clearly states the verb, resource, and lookup key in a compact form. No wasted words.
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?
The tool is simple (one parameter, no output schema), so the description is adequate but not rich. It doesn't explain return values, error behavior, or any special contexts. Given the low complexity, a score of 3 seems appropriate—it covers the essentials but leaves room for more detail about expected outcomes.
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 describes the 'doi' parameter fully (type, required, example), and the description only repeats that it uses a DOI number. With 100% schema coverage, the baseline is 3, and the description adds no extra 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: retrieving article information from TR Dizin using a DOI number. The verb 'getir' (get) combined with the specific resource (article info by DOI) distinguishes it from sibling search tools like search_publications and get_author_by_orcid.
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 implies a clear usage scenario: use this tool when you have a DOI number. While no explicit alternatives or exclusions are mentioned, the context is unambiguous given the tool's name and purpose. It doesn't state what to do if the DOI isn't known, but for a simple lookup this is acceptable.
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 is the only source of behavioral info. It adds the comparison dimensions but does not disclose output format, data limits, or error handling.
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 that states the action and criteria without any fluff. Every word contributes meaning.
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?
The schema is simple and fully covers parameters, but there is no output schema or annotations. The description explains the comparison criteria but omits what the result looks like or how errors are handled, leaving some 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?
Both parameters are fully documented in the schema with clear descriptions (name surname). The description does not add further syntax or formatting details beyond the schema, so a baseline score of 3 applies.
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 ('karşılaştır' = compare) and identifies the resource ('iki yazar' = two authors) along with the comparison criteria (publication count, citation count, active topics). This clearly distinguishes it from sibling search/get 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 description clearly implies the tool is for comparing two authors, which is distinct from the search/get siblings. However, it does not explicitly state when not to use it or mention alternatives for single-author lookups.
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:

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

Score Badge

Copy to your README.md:

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

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/MustafaKemal0146/trdizin-mcp'

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