harbor-mcp-server

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: schema discovery, query execution, customer lookup, customer snapshot, revenue reporting, and write actions. Even the two write tools are unambiguous—one targets invoices, the other targets subscriptions.
Naming Consistency4/5
All tools share the consistent 'harbor_' prefix and snake_case convention, with most following verb_noun naming (list_tables, describe_table, run_query, find_customer, issue_refund, extend_trial). 'customer_360' and 'revenue_summary' deviate slightly from the verb-first pattern but remain clear and readable.
Tool Count5/5
Eight tools is well within the ideal range and each earns its place. The set covers schema discovery, querying, customer-specific lookups, a 360 view, revenue reporting, and two common business actions without excess.
Completeness4/5
The tool surface covers the core read/query workflow plus the most needed write operations (refund and trial extension). Minor gaps exist—there are no direct ticket management or subscription modification tools—but the run_query tool can access underlying tables and the 360 view provides recent support/invoice context.
Average 4.8/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details not captured by annotations: the 'masked' field indicates partially redacted values, and errors return a list of valid tables. It also details the exact return JSON. There is no contradiction with annotations.
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 well-structured with a one-line summary, labeled args, returns JSON, example, and error behavior. Every sentence earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema in the tool definition, the description fully documents the return JSON structure, including column attributes and masking semantics. It also covers error behavior and an example usage, making it complete for a 1-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the parameter with an enum and description. The description repeats the allowed values but adds no extra semantic meaning beyond reminding the user it is 'one table.' Schema coverage is 100%, so 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 tool's function: 'Return the column list, types, nullability and primary key for one table.' This is a specific verb+resource pairing and distinguishes the tool from siblings like harbor_list_tables and harbor_run_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Example: use before writing a query that filters on a column you have not seen yet.' This gives context for when to use the tool, though it does not explicitly contrast with alternatives or mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds substantial behavioral context by detailing the two distinct data sources (collected revenue vs. current MRR), the return JSON structures for each mode, and the 'basis' field that indicates which metric is being reported. It also notes that from/to only apply to group_by='month', preventing misuse.
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 longer than typical but well-structured with clear sections (main line, mode clarification, Args, return formats, examples). It front-loads the core purpose and uses bullet-style lists. Some redundancy exists with the schema parameter descriptions, but the examples and return format details justify the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully documents the return JSON for both modes, including field names and types. It provides three usage examples covering the main group_by options. It is self-contained and sufficiently complete for an AI agent to select parameters and interpret results without external context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% per the provided context, so the baseline is 3. The description adds value by explaining the semantic difference between group_by values (historical invoices vs. live MRR), clarifying the default 'month', and providing concrete examples of using from/to with YYYY-MM-DD format. This goes slightly beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Revenue broken down by month, plan, country or industry', which immediately states the verb (broken down) and resource (revenue). It clearly distinguishes between the two modes: month (collected revenue from invoices) and plan/country/industry (current MRR), differentiating this tool from sibling tools like harbor_run_query and harbor_customer_360.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each grouping: 'group_by='month' reads collected revenue from paid invoices' versus 'the other groupings read current MRR from live subscriptions', and explains these answer different questions. Examples like 'How much did we collect in Q2?' map to group_by='month' with date range. It does not explicitly name alternative sibling tools, but it clearly contextualizes when to invoke this tool and which parameters to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations already declare readOnlyHint=true and idempotentHint=true, the description adds valuable behavioral context: it specifies the exact return structure in JSON, indicates that an error names the id if the customer does not exist, and notes that it aggregates data from multiple sources. This goes beyond the annotations and helps the agent understand side effects (none) and failure modes, which is particularly useful given the absence of an 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 well-organized and front-loaded: a one-sentence summary, usage guidance, args, return schema, example, and error behavior. Every section serves a purpose. The detailed JSON return structure is necessary because there is no output schema, and the example clarifies the tool's role in a broader workflow. Nothing is wasted or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and moderate complexity (aggregating five data areas), the description is exceptionally complete. It covers the purpose, usage context, input format, full return structure, an example workflow, and error behavior. It also integrates gracefully with sibling tools by referencing harbor_find_customer. There are no 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 input schema already fully describes the single parameter customer_id with a pattern and explicit instruction to use harbor_find_customer if only a name is available. The description's 'Args' section repeats the same information ('exact id, format cus_0042') without adding new meaning. With 100% schema coverage, the baseline is 3, and the description adds no additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific and comprehensive statement: 'Everything about one customer in a single call: profile, subscription, recent invoices, open tickets and 90-day usage totals.' This clearly identifies the tool as an aggregation endpoint and differentiates it from siblings like harbor_find_customer (which locates IDs) and harbor_revenue_summary (which focuses on revenue). The verb 'get' is implied by 'Everything about one customer', making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use this instead of four separate queries when a human asks about an account.' The example 'Why is Kestrel Robotics unhappy?' -> find_customer, then this tool illustrates the intended workflow and contrasts with harbor_find_customer. This clearly communicates when to use the tool and what to do before calling it, fulfilling the dimension fully.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description adds valuable context: email masking behavior, matching still works on unmasked values, and returning an empty match list instead of an error. These are non-obvious traits beyond what annotations convey.
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 well-structured and front-loaded: it states purpose, usage, arguments, return format, and edge-case behavior in a logical flow. Every sentence contributes useful information without redundancy. It is appropriately sized for a lookup tool with edge cases to clarify.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema) and rich annotations, the description covers all necessary aspects: input semantics, return structure, example usage context, and error behavior. It is complete enough for an agent to invoke the tool correctly without further assumptions.
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 full parameter descriptions (100% coverage), including the meaning of 'query' and 'limit'. The description largely repeats this information without adding new semantic detail. For example, both describe partial matches and exact ids. Thus it meets baseline but adds little beyond the schema.
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 customers by multiple criteria (company name, contact name, email, or id) with a specific verb ('Search'). It also distinguishes itself from sibling tools by explicitly positioning it as a pre-step for harbor_customer_360, making its 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: 'Use this to turn a human's phrasing ... into a customer id before calling harbor_customer_360.' This provides a clear use case and differentiates from customer_360. It also notes the empty-list behavior, setting expectations for no-match cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by explaining the mandatory two-call preview/execute flow, the refusal cases (no subscription or non-trialing status), and the exact structure of preview and executed responses. It clarifies the token-based confirmation mechanism that isn't evident from annotations or 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 structured with a one-sentence purpose, a clear call-by-call breakdown, parameter list, and return formats. Every section earns its place; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a stateful two-call tool with no output schema, the description fully covers all behavioral aspects: request flow, return shapes, validation constraints, and error conditions. This is a complete specification for the agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though the schema already covers all four parameters, the description adds crucial context: confirm_token's role in the two-step flow, the day range, reason length, and the exact format for customer_id. It explains the meaning of omitting or passing the token, which the schema only hints at.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb phrase 'Push a trialing subscription's end date out' and clearly states the resource (trial subscription) and action (extend by days). This clearly differentiates from siblings like harbor_issue_refund or harbor_run_query.
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 states when the tool is applicable (trialing subscription) and provides refusal conditions, but it doesn't name any alternative tool for extending trials or handling non-trialing customers. The two-call protocol is described explicitly, which is helpful context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and readOnlyHint=false, but the description goes far beyond that by explaining the preview/execute two-step flow, token expiry (5 minutes), audit log storage, return shapes for both stages, and refusal rules. This adds substantial behavioral context that the annotations alone do not convey, with no contradictions.
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 well-organized with clear call labels, an Args list, return format examples, and refusal conditions. Every sentence conveys necessary information—no fluff or redundancy. The front-loaded 'Requires two calls' immediately signals the key complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two-call flow, no output schema), the description covers all essential aspects: purpose, step-by-step usage, parameter semantics, return values for both preview and execution, and failure conditions. It is self-contained enough for an agent to invoke correctly without additional external docs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema already covers all parameters at 100%, the description enriches them with practical formats (e.g., 'inv_00123'), ranges (1–50000 cents, 4–200 chars), and the crucial two-call semantics of confirm_token (omit, then supply). It clarifies the exact role of each parameter in the workflow, adding procedural meaning beyond the schema definitions.
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: 'Refund part or all of a paid invoice.' The specific verb 'refund' paired with the resource 'paid invoice' distinguishes it from all siblings (list, query, extend_trial, etc.). It also outlines the two-call execution model, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong contextual guidance by detailing the two-call sequence, explicit refusal conditions (invoice not found, not paid, or would exceed amount), and parameter constraints. However, it does not explicitly mention when to use this tool over alternatives, though no sibling serves a similar purpose. This is a minor gap, hence 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description discloses the return format (JSON with tables array and pii_masked flag), notes that PII may be partially redacted, and states that unlisted tables will be rejected. This important behavioral context is not present in the annotations.
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 concise and well-structured: core purpose in the first line, then usage guidance, args, return JSON example, and a restriction note. Every sentence contributes meaningful information without redundancy, and the JSON example is compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although no output schema is provided, the description fully documents the return structure with an inline JSON example, including the pii_masked flag. It also explains the closed-world behavior that unlisted tables cannot be queried. Combined with strong annotations, all aspects of the tool's behavior are specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, and the description explicitly states 'Args: none,' confirming there are no parameters. With zero parameters, the baseline is 4, and the description adds no further parameter details because none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List every table an agent may read, with row counts and a one-line note on each,' which clearly identifies the action (list) and scope (all tables). It distinguishes itself from siblings like harbor_describe_table by focusing on all tables rather than a specific one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs 'Call this first when you do not already know the schema. It is cheap and it prevents guessing.' This is a clear when-to-use directive. It also mentions that tables not listed here will be rejected by harbor_run_query, which proactively warns against querying unknown tables.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/idempotent/destructive annotations, the description discloses rejection rules, automatic LIMIT adjustments, allowed tables, PII masking, truncation behavior, and the exact JSON return structure. This is rich behavioral context that the annotations alone do not provide.
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 longer than average, but every section earns its place: bulleted rejection rules, parameter definitions, return JSON, examples, and error guidance. It is front-loaded with the core purpose and uses clear structure for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex guarded SQL tool with no output schema, the description fully compensates by specifying the JSON return shape, error remediation, allowed tables, and query constraints. The agent has enough information to select and invoke the tool correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds meaningful semantics: explains LIMIT adjustment behavior, default row cap, response_format effects, and shows example SQL strings. It clarifies implication of parameters beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Run a read-only SQL query against the Harbor business database', using a specific verb and resource and making the guarded, read-only nature explicit. It also distinguishes itself from sibling write tools by explicitly directing mutation use to harbor_issue_refund or harbor_extend_trial.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete examples of appropriate queries ('How many customers churned?', 'Revenue by plan') and explicit when-not guidance: 'Don't use for: changing data. Use harbor_issue_refund or harbor_extend_trial instead.' This gives the agent clear criteria for selecting this tool over alternatives.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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