OwlStack MCP

Official

by owlstacks

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct resource and action. Post operations are split clearly (get, list, schedule, edit, cancel, delete, delivery), account tools are separate, and AI tools have distinct purposes (caption generation, platform rewriting, URL repurposing). The minimal overlap between get_post and list_post_deliveries is acceptable since the latter provides per-account detail.
Naming Consistency5/5
All tools follow a consistent verb_noun snake_case pattern (e.g., list_posts, schedule_post, get_account_health). Even multi-word actions like repurpose_url and rewrite_for_platforms maintain the structure. No mixing of casing or verb styles.
Tool Count5/5
14 tools is well within the ideal range and each tool earns its place. The count covers post CRUD, delivery, accounts, workspaces, and AI features without feeling bloated or sparse for the domain.
Completeness4/5
The core content scheduling lifecycle is fully covered: create, read, update, cancel, delete, and track delivery. Account management is read-only plus health checks, which is sufficient for the stated purpose. Minor gaps like no single-workspace getter or account update tool exist, but they are not critical for typical workflows.
Average 3.9/5 across 14 of 14 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It adds 'Costs 1 AI credit,' which is useful economic context, and hints that the operation may create or modify content. However, it omits expected output format, permissions, rate limits, and side effects beyond the cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the core purpose before optional details, with no filler.
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 tool with four optional parameters and no output schema, a 31-word description leaves gaps including char_limit, workspace_id, and return value expectations. But it does establish purpose, optional inputs, and cost, so it's minimally adequate.
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 coverage is 0%, so the description must compensate. It explains 'current draft text' and 'target platforms for tone-aware output,' mapping to two parameters, but char_limit and workspace_id are never described; the description does not fully compensate for the schema gap.
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?
Description uses 'Generate or improve a social media caption with AI,' specifying both action and resource. It mentions optional draft and platforms, which adds scope. However, it doesn't explicitly differentiate from sibling 'rewrite_for_platforms,' which appears to handle similar caption rewriting, so it isn't 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives context for optional current_caption and platforms for tone-aware output, which guides parameter usage. But there is no explicit when-to-use or alternative recommendation, such as referencing rewrite_for_platforms.
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, the description must disclose behavioral traits. It does disclose the cost (6 AI credits per call) and the 'single call' behavior, which is useful. However, it does not clarify whether the generated posts are saved, returned, or scheduled, leaving a significant ambiguity about side effects and output.
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 three sentences and each provides unique value: function, positioning, and cost. It is concise with no filler, though 'write once, get 16 versions' is slightly redundant and possibly inaccurate, which prevents a perfect score.
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?
The tool has no output schema and no annotations, so the description must explain what happens after generation. It fails to mention return format, whether posts are persisted, or how to retrieve them. It also omits any requirement for workspace_id. This leaves the agent without crucial context for a complex feature.
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 covers the url param ('Fetch a blog/article URL') and the platforms param ('per requested platform'), but completely ignores workspace_id. Additionally, the '16 versions' claim contradicts the 20-item platform enum, potentially misleading the agent about the allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Fetch') and resource ('blog/article URL'), then explains the main output: generate one optimized post per requested platform. It also distinguishes itself by emphasizing the 'single call' and '16 versions' aspect, which sets it apart from sibling tools like rewrite_for_platforms.
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?
It provides context that this is the 'flagship Developer Content Stack feature' and mentions 'write once, get 16 versions', implying a bulk repurposing use case. However, it does not explicitly state when to use this vs alternatives (e.g., rewrite_for_platforms, generate_caption), and gives no 'when not to use' guidance.
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, the description carries the burden of disclosing behavior. It states 'Only provided fields are changed,' which reveals partial-update semantics, a key behavioral trait. However, it does not disclose potential side effects (e.g., rescheduling behavior when schedule_at is updated, impact on existing deliveries) or error conditions, so transparency is incomplete.
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, consisting of two short sentences. It is front-loaded with the core purpose and adds a key behavioral detail without any fluff. Every word earns its place.
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?
The tool has 4 parameters, no annotations, and no output schema, so the description should provide more context. It only covers purpose and partial-update behavior, but omits return values, error handling, side effects, and any guidance on how the parameters interact. This is inadequate for a mutation tool with this complexity.
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 coverage is low at 25%—only the 'id' parameter has a description. The description adds no information about the meanings or usage of 'labels', 'content', or 'schedule_at'. It only mentions the patch behavior, which does not compensate for the missing 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 uses the specific verb 'Update' with the resource 'post', and clarifies it applies to an existing post, distinguishing it from creation or deletion. This is clear and specific, and the sibling tools like get_post, delete_post, and schedule_post are clearly differentiated by the intent to modify an existing post.
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 the tool is for updating existing posts, which gives some contextual guidance. However, it does not explicitly state when to use this tool over alternatives like schedule_post, which could also modify schedule_at, or mention any exclusions. The guidance is mostly implied rather than explicit.
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 indicates a read-only 'Show' operation and lists possible statuses, but does not disclose response shape, error behavior, whether all accounts are included, or any other behavioral details. This is acceptable for a simple read tool but lacks depth.
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, front-loaded sentence that states the action and includes the relevant status values. No unnecessary words or repetition.
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 one-parameter read-only tool with no output schema, the description covers the essential purpose and status vocabulary, but lacks details on the response format, potential errors, or account coverage. It is minimally complete but does not exceed the baseline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single 'id' parameter (100% coverage as 'Post id (uuid)'). The description's phrase 'for a post' merely restates the schema, adding no new semantic value. Baseline 3 applies because the schema already carries the parameter meaning.
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 specifies a clear verb ('Show') and resource ('per-account delivery status'), and enumerates the status types ('queued, publishing, published, failed') with the scope 'for a post.' This strongly distinguishes it from sibling tools like list_posts or get_post.
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 usage is implied: one would use this to check delivery status of a post. However, there is no explicit guidance on when to use this versus alternatives (e.g., get_post) or any exclusions, so the context is clear but not fully enumerated.
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, the description carries full burden for behavioral disclosure. It states that the tool 'checks' and 'tells you' about token freshness and rate-limit headroom, implying a read-only operation. However, it does not disclose potential side effects, whether it makes external API calls that consume rate limits, or the meaning of 'headroom' in terms of return values. This is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action and purpose. Every sentence adds value: the first defines what the tool does, the second provides context and an example use case. There is no wasted wording.
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 simple tool with one parameter and no output schema, the description explains the tool's input and purpose but does not describe the return format or how to interpret 'rate-limit headroom.' Since there is no output schema, the description should clarify what the agent can expect in the response. This gap makes the description incomplete, though it covers the core use case.
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. The description mentions 'a single account' but does not explicitly name or explain the 'account_id' parameter, its format, or where to obtain it. The schema provides type/format but no semantic guidance. The agent would need to infer that account_id refers to the target account, but the description lacks sufficient detail.
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 function: 'Check token freshness and rate-limit headroom for a single account.' The verb 'check' is specific, the resource is 'account health', and it distinguishes itself from sibling tools like list_accounts by focusing on a single account's health rather than listing accounts. It accurately conveys the tool's unique purpose.
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 explicit guidance on when to use the tool: 'Useful when posts are failing — tells you if the OAuth token has expired.' This gives a clear context for invocation, though it does not explicitly mention alternatives or exclusions. The guidance is strong enough to inform an agent's decision, meriting a 4 rather than a 5.
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, the description carries the transparency burden. It adds return fields and filter options but does not explicitly state that the operation is read-only, nor does it describe default pagination behavior or edge cases. The 'list' wording implicitly indicates non-mutation.
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?
Three concise, front-loaded sentences: purpose, filtering, and return data. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers essential behavior (what it lists, filters, and returns). However, it lacks explicit guidance on when to use this tool vs. siblings and does not mention any limitations or ordering. It is adequate for a straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (status and workspace_id have descriptions). The description adds meanings by expanding status values and mentioning pagination, but it does not name limit/offset parameters or specify their roles beyond 'pagination'. Workspace_id is implied by 'in a workspace'.
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 uses the specific verb 'List' with a clear resource ('posts in a workspace'), and enumerates filters and return fields. It distinguishes the tool from siblings like 'get_post' (single post) and 'list_post_deliveries' (deliveries).
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 contexts (listing with status/pagination) but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. No reference to sibling tools is 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 burden. It discloses the returned fields but omits details like pagination, error behavior, or auth requirements. For a read-only list tool, this level of disclosure is moderate but not comprehensive.
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 consists of two short, informative sentences with the verb front-loaded and no redundant words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description adequately covers purpose and return fields, which is especially useful given the absence of an output schema. It lacks details on pagination or limits, but the overall context is reasonably complete relative to the tool's simplicity.
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 has one parameter (workspace_id) with 0% description coverage. The tool description does not explain the parameter's meaning or add any semantic nuance beyond the self-explanatory name and uuid format, leaving the compensation gap unfilled.
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 action ('List'), the resource ('connected social accounts'), and the scope ('in a workspace'), distinguishing it from sibling list tools like list_workspaces and list_posts.
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 by specifying the workspace scope and the returned fields (platform, username, primary flag, connection status), which implies when to use it. It does not explicitly mention exclusions or alternatives, but the purpose is unambiguous.
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 reveals the key behavior (post remains in system, not published), which is valuable. But it omits other potentially relevant traits like whether the cancellation is reversible, what happens if the post is already published, or any permission requirements. This is adequate but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and immediately clarifying the key distinction from deletion. Every word earns its place; no filler 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?
For a simple tool with one parameter and no output schema, the description covers the essential purpose and the most critical behavioral nuance. It lacks explicit error/state-mutation details, but given the low complexity, a score of 4 is appropriate rather than 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter id (uuid), giving it 100% coverage. The description adds no additional meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb+resource: 'Cancel a scheduled post.' It clearly distinguishes from sibling tools like delete_post by specifying the outcome: the post stays but will not be published. This is a precise, non-tautological statement of purpose.
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?
It states the tool is for scheduled posts and clarifies the distinction from deletion ('stays in the system but will not be published'), giving clear context for when to choose this over delete_post. However, it doesn't explicitly name alternative tools or list exclusions, so it falls short of a perfect 5.
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?
No annotations are provided, so the description carries the full burden. It discloses the critical behavioral trait of irreversibility ('Cannot be undone') and permanence, which warns the agent about destructive side effects. It does not describe additional consequences like cascading deletes, but the essential warning is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action and resource, followed by a short warning. Every word adds value with no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, single-parameter destructive tool with no output schema or annotations, the description adequately covers the core function and the key caveat (irreversibility). It could detail side effects or prerequisites, but given the low complexity, the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with a clear description for 'id' (Post id uuid). The tool description adds no additional parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate.
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 action ('Permanently delete') and the resource ('a post'), and the permanent nature distinguishes it from similar operations like cancel_post or edit_post.
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 permanent removal ('Permanently delete', 'Cannot be undone'), but does not explicitly mention when to prefer this over alternatives like cancel_post for scheduled posts. No exclusions or prerequisites 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?
With no annotations, the description carries the burden for behavioral disclosure. 'Fetch' implies a read-only operation with no side effects, and the mention of included data categories adds context. However, it does not explicitly discuss permissions, rate limits, or edge-case 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 one front-loaded sentence with no wasted words. It states the action, target, and result content in a scannable format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch-by-id tool, the description adequately covers the purpose and return scope by listing three content categories. It does not have an output schema, but the description gives a high-level idea of the response, though edge cases like 404s are not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single 'id' parameter with a description ('Post id (uuid)'), so schema coverage is 100%. The description merely repeats that it fetches by id, adding no additional semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Fetch', the resource 'a single post by id', and the scope 'full content, settings, and delivery records'. This distinguishes it from siblings like list_posts (listing multiple posts) and delete_post (mutation).
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 retrieving one post's complete data, which is clear context. However, it does not explicitly say when to use list_posts or list_post_deliveries instead, so it lacks explicit exclusions or alternatives.
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 states the tool 'Show's information, implying a read-only operation, but does not explicitly disclose that it has no side effects, or any authentication/rate-limit considerations. The behavior is largely obvious from the name and description, but lacks explicit safety disclosure.
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 sentence with only 14 words, front-loaded with the action verb 'Show'. Every word contributes to the meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description adequately covers what the tool does and what data it returns (balance, usage, reset date). This is sufficient for an agent to select and invoke it correctly, especially given the clear differentiation from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. The baseline for 0 params is 4, as there are no parameters for the description to explain. The description adds no parameter-related meaning, but none is needed.
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 uses the specific verb 'Show' and clearly identifies the resource: AI credit balance, usage, and reset date. This clearly distinguishes it from sibling tools like post management and account tools, leaving no ambiguity about its function.
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 clear context about what the tool does, but does not explicitly state when to use it or mention any alternatives. Since no sibling tool offers credit information, usage is implied rather than explicitly guided.
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?
The description discloses a valuable behavioral detail—cost per platform—which is beyond what the schema provides. It does not, however, mention whether the operation has side effects, the return structure, or any permission requirements. Since no annotations are present, the description carries the full burden but only partially meets it.
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: one sentence for the core function and one for the cost note. There is no fluff, and the most critical information is front-loaded.
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?
The description explains what the tool does and its cost but omits the return format and any error/side-effect behavior. Since there is no output schema and no annotations, this creates ambiguity for the agent. However, the platform enum in the schema and the clear purpose partially compensate for the missing output details.
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 gives functional meaning to the two required parameters: 'content' (the piece to rewrite) and 'platforms' (the targets with platform-specific tone/length). This compensates for the low schema coverage (25%). The 'tone' parameter is already described in the schema, and 'workspace_id' is a standard context parameter. The phrase 'platform-specific constraints' enriches the platforms enum.
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 action ('Rewrite a piece of content'), the target ('for one or more target platforms'), and the specific behavior ('applying platform-specific tone and length constraints'). This differentiates it from sibling tools like generate_caption or edit_post by focusing on multi-platform rewriting.
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 the usage context (adapting content for multiple platforms) and adds a cost consideration ('Costs 1 AI credit per platform') that helps decision-making. However, it does not explicitly name alternatives or state when NOT to use this tool, so it stops short of full exclusionary guidance.
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, the description is the sole source of behavioral context. It discloses that the result is scoped to the authenticated user's access, which is useful. However, it does not describe the return format, pagination, or confirm the read-only nature, though listing implies it.
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, front-loaded sentence with no redundant information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless list tool without an output schema, the description provides the essential context: purpose and access scoping. It could specify the return structure, but the overall complexity is low enough that the description is sufficient.
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 accepts zero parameters, and the schema shows a fully covered empty object. The description adds no parameter-specific details, but none are needed given the absence of parameters.
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 uses the specific verb 'List' with the resource 'workspaces' and adds the qualifier 'authenticated user has access to'. This clearly states the tool's function and differentiates it from sibling tools, none of which target workspaces.
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 the tool is used when the user needs to see their accessible workspaces. It doesn't explicitly mention alternatives or exclusions, but the context is clear enough that an agent would know when to invoke it.
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 behaviors: creating, scheduling, saving as draft, and publishing immediately. It does not mention side effects like irreversibility or auth requirements, but the core behavioral distinctions are clearly described.
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 three concise sentences with no redundancy. Each sentence adds distinct information: main action, draft behavior, and publish_now behavior. It is well-structured and front-loaded with the primary purpose.
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?
The description covers the primary modes and the main parameters, but it omits optional parameters like labels and media_urls, and does not mention the return value or post-creation behavior. Since there is no output schema, a brief note on what is returned would have improved 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 description adds meaning beyond the schema by explaining that omitting schedule_at saves as draft and that publish_now=true overrides scheduling. It also names the required parameters (body text, account_ids). It does not cover labels or media_urls, but those are optional and less critical.
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 a specific verb and resource: 'Create and schedule a post.' It distinguishes from sibling tools like edit_post, cancel_post, and list_posts by focusing on creation and scheduling. The mention of scheduling, draft, and immediate publishing further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool: pass body text, account ids, and an ISO 8601 schedule_at; omit schedule_at for draft; use publish_now=true for immediate publishing. However, it does not explicitly mention when to use this tool instead of alternatives like edit_post or cancel_post, so it lacks full exclusion guidance.
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:

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

Score Badge

Copy to your README.md:

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

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