BusinessMap MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
The tools have mostly distinct purposes: list_* enumerate top-level entities, get_* retrieve cards in different ways, and create/update_card handle mutations. The only potential confusion is between get_board_cards and get_user_cards, both returning cards but with different filters; descriptions clarify this. Search and details are clearly separate.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern with list_, get_, search_, create_, update_. However, get_board_cards and get_user_cards use get_ for what are list-like operations, and get_card_details is oddly specific; a more consistent scheme would be list_cards_by_board and list_cards_by_user.
Tool Count5/5
Nine tools is well-scoped for a BusinessMap integration, covering the core entities (users, workspaces, boards, cards) without redundancy. Each tool serves a clear purpose, and the count is within the ideal range.
Completeness4/5
The card lifecycle is partially covered: read (via board, user, details, search), create, and update title/description. Missing delete_card and card state transitions (e.g., moving between columns) are notable gaps. User, workspace, and board operations are limited to listing, which may be sufficient for context.
Average 3.7/5 across 9 of 9 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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

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 merely states that it creates a card and lists arguments, omitting any details about permissions, side effects, idempotency, return values, or error conditions. This is a minimal behavioral description.
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 appropriately short and front-loaded, with a clear opening sentence and a compact parameter list. The argument list is somewhat redundant with the schema but does not unduly bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and the presence of an output schema, the description omits critical context such as when to use the tool, behavioral expectations, and accurate parameter requirements. The optional/required contradiction further reduces completeness, leaving the agent with ambiguous guidance.
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 description adds semantic meaning to parameters, such as 'assign the card to' for user_id and 'assign' for tag_ids, which goes beyond the bare schema titles. However, it explicitly labels user_id and tag_ids as optional, directly contradicting the input schema which requires all four parameters. This inaccuracy undermines the reliability of the parameter 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 'Create a new card in BusinessMap' clearly identifies the action (create) and the resource (card), and it distinguishes itself from sibling tools like update_card and get_card_details. This is a specific verb+resource combination.
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 gives no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The only implied context is that this is the creation operation for cards, which is insufficient for an AI agent to make nuanced decisions.
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, but it only says 'Get detailed information' which implies a read operation. It does not disclose any behavioral traits such as error handling, permissions, or safety guarantees.
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 very short and to the point, with no filler words. The Args block is somewhat redundant with the schema but does not detract. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present, read operation), the description covers the essential purpose. However, it lacks usage guidance and any notes on edge cases or behavioral limitations, which makes it minimally viable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an Args section explaining card_id as 'The ID of the card', which adds a small amount of semantic value beyond the schema's bare type/title. With schema description coverage at 0%, this compensation is minimal but sufficient for a single simple parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information for a specific card, using a clear verb+resource pattern. It is distinguishable from sibling list/search tools by focusing on a single card, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like search_cards or get_board_cards. The description implies use when you have a card ID, but it doesn't state exclusions or mention other tools.
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 does not mention read-only behavior, authentication requirements, pagination details, or how cards are ordered or filtered.
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 very concise, consisting of a single clear sentence followed by parameter definitions. No unnecessary information is included.
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 covers the purpose and parameters adequately for a simple tool, and an output schema exists to explain return values. However, it lacks usage guidelines and behavioral context, making it acceptable but not comprehensive.
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 description explains both parameters: board_id as the board's ID and limit as the maximum number of cards with a default. This compensates for the schema's 0% description coverage, though board_id is somewhat tautological.
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 'Get cards from a specific board' with a specific verb and resource, and distinguishes itself from sibling tools like get_user_cards and get_card_details by board scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as search_cards or list_boards. The description only states the operation and arguments, providing no context for 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?
Since no annotations are provided, the description carries the full burden for behavioral disclosure. It hints at partial updates by using 'New title' and 'New description', but does not explicitly state whether omitted fields are preserved or any other side effects. It omits information about permissions, return values, or error conditions.
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, with a single opening sentence followed by a compact Args list. Every line earns its place, and the structure is easy to scan for the agent.
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 update tool with an output schema, the description adequately covers purpose and parameters. However, it leaves ambiguous the update semantics (partial vs full replacement) and does not mention any prerequisites, making it minimally complete but with clear gaps.
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 has no per-property descriptions (0% coverage), so the description compensates by providing an Args block that explains each parameter's meaning and optionality. This adds real value beyond the raw schema types and enums.
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 as 'Update an existing card in BusinessMap', using a specific verb and resource. It distinguishes from sibling tools by specifying 'existing', which differentiates it from create_card.
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 modifying existing cards but gives no explicit guidance on when to use this tool versus alternatives like create_card. It does not state any exclusions or prerequisites, relying on the reader to infer the appropriate context.
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?
The verb 'List' implies a read-only operation, but with no annotations provided, the description carries the full burden. It does not disclose potential side effects, authentication requirements, rate limits, or size of the response. Minimal behavioral context is given beyond the action.
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, front-loaded with the verb and object, with no redundant or unnecessary wording. It is optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list operation with an output schema present, the description is sufficient and clear. It states the scope ('all') and resource ('users'), though it could optionally mention potential large response sizes or access prerequisites.
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 has zero parameters, so the description has nothing to add. A baseline score of 4 is appropriate since the schema fully covers 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 uses a specific verb ('List') and resource ('BusinessMap users'), clearly distinguishing it from sibling tools like list_workspaces and list_boards. It unambiguously states what the tool does.
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 any context, exclusions, or specific scenarios, leaving the agent without clear selection criteria.
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 is the only source of behavioral information. It states the search action and parameter constraints, but does not disclose match semantics (exact vs. partial, case-sensitivity), result ordering, or that the operation is read-only, though that is somewhat implicit in a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single-sentence purpose statement followed by a clean Args list. Every sentence adds essential information with no wasted 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?
For a simple search tool with an output schema (return format already externally defined), the description covers the key invocation details: purpose, all parameters, and optional/default behaviors. It lacks explicit comparison to sibling tools, but is otherwise complete enough to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates fully by explaining each parameter: 'query' as the title search string, 'board_id' as an optional scoping filter, and 'limit' with a default value. This adds meaningful guidance beyond the bare schema property names.
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 opens with 'Search for cards by title', which clearly specifies the action, resource, and attribute. It distinguishes search from simple board/user listings by focusing on title-based search, though it does not explicitly name sibling tools.
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 provides clear context about searching by title with an optional board filter, implying when it should be used. However, it does not explicitly state when to prefer this over sibling tools like get_board_cards or get_user_cards, nor does it mention exclusions.
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?
It discloses useful defaults: user_id falls back to the current user and limit defaults to 50. However, with no annotations, the description could also clarify that this is a read-only operation and whether 'assigned' means only direct assignment or includes related associations.
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 compact and well-structured: a one-sentence purpose followed by a concise args list. Every line provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with an output schema, the description covers all parameters and default behaviors. It lacks explicit usage guidance but is otherwise sufficient for invoking the tool 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?
Schema description coverage is 0%, and the description fully compensates by explaining each parameter's purpose, including the default fallback for user_id and the meaning of optional board/column filters. This adds significant value beyond the bare 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 'Get cards assigned to a specific user', using a specific verb and resource, and the scope ('assigned to a user') distinguishes it from siblings like get_board_cards and search_cards.
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 through its parameters and default behavior (e.g., current user, optional board/column filters), but it does not explicitly mention when to prefer this tool over alternatives like search_cards or get_board_cards, nor does it state exclusions.
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 provided, the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, but the description does not mention any potential limitations such as pagination, ordering, or authorization requirements. It is minimally adequate for a simple list operation but lacks depth.
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-front-loaded sentence with zero wasted words. It conveys the essential information directly and efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless list operation, the description is sufficiently complete. It clearly states the scope ('all') and resource ('boards'). The existence of an output schema means return values are structured elsewhere, so the description does not need to elaborate on the response format. A slightly lower score would apply if there were more behavioral nuances, but here it fits the tool's simplicity.
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?
Since there are no parameters (0 params), the description need not add parameter semantics. The baseline for 0 params is 4, and the description appropriately focuses on the action without needing to explain 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 uses a specific verb ('List') and resource ('BusinessMap boards'), making the tool's purpose immediately clear. It also distinguishes itself from sibling tools like list_users and list_workspaces by explicitly naming boards as the target resource.
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 retrieving all boards, which differentiates it from tools like get_board_cards or search_cards. However, it does not explicitly state when to use this tool over alternatives or mention any exclusions, so it stops short of full guideline coverage.
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 safety/behavioral burden. It states 'List all' which implies a read-only, non-destructive operation, but it does not disclose details like pagination, ordering, or authentication. For a simple, parameterless list tool, this is acceptable but not thoroughly transparent, so 3.
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 with no fluff. It gets straight to the point and earns its place.
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 zero-parameter complexity and the presence of an output schema (covering return-value structures), the description provides complete context for a simple list-all tool. There is no missing information that the agent would need to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty (100% coverage by default). The description adds semantic value by specifying that it lists 'all' workspaces, implying no filtering is possible. Per the rubric, 0 params gets a baseline of 4, and the description does not hurt that.
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 'List all BusinessMap workspaces' uses a specific verb ('List') and clearly identifies the resource ('BusinessMap workspaces'). This distinguishes it from sibling tools like list_users and list_boards, which clearly 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to list all workspaces. It does not explicitly mention when not to use it or name alternatives, but the sibling-tool context makes it obvious that this is the workspace-listing tool, differentiating it from user/board/card listers. It lacks explicit exclusions, so a 4 is appropriate.
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:

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

Score Badge

Copy to your README.md:

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

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