Neptune MCP Server

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation4/5
Most tools have distinct purposes, but wait_for_deployment and get_deployment_status are closely related and add_new_resource's name is misleading (it only returns info about resource types, not actually adding). However, descriptions generally clarify the differences.
Naming Consistency3/5
The majority follow a verb_noun pattern (list_projects, get_logs, delete_project), but some deviate: 'info' and 'login' lack objects, and 'add_new_resource' implies an action different from its actual informational purpose. This mixed convention reduces predictability.
Tool Count4/5
15 tools is at the high end of the ideal range, but each addresses a distinct aspect of cloud deployment and management. A few informational tools (info, get_project_schema, add_new_resource) are somewhat redundant but still marginally useful.
Completeness3/5
Core project operations (list, deploy, delete, status) and resource operations (provision, bucket, secret, database) are covered, but there is no create_project tool, no secret retrieval, and no resource deletion. These gaps may require workarounds.
Average 3.7/5 across 15 of 15 tools scored. Lowest: 2.8/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
- Last stable release on December 19, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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?
The description discloses only the basic retrieval behavior, with no information about side effects, authentication needs, rate limits, or what 'current project deployment' means. Since annotations are absent, the description carries the full burden but offers minimal detail, leaving ambiguity about the output and invocation context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently communicates the primary purpose without verbose filler. However, it omits critical details about parameters and usage, so it is not ideally structured for effective tool invocation despite being succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one required parameter with no schema description and no annotations, the description leaves the agent without enough context to invoke the tool correctly. While an output schema exists, the meaning of 'neptune_json_path' and the deployment context are completely unexplained, making the tool under-specified for autonomous 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?
The sole parameter 'neptune_json_path' has no description in the schema and the tool description does not mention it at all. With 0% schema coverage, the description fails to explain what this path refers to, how to format it, or its role in retrieving logs.
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 retrieves logs for the current project deployment. The verb 'Retrieve' and resource 'logs' are specific, and the scope 'current project deployment' distinguishes it from sibling tools like get_deployment_status or list_bucket_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. While the behavior is clear, there is no mention of prerequisites, context requirements, or situations where another tool might be more appropriate. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'wait for the current project deployment to complete' without explaining whether this involves polling, blocking, timeouts, error handling, or what the return value will be. The existence of an output schema is not acknowledged, leaving the actual behavior opaque.
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 short sentence that is direct and front-loaded. It avoids unnecessary verbosity and states the core action clearly. However, it may be too terse to be fully self-sufficient, but for conciseness alone, it is appropriately sized for a simple wait operation.
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 description is incomplete given the tool has one required parameter, no annotations, and an output schema. It does not explain the meaning of 'current project deployment', the neptune_json_path parameter, or the expected return behavior. This leaves substantial gaps for the agent to fill with assumptions.
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?
The input schema has one required parameter, neptune_json_path, with no description, and the schema description coverage is 0%. The tool description does not mention this parameter at all, so the agent has no understanding of what path is needed or how it relates to the deployment being waited on. The description completely fails to compensate for the schema gap.
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 waits for the current project deployment to complete. This distinguishes it from sibling tools like deploy_project (which initiates deployment) and get_deployment_status (which queries status). The verb 'wait' and the resource 'current project deployment' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention that it should be used after deploy_project, nor does it contrast with get_deployment_status. The agent must infer the appropriate usage context from sibling tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should carry behavioral disclosure. It does mention one failure mode (missing neptune.json), but does not disclose side effects (e.g., creating/modifying cloud infrastructure), required permissions, or whether the operation is asynchronous. This is a significant gap for a provisioning 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?
Two sentences, front-loaded with purpose and a useful error condition. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values are covered. However, the description fails to explain how the path parameter relates to the working directory, and does not clarify whether provisioning is immediate or requires later status checks (siblings include wait_for_deployment and get_deployment_status). The description feels incomplete for a tool that likely triggers infrastructure changes.
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?
The input schema has one required parameter (neptune_json_path) with no description (schema coverage 0%). The description never mentions the parameter and instead references the 'working directory' and 'current project', potentially confusing the path parameter's role. It adds no value beyond the schema's bare type declaration.
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 (provision), resource (cloud resources), and scope (current project as per its configuration). It distinguishes itself from siblings like deploy_project (deploy vs provision) and add_new_resource (provision all vs add one).
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 that the tool works with the current project's configuration and will error without a neptune.json file, implying when to use it. However, it does not explicitly state when to use this tool over alternatives or any 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?
No annotations are provided, so the description carries the burden. It does disclose that the tool 'will tell you about running resources' and 'the state of the service,' indicating a read-only informational nature. However, it does not mention potential side effects, authentication requirements, rate limits, or output specifics beyond the high-level statement.
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 that immediately establish the function and key detail. Every word earns its place, with no redundancy or off-topic information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a high-level purpose but lacks usage guidelines and parameter semantics. An output schema exists, so return-value details are not required, but for a tool with one undocumented parameter and no sibling differentiation, the completeness is moderate.
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?
The schema has 0% description coverage for the only parameter, neptune_json_path, and the description does not mention or explain this parameter at all. The agent has no guidance on how to specify the path, making the tool difficult to invoke correctly.
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 verb and resource: 'Get the status of the current deployment of a project and its provisioned resources.' It adds specific detail about running resources and service state, which distinguishes it from siblings like wait_for_deployment and get_logs.
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 does not provide any guidance on when to use this tool versus alternatives. It lacks explicit context such as 'use this to check whether deployment is complete' or mention of not blocking, unlike the sibling wait_for_deployment.
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 must disclose behavioral traits. It only says 'Get information', which implies a read-only operation, but it doesn't state whether it requires authentication, makes network calls, or has any side effects. It also doesn't mention how the information is structured or any limitations. The description is too sparse to be 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 a single sentence, extremely concise, and front-loaded with the verb 'Get information'. Every word adds value, and there is no wasted text. It is appropriately sized for a simple informational tool.
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 tool has no parameters and an output schema exists, so the description doesn't need to explain return values. However, it lacks context about what 'Neptune' refers to, what kind of 'information' is available, and how this tool relates to the deployment management workflow. Given its simple nature, the description is marginally adequate but could benefit from a brief example or clarification.
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, so the description is not required to explain parameter details. The input schema is empty, and the description adds no parameter information. Per the baseline for 0 parameters, a score of 4 is appropriate since there is no parameter semantics burden.
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 clear action ('Get information') and identifies the resource ('Neptune and available tools for cloud deployment management'). It distinguishes itself from sibling tools that perform specific operations (list_projects, get_logs, etc.) by being a general informational tool. However, it is vague about what kind of information is returned or how deep the coverage is.
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 that the tool is for retrieving information about the Neptune platform and its toolset, but it does not explicitly state when to use it versus alternatives. No exclusions or alternative tool mentions are provided. For a meta/informational tool, this is acceptable but could be clearer.
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 disclosure. It notes prerequisites but doesn't explicitly state read-only behavior, auth requirements, or error behavior. The verb 'list' implies safety, but it's not explicit.
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 short sentences, front-loaded with the primary purpose, followed by essential prerequisites. No redundancy.
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 core action and prerequisites, but lacks parameter explanations and doesn't reference related tools like 'get_bucket_object' or note error cases. The output schema covers return data, so that's acceptable.
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 no descriptions (0% coverage). The description mentions 'bucket' and 'project' but doesn't explain 'neptune_json_path' or how parameters map to arguments, leaving the agent to infer.
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 function: 'List all files in a storage bucket resource for the current project.' This uses a specific verb and resource, though it doesn't explicitly differentiate from the sibling 'get_bucket_object,' which would retrieve a single file.
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 noting that the bucket must exist in neptune.json and be provisioned via 'provision_resources' before calling. This is a usage precondition, though no alternatives are mentioned.
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 burden. It discloses the return type (dictionary) and prerequisite setup, but does not state whether the operation is read-only, what error behavior to expect, or how the where_clause is interpreted beyond the example.
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 repetitive: the return statement and example appear twice verbatim. This wastes space and makes the description longer than necessary without adding new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core usage and prerequisites are covered, and the output schema removes the need to describe return values. However, the lack of explicit neptune_json_path explanation and the absence of guidance on when to use this versus siblings leave some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains table_name and where_clause well, and the example shows how to pass neptune_json_path, but neptune_json_path is never explicitly described, leaving some ambiguity.
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 queries a database resource for the current project, with a specific verb and resource. It distinguishes itself from sibling tools like get_bucket_object and get_logs by focusing on database querying.
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?
Clear context is provided: the database must exist in neptune.json and be provisioned before querying. However, it does not explicitly mention when to prefer this tool over alternatives or when not to use it, 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 provided, the description carries the full burden. It discloses the prerequisite of bucket existence and provisioning, adding behavioral context. However, it does not describe error behavior, return format, or explicitly state that it is a non-destructive read operation (though 'retrieve' implies this).
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 with a useful note. No wasted words, front-loaded with the action.
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 tool has an output schema, so return values are covered. The description provides crucial prerequisites and resource scope, but lacks error handling details, alternative tool guidance, and parameter semantics. It is minimally adequate for a simple get operation but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the three parameters (neptune_json_path, bucket_name, key) beyond implicit references to the bucket and neptune.json config. The 'key' parameter is never clarified as the object identifier.
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 'Retrieve' with the resource 'object from a storage bucket resource for the current project'. It clearly states the primary action and scope, distinguishing it from sibling tools like list_bucket_files.
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 prerequisites: the bucket must already exist in neptune.json and must be provisioned via 'provision_resources'. This gives clear context for when the tool can be used, though it does not mention alternatives 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?
Discloses that it elicits a prompt for secure entry and requires prior provisioning. With no annotations, it doesn't explicitly state whether it is a write operation or describe side effects like overwriting, but the verb 'set' implies modification. Adds useful context beyond the bare action.
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 short paragraphs with no redundancy. The main purpose is stated first, followed by the interactive note and prerequisites. Every sentence adds unique information, making it appropriately sized and 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 simple mutation tool with an output schema and two required parameters, the description covers the action, interactive prompt, and prerequisites. It lacks error-handling or permission details, but the provided information is sufficient for an agent to invoke it correctly in most scenarios.
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%, and the description fails to explicitly explain the two parameters (neptune_json_path and secret_name). It mentions 'neptune.json configuration' but does not map that to the path parameter, leaving the agent to infer roles. Insufficient compensation for the lack of schema descriptions.
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 'Set the value of a secret resource for the current project' with a specific verb, resource, and scope. It distinguishes from siblings by focusing exclusively on updating an existing secret's value, not creating or provisioning resources.
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?
Provides explicit prerequisites: the secret must exist in neptune.json and be provisioned via provision_resources. It also explains the interactive prompt behavior. It does not name alternative tools or state when not to use it, but the context is clear for the intended use case.
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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It prominently warns that the action is permanent, cannot be undone, and that it deletes associated storage buckets and secrets—essential context beyond merely saying 'delete project'.
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 sentences plus a warning, with no redundant wording. The warning is effectively broken out on a new line, making critical safety information prominent and easy to parse.
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 destructive impact (permanence, scope) is thoroughly covered, and the presence of an output schema likely handles return values. However, the complete lack of parameter explanation for neptune_json_path remains a significant gap, especially since the tool is otherwise simple.
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?
The sole parameter, neptune_json_path, has 0% schema description coverage and the description does not explain what it represents, its format, or how to obtain it. This leaves the agent without necessary guidance for correct invocation.
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 ('Delete') with a clear resource ('a project') and scope ('all its resources'). This clearly distinguishes it from all sibling tools, which are non-destructive operations like listing, deploying, or querying.
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 clearly implies when to use this tool (when permanent deletion of a project is desired) and there is no competing delete operation among siblings. However, it does not explicitly state exclusions or alternatives, such as 'use this only if you want to permanently remove a project and its data'.
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 provided, the description carries the full burden. It discloses that the tool builds an image from the Dockerfile and warns that all container data is lost if the task stops or is redeployed, recommending provisioned resources for persistence. This is significant and beyond what the schema alone would convey.
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 compact and well-structured: one short sentence for purpose, one for the prerequisite, one for the under-the-hood build, and a concise note about persistence. There is no filler or repetition; every sentence earns its place.
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 purpose, prerequisite, build behavior, and data persistence, and an output schema exists to handle return values. However, the sole required parameter is left unexplained, which is a significant gap for a deployment tool that needs a specific path to function correctly.
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?
The only required parameter, neptune_json_path, is not mentioned at all in the description, and the input schema gives only its name and type with 0% coverage. The description adds no meaning or format guidance for this parameter, leaving the agent without enough information to provide a correct value.
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 starts with the specific action 'Deploy the current project' and adds the under-the-hood detail that it builds an image from the Dockerfile. This clearly distinguishes it from sibling tools like provision_resources, wait_for_deployment, and get_deployment_status.
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 states a strong prerequisite: 'This only works after the project has been provisioned using provision_resources.' It also gives a when-not by warning about non-persistent data and advising use of provisioned resources. However, it does not explicitly name alternative tools for status or monitoring.
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 burden. It adds a behavioral nuance by specifying 'current account' (scoping) and the verb 'List' implies a read-only action. However, it doesn't explicitly mention auth requirements, rate limits, or that it's non-mutating beyond what the verb implies.
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 no wasted words. The description is front-loaded with the action ('List') and immediately states the resource and scope. Perfectly concise.
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?
The tool is simple (no parameters) and an output schema exists, so the description doesn't need to explain return values. The 'current account' scope is useful. It could mention authentication or a use case, but it's sufficient for a basic listing 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 zero parameters, so the baseline for parameter semantics is 4. The description adds no parameter details, but none are needed since there are no 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 'List all projects in the current account' uses a specific verb ('List') and resource ('projects') with a clear scope ('current account'). It effectively distinguishes from sibling tools like list_bucket_files or info by naming the exact resource.
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 see projects in the current account, but it provides no explicit guidance on when to use this tool versus alternatives. There are no exclusions or specific context provided, so it just meets the 'implied usage' baseline.
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 side effects. It does mention that a browser window opens and that the access token is saved, which are key behavioral traits. However, it does not discuss error scenarios (e.g., user cancels, already authenticated, token expiry) or whether the operation is blocking. It is adequate but not rich.
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 sentences, front-loaded with the primary purpose. The second sentence adds essential behavioral context. Every word earns its place, with 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 no parameters and an output schema present, the description covers the core purpose, side effects, and downstream utility ('for use with Neptune tools'). It could additionally state that this should be executed before other Neptune tools, but the value is otherwise quite complete for its complexity.
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, so the baseline is 4. The description does not need to explain parameter semantics since none exist. It correctly focuses on the action and outcome rather than any input fields.
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 verb 'Authenticate' clearly states the action, and 'with Neptune' specifies the resource. It distinguishes itself from sibling tools, which are all project/deployment/database operations. The description makes it evident that this tool is for authentication and nothing else.
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?
Usage is implied by the fact that this is the only authentication tool among the siblings, but there is no explicit 'use this when' or 'do not use this if' guidance. It does not clarify whether it should be called before other tools or if re-authentication might be needed periodically.
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?
The verb 'Get information' clearly conveys that the tool is read-only and does not modify resources, which is essential given the lack of annotations. It does not explicitly mention 'no side effects,' but the phrasing is strong enough. The description also provides the valid 'kind' values, which is more of a parameter detail than behavior, but overall it gives sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose statement, an important usage note, and a parameter hint. Every sentence contributes meaning without redundancy, and the IMPORTANT and list formatting enhance readability.
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 one parameter, an explicit valid-value list, usage timing, and an output schema, the description is nearly complete. The only minor gap is that it doesn't explicitly state that this tool should not be used to actually provision resources, but 'Get information' implicitly conveys that. This is sufficient for the tool's scope.
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 input schema provides no description for the required 'kind' parameter, leaving it ambiguous. The description fully compensates by listing the exact valid values: 'StorageBucket' and 'Secret'. This is crucial for correct usage and adds meaning 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 tool's function: getting information about resource types that can be provisioned on Neptune. It identifies the specific resource types (StorageBucket and Secret) and differentiates itself from sibling tools that actually perform provisioning, such as provision_resources.
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 an explicit usage guideline: 'Always use this tool before modifying neptune.json.' This clearly indicates when to use the tool. However, it does not state when not to use it or name alternative tools for actual resource provisioning, so it lacks full when/when-not/alternatives guidance.
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 openly describes the tool as a read-only retrieval of a schema and details the schema's content, including required fields and allowed values. It also clarifies that the schema is 'authoritative,' setting expectations for how the output should be used. The lack of side-effect discussion is acceptable for a getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise purpose statement, an important usage note, and a compact bullet list of the schema's contents. Each sentence adds value, and the forward placement of the 'IMPORTANT' instruction ensures the agent sees the critical usage guidance early.
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 no-input tool with a defined output (a JSON schema), the description fully covers what the tool returns, what that output contains, when to use it, and why it's necessary. The presence of an output schema means the return format doesn't need over-explanation, and the description provides ample context 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 accepts zero parameters, as indicated by the empty input schema. With no parameters to document, the description needs no parameter-level details. The baseline for 0 params is 4, and the description appropriately avoids adding irrelevant parameter information.
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 'Get the JSON schema' with a specific resource (neptune.json), using a definite verb and object. It distinguishes itself from sibling tools like deploy_project or set_secret_value by focusing on schema retrieval, not deployment or configuration 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 explicitly says 'Use this tool BEFORE creating or modifying neptune.json' and explains why (to ensure validity). It provides clear usage context, though it doesn't mention alternatives or when not to use it, which is a minor omission given the tool's unique purpose.
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:

[![neptune-mcp MCP server](https://glama.ai/mcp/servers/shuttle-hq/neptune-mcp/badges/card.svg)](https://glama.ai/mcp/servers/shuttle-hq/neptune-mcp)

Score Badge

Copy to your README.md:

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

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