APIFold
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_serversA | List all 18 free hosted APIFold MCP servers (GitHub, Stripe, Slack, OpenAI, Notion, and more). Each server proxies a REST API — bring your own API key. |
| get_server_endpointB | Get the SSE endpoint URL for a specific APIFold MCP server by slug. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: one lists all available servers (discovery), while the other retrieves a specific connection endpoint (retrieval). No functional overlap exists between listing a catalog and fetching a specific URL.
Both tools follow a consistent verb_noun pattern using snake_case (get_server_endpoint, list_servers). The verb choices ('get' vs 'list') accurately reflect the read operations and maintain predictable conventions.
With only 2 tools, the surface feels minimal/thin despite the server connecting to 18 different API proxies. While functional for pure discovery (list + get), the count is borderline for the implied richness of the domain.
Covers the core read-only lifecycle for a directory service: discovery (list) and connection (get endpoint). Minor gap in filtering/search capabilities for the 18 servers, though listing all is acceptable at this scale.