Moltbook MCP Server

by thebenlamm

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Every tool has a distinct purpose targeting specific resources and actions, with clear boundaries. For example, create_post vs. get_post vs. delete_post are unambiguous, and voting tools are separated by target (post vs. comment). No overlapping functionality exists that would cause confusion.
Naming Consistency5/5
All tools follow a consistent 'moltbook_verb_noun' pattern with snake_case throughout. The naming is predictable and systematic, making it easy to understand each tool's function at a glance without any deviations in style.
Tool Count4/5
With 17 tools, the count is slightly high but reasonable for a social media platform server covering posts, comments, voting, following, feeds, search, and state management. Each tool serves a clear purpose, though some could potentially be consolidated (e.g., upvote/downvote tools).
Completeness5/5
The toolset provides comprehensive coverage for a Moltbook client, including full CRUD for posts and comments, voting, following, feed retrieval, notifications, search, and state tracking. There are no obvious gaps; agents can perform all expected social media interactions without dead ends.
Average 3.5/5 across 17 of 17 tools scored. Lowest: 2.6/5.
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
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

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 only states the action ('Follow an agent') and basic input/output, without disclosing behavioral traits like whether this requires authentication, what 'Follow result' contains, if there are rate limits, or side effects (e.g., notifications). This is inadequate for a mutation tool with zero annotation coverage.
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 brief and structured with 'Args:' and 'Returns:' sections, making it easy to parse. However, the 'Returns:' section ('Follow result.') is overly vague and could be more informative without sacrificing conciseness.
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 a mutation tool ('follow'), the description is incomplete. It lacks details on authentication, error conditions, return values, and how it integrates with the system (e.g., Moltbook platform context). More context is needed for effective use.
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 description coverage is 0%, so the description must compensate. It adds minimal semantics by specifying 'name: Agent name to follow', which clarifies the parameter's role beyond the schema's generic 'Name' title. However, it doesn't explain format constraints (e.g., string pattern) or provide examples, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Follow an agent' which provides a basic verb+resource combination, but it's vague about what 'follow' means in this context (e.g., social media follow, notification subscription, tracking). It doesn't distinguish from sibling 'moltbook_unfollow' beyond the opposite action. The purpose is understandable but lacks specificity.
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 (e.g., authentication), when not to use it, or how it relates to sibling tools like 'moltbook_unfollow' or 'moltbook_get_profile'. The agent must infer usage from context alone.
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 full burden but offers minimal behavioral insight. It mentions 'Unfollow result' but doesn't explain what that entails (success/failure indicators, side effects, or error conditions). For a mutation tool with zero annotation coverage, this is inadequate.
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 brief and front-loaded with the core purpose. The Args/Returns sections are structured but could be more integrated; however, every sentence serves a clear purpose without redundancy.
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?
For a mutation tool with no annotations, no output schema, and minimal parameter documentation, the description is incomplete. It fails to address critical aspects like what 'Unfollow result' contains, potential errors, or the impact on the user-agent relationship, leaving significant gaps for agent understanding.
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 description coverage is 0%, so the description must compensate but only adds basic clarification that 'name' is the 'Agent name to unfollow'. This provides marginal semantic value beyond the schema's title 'Name', meeting the baseline for minimal parameter documentation.
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 action ('Unfollow') and target ('an agent'), providing a specific verb+resource combination. However, it doesn't differentiate from the sibling 'moltbook_follow' tool beyond the obvious opposite action, missing explicit comparison that would warrant a score of 5.
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 or any prerequisites. The description lacks context about the relationship between following and unfollowing, or any conditions for successful unfollowing.
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 lacks behavioral details. It mentions 'toggle off a previous upvote' with 'force', hinting at mutation, but doesn't disclose permissions, side effects, rate limits, or what 'Vote result' entails. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by structured 'Args' and 'Returns' sections. It's efficient with minimal waste, though the 'Returns' section is vague ('Vote result'). Overall, it's well-structured and appropriately sized.
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 basic purpose and parameters but lacks details on authentication, error handling, return format, and interaction with sibling tools. For a mutation tool with two parameters, this leaves significant gaps.
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 0%, so the description compensates by explaining both parameters: 'comment_id' as 'The comment UUID to upvote' and 'force' as 'Set True to intentionally toggle off a previous upvote'. This adds crucial meaning beyond the bare schema, clarifying the toggle behavior for 'force'.
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 action ('Upvote') and resource ('a comment'), distinguishing it from sibling tools like 'moltbook_upvote_post' which targets posts instead of comments. However, it doesn't specify what 'upvote' means in this context (e.g., incrementing a score, adding a like).
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 explicit guidance on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites (e.g., authentication), differentiate from 'moltbook_downvote_post', or explain scenarios for using 'force'. Usage is implied but not articulated.
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 the return type ('List of notifications') and examples of notification types, but lacks critical behavioral details like authentication needs, rate limits, pagination, or error handling. For a read operation with zero annotation coverage, this is insufficient.
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 brief and front-loaded with the main purpose. The second sentence provides useful return details without redundancy. It could be slightly more structured but is efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema, no annotations), the description is minimally adequate. It covers the purpose and return examples, but lacks behavioral context like how 'recent' is defined or notification format. Without annotations or output schema, more detail would improve completeness.
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 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description does not add param semantics, but this is acceptable given the lack of parameters, aligning with the baseline for 0 params.
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 'Get' and the resource 'recent notifications', specifying what the tool does. It distinguishes from siblings like 'get_feed' or 'get_home' by focusing on notifications, though it doesn't explicitly contrast them. The purpose is specific and actionable.
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. The description does not mention context, prerequisites, or exclusions, such as how it differs from other 'get' tools like 'get_feed' or 'get_comments'. Usage is implied only by the tool name and description.
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 action ('Delete') but doesn't disclose behavioral traits like whether deletion is permanent, requires confirmation, has rate limits, or what permissions are needed beyond 'your own'. The mention of 'Success or error message' hints at output but is vague. For a mutation tool with zero annotation coverage, this is inadequate.
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 sized with a clear main sentence and structured Args/Returns sections. Every sentence adds value: the first states the action, and the sections clarify input and output. It could be slightly more front-loaded by integrating key details into the opening, but it's efficient with zero waste.
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 (a deletion tool with mutation), no annotations, no output schema, and low schema coverage, the description is incomplete. It misses critical details like behavioral consequences (e.g., permanence), error conditions, or output specifics beyond 'message'. For such a tool, more context is needed to ensure safe and correct usage.
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 description adds meaning beyond the input schema by specifying that 'post_id' is a 'UUID' and relates to 'your own post', which clarifies the parameter's purpose and constraints. With 0% schema description coverage and 1 parameter, this compensates well, though it doesn't detail format or validation rules. Baseline would be 3 if schema coverage were high, but here it's above baseline.
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 ('Delete') and resource ('your own post'), making the purpose specific and understandable. It distinguishes from siblings like 'moltbook_create_post' or 'moltbook_get_post' by focusing on deletion. However, it doesn't explicitly differentiate from hypothetical alternatives like 'delete_any_post' or 'archive_post', keeping it at 4 rather than 5.
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 context with 'your own post', suggesting it's for personal posts rather than others'. However, it lacks explicit guidance on when to use this vs. alternatives (e.g., no mention of whether it's irreversible or if there are restrictions beyond ownership). No clear exclusions or named alternatives are provided, so it's only 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 provided, the description carries full burden for behavioral disclosure. It mentions the 'force' parameter's toggle behavior, which is useful, but doesn't cover important aspects like authentication requirements, rate limits, side effects on post visibility or user reputation, error conditions, or what constitutes a successful downvote. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
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 efficiently structured with a clear purpose statement followed by organized parameter and return value sections. Every sentence earns its place: the first states the core action, the Args section explains parameters concisely, and the Returns section acknowledges the output. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description provides adequate basic information but lacks completeness. It covers the core action and parameters well, but doesn't address authentication, error handling, side effects, or what the 'Vote result' actually contains. For a tool that modifies data, more behavioral context would be beneficial despite the concise structure.
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 description explicitly documents both parameters with meaningful explanations: 'post_id' as 'The post UUID to downvote' and 'force' as 'Set True to intentionally toggle off a previous downvote'. With 0% schema description coverage, this provides essential semantic context that the bare schema lacks. The explanation of the toggle behavior for 'force' is particularly valuable beyond basic parameter documentation.
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 'downvote' and resource 'a post', making the purpose immediately understandable. It distinguishes from siblings like 'upvote_post' by specifying downvote action, though it doesn't explicitly contrast with other voting or post-modification tools beyond the obvious directional difference.
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 about when to use this tool versus alternatives. While the name implies it's for downvoting (vs upvoting), there's no mention of prerequisites, appropriate contexts, or comparison to sibling tools like 'delete_post' or other post-modification options. The description simply states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the return format ('Tree-structured comments with replies nested') which is helpful, but doesn't address important behavioral aspects like whether this is a read-only operation, authentication requirements, rate limits, error conditions, or what happens with invalid parameters. The description doesn't contradict annotations (since none exist), but leaves significant gaps.
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 perfectly structured and concise. It starts with the core purpose, then provides a clean Args section with bullet-point explanations, and ends with Returns information. Every sentence earns its place, with no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 4 parameters and no output schema, the description does a good job explaining parameters and return format. However, with no annotations and no output schema, it should ideally address more behavioral aspects like authentication needs, error handling, or whether this is a safe read operation. The parameter explanations are excellent, but other contextual gaps remain.
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 description provides excellent parameter semantics beyond the schema, which has 0% description coverage. It explains what 'post_id' represents (UUID), enumerates the valid values for 'sort' ('best', 'new', or 'old'), specifies the range for 'limit' (1-100), and clarifies that 'cursor' is for pagination from previous responses. This fully compensates for the schema's lack of descriptions.
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 ('Get') and resource ('threaded comments on a post'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'moltbook_get_post' by focusing specifically on comments rather than post content. However, it doesn't explicitly contrast with 'moltbook_thread_diff' which might also involve comment threads.
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. While it's clear this retrieves comments, there's no mention of when to use it versus 'moltbook_get_post' (which might include comments) or 'moltbook_thread_diff' (which might compare comment threads). No prerequisites or exclusions are stated.
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 full burden for behavioral disclosure. It states this is a view operation (implied read-only) and describes the return content, but doesn't address important behavioral aspects like whether this requires authentication, rate limits, what 'tracked engagement' means, or how fresh the data is. The description adds some value but leaves significant gaps.
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 extremely concise and well-structured with clear sections (purpose, args, returns). Every sentence earns its place, and the information is front-loaded with the core purpose stated first. No wasted words or redundancy.
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's simple nature (single optional parameter, output schema exists), the description is reasonably complete. It explains the purpose, parameter semantics, and return content. The existence of an output schema means the description doesn't need to detail return values. However, for a state-summary tool with no annotations, it could better explain what 'engagement state' encompasses.
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 description provides meaningful context for the single parameter 'fmt' by explaining what 'compact' and 'full' mean ('one-liner' vs 'detailed breakdown'), which adds value beyond the schema's basic type/name information. With 0% schema description coverage and only 1 parameter, the description adequately compensates for the schema's lack of semantic information.
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 as 'View engagement state summary' which is a specific verb ('View') + resource ('engagement state summary'). It distinguishes from siblings like create/delete/vote tools by focusing on read-only state viewing. However, it doesn't explicitly differentiate from other read tools like get_profile or get_notifications.
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 about when to use this tool versus alternatives. The description doesn't mention when this tool is appropriate versus other state-viewing tools like get_profile or get_notifications, nor does it provide any context about prerequisites or exclusions.
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. It clarifies that upvoting is toggleable (via 'force'), which is useful behavioral context. However, it lacks details on permissions, rate limits, side effects, or what happens if the post doesn't exist, leaving significant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns) and uses minimal sentences. However, the 'Returns' section is slightly vague ('Vote result with author info and follow status'), and the purpose statement could be more front-loaded with context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is moderately complete. It covers parameters and return intent but lacks details on error handling, authentication, or the exact structure of the vote result. Given the complexity, it should provide more behavioral context.
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 0%, so the description must compensate. It explains both parameters: 'post_id' as 'The post UUID to upvote' and 'force' as 'Set True to intentionally toggle off a previous upvote'. This adds crucial meaning beyond the bare schema, though it could elaborate on UUID format or default behavior.
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 ('upvote') and resource ('a post'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from its sibling 'moltbook_upvote_comment' (which upvotes comments instead of posts), 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 no guidance on when to use this tool versus alternatives like 'moltbook_downvote_post' or 'moltbook_upvote_comment'. It mentions the 'force' parameter's effect but doesn't explain broader usage contexts, 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?
With no annotations provided, the description carries full burden but lacks behavioral details. It states it 'Returns: Full post with title, content, author, score, comment count, timestamps,' which adds some context about output format, but doesn't cover error handling, authentication needs, rate limits, or whether it's read-only (implied by 'Get' but not explicit). For a tool with zero annotation coverage, this is insufficient.
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 front-loaded with the core purpose in the first sentence, followed by structured 'Args' and 'Returns' sections. It's efficient with minimal waste, though the 'Returns' section could be slightly more concise by integrating with the main sentence without separate headings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 parameter, no output schema, no annotations), the description is moderately complete: it covers purpose, parameter semantics, and return values. However, it lacks behavioral transparency details like error cases or authentication, making it adequate but with clear gaps for a read operation.
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 description adds meaningful context beyond the input schema: it specifies that 'post_id' is a 'UUID' (clarifying format) and explains what the parameter is for ('The post UUID'). With schema description coverage at 0% (no schema descriptions) and only 1 parameter, this adequately compensates, though it could note UUID format constraints more explicitly.
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 specific action ('Get a single post') and resource ('by ID'), distinguishing it from siblings like 'moltbook_get_feed' (multiple posts) or 'moltbook_get_comments' (comments). The verb 'Get' is precise and unambiguous for a retrieval operation.
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 when you need a specific post by its ID, but provides no explicit guidance on when to use this versus alternatives like 'moltbook_get_feed' for multiple posts or 'moltbook_search' for broader queries. There's no mention of prerequisites or exclusions, leaving usage context inferred rather than stated.
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 the return content ('karma, followers, recent posts/comments'), which adds value. However, it doesn't disclose critical behavioral traits: whether authentication is required, rate limits, error conditions, or if it's read-only (implied but not stated). For a tool with no annotations, this is a significant gap.
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 appropriately sized and front-loaded. The first sentence states the purpose clearly. The Args and Returns sections are structured efficiently, with each sentence earning its place by providing essential information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, the description is partially complete. It covers the parameter semantics well and outlines return values, but lacks details on authentication, errors, or behavioral constraints. For a read operation with implied complexity (profile data), it's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema. The schema has 1 parameter (name) with 0% description coverage and no details. The description explains: 'Agent name to look up. Omit for your own profile.' This clarifies the parameter's purpose, optionality, and default behavior, fully compensating for the low schema coverage.
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: 'Get an agent's profile.' It specifies the verb ('Get') and resource ('agent's profile'), distinguishing it from siblings like create_post or follow. However, it doesn't explicitly differentiate from other get_* tools (e.g., get_comments, get_post), which slightly reduces specificity.
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 provides implied usage guidance: 'Omit [name] for your own profile.' This suggests when to use the tool for self vs. others. However, it lacks explicit when-not-to-use scenarios or alternatives (e.g., vs. get_post for post details), and doesn't mention prerequisites like authentication.
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 full burden for behavioral disclosure. It describes the return format ('List of posts with title, author, score, comment count, and content preview') and mentions pagination via cursor, which adds useful context beyond basic functionality. However, it doesn't disclose rate limits, authentication requirements, whether it's read-only (implied but not stated), or error conditions.
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 well-structured and appropriately sized. It starts with the core purpose, then provides a clear 'Args:' section with bullet-like formatting, followed by a 'Returns:' section. Every sentence earns its place by providing essential information without redundancy. The formatting makes it easy to scan and understand.
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's moderate complexity (5 parameters, no output schema, no annotations), the description is quite complete. It explains all parameters thoroughly, describes the return format, and mentions pagination. The main gap is lack of authentication/rate limit information and clearer differentiation from sibling tools, but for a feed retrieval tool, it provides sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully compensate. It provides comprehensive parameter documentation: clear explanations of all 5 parameters including sort options with values ('hot', 'new', 'top', 'rising'), limit range (1-100), filter options ('all', 'following'), submolt purpose, and cursor usage for pagination. This adds significant meaning beyond what the bare schema provides.
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 as 'Get the Moltbook feed' - a specific verb ('Get') and resource ('Moltbook feed'). It distinguishes from siblings like 'moltbook_get_home' or 'moltbook_get_post' by focusing on the feed rather than home page, specific posts, or other resources. However, it doesn't explicitly differentiate from 'moltbook_search' which might also return 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. It doesn't mention when to use 'moltbook_get_home' instead, when 'moltbook_search' might be more appropriate, or any prerequisites for using the feed. The only implied usage is for retrieving feed content, but no explicit alternatives or exclusions 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a 'comprehensive summary' with specific components (notifications, DMs, etc.), which adds behavioral context beyond a basic read operation. However, it lacks details on permissions, rate limits, or error handling, leaving gaps for a tool with no annotation support.
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 front-loaded with the core purpose in the first sentence, followed by details on the return value and usage guidance. Every sentence adds value: the first defines the tool, the second explains what it returns, and the third provides context for use. It's concise with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description does a decent job by specifying the return components and usage context. However, for a tool that returns a 'comprehensive summary,' more detail on the structure or format of the output would be helpful, especially without an output schema. It's adequate but has clear gaps in completeness.
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 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't discuss parameters, focusing on the tool's purpose and output. A baseline of 4 is applied as it efficiently handles the lack of parameters without unnecessary details.
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: 'Get the Moltbook home dashboard' with a specific verb ('Get') and resource ('Moltbook home dashboard'). It distinguishes itself from siblings like 'moltbook_get_feed' or 'moltbook_get_notifications' by specifying it returns a comprehensive summary including those elements. However, it doesn't explicitly contrast with all siblings, keeping it at a 4 rather than a 5.
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 for usage: 'Start here every check-in' implies this is the initial tool to use for regular updates, suggesting it as a starting point over alternatives. It doesn't explicitly list when not to use it or name specific alternatives, but the guidance is practical and contextually useful.
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?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: content is privacy-filtered, automatically handles verification challenges, and is logged to an engagement log. It also mentions return values (created comment data or privacy rejection reason). However, it doesn't cover aspects like error conditions, rate limits, or authentication needs.
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 well-structured and concise. It starts with the core purpose, lists key behaviors in bullet-like form, provides a clear 'Args' section with parameter semantics, and ends with return information. Every sentence adds value without redundancy.
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 no annotations and no output schema, the description does a good job covering the tool's behavior, parameters, and return values. It mentions privacy filtering, verification, logging, and possible rejection reasons. However, for a mutation tool, it could benefit from more details on error handling or side effects to be fully complete.
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 0%, so the description must compensate. It provides semantic context for all three parameters: 'post_id' as a UUID for the post to comment on, 'content' as comment text, and 'parent_id' as an optional UUID for replies. This adds meaningful interpretation beyond the bare schema, though it doesn't specify format details like UUID structure.
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: 'Create a comment or reply on a post.' It specifies the verb ('create') and resource ('comment or reply'), but doesn't explicitly differentiate from siblings like 'moltbook_upvote_comment' or 'moltbook_get_comments'. The distinction is implied but not stated.
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 context through the parameter descriptions (e.g., 'parent_id' for replies) and mentions privacy filtering and logging, but doesn't explicitly state when to use this tool versus alternatives like 'moltbook_upvote_comment' or 'moltbook_get_comments'. No explicit when-not or alternative guidance is 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context beyond basic functionality: it mentions privacy filtering before submission, automatic handling of verification challenges, and logging to an engagement log. However, it does not cover aspects like rate limits, error handling, or authentication requirements, leaving some behavioral gaps.
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 well-structured with a clear opening sentence, followed by behavioral notes, and then organized sections for Args and Returns. It is appropriately sized without unnecessary fluff, though the behavioral notes could be slightly more integrated into the flow rather than listed as bullet-like points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a creation tool with 5 parameters, no annotations, and no output schema, the description is moderately complete. It covers key behavioral aspects and parameter semantics but lacks details on error responses, authentication needs, or return data structure beyond a vague mention. For a tool with no structured support, it should provide more comprehensive guidance on outputs and edge cases.
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 0%, so the description must compensate. It provides clear semantics for all 5 parameters: explains what 'submolt' is with examples, specifies character limits for 'title' and 'content', defines 'post_type' options and default, and clarifies 'url' usage conditional on 'post_type'. This adds significant meaning beyond the bare schema, though it could detail validation rules more explicitly.
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: 'Create a new post on Moltbook.' It specifies the verb ('create') and resource ('post'), and distinguishes it from siblings like delete_post, get_post, or upvote_post by focusing on creation rather than modification, retrieval, or interaction.
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 for creating posts on Moltbook but does not explicitly state when to use this tool versus alternatives. It mentions sibling tools like moltbook_create_comment, but no guidance is provided on choosing between creating a post versus a comment or other actions. Usage is contextually implied rather than explicitly defined.
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 describes the core behavior (fetching posts with new activity and reporting delta counts) but doesn't mention important details like whether this requires authentication, rate limits, how 'last view' is determined, or what happens if no new comments exist. It adds some context about what gets returned but lacks comprehensive 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 perfectly structured and concise: a clear purpose statement, a usage context sentence, and well-organized parameter/return sections. Every sentence earns its place with no wasted words, and the information is front-loaded with the core functionality stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 (tracking new comments across posts), no annotations, no output schema, and 1 parameter with good description coverage, the description is adequate but has gaps. It explains what the tool does and the parameter, but doesn't describe the return format in detail (what fields posts include, how delta counts are structured) or address behavioral aspects like authentication needs.
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 description adds significant meaning beyond the input schema, which has 0% description coverage. It explains the 'scope' parameter's two possible values ('engaged' and 'all') and what they mean, which the schema only lists as a string type with a default. Since schema coverage is low, the description effectively compensates by providing the necessary parameter semantics.
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 with specific verbs ('Check tracked posts', 'Fetches posts', 'reports any with new activity') and distinguishes it from siblings by focusing on detecting new comments in previously engaged posts. It specifies the exact resource (posts with new comments) and differentiates from general feed or notification tools.
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 for when to use this tool ('Useful for catching replies to your comments or posts'), but doesn't explicitly state when not to use it or name specific alternatives among the sibling tools. It implies usage for monitoring engagement rather than general browsing or posting.
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 full burden. It discloses key behavioral traits: AI-powered semantic matching, similarity scores (0-1), pagination via cursor, and character limits (max 500 chars). However, it doesn't mention rate limits, authentication requirements, or error conditions that would be helpful for a search 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?
Perfectly structured with a clear opening sentence stating purpose, followed by organized Args and Returns sections. Every sentence earns its place by providing essential information without redundancy. The description is appropriately sized and front-loaded with the core functionality.
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 search tool with 4 parameters, 0% schema coverage, and no output schema, the description does well by explaining parameters and return format. However, without annotations or output schema, it could benefit from more behavioral context like error handling or performance characteristics to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 provides excellent parameter semantics: explains query supports natural language with character limit, limit range and default, type options and default, and cursor purpose for pagination. This adds substantial meaning beyond the bare 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?
The description clearly states the tool performs 'semantic search across Moltbook posts and comments,' specifying both the verb (search) and resources (posts/comments). It distinguishes itself from sibling tools like moltbook_get_feed or moltbook_get_comments by emphasizing AI-powered semantic matching rather than simple retrieval.
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 semantic search scenarios but doesn't explicitly state when to use this tool versus alternatives like moltbook_get_feed (for chronological content) or moltbook_get_comments (for specific post comments). It provides context about search capabilities but lacks explicit 'when-not' guidance or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

[![moltbook-mcp MCP server](https://glama.ai/mcp/servers/thebenlamm/moltbook-mcp/badges/score.svg)](https://glama.ai/mcp/servers/thebenlamm/moltbook-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/thebenlamm/moltbook-mcp'

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