Kindora-for-ChatGPT MCP server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool serves a clear, distinct purpose: foundation financials, grants, profiles, stats, search for funders/grants/jobs, NTEE codes, and health check. Descriptions explicitly differentiate between similar tools like search_funders, search_open_grants, and search_funder_jobs.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., get_990_summary, search_funders, health_check). No mixing of conventions like camelCase or inconsistent verb forms.
Tool Count5/5
9 tools is well-scoped for a philanthropy-focused server, covering all major user needs: exploring foundations, grants, jobs, and NTEE codes, with a health check. Not too many to overwhelm, and each tool earns its place.
Completeness5/5
The tool set covers the full lifecycle of philanthropy research: finding funders and NTEE codes, retrieving detailed profiles and financial trends, listing individual grants, searching open grants and jobs, and system health. No obvious gaps for the intended use.
Average 4.3/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark as read-only and open-world. Description adds that it computes trends and returns specific fields, but does not disclose potential missing data or edge cases. With annotations covering safety, the description adds moderate context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second lists returned data. No redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two well-described params and no output schema, the description lists returned fields adequately. Missing details on error cases or data freshness, but overall sufficient for a simple retrieval tool.
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?
Input schema has 100% parameter description coverage. The description adds meaning by listing returned fields, which informs how the 'years' parameter affects the output. Provides context 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?
Description clearly states it retrieves IRS 990 financial summary and year-over-year trends, listing specific data fields (revenue, assets, grants, mission). This distinguishes it from sibling tools like get_foundation_grants or get_funder_profile.
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?
No explicit guidance on when to use this tool versus alternatives. The purpose is implied by name and description, but no when-not-to or alternative directives are provided.
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?
Annotations already indicate read-only and open-world behavior. The description adds the specifics of checking for reachability and health, but does not detail what happens if unhealthy or what the exact response includes. It adds some context beyond annotations but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no extraneous information. It is front-loaded and directly states the purpose.
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 health check tool with no parameters, the description provides sufficient context to understand its purpose and operation. However, it does not specify the return format or what constitutes a healthy response, which could be useful given the lack of an output schema.
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 coverage is 100% (trivially). No parameter descriptions are needed, so the description does not need to add meaning beyond the schema. Baseline is 4.
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 verb 'check' and the resource 'upstream Kindora service', specifying reachability and health. This distinguishes it from sibling tools that deal with data retrieval about funders and grants.
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 that the tool is for verifying service health before other operations, but it does not explicitly state when to use it or when not to. No alternatives are mentioned, leaving the agent to infer usage context.
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?
The description is consistent with annotations (readOnlyHint, openWorldHint) and adds behavioral context by detailing the types of aggregated statistics returned. It does not introduce contradictions or undisclosed side effects.
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-organized paragraph: a concise summary followed by a list of metrics and a usage statement. Every sentence adds value without redundancy.
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 has one parameter and no output schema, the description adequately explains the return value in detail (lifetime stats, distributions, etc.). It provides sufficient context for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter (ein) with a clear explanation, so schema coverage is 100%. The description does not add extra parameter information, aligning with the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets aggregate giving statistics for a foundation, listing specific metrics like lifetime totals, averages, NTEE areas, and year-by-year breakdowns. This distinguishes it from sibling tools that provide detailed grant lists or funder profiles.
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 mentions it is 'useful for prospect targeting,' providing a usage hint. However, it does not explicitly state when to use this tool versus alternatives like get_foundation_grants or get_funder_profile, nor does it specify exclusions.
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?
Annotations indicate readOnlyHint and openWorldHint. The description adds useful behavioral context: grants are ordered largest-first, include aggregate stats, and note the meaning of recipient_country. This goes beyond annotations without contradiction.
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 highly concise: two sentences plus a note, front-loaded with the main purpose. Every sentence adds value, 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?
Given the tool has 7 parameters, no output schema, but good annotations, the description covers the main purpose, ordering, and data source. It lacks details on pagination or result limits, but the schema covers those, so it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already having a clear description. The tool description does not add any extra meaning or context about parameters beyond what the schema provides, earning baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List individual grants a foundation has made, from its 990-PF filings,' specifying the verb, resource, and data source. It also notes ordering and aggregate stats, distinguishing it from sibling tools like search_open_grants which search across foundations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing grants from a specific foundation's filings but lacks explicit guidance on when to use this tool versus alternatives like search_open_grants. No exclusions or when-not-to-use are provided.
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?
Annotations already indicate readOnlyHint=true (safe read) and openWorldHint=true (results may change). The description adds valuable behavioral context: it uses stemming, natural-language matching, and searches across program names, descriptions, focus areas, and beneficiary types. No contradictions with annotations. Some limitations (like rate limits) are not mentioned but not critical.
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 two paragraphs, about 5-6 sentences, front-loaded with purpose and scope. Every sentence adds value: scope, primary designation, search capabilities, query syntax, and browsing behavior. No fluff or repetition.
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?
Given 11 well-documented parameters, no output schema, and appropriate annotations, the description covers purpose, usage, query variants, and browse option. It does not describe return format explicitly, but for a search tool this is acceptable. Overall sufficiently complete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with thorough parameter descriptions, so baseline is 3. The description adds minimal extra meaning beyond the schema, except for query syntax notes and the ability to browse by omitting query. This is helpful but does not significantly enhance parameter understanding.
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?
Description clearly states the tool finds open grant opportunities and RFPs by topic, and identifies itself as the primary tool for grants. It specifies the scope (172K+ foundation programs and federal Grants.gov), using a specific verb+resource combination that distinguishes it from sibling tools like get_foundation_grants or search_funders.
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 on when to use this tool (primary tool for finding grants) and query syntax. It offers examples for natural language, quoted phrases, and exclusion. However, it does not explicitly state when to avoid this tool or alternative tools, though the 'primary' implication is strong.
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?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds that it searches 174K+ US and 32K+ European funders from IRS 990 data, implying a broad but possibly stale dataset. It does not mention pagination or exact return format, but overall provides useful behavioral context beyond 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 with two short paragraphs. The first sentence is a clear verb+resource statement. Every sentence serves a purpose: stating what it does, providing data source, and giving usage guidance with sibling differentiation. 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?
Given the complexity (12 parameters) and lack of output schema, the description covers the core purpose, data sources, and when to use. It could mention output format (list of funders with details) for completeness, but the absence is minor given the clarity otherwise.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 12 parameters. The description adds no additional parameter-specific meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds grantmaking organizations by name, cause area, or location. It also distinguishes from the sibling tool search_open_grants by specifying that search_funders is for funders that may not have a live RFP, while the sibling is for active opportunities.
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 provides when to use (to find aligned funders, or when user names a specific funder) and when not to use (for active/open opportunities, use search_open_grants instead). It also adds context that these funders may fund by relationship, LOI, or annual cycle.
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?
Annotations already declare readOnlyHint and openWorldHint, so description reasonably focuses on content (fields returned). It adds useful context about financials, leadership, classification, and website, which goes beyond what annotations 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?
Two efficient sentences: first states purpose, second gives usage guidance. No extraneous words, front-loaded with key action.
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 low complexity (1 param, no output schema), description covers all necessary aspects: purpose, prerequisite workflow, and returned fields. No 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already has 100% coverage with detailed description (9 digits, hyphen allowed). Description only mentions 'by EIN' without additional semantic value, warranting baseline score.
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?
Description clearly states 'Get a detailed profile for one foundation by EIN' with specific verb 'get' and resource 'foundation profile'. It lists returned fields, distinguishing it from siblings like search_funders (which finds EIN) and get_990_summary (which returns tax form data).
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 instructs to 'Use search_funders first to find the EIN', providing clear when-to-use guidance and implying an alternative workflow. This precludes misuse and clarifies prerequisites.
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?
Annotations indicate readOnlyHint and openWorldHint; the description adds that the tool is for browsing/searching and can list all categories with no arguments. It does not contradict annotations and provides reasonable behavioral context, but could detail output format or pagination.
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 two sentences, front-loading the purpose and providing concise usage instructions with no fluff.
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 simple lookup tool with no output schema, the description is complete: it explains both usage modes, links to sibling tools, and context signals show no missing elements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with adequate parameter descriptions. The description adds no new semantic detail beyond the schema, matching the baseline of 3 for full coverage.
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 browses or searches NTEE classification codes, and distinguishes its purpose by linking to sibling tools like search_funders and get_foundation_grants. It also explains two modes: listing all categories or searching by category/query.
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 tells when to use each mode ('Call with no arguments to list all 26 major categories' and 'Filter by category letter or search by description'), and mentions the codes are for use with other tools, providing clear guidance.
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 discloses that the data is 'backed by a weekly scrape of ~50K funder career pages plus LLM classification,' indicating data freshness and methodology. This adds context beyond the annotations (readOnlyHint, openWorldHint) which already indicate the tool is read-only and data may change externally. 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 concise at 8 sentences, with a clear first sentence stating purpose. It front-loads key information, uses bullet-like structure, and avoids redundancy. Every sentence adds value.
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?
Given 12 parameters, 100% schema coverage, no output schema, and no required params, the description covers purpose, scope, data source, usage boundaries, and workflow integration with siblings. It does not detail return format or pagination, but the limit parameter is documented. Overall highly complete for a search tool.
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%, so most parameters are well-documented. The description adds value by explaining the relationship between search_funders and the 'funder_eins' parameter, and notes limits (up to 100). This extra context justifies a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find OPEN philanthropy jobs at grantmaking foundations.' It specifies the verb, resource, and scope, and distinguishes itself from the sibling tool 'search_open_grants' by explicitly specifying that this tool is for jobs, not grants.
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 tells when to use ('for jobs/careers/hiring questions'), when not to use ('NOT for grant opportunities'), and provides an alternative ('use search_open_grants for those'). It also gives a multi-step workflow for uncovered cause areas, instructing to call search_funders first and then pass funder EINs.
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:

[![kindora-chatgpt-mcp MCP server](https://glama.ai/mcp/servers/wayanvota/kindora-chatgpt-mcp/badges/card.svg)](https://glama.ai/mcp/servers/wayanvota/kindora-chatgpt-mcp)

Score Badge

Copy to your README.md:

[![kindora-chatgpt-mcp MCP server](https://glama.ai/mcp/servers/wayanvota/kindora-chatgpt-mcp/badges/score.svg)](https://glama.ai/mcp/servers/wayanvota/kindora-chatgpt-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wayanvota/kindora-chatgpt-mcp'

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