Goose App Maker MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some potential confusion between app_open and app_serve, as both involve launching an app, and app_error's dual functionality for reporting and retrieving errors could be ambiguous. However, the descriptions clarify their specific roles, making them generally distinguishable.
Naming Consistency5/5
All tool names follow a consistent 'app_' prefix with a descriptive action in snake_case, such as app_create, app_delete, and app_list. This pattern is maintained throughout all nine tools, making them predictable and easy to understand.
Tool Count5/5
With 9 tools, the count is well-scoped for managing web applications, covering creation, deletion, listing, serving, opening, error handling, refreshing, responding, and stopping the server. Each tool serves a clear purpose without redundancy, fitting the domain appropriately.
Completeness4/5
The toolset provides comprehensive coverage for basic app lifecycle management, including CRUD operations and runtime interactions. A minor gap exists in the lack of an update tool for modifying existing apps, but agents can work around this by recreating apps or using other tools like app_response for content changes.
Average 3.5/5 across 9 of 9 tools scored. Lowest: 2.9/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 the full burden of behavioral disclosure. It states the tool deletes an app, implying a destructive mutation, but doesn't describe what 'delete' entails (e.g., irreversible removal, cleanup of resources, permissions required, or error handling). This leaves gaps in understanding the tool's behavior beyond the basic action.
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 and front-loaded: the first sentence states the purpose clearly, followed by structured sections for Args and Returns. There's no wasted text, and the structure aids readability, though the Returns section is vague ('A dictionary containing the result of the operation').
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 complexity (destructive operation with 1 parameter) and context (no annotations, schema coverage 0%, but has output schema), the description is minimally adequate. It covers the basic action and parameter, but lacks details on behavior, usage, and output specifics, even though the output schema might document return values. For a deletion tool, more guidance is needed.
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 description adds minimal semantics: it names the parameter ('app_name') and indicates it's 'Name of the application to delete.' With 0% schema description coverage, the schema provides no details, so the description compensates slightly by clarifying the parameter's role. However, it doesn't explain format, constraints, or examples, leaving the parameter only partially documented.
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: 'Delete an existing web application.' It specifies the verb ('Delete') and resource ('web application'), making the action unambiguous. However, it doesn't differentiate from sibling tools like 'app_stop_server' or 'app_error', which might also involve application management, so it doesn't fully distinguish from alternatives.
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 prerequisites (e.g., the app must exist or be stopped), exclusions (e.g., don't use if the app is running), or refer to sibling tools like 'app_list' to check before deletion. Usage is implied by the purpose but lacks explicit 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool stops a server, implying a destructive mutation, but doesn't clarify permissions needed, whether the action is reversible, side effects (e.g., interrupting active connections), or error handling. The mention of a return dictionary adds minimal value without details on its structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) and front-loaded with the core action, but the second sentence about returns is vague and adds little value without specifics. It could be more structured by integrating return details more meaningfully or omitted if covered by an output schema.
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 complexity (a destructive operation with no annotations), the description is minimally adequate. It states what the tool does but lacks critical behavioral context. The presence of an output schema mitigates the need to explain return values, but gaps remain in usage guidelines and transparency for a mutation tool.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing on the tool's action. A baseline of 4 is applied since it avoids unnecessary repetition of schema 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 action ('Stop') and target ('currently running HTTP server'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from its siblings like 'app_delete' or 'app_error', which might also affect server state, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 prerequisites (e.g., a server must be running), exclusions, or how it relates to sibling tools like 'app_serve' (which likely starts a server). This leaves the agent with minimal context for decision-making.
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. It mentions creating directories and copying files, but doesn't disclose critical behavioral traits like whether this requires specific permissions, if it overwrites existing directories, what happens on failure, or rate limits. The description adds some context about starter files but misses key operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and poorly structured, mixing operational instructions with usage advice. Sentences like 'After this, consider how you want to change the app...' don't belong in a tool description. It's front-loaded but then diverges into tangential guidance, reducing clarity.
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 2 parameters with 0% schema coverage and an output schema exists, the description adds some parameter semantics but lacks completeness. It doesn't explain the return dictionary structure or error conditions, and with no annotations, it should provide more behavioral context for a creation tool.
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 app_name will be used as the directory name and description is a brief description with a default, adding meaningful semantics beyond the bare schema. However, it doesn't cover constraints like character limits or validation rules.
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 creates a new web application directory and copies starter files, specifying the verb (create) and resource (web application directory). It distinguishes from siblings like app_delete or app_list by focusing on creation, though it doesn't explicitly contrast with app_open or app_serve.
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 new apps and mentions using app_error after creation, but doesn't explicitly state when to use this tool versus alternatives like app_open for existing apps or app_list for viewing. It provides some context but lacks clear when/when-not 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?
No annotations are provided, so the description carries full burden. It mentions the return format ('dictionary containing the list of available apps and their details'), which adds useful context beyond basic purpose. However, it doesn't disclose behavioral traits like whether this is a read-only operation, potential rate limits, or authentication requirements, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences: one stating the purpose and one describing the return value. It's front-loaded with the core functionality and avoids unnecessary details, though it could be slightly more structured by explicitly labeling sections.
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 simplicity (0 parameters, no annotations, but with an output schema), the description is reasonably complete. It covers purpose and return format, and the output schema handles return values, so no major gaps exist. However, it lacks behavioral context like safety or performance considerations, preventing a perfect score.
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 with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter semantics, and it appropriately avoids discussing parameters, earning a baseline score of 4 for this context.
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 with a specific verb ('List') and resource ('web applications'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'app_refresh' or 'app_serve' which might also involve listing operations, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. With siblings like 'app_refresh' and 'app_serve' that might overlap in functionality, there's no explicit or implied context for choosing this specific listing tool, leaving usage unclear.
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 discloses that the server 'will automatically find an available port' and 'can only serve one app at a time,' which are useful behavioral traits. However, it doesn't mention permissions, rate limits, or what happens if the app is already running, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the main purpose. The sentences are efficient, though the 'Args' and 'Returns' sections could be integrated more smoothly into the flow, but overall it's concise with minimal 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 an output schema (returns 'A dictionary containing the result of the operation'), the description doesn't need to detail return values. However, as a mutation tool with no annotations and only basic behavioral context, it lacks information on error handling or prerequisites, making it adequate but with clear 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?
The description adds meaning beyond the input schema by explaining that 'app_name' is the 'Name of the application to serve.' Since there is only one parameter and schema description coverage is 0%, this compensates well, though it doesn't detail format or constraints like valid app names.
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: 'Serve an existing web application on a local HTTP server.' It specifies the verb ('serve') and resource ('existing web application'), but doesn't explicitly differentiate from siblings like 'app_open' or 'app_stop_server' that might involve similar concepts.
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 some implied usage context with 'Can only serve one app at a time,' which suggests a constraint but doesn't explicitly state when to use this tool versus alternatives like 'app_open' or 'app_stop_server.' No clear alternatives or exclusions are named.
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 discloses key behavioral traits: it opens in a web browser, serves the app if not already served, and enforces a single-app-at-a-time constraint. However, it lacks details on permissions, error handling, or what 'served first' entails (e.g., time, resources). This is adequate but has gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core action, followed by important behavioral notes and parameter/return details. Every sentence adds value without redundancy, and the structure with 'Args:' and 'Returns:' sections enhances clarity efficiently.
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 (mutation with constraints), no annotations, and an output schema present (so return values are documented elsewhere), the description is fairly complete. It covers purpose, key behavior, and parameter semantics, but could improve by addressing error cases or interaction with sibling tools like app_serve. The presence of an output schema reduces the need for return value 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 schema description coverage is 0%, so the description must compensate. It adds meaning by explaining 'app_name' as 'Name of the application to open,' which clarifies the parameter's role beyond the schema's basic type. Since there's only one parameter, this is sufficient to understand its use, though it doesn't specify format or constraints like valid app names.
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 ('Open') and resource ('an app in the default web browser'), making the purpose specific and understandable. It distinguishes from siblings like app_serve (which only serves) and app_list (which lists), though it doesn't explicitly name alternatives. The mention of serving if needed adds useful context but doesn't fully differentiate from app_serve in a comparative way.
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 by stating 'Can only open one app at a time,' which provides some context on limitations, but it doesn't explicitly say when to use this tool versus alternatives like app_serve or app_list. No guidance on prerequisites or exclusions is given, leaving the agent to infer based on the description alone.
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 discloses the tool's dual behavior (reporting vs. retrieving) and mentions clearing errors, which adds context. However, it doesn't cover aspects like permissions needed, rate limits, or whether operations are persistent, leaving gaps in behavioral understanding.
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 and front-loaded, with the core purpose stated first. The Args and Returns sections are structured but could be more integrated; however, every sentence adds value without redundancy, making it efficient overall.
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 (dual functionality, 2 parameters), no annotations, and an output schema present, the description is fairly complete. It explains parameters, return values, and usage context, though it could benefit from more behavioral details like error handling or persistence.
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 significant meaning beyond the input schema, which has 0% coverage. It explains that 'error_message' is optional and determines the tool's mode (report if provided, retrieve if None), and that 'clear' is optional and clears the list if True. This fully compensates for the lack of schema 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 dual purpose: 'Report an error from the app or retrieve the list of errors.' It specifies the verb (report/retrieve) and resource (errors), though it doesn't explicitly differentiate from sibling tools like app_response or app_list, which might handle other app-related operations.
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 context: 'useful while developing or debugging the app.' However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., app_response for general responses or app_list for listing other items) and does not specify 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 of behavioral disclosure. It describes the tool's behavior by specifying the return value ('True if the response was stored successfully, False otherwise') and the parameter constraints, but it lacks details on permissions, rate limits, or error handling. This is adequate for a basic tool but misses deeper 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the purpose and key usage rule. Sentences are efficient, with no wasted words. However, the structure could be slightly improved by separating the 'Args' and 'Returns' sections more clearly, but overall it's concise and well-organized.
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 complexity (3 parameters, nested objects, no annotations, but has an output schema), the description is fairly complete. It covers purpose, parameter semantics, and return values, and the output schema handles return details, so no need to explain those further. It could benefit from more behavioral context, but it's sufficient for basic 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?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains the semantics of each parameter (string_data, list_data, table_data), provides a format example for table_data, and clarifies that only one should be provided. This fully compensates for the schema's lack of descriptions, making parameters clear and actionable.
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: 'to return a response to the app that has been requested.' It specifies the verb ('return a response') and resource ('to the app'), making it understandable. However, it doesn't explicitly differentiate from siblings like app_error or app_list, which might also involve app interactions, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance: 'Provide only one of string_data, list_data, or table_data,' indicating mutual exclusivity among parameters. It doesn't explicitly state when to use this tool versus alternatives like app_error for errors or app_list for listing, nor does it mention prerequisites or exclusions, leaving usage context somewhat vague.
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 platform/software constraints (macOS/Chrome) and mentions the return format, but doesn't cover other behavioral aspects like error handling, permissions needed, or what 'refresh' entails operationally (e.g., reloads page, clears cache).
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 with three concise sentences that each add value: stating the action, specifying constraints, and describing the return. It's front-loaded with the core purpose and wastes no words.
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 0 parameters, 100% schema coverage, and an output schema (which handles return values), the description is reasonably complete. It covers the tool's purpose, operational constraints, and mentions the return format. However, for a tool with no annotations, it could benefit from more behavioral context about what 'refresh' actually does.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose and constraints.
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 ('Refresh') and target ('the currently open app in Chrome'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'app_open' or 'app_stop_server' in terms of when to use one versus the other.
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 about when this tool works ('Only works on macOS with Google Chrome'), which is helpful for usage decisions. However, it doesn't explicitly state when to use this versus alternatives like 'app_open' or 'app_stop_server' from the sibling list.
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:

[![goose-app-maker-mcp MCP server](https://glama.ai/mcp/servers/michaelneale/goose-app-maker-mcp/badges/card.svg)](https://glama.ai/mcp/servers/michaelneale/goose-app-maker-mcp)

Score Badge

Copy to your README.md:

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

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