JSONPlaceholder MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness3/5
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.
Average 2.9/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/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: '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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure 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.
Conciseness5/5
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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and 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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives 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.
Behavior2/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 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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/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 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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/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: '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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.

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:

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

Score Badge

Copy to your README.md:

[![mcp-JSONPlaceholder MCP server](https://glama.ai/mcp/servers/danielpdev/mcp-JSONPlaceholder/badges/score.svg)](https://glama.ai/mcp/servers/danielpdev/mcp-JSONPlaceholder)

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/danielpdev/mcp-JSONPlaceholder'

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