manager-mcp
Server Quality Checklist
Latest release: v0.2.6
- Disambiguation5/5
Each tool has a clearly distinct purpose: listing/searching resources and records, fetching a single record, and specific financial report snapshots. There is no ambiguity between tools like list_records and get_record, as one is for searching and the other for retrieving by ID.
Naming Consistency4/5The tools follow two clear naming patterns: verb_noun for list and get operations (list_resources, list_records, get_record) and noun_phrases for financial reports (aged_receivables, trial_balance, etc.). While the shift between patterns is noticeable, it is predictable and domain-appropriate.
Tool Count5/5With 10 tools, the server covers a reasonable set of operations for an accounting system: resource introspection, data retrieval, and key financial reports. The count is well-scoped, neither too sparse nor too heavy.
Completeness3/5The tool set is read-only, providing search, retrieval, and report snapshots but lacking any create, update, or delete operations. For a management tool, this is a notable gap that limits agent functionality for common tasks like entering invoices or managing customers.
Average 3.2/5 across 10 of 10 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 29 commits in the last 12 weeks
- Last stable release on
- 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.
This server has been verified by its author.
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?
Only 'read-only' is declared. No other behavioral traits like compute source, aggregation, or performance implications. With no annotations, the description should provide more detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (3 words) but under-specified. Fails to convey necessary information beyond the title-level summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits critical context on parameter usage and result interpretation. For a financial tool, more detail is essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has two parameters (to_date, from_date) with no descriptions in schema or description. Agent cannot infer their purpose, format, or effect. Schema description coverage is 0% and description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool provides a tax summary snapshot and is read-only. It distinguishes from sibling financial reports, but lacks specifics on what the snapshot contains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like profit_and_loss or balance_sheet. No mention of date range usage or other 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, the description only discloses 'read-only' but fails to mention other traits like required permissions, data scope (e.g., all payables or filtered), or performance implications. The output schema exists but is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief (3 words), but under-specification rather than conciseness. No structure, and critical information about parameters and usage is omitted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks details about what the snapshot includes (e.g., aging buckets, totals). It does not address the optional date parameters, leaving gaps for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters, despite there being two optional parameters (to_date, from_date) with 0% schema description coverage. An agent cannot infer their meaning or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a snapshot of aged payables, which matches the tool name. It is read-only, distinguishing it from mutation tools, but less explicitly from sibling financial reports like aged_receivables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like bank_balances or profit_and_loss. The description does not mention prerequisites, date range handling, or any context-specific recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only discloses 'read-only,' which is positive, but omits other behavioral traits such as authentication requirements, data freshness, or response format details beyond what the output schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but lacks structure. It is a single sentence that conveys only the tool's name and read-only nature, but does not introduce parameters or usage context. It is under-informative despite being short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two optional date parameters, no required fields, output schema present), the description should still explain the purpose of the parameters and how the snapshot relates to time periods. It fails to do so, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (to_date, from_date) with 0% description coverage, and the description makes no mention of them. The agent receives no guidance on how to use date parameters, their format, or their meaning in the context of a balance sheet.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'Balance sheet snapshot' and is 'read-only,' which distinguishes it from sibling tools like profit_and_loss or trial_balance. However, it could be more specific about the scope (e.g., period, level of detail).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other financial report tools (aged_receivables, profit_and_loss, etc.). It does not mention any conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral trait disclosed is 'read-only', but without annotations the description should cover more (e.g., date filtering, scope of accounts). The output schema exists but behavioral aspects beyond schema are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. However, the brevity sacrifices necessary information, earning a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 optional params, existing output schema, and multiple sibling financial reports), the description is too sparse to fully guide an agent. It lacks context about what a trial balance is and how it differs from balance_sheet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the to_date/from_date parameters. The agent has no clue about date format, interpretation, or constraints, making parameter usage ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as a trial balance snapshot and notes it is read-only, but lacks a specific verb (e.g., 'get' or 'retrieve') and does not differentiate from sibling tools like balance_sheet or profit_and_loss.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as balance_sheet or aged_receivables. The agent receives no context about typical 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?
The description explicitly states 'read-only snapshot', which is a key behavioral trait. However, with no annotations, it lacks details on auth, rate limits, or data freshness. The description partially fulfills but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, which is efficient. However, it sacrifices necessary detail, making it under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 optional params, output schema exists), the description is insufficient. It explains purpose but not how to use parameters or what the output contains, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention or explain the parameters (to_date, from_date). It adds no meaning beyond the schema types and optionality, which is insufficient for agent usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an aged receivables/outstanding customer balances read-only snapshot. It is specific and distinct from siblings like aged_payables. However, it could be more action-oriented (e.g., 'Retrieve aged receivables').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs alternatives, nor does it mention prerequisites or contexts. It only labels it as read-only without further 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 'read-only' note is helpful, indicating no side effects. However, with no annotations, the description doesn't disclose additional behaviors such as caching, rate limits, or whether parameters are date ranges for filtering the report. The parameter names hint at date filtering, but this could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one short sentence). While brevity is positive, it sacrifices critical details. It could be restructured to front-load the purpose while still being compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and sibling tools, the description is incomplete. It doesn't explain what the snapshot contains, how date ranges work, or any prerequisites. The 0% schema description coverage and lack of annotations mean the description carries full burden, which it does not meet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and no parameter descriptions. The names 'to_date' and 'from_date' are self-explanatory, but the description fails to explain their format, interpretation, or how they affect the report. Multiple formats (string with no pattern) increase ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a profit and loss snapshot, which is a specific financial report, and the read-only note clarifies its nature. It distinguishes from siblings like balance_sheet and trial_balance by name, though further detail would solidify differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives like aged_receivables or bank_balances. Sibling tools are listed but without any comparative notes.
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 provided, so description carries burden. It implies read operation and searchability but lacks details on rate limits, auth, side effects, or pagination behavior beyond schema parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Front-loaded with core purpose and differentiators. Each sentence is valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no annotations, description covers purpose and some sibling differentiation but omits parameter semantics. Output schema exists, so return values need not be explained, but parameter documentation is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and description does not explain any parameters (skip, term, sort_by, etc.). It only lists some resource values implicitly, failing to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches/pages a curated collection, lists core resources, and distinguishes from sibling tool bank_balances. Verb 'search/page' and resource 'curated collection' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use alternatives: 'use bank_balances for snapshot balances.' Mentions writable domains in discovery, providing context for when to use this tool vs others.
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?
States 'read-only' and 'snapshot', which are key behavioral traits. For a read-only tool without annotations, this is good transparency, though it could mention default behavior with no date parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and followed by usage guidance. Every sentence earns its place without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides core function and a key alternative; output schema likely details return values. Minor gap: no explanation of default date range behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not elaborate on the from_date and to_date parameters. With 0% schema coverage, this leaves the agent without guidance on parameter meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a read-only snapshot of bank/cash balances and distinguishes it from sibling tools by specifying that for individual account details one should use list_records/get_record on bank_accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use alternative tools (list_records/get_record) for search/drill-in of individual accounts, providing clear when-not and alternative guidance.
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 the endpoint pattern, restrictions for chart_of_accounts, and correct resource usage for bank accounts. However, it does not mention authentication, rate limits, error handling, or null handling for missing keys, which are relevant for a fetch operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each essential. The first sentence defines the core operation, the second adds critical caveats and alternatives. No unnecessary words, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return values are documented), the description covers the key contextual points: endpoint pattern, resource restrictions, and sibling differentiation. It could mention error scenarios or authorization requirements for completeness, but is adequate for a simple get tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% parameter descriptions, but the description adds meaning by indicating that 'key' is a GUID and 'resource' refers to specific endpoints (e.g., 'bank_accounts' not 'bank_balances'). It does not list all possible resources or formats, but provides useful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch one collection record by GUID') and the resource via a form endpoint, with specific examples (e.g., /customer-form/{key}). It distinguishes from siblings like list_records by focusing on single-record retrieval and provides special-case guidance for chart_of_accounts and bank accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use this tool (to fetch a single record by GUID) and provides an alternative resource for bank detail. However, it does not explicitly state when not to use this tool or compare directly with siblings beyond 'list_records' being a different operation.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool is read-only by default, lists 10 tools, and describes the scoping/deprecation behavior, which adds value beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The first sentence immediately states the purpose, and the second provides behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema shown, the description is mostly complete for a simple zero-parameter tool. It could mention what the output contains (e.g., list of tool names), but current info is sufficient for an agent to decide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so baseline is 4. The description does not need to add parameter details since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List curated Manager.io capabilities' with a specific verb and resource, and the sibling list includes other data-oriented tools (list_records, aged_receivables, etc.), so it distinguishes itself as a capabilities listing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use this tool: it is read-only by default (10 tools), and explains that task tools register with write scopes while CRUD tools are deprecated unless raw scope is set, offering implicit guidance on 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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/flumpiey/manager-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server