Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@JSONPlaceholder MCP Server get user details for ID 5"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A modern Model Context Protocol (MCP) server built with FastMCP that provides access to the JSONPlaceholder API - a free fake REST API for testing and prototyping.
This MCP server provides Resources, Tools, and Prompts for interacting with JSONPlaceholder:
get_posts - Retrieve all posts or a specific post by ID
get_users - Retrieve all users or a specific user by ID
get_comments - Retrieve comments, optionally filtered by post ID
get_albums - Retrieve albums, optionally filtered by user ID
get_photos - Retrieve photos, optionally filtered by album ID
get_todos - Retrieve todos, optionally filtered by user ID
create_post - Create a new post (simulated)
search_posts - Search posts by title or body content
posts://all - Get all posts as a resource
posts://{post_id} - Get a specific post as a resource
users://all - Get all users as a resource
users://{user_id} - Get a specific user as a resource
analyze_post - Generate analysis prompt for a specific post
user_profile_summary - Create comprehensive user profile analysis
"mcpServers": {
"jsonplaceholder": {
"command": "/Users/danielpopa/Projects/work/mcp-server/cursor_runner.sh",
"args": []
}
}
} Python 3.10+
uv package manager
Clone or download this project
The project is already configured with uv. Simply run:
uv syncMCP Inspector (recommended for development):
uv run mcp dev server.pyThis opens an interactive web interface to test all tools, resources, and prompts.
Direct server execution:
uv run python server.pyTest API connectivity:
uv run python test_server.pyInstall directly into Claude Desktop:
uv run mcp install server.py --name "JSONPlaceholder API"Once connected to an MCP client, you can:
Use Tools:
"Get all posts from JSONPlaceholder"
"Show me user details for user ID 1"
"Search for posts containing 'dolor'"
"Create a new post titled 'Test' with body 'Hello World' for user 1"
Access Resources:
The client can load posts://all to get all posts as context
Load users://5 to get user 5's details as background information
Use Prompts:
Use the "analyze_post" prompt with post ID 1 for detailed post analysis
Use "user_profile_summary" with user ID 2 for comprehensive user profiling
Related MCP server: MockMCP
This server uses the JSONPlaceholder API (https://jsonplaceholder.typicode.com/), which provides:
100 posts
10 users
500 comments
100 albums
5000 photos
200 todos
No API key is required as it's completely free and public.
Built with FastMCP, this server demonstrates modern MCP patterns:
Decorator-based setup - Clean, Pythonic code
Type hints - Better development experience
Async/await - Efficient HTTP requests
Resource management - Proper data exposure to LLMs
Prompt templates - Reusable interaction patterns
Development tools - Built-in testing and debugging
The server uses:
FastMCP - Modern MCP server framework
httpx - Async HTTP client
Python 3.10+ - Modern Python features
uv - Fast Python package management
Create a new post (simulated - JSONPlaceholder doesn't actually store data)
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| body | Yes | ||
| user_id | Yes |
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 states this is a creation tool, implying mutation, and adds that it's simulated with no actual data storage, which is useful context about the tool's behavior. However, it lacks details on permissions, response format, or error handling, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Create a new post') and includes a brief, relevant note about simulation. Every word earns its place, with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It covers the simulated nature but misses critical details like parameter explanations, return values, or error conditions, making it inadequate for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It provides no information about the three required parameters (title, body, user_id), such as their meaning, constraints, or examples, failing to add value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('new post'), making the purpose specific and understandable. However, it doesn't distinguish this tool from potential siblings like 'search_posts' or 'get_posts' beyond the creation action, and the parenthetical note about simulation adds context but doesn't affect the core purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'get_posts' or 'search_posts'. It mentions that JSONPlaceholder doesn't actually store data, which hints at a simulated environment, but offers no explicit usage rules, prerequisites, or exclusions for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve albums, optionally filtered by user ID or get a specific album
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | No | ||
| album_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieval and filtering but lacks details on permissions, rate limits, pagination, or response format. For a read operation with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Retrieve albums') and adds necessary qualifiers without waste. Every word earns its place, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a retrieval tool with two parameters, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like response format or error handling, and parameter semantics are only partially addressed, failing to provide enough context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds some meaning by explaining that 'user_id' filters albums and 'album_id' retrieves a specific album, but it doesn't clarify if both can be used together, their data types, or default behaviors, leaving key semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieve') and resource ('albums'), and specifies optional filtering capabilities ('by user ID or get a specific album'). However, it doesn't explicitly differentiate from sibling tools like 'get_photos' or 'get_posts' that might also retrieve media-related data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the phrase 'optionally filtered by user ID or get a specific album,' suggesting when to use parameters, but it doesn't provide explicit guidance on when to choose this tool over alternatives like 'get_photos' or 'search_posts,' nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve comments, optionally filtered by post ID or get a specific comment
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | No | ||
| comment_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieval and filtering but fails to describe key behaviors such as whether this is a read-only operation, what permissions are needed, how results are returned (e.g., pagination, format), or any rate limits. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('retrieve comments') and adds necessary detail about optional filtering. There is no wasted language, and it is appropriately sized for the tool's complexity, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It covers the basic purpose and parameter intent but lacks information on behavioral traits, return values, error handling, or how it differs from siblings. For a retrieval tool with two parameters, this leaves too many contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for undocumented parameters. It adds some meaning by explaining that parameters allow filtering by post ID or getting a specific comment, which clarifies the purpose of 'post_id' and 'comment_id'. However, it doesn't provide details on parameter interactions, defaults, or constraints, leaving semantics partially unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and resource 'comments', making the purpose understandable. It specifies optional filtering by post ID or getting a specific comment, which adds specificity. However, it doesn't explicitly differentiate from sibling tools like 'get_posts' or 'search_posts', keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the mention of optional filtering parameters (post_id or comment_id), suggesting when to use these options. However, it lacks explicit guidance on when to choose this tool over alternatives like 'get_posts' or 'search_posts', and no exclusions or prerequisites are stated, making the guidance incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve photos, optionally filtered by album ID or get a specific photo
| Name | Required | Description | Default |
|---|---|---|---|
| album_id | No | ||
| photo_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves photos but doesn't disclose behavioral traits such as whether it's read-only, requires authentication, has rate limits, returns paginated results, or what happens with invalid inputs. The description is minimal and misses key operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Retrieve photos') and adds optional details. There is no wasted text, making it appropriately sized and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is incomplete. It covers the basic purpose but lacks details on behavior, parameter usage, return values, and error handling. For a retrieval tool with two parameters, this leaves significant gaps in understanding how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'filtered by album ID or get a specific photo', which loosely maps to the two parameters (album_id, photo_id), but doesn't explain their semantics, interactions, defaults, or constraints. The description adds some meaning but is insufficient for full parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve photos' with optional filtering by album ID or specific photo. It uses a specific verb ('Retrieve') and resource ('photos'), though it doesn't explicitly distinguish from sibling tools like 'get_albums' or 'get_users' which retrieve different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'optionally filtered by album ID or get a specific photo', suggesting when to use parameters, but provides no explicit guidance on when to choose this tool over alternatives like 'get_albums' or general search tools. It lacks context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve all posts or a specific post by ID from JSONPlaceholder
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | No |
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 states the tool retrieves data, implying it's a read operation, but doesn't disclose important behavioral traits like whether it requires authentication, has rate limits, returns paginated results, or what happens when an invalid ID is provided. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with a single sentence that efficiently communicates the core functionality. It's front-loaded with the main purpose and doesn't contain unnecessary words or redundant information. However, it could be slightly more structured by explicitly separating the two use cases (all posts vs. specific post).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieval with optional filtering), lack of annotations, no output schema, and minimal parameter documentation, the description is incomplete. It doesn't explain what the return format looks like, error conditions, or how to handle the optional parameter. For a tool that could return either a list or single item, more context is needed for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions retrieving 'a specific post by ID', which corresponds to the 'post_id' parameter in the schema. However, with 0% schema description coverage and only one parameter, the description doesn't adequately explain parameter semantics. It doesn't clarify what happens when 'post_id' is null (retrieving all posts) versus provided, or the format/constraints of the ID. The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve all posts or a specific post by ID from JSONPlaceholder'. It specifies the verb ('retrieve'), resource ('posts'), and scope ('all' or 'by ID'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'search_posts' or 'create_post', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance on when to use this tool. It mentions retrieving 'all posts or a specific post by ID', but doesn't clarify when to use it versus alternatives like 'search_posts' (for filtering) or 'create_post' (for adding posts). There's no explicit when/when-not guidance or mention of prerequisites, leaving usage context largely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve todos, optionally filtered by user ID or get a specific todo
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | No | ||
| todo_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions retrieval and filtering options but doesn't disclose behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, or what happens when both parameters are provided. The description is minimal and misses key operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, no output schema, and two parameters, the description is incomplete. It lacks details on return values, error conditions, and full parameter usage, making it inadequate for a tool with this complexity. The description does not compensate for the missing structured information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'filtered by user ID' and 'get a specific todo', which loosely maps to the two parameters, but doesn't explain semantics like how filtering works, whether parameters are exclusive, or default behaviors. This adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieve') and resource ('todos'), making the purpose understandable. It distinguishes between retrieving all todos versus filtered/specific ones, though it doesn't explicitly differentiate from sibling tools like 'get_users' or 'get_posts' which might have similar retrieval patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'optionally filtered by user ID or get a specific todo', suggesting when to use parameters, but lacks explicit guidance on when to choose this tool over alternatives like 'search_posts' or other get_* siblings. No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve all users or a specific user by ID
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action. It lacks details on permissions, rate limits, pagination for 'all users', or response format, which are critical for a retrieval tool with potential behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality without waste. It's appropriately sized for the tool's scope, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't address key aspects like return values, error handling, or behavioral context needed for effective tool use in this environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'user_id' for retrieving a specific user, but doesn't explain the parameter's semantics, such as what happens when it's null or omitted, or format details, leaving gaps in understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and resource 'users', specifying it can fetch all users or a specific one by ID. However, it doesn't differentiate from sibling tools like 'get_albums' or 'get_posts' beyond the resource type, missing explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites, context for user retrieval, or comparisons to other tools like 'search_posts' for user-related queries, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search posts by title or body content
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
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 but only states the basic action. It doesn't cover important aspects such as whether the search is case-sensitive, supports partial matches, returns paginated results, or has rate limits, which are critical for an agent to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it easy to parse. It's appropriately sized for the tool's apparent simplicity, though this conciseness comes at the cost of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It fails to explain the tool's behavior, return values, or error handling, which are essential for a search operation. The minimal information provided doesn't suffice for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only vaguely mentions 'title or body content' without detailing the 'query' parameter's format, syntax, or examples. This leaves the parameter's meaning unclear beyond the basic schema type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('search') and resource ('posts') with the search criteria ('by title or body content'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'get_posts', which might retrieve posts differently (e.g., by ID or all posts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'get_posts' or other sibling tools. It lacks context about scenarios where searching by content is preferred over other retrieval methods, leaving usage decisions ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0create_postget_albumsget_commentsget_photosget_postsget_todosget_userssearch_postsMost tools are clearly distinct by resource type (posts, albums, comments, photos, todos, users), but 'get_posts' and 'search_posts' have overlapping purposes since both retrieve posts with different filtering approaches. The descriptions help clarify the distinction, but an agent might occasionally misselect between them.
All tools follow a consistent verb_noun pattern with 'create_' or 'get_' or 'search_' prefixes, all in snake_case. This predictability makes it easy for agents to understand and use the tool set without confusion.
With 8 tools, this server is well-scoped for interacting with JSONPlaceholder's mock REST API resources. Each tool corresponds to a key resource (posts, albums, comments, photos, todos, users), and the count is neither too sparse nor bloated for the domain.
The server covers retrieval (get) operations for all major resources and creation for posts, but lacks update and delete operations, which are typical in CRUD workflows. This creates notable gaps that agents must work around, as they cannot modify or remove data beyond creating posts.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
JSONPlaceholder MCP — wraps JSONPlaceholder fake REST API (free, no auth)
DummyJSON mock REST: products, users, posts, recipes, todos. Keyless test data.
AI-callable tools for API mocking, testing, monitoring, security, and automation.
Hosted MCP endpoint with realistic fake data for prototyping agents. 12 tools, no setup.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/danielpdev/mcp-JSONPlaceholder'
If you have feedback or need assistance with the MCP directory API, please join our Discord server