InstaServer

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, but create_pod overlaps with deploy_pod since deploy_pod can also create the pod. The descriptions explicitly call this out, so an agent can still choose correctly, but the boundary is slightly fuzzy.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern: list_, create_, get_, manage_, delete_, exec_, read_, write_. The naming style is uniform and predictable across the entire set.
Tool Count5/5
12 tools is well-scoped for a deployment and pod-management server. Each tool maps to a distinct lifecycle operation or inspection task, and none feel redundant or unnecessary.
Completeness5/5
The tool surface covers the full pod lifecycle: deploy, list, inspect, manage, delete, execute, log, and file operations. There are no obvious dead ends, and the provided tools are sufficient to go from source files to a live managed URL.
Average 3.7/5 across 12 of 12 tools scored. Lowest: 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 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior; it conveys a read-only listing operation and scopes it to a pod's app root. It does not disclose whether the listing is recursive, whether directories are included, or what happens on an invalid path.
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 filler. Every word contributes to the tool's core purpose.
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?
Despite the tool's apparent simplicity, there are no annotations and no output schema, and the required 'name' parameter is unexplained. An agent would need outside context or sibling-tool conventions to invoke this tool reliably.
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 only 50%: 'path' has a description, but the required 'name' parameter is not described anywhere. The description does not clarify that 'name' refers to the target pod, so the most important parameter remains ambiguous.
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 states a specific verb ('List') and resource ('files under a path inside a pod's app root'), and the resource clearly differs from sibling tools like list_pods and read_file. However, it does not explicitly name sibling tools or call out exclusions, so it stops short of fully differentiating itself.
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 when-to-use or when-not-to-use guidance is provided, and no alternative sibling tools are mentioned. The phrase 'inside a pod's app root' gives some scope, but an agent must infer when this tool is preferred over list_pods, read_file, or exec_command.
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 behavioral disclosure burden. 'Get details' strongly implies a safe read-only operation, and the mention of 'public URL and status' clues the expected output. However, it does not explicitly state that the tool is non-mutating, does not deploy/delete/exec, or whether any permissions are needed.
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 filler. Every word adds signal: 'one pod,' 'public URL,' and 'status' all contribute to tool selection and expected behavior.
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 it is a simple one-parameter read tool, the description is minimally viable: an agent can infer it fetches a single pod by name and returns URL/status. However, with no annotations, no output schema, and no input-parameter explanation, it leaves some ambiguity about exact status values, required permissions, and the identifier format.
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 does not mention the `name` parameter at all, nor does it explain that `name` identifies the target pod. 'One pod' hints at a singular target but adds little meaning to the required string parameter.
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 uses a specific verb ('Get'), a clear resource ('pod'), and narrows scope to 'one pod,' which distinguishes it from the sibling list_pods. It also names useful output facets ('public URL and status'), though it does not explicitly distinguish itself from other detail-like siblings.
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 gives no guidance about when to use this tool versus sibling alternatives like list_pods or manage_pod. It does not state exclusions, prerequisites, or mention any alternative. The only implied signal is 'one pod,' but there is no explicit usage direction.
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?
Annotations are absent, so the description must shoulder the burden of behavioral disclosure. It only provides the action verbs and the reload alias; it does not mention side effects, state changes, idempotency, or whether the operation is synchronous.
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 filler. Every phrase adds meaning, and the parenthetical 'alias for restart' is high-value disambiguation.
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?
With no output schema and no annotations, the minimal description leaves out expected context such as prerequisites, return information, and side effects. For a state-changing control operation, this is too sparse to guide a confident agent call.
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 needs to compensate for the missing parameter docs. It repeats the action values from the enum and adds only the reload-alias detail; it never explains the 'name' parameter or the consequences of each action.
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 names specific lifecycle verbs ('start, stop, restart, or reload') and a concrete resource ('a pod's container'), which clearly distinguishes it from sibling create/delete/inspect tools. It also clarifies that reload is an alias for restart, removing ambiguity.
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?
There is no guidance about when to use this tool instead of alternatives such as deploy_pod, create_pod, or exec_command. The description states what it does but not what conditions select it.
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 behavioral disclosure burden. It usefully specifies that logs come from stdout/stderr and from the pod's app process, but it omits details like default line count, ordering, timestamps, or whether logs from previous container instances are included.
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 a single, front-loaded sentence with no filler or repetition. It is concise and readable, though the brevity comes at the cost of parameter and usage detail captured in other dimensions.
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?
Despite the simple two-parameter schema, there is no output schema and no annotations, so the description must support both selection and invocation. It explains what logs are returned but leaves the behavior of the optional 'lines' parameter, default behavior, and return format unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only indirectly suggests that 'name' identifies a pod. The 'lines' parameter is not explained at all beyond schema constraints, leaving its meaning, default, and relationship to 'recent' ambiguous.
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 a specific verb ('Get') and a precise resource ('recent stdout/stderr logs from a pod's app process'). It clearly distinguishes this from sibling tools like get_pod or exec_command by naming the exact log streams and process scope.
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 retrieving application logs from a pod, which gives some usage context. However, it does not explicitly state when to prefer it over alternatives such as exec_command, read_file, or get_pod, nor does it mention exclusions or prerequisites.
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 carry behavioral disclosure. 'Read' clearly signals a non-mutating operation and 'text file' sets a content expectation. However, it does not disclose error behavior, path restrictions, or what happens for non-text files.
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?
A single sentence with zero filler, front-loading the verb and resource. The size fits the tool's simplicity.
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 two-parameter read tool, the description gives the core operation. But with no schema descriptions and no output schema, it leaves the `name` parameter and exact path semantics to inference. An agent could likely call it correctly but not with certainty.
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 explain the parameters. It only hints that the path relates to the pod's app root, while `name` is left ambiguous as either a pod name or file name. This is insufficient compensation for the empty 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?
States a clear verb and resource: read a text file, scoped to a pod's app root. This distinguishes it from siblings like write_file, list_files, and get_logs. No tautology.
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 on when to choose this tool instead of alternatives like exec_command, get_logs, or list_files. The usage context is only implied by the phrase 'pod's app root', with no explicit conditions 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?
The description discloses the return behavior (stdout/stderr/exit code), which is useful. However, with no annotations, it fails to disclose potential side effects of running arbitrary shell commands (e.g., modifying files, installing packages, or changing container state), and provides no safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that delivers the core function and return values with no filler. It is front-loaded with the action and resource, making it efficient for an agent to parse.
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 tool that executes commands, the description omits essential context: what 'name' refers to, how the container is selected, whether the pod must be running, and what side effects may occur. The lack of any caveat or usage note makes it incomplete for safe autonomous invocation.
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 has 0% parameter description coverage, so the description must define the parameters. It implies 'command' is the shell command, but 'name' is left ambiguous (pod name? container name? a composite identifier?). The description does not clarify how 'name' maps to the target container.
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 states a specific verb ('Run'), a resource ('a pod's container'), and the key return values ('stdout/stderr/exit code'). This clearly distinguishes it from sibling tools like get_logs or read_file, which inspect without executing arbitrary commands.
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 to execute a shell command inside a container. However, it gives no explicit guidance on when to prefer this over alternatives like get_logs or list_files, and does not mention exclusion criteria such as read-only operations or file inspection.
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 disclosing behavioral traits. It clearly discloses that the tool can overwrite existing content, which is important mutation information. However, it does not mention persistence, whether the file is created if absent, permissions required, or side effects on the running pod.
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 tight sentence that front-loads the core operation, specifies the target resource, and adds the key differentiator (no full redeploy). Every clause carries meaning and there is no filler.
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 tool with 4 parameters, no output schema, and no annotations, the description leaves important invocation details unexplained: how the target pod is identified, whether path is absolute or relative, which file states are overwritten vs created, and what response is returned. The description gives the purpose but not enough operational context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description offers no parameter-level meaning beyond what the parameter names themselves imply. It does not explain what 'name' refers to, what 'path' should contain, how content is provided, or how encoding affects input. The description fails to compensate for the schema's lack of documentation.
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 a specific verb ('Write (or overwrite)') and a clear resource ('a single file inside a pod's app root'), and immediately contrasts it with a full redeploy. This makes the tool's purpose clear and distinguishable from siblings like read_file, list_files, and deploy_pod.
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 phrase 'without a full redeploy' provides clear context for when to use this tool: when a file change should be applied directly to a running pod rather than through a redeploy. It does not explicitly name alternatives or exclusions, so it stops short of 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 full behavioral burden. It indicates the operation is a read-only listing and that status is included, but it does not disclose scoping (e.g., namespace/all namespaces), ordering, pagination, or error behavior. It is adequate but minimal.
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 clear sentence with no filler. Every word contributes meaning, and the core verb-object relationship is front-loaded.
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 zero-parameter listing tool, the description is mostly complete: it names the action, the resource, and the output content ('status'). Some ambiguity remains about the exact scope of 'all pods', but the tool's low complexity reduces the impact of that gap.
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 zero parameters, so the baseline is 4. The description does not need to explain parameter semantics because there are none to explain.
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 states a specific verb ('List'), a specific resource ('pods'), and the scope ('all') plus the returned aspect ('status'). This clearly distinguishes it from sibling tools like get_pod, which presumably targets a single pod.
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 phrase 'List all pods' implies use when an agent needs an enumeration of pods and their status, but no explicit guidance is given about when to prefer this over get_pod or when not to use it. The usage context is implied rather than stated.
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 present, so the description must carry behavioral disclosure. It explicitly flags permanence and enumerates three consequences of deletion (container, volume, tunnel), which is strong transparency for a destructive tool. It could additionally note irreversibility or permission requirements, but it already exceeds a bare 'Deletes a pod'.
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 entire description is a single efficient sentence that front-loads the action ('Permanently delete a pod') and only then specifies artifacts affected. Zero filler or duplication.
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 one-parameter destructive operation with no output schema, the description gives enough to invoke it correctly: what action, what objects are affected, and permanence. It stops short of stating error/return behavior or permission prerequisites, but those are secondary for this simple tool.
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 0%, so the description should compensate for the undocumented `name` parameter; it does not mention the parameter directly. The meaning is inferable from 'delete a pod' and the schema's `name` property, but the description adds no explicit parameter guidance.
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?
Description uses a specific verb phrase 'Permanently delete a pod' followed by the concrete scope of destruction ('removes its container, volume, and tunnel'). This clearly distinguishes it from sibling tools like get_pod/list_pods, which inspect, and manage_pod, which suggests modification.
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 makes the usage context evident: call this when a pod must be permanently removed, not merely stopped or managed. It does not explicitly name alternatives or state when-not-to-use (e.g., 'use manage_pod for reversible actions'), so it falls short of a full routing explanation.
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 behavioral burden. It discloses that the pod is persistent, that it includes a Docker container and volume, and that no app files are deployed. It does not mention return values or conflict behavior, but the core side effects are clearly stated.
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 with no wasted words. The core definition comes first, clarified in parentheses, and the deployment guidance is delivered in the second sentence. Every element 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 two-parameter creation tool, the description covers the essential concept, the persistent side effect, and the relationship to deploy_pod. The absence of return-value details is a minor gap, but not enough to block a correct invocation.
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 only 50%, and the description adds no parameter-level meaning. It does not explain how 'preset' affects the pod or clarify 'name' beyond what the schema already provides. The description should compensate for the partially undocumented schema but does not.
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 states a specific verb and resource ('Create a new empty pod') and immediately defines what a pod is in parentheses. It explicitly contrasts with deploy_pod by noting no app files are deployed yet, making it easy for an agent to distinguish the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives direct usage guidance: 'Usually you can skip this and call deploy_pod directly.' This explicitly names the alternative and states when this tool is unnecessary, which is exactly what an agent needs to choose the right sibling.
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?
There are no annotations, so the description carries the burden, and it does communicate read-only informational behavior through 'List' plus the substance of the result ('what each expects'). It does not detail output structure or explicitly state absence of side effects, but for a zero-parameter list tool this is sufficient behavioral 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?
A single front-loaded sentence that names the action, scope, and included preset types with no filler. Every word contributes.
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?
With no parameters, no output schema, and a simple informational purpose, the description states what will be returned (available presets and what each expects) and is complete enough for an agent to select and invoke the tool correctly.
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 takes zero parameters, so parameter documentation is moot; the description correctly focuses on behavior rather than inputs. Baseline 4 is appropriate for a parameterless tool.
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 names a specific verb ('List'), a specific resource (runtime presets InstaServer can deploy), and enumerates the exact preset types, so an agent can distinguish this from pod/list/file siblings without opening schemas.
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 context of 'can deploy' and 'what each expects' clearly implies this is the reference to consult when choosing a preset before create/deploy operations, but it never explicitly states when to use it versus alternatives or when not to use it. No exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It lays out side effects and conditions: pod creation if missing, file upload, dependency installation, app restart, public URL exposure via Cloudflare, and a health check. That goes far beyond the schema and annotations.
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 sentences with no filler. It front-loads the core action and then adds only necessary workflow details, making it easy for an agent to parse quickly.
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 complex side-effecting tool with no annotations and no output schema, the description covers the key behavioral sequence and outcome well. It does not explicitly state what the tool returns (e.g., the generated URL) or call out that preset is required on first creation, but those are relatively minor gaps given the strong overall coverage.
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 only 33%, so the description needs to compensate. It gives meaningful context for 'files' by describing upload and dependency installation, and the deploy narrative implies what 'name' is for. However, it does not explicitly define 'name' as the pod identifier or describe how 'preset' affects runtime, leaving those partially under-specified.
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 opens with a specific verb+resource ('Deploy files to a pod') and then enumerates the full lifecycle: create pod, upload files, install dependencies, restart app, open HTTPS URL, verify. This clearly tells an agent what the tool does and distinguishes it from narrower siblings like create_pod or manage_pod.
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 explicitly frames itself as 'the main tool — one call to go from source files to a live URL,' which gives strong guidance that this is the primary deployment entry point. It does not explicitly say when to prefer create_pod or manage_pod instead, so there are no explicit exclusions, but the context is clear.
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:

[![instaserver MCP server](https://glama.ai/mcp/servers/CodesbyFebin/instaserver/badges/card.svg)](https://glama.ai/mcp/servers/CodesbyFebin/instaserver)

Score Badge

Copy to your README.md:

[![instaserver MCP server](https://glama.ai/mcp/servers/CodesbyFebin/instaserver/badges/score.svg)](https://glama.ai/mcp/servers/CodesbyFebin/instaserver)

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/CodesbyFebin/instaserver'

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