fortigate-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource or action: system status, interfaces, routing, firewall policies, address objects, services, VPN, and sessions. The list/get distinction for firewall policies is clear, with list providing summary and get providing details. No two tools appear to overlap in purpose.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case. Verbs are limited to 'get', 'list', and 'search', and are used predictably: 'list_' for plural resources, 'get_' for single items, and 'search_' for queries. This makes the tool set easy to navigate.
Tool Count5/5
Nine tools is well within the ideal range for a focused server. Each tool covers a meaningful aspect of FortiGate status and configuration, without redundancy. The scope is broad enough to be useful but not so large that it becomes overwhelming.
Completeness4/5
The tool surface provides solid read-only coverage of the FortiGate domain: system health, interfaces, routing, policies, objects, services, VPN, and sessions. The only notable gap is the lack of any write operations (e.g., create/update/delete firewall policies or address objects), which would be expected for full management but is acceptable for a monitoring-focused server. Minor missing details like a single-address-object lookup are not critical.
Average 3.5/5 across 9 of 9 tools scored.
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

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 'Active IPv4 routing table' without mentioning whether the operation is read-only, potential side effects, or required permissions. It also doesn't describe output format or pagination 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 extremely concise, consisting of a single phrase that conveys the essential information with no filler or redundant text.
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 relatively simple with two optional parameters and no output schema. However, the description omits details about the nature of the return value (e.g., whether it's a list or a summary), and with no annotations, the agent has limited context. It is minimally adequate but not rich.
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 fully describes both parameters (vdom and device) with clear descriptions, achieving 100% coverage. The tool description adds no additional parameter semantics, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving the active IPv4 routing table, mentioning specific protocols (connected, static, OSPF, BGP). This is specific and distinguishes it from sibling tools like list_interfaces or get_system_status, though it lacks an explicit verb in the description itself.
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, nor any exclusions or prerequisites. It simply states what the tool returns, so the agent has no context for when to select this tool over others.
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 states only the basic action without addressing read-only nature, output format, pagination, permissions, or potential side effects. For a listing tool, the user is left without information about what the response will contain or whether any filters are applied.
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 sentence with no filler, efficiently conveying the core purpose. It is appropriately sized for a simple list operation with two optional parameters, though it could arguably be expanded slightly without becoming verbose.
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 tool with no output schema and no annotations, the description is minimal. It does not specify the return format, whether the list is paginated, or how errors are handled. Given the low complexity and two optional parameters, a bit more context (e.g., 'Returns all address objects in the specified VDOM') would be expected for 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?
Schema description coverage is 100%, and both parameters ('vdom' and 'device') have clear descriptions in the schema. The tool description adds no extra parameter semantics beyond naming the object types, but the schema already handles parameter documentation adequately. Baseline 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 action ('List') and the resource ('address objects'), and even enumerates the object types (subnet, fqdn, iprange, geography). This distinguishes it from sibling tools like list_interfaces or list_firewall_policies, which operate on different resource types.
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. It does not mention any prerequisites, exclusions, or conditions under which another tool (e.g., search_sessions) would be preferred. The intended use is only implied by the tool's name and description.
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 for behavioral disclosure. It only states 'List', implying a read-only operation, but does not mention response format, pagination, VDOM behavior, or any side effects. This is minimal information for an agent to understand the tool's 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 a single, front-loaded sentence that directly states the verb and resource without any filler. It is concise and to the point, containing only essential information.
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 list tool with two optional parameters and no output schema, the description provides the basic object type but omits details that would aid an agent, such as whether system predefined services are included, the response structure, or when the device parameter can be omitted. The lack of annotations further increases the need for context, making this moderate.
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%, as both parameters (vdom and device) have detailed descriptions. The tool description adds no parameter-level insight beyond what the schema already provides. The mention of 'protocol and port ranges' is about the returned objects, not the parameters, so the baseline 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 clearly states the tool's action ('List') and the resource ('custom service objects'), further specified as 'protocol and port ranges'. This distinguishes it from sibling tools like list_address_objects and list_interfaces, which list different resource types.
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 does not mention exclusions, prerequisites, or scenarios where another sibling would be more appropriate. The schema hints at parameter usage, but the description itself offers no selection context.
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 for disclosing behavioral traits. It does not state whether the operation is read-only, requires specific permissions, or has side effects, though the 'get_' prefix and status nature imply a safe read. No details about output size or pagination are given.
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 front-loads 'VPN status' and specifies its contents without any 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?
The tool is relatively simple with two optional parameters and an output schema present. The description adequately covers the scope of status information (IPsec tunnels and SSL-VPN sessions), but it does not mention usage context or any limitations. Given the simplicity and presence of an output schema, it is reasonably complete.
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 already provides 100% coverage with descriptions for both vdom and device parameters. The description adds no information about these parameters, but since the schema fully covers them, the baseline 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 what the tool does: it retrieves VPN status, specifically IPsec tunnel states/traffic and active SSL-VPN sessions. This distinguishes it from sibling tools like get_system_status or list_interfaces, which cover different domains.
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 get_system_status or list_interfaces. It lacks explicit context, exclusions, or alternative references, leaving the agent to infer usage from the tool name 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 must disclose behavioral details, but it does not mention the output format, filtering semantics (e.g., whether filters are ANDed), pagination behavior, or any side effects. The read-only nature is implied by 'search' but not explicit, and no information about authentication or rate limits is given.
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 conveys the essential purpose with no filler. It is concise and front-loaded, earning full marks for efficiency.
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?
This is a read-only search tool with well-documented parameters, but the description omits any mention of the return value or result shape. Since there is no output schema, the description should compensate by indicating what the agent can expect, yet it does not. The tool is simple enough that the gap is moderate, but completeness is not fully achieved.
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 each parameter already clearly described. The description only echoes filter names without adding new meaning, such as how filters interact or default behavior. Thus it meets the baseline but provides no extra semantic value.
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 action ('Search'), the target resource ('active session table'), and the specific filters ('source/destination/port'). This distinctly separates it from sibling tools that operate on system status, interfaces, routing, or firewall policies.
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 finding active sessions by IP or port, but does not explicitly state when to use this tool over alternatives or when not to use it. There is no comparison or exclusionary guidance, leaving the agent to infer relevance.
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 carries the burden of behavioral disclosure. It reveals two important traits: the list contains compact fields, and the order reflects rule evaluation order. These go beyond the basic action and provide meaningful context for interpretation.
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 consists of two short sentences with no redundant wording. The first sentence states the purpose, and the second adds crucial ordering information, making it highly efficient.
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 description provides the core purpose and one behavioral detail, but lacks an output schema, explicit usage alternatives, or discussion of what 'compact fields' entails. For a simple list tool this is adequate, but there are clear gaps in supporting agent decision-making.
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% for all three parameters (vdom, device, include_hit_counts), so the schema already documents them well. The description adds no additional parameter-level information, which is acceptable at the baseline of 3.
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') and resource ('firewall policies'), and adds a distinguishing detail about evaluation order. It is easily differentiated from the sibling tool 'get_firewall_policy' which implies retrieving a single policy.
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 explicit guidance is given on when to use this tool versus alternatives. The description does not mention that 'get_firewall_policy' is better for single-policy details or provide any contextual triggers for use.
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 burden. It discloses that the operation returns all CMDB fields, which clarifies the scope of output. However, it does not explicitly state read-only behavior, error conditions (e.g., policy not found), or any permissions required. The description is adequate for a simple get operation but lacks deeper behavioral 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?
The description is a single, front-loaded sentence that conveys the purpose and output scope without waste. It is appropriately concise and easy to parse at a glance.
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?
The tool is a simple get operation with one required parameter. The description explains the return value ('all cmdb fields') which compensates for the absence of an output schema. However, it does not mention default behavior for omitted vdom/device (which is in the schema), nor any specific error handling. For its simplicity, it is mostly complete.
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% coverage for all three parameters (policy_id, vdom, device) with clear descriptions. The tool description adds no additional parametric meaning beyond what the schema already provides, so the baseline score 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 clearly states the tool returns full detail of a single firewall policy, specifying 'all cmdb fields'. This distinguishes it from list_firewall_policies (which lists) and other resource-specific tools. The verb and resource are explicit and 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?
Usage context is implied through 'single' and 'full detail', but no explicit mention of when to use this vs. alternatives like list_firewall_policies. The description does not provide exclusions or when-not-to-use guidance, though the 'single' phrasing hints at targeted lookup use cases.
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 states the tool returns status fields, which strongly implies a read-only operation, but it does not explicitly confirm no side effects, permissions required, or failure behavior. The field list adds some transparency, but not comprehensive behavioral disclosure.
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 lists both the tool's scope and its key output fields. It contains no fluff, repetition, or unnecessary detail.
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?
The tool is simple (one optional parameter, no nested objects) and has an output schema, so the description does not need to detail return values. It provides enough context to understand the tool's purpose and general output, though it could benefit from explicit usage guidance.
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 only parameter (device) fully with 100% coverage, including its optionality and default behavior. The description adds no parameter-specific details, but the baseline of 3 applies because the schema already handles the documentation burden.
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 ('get') and resource ('system status'), and enumerates the exact data returned (hostname, model, FortiOS version, serial, HA mode, CPU/memory/session usage). This clearly distinguishes it from sibling tools that target interfaces, routing, or VPN status.
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 phrase 'General FortiGate status' implies this is the go-to for overall device health, while sibling tools cover specific subsystems. However, it does not explicitly mention alternatives or when not to use this tool, so guidance remains only implicit.
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 carry the burden. It does disclose the data fields returned, which is useful. However, it does not mention edge cases such as pagination, filtering, or error scenarios, which keeps it at an adequate but not rich level.
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. It front-loads the action ('List interfaces') and immediately specifies the useful data fields. No filler or unnecessary words.
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?
The description is sufficient for a simple list tool. It names the returned data fields, which partially compensates for the lack of an output schema. It could be more complete by stating whether all interfaces are returned or if any filtering applies, but the core information is present.
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 adds no extra meaning about the parameters beyond what the schema already provides, which is acceptable because the schema descriptions are complete.
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 and resource ('List interfaces') and enumerates the returned attributes (link status, IP, speed, and traffic counters). This clearly distinguishes it from sibling list tools such as list_firewall_policies or list_address_objects.
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 purpose is self-evident: an agent would use this when they need interface details. However, there is no explicit mention of when not to use it or alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

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

Score Badge

Copy to your README.md:

[![fortigate-mcp MCP server](https://glama.ai/mcp/servers/irfanharis/fortigate-mcp/badges/score.svg)](https://glama.ai/mcp/servers/irfanharis/fortigate-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/irfanharis/fortigate-mcp'

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