hamravesh-mcp

Server Quality Checklist

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

Latest release: v0.1.4
Disambiguation5/5
Each tool targets a distinct resource and operation. For example, hamravesh_app_logs is clearly for logs, hamravesh_create_app for creation, and hamravesh_billing for financial status. No two tools have ambiguous overlap.
Naming Consistency3/5
The consistent prefix 'hamravesh_' is good, but the pattern varies: some use verb_noun (e.g., create_app, list_apps), while others are noun phrases (e.g., app_builds, app_containers) without an explicit verb. This mixed convention reduces consistency.
Tool Count5/5
With 21 tools, the server covers a comprehensive set of operations for app management, API keys, billing, and more. The count feels well-scoped for its purpose without being excessive.
Completeness4/5
The core workflows (CRUD for apps and API keys, read for databases/registries) are present. Minor gaps like missing database update/delete are mitigated by the raw request tool. Overall, the surface is nearly complete.
Average 3.1/5 across 21 of 21 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on June 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations available. The description minimally discloses that the tool returns YAML manifests but does not mention read-only behavior, authentication needs, or other behavioral traits. Insufficient for a tool with no annotations.
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 extremely short but underspecified. It is not concise in a helpful way; it lacks critical information, making it inefficient for understanding the tool.
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?
No output schema provided. The description only states the output format (YAML) but does not clarify if it returns a single manifest or multiple, or the structure. Incomplete for a tool with two parameters and no output schema.
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 adds no meaning to the parameters (app_id, org). An agent cannot infer what the parameters represent from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Kubernetes manifests of an app (YAML)' is a noun phrase indicating the resource but lacks a verb specifying the action (e.g., get, list). It vaguely conveys the tool's purpose but does not clearly state what the tool does.
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 use this tool versus sibling tools like hamravesh_get_app or hamravesh_list_apps. The description does not provide context for appropriate usage.
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 for behavioral disclosure, but it only states the list action. It does not mention authentication requirements, pagination, output format, or any side effects. This is insufficient for understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but at the expense of completeness. It is not front-loaded with critical information and lacks structure.
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 lack of output schema, annotations, and parameter details, the description is incomplete. It does not explain return values, filtering possibilities, or any constraints, making it inadequate for a list tool with a parameter.
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 one parameter 'org' with 0% description coverage, and the tool description does not mention this parameter at all. It fails to explain what the parameter does or how it affects the results, leaving the agent without necessary context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'فهرست کلیدهای API سازمان' translates to 'List of organization API keys,' which clarifies the tool's purpose as listing API keys. However, it is a noun phrase rather than an explicit verb action, and it does not distinguish from sibling tools like create or delete.
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 lacks context about prerequisites, typical scenarios, or comparisons with related tools such as hamravesh_create_apikey.
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 must fully disclose behavior. It only states the tool returns build history but does not mention if it's read-only, pagination, error behavior, or any side effects. Minimal transparency.
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 very concise (one short sentence) but under-specified. It lacks necessary details about parameters and usage. Conciseness without completeness is not effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and no output schema or annotations, the description is highly incomplete. It does not cover output format, parameter usage, prerequisites, or any behavioral context.
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%, so the description must explain parameters. It does not mention app_id, limit, or org at all. No information on what each parameter does or how to use them.
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 retrieves build history for an app. The verb 'history of builds' and resource 'app' are specific. However, it does not explicitly differentiate from sibling tools, though the name itself suggests the focus on builds.
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 use this tool versus alternatives like hamravesh_app_containers or hamravesh_app_logs. The description only states the function, not the context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It mentions a past 404 issue due to wrong path, but does not state whether the tool is read-only, destructive, or requires authentication. Lacks critical 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Reasonably concise with key action and examples upfront, but mixes Farsi/English and includes a warning that could be shorter. Not optimally structured.
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?
Missing explanations for parameter 'org', return format, and pagination. Warning about path is useful but not sufficient given lack of output schema and no parameter documentation.
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 has one parameter 'org' with 0% description coverage. Description does not explain what 'org' is for (e.g., organization ID, namespace). Agent cannot infer its use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists marketplace/SaaS products with concrete examples (GitLab Runner, n8n, etc.), distinguishing it from general app list tools. However, it does not explicitly differentiate from sibling hamravesh_list_saas, which may overlap.
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 use this tool over alternatives like hamravesh_list_saas. Only includes a warning about the API path, but no context on prerequisites or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral information such as whether the tool is read-only, destructive, or pagination behavior. For a list operation, read-only nature is implied but not stated, and there is no disclosure of potential side effects or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one phrase), which is concise, but it lacks structure and important details. Every word serves a purpose, but the description is incomplete.
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's simplicity (one optional parameter, no output schema), the description should still clarify the parameter's role and the return format. Without this, it's incomplete for an agent to use 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 input schema has one parameter 'org' with no description (schema description coverage 0%). The tool description does not explain what 'org' means or its purpose, leaving the agent to infer from context.
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 it lists marketplace/SaaS services installed in an organization, using a specific verb ('list') and resource ('SaaS services'). It distinguishes from sibling list tools (e.g., hamravesh_list_apps, hamravesh_list_databases) by specifying marketplace services.
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 use this tool versus alternatives (e.g., other list tools). The description simply states what it does, with no context about when it's appropriate or when not 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 for behavioral disclosure. It implies a read operation but does not explicitly state idempotency, authentication needs, or potential side effects. The description is too brief to assure safe usage.
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 sentence that concisely conveys the core purpose. It is front-loaded with the key information. However, it lacks structured formatting like bullet points or sections, which would improve readability.
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's simplicity (one parameter, no output schema) and many siblings, the description is incomplete. It fails to explain the parameter, return format, or usage context. A more complete description would include examples or clarify the parameter's role.
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% (the parameter 'org' has no description), and the description does not mention or clarify the parameter at all. The description fails to compensate for the missing schema documentation, leaving the parameter's purpose and constraints entirely undefined.
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 indicates that the tool retrieves financial status including wallets, budget, and debt. It distinguishes itself from sibling tools focused on apps, keys, etc. However, it lacks a verb like 'get' or 'list' to explicitly state the action.
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. There is no mention of prerequisites, scenarios, or exclusions, leaving the agent without context for selection.
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, and the description does not disclose behavioral traits such as authentication requirements, error conditions, or side effects. The read-only nature is implied but 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise, but the brevity sacrifices important details. It is structured adequately but lacks depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and only two parameters, the description should hint at the return format or the role of 'org'. The current description leaves significant gaps for an agent to use the tool correctly.
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%, but the description adds no explanation for the parameters. 'service_id' is self-evident, but 'org' is unexplained, leaving the agent uncertain about its necessity or effect.
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 it retrieves details of an installed SaaS service using service_id. It is specific enough to distinguish from list operations, though it does not explicitly differentiate from sibling 'hamravesh_list_saas'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, or when not to use it. There is no mention of prerequisites or context.
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 the key value is returned only once and that the tool is disabled by default, requiring an environment variable to activate. Also mentions a preview dry-run mode. No annotations exist, so description carries the burden, but it omits details like auth or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but includes technical details in parentheses and brackets. It is not front-loaded with the most critical information, and the Persian text may reduce clarity for non-native readers.
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 write operation with no output schema and incomplete parameter documentation, the description lacks explanation of return format, error conditions, and parameter roles. It covers key behavioral traits but leaves significant gaps.
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%, but the description adds no meaning to the parameters 'name' or 'org'. It does not specify expected format, constraints, or the role of 'org'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'new API key for the organization', distinguishing it from sibling tools like delete or list. However, the note about being disabled adds minor 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?
No explicit guidance on when to use this tool versus alternatives. No prerequisites or context for setting the activation environment variable is provided beyond a note.
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 exist, so the description carries full burden. It does not disclose behavioral traits such as read-only nature, permission requirements, or any side effects. The description only states it returns 'details,' which is minimal.
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 sentence, concise and to the point. There is no unnecessary information, but it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete. It fails to specify what 'details' are returned, nor does it provide any context about the database or expected behavior.
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 0% description coverage for parameters. The description only mentions app_id implicitly but does not explain its meaning or the optional org parameter. It adds little value beyond the param names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves details of a DBaaS database, identified by app_id. However, it does not differentiate from sibling tools like hamravesh_list_databases, which lists all databases.
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 lacks context about prerequisites, when not to use it, or how it relates to other tools.
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 provided, and the description does not disclose behavioral traits beyond listing. No mention of read-only nature, rate limits, or side effects. The safe read operation is only implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence is concise but could be improved by including parameter information or usage details. It lacks structure for a complete tool definition.
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 lack of output schema and minimal parameter description, the description does not fully convey what the agent can expect. It mentions 'space consumption' but no details about the returned data.
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 single parameter 'org' has no description in the schema (0% coverage) and the tool description does not explain its purpose or usage. The description adds no value 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?
Description clearly states the action (list) and the resource (container registries) along with additional info (space consumption). It distinguishes from sibling tools like hamravesh_list_apps, which list apps.
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 use this tool versus alternatives like hamravesh_list_apps or other listing tools. The description only states what it does without context for selection.
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 the tool is disabled by default and requires an env var, and mentions a dry_run mode. However, no details on side effects, errors, or what 'disabled' means. With no annotations, more is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes cryptic parentheses notes. It could be more clear and structured. Not excessively long, but not optimally written.
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 minimal description, the agent lacks information about return values, effect of enabled parameter, and the optional org. The tool is incomplete for correct invocation.
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 does not explain any of the three parameters (app_id, enabled, org). It adds no value beyond the schema.
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 it turns an app on/off, using the verb 'set' in the name and Farsi description. It is distinct from sibling tools like restart or redeploy. However, the extra notes about dry_run and env var may distract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The only hint is the note about HAMRAVESH_ALLOW_WRITE being required, but no when-not or comparison with siblings.
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 mentions a disabled state and dry run mode, but does not clarify whether the action is destructive (e.g., shutdown stops database, potentially causing data loss), permissions required, or side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short—two sentences and a parenthetical note—and immediately states the core function. However, its brevity sacrifices important details about parameters and behavior. Still, it is efficiently structured for its limited content.
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 three parameters (two required), no output schema, and no annotations, the description fails to provide sufficient context for an AI agent to invoke it correctly. It does not explain what app_id refers to, what action values mean, or what the response will be.
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 0% description coverage for parameters, and the description does not explain the purpose or acceptable values of app_id, action, or org. It only mentions dry_run and environment variables, ignoring the required parameters entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: turning a DBaaS database on or off. It specifies both actions (start/shutdown) and indicates it is disabled by default, requiring activation. It is distinct from sibling tools which focus on apps and other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context: it mentions that the tool is disabled unless HAMRAVESH_ALLOW_WRITE=1 is set, and it mentions a preview/dry run mode. However, it does not provide explicit guidance on when to use this tool versus alternatives, nor does it exclude any scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states 'list,' implying a read operation, but does not confirm idempotency, permissions needed, rate limits, or any side effects. The description adds minimal transparency beyond the basic function.
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, concise and front-loaded. Every word is meaningful; there is no redundancy or unnecessary detail. It efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 optional parameter, no output schema), the description minimally covers the basic purpose. However, it lacks explanation of the parameter and does not specify what information is returned. It is adequate but could be more complete.
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 optional parameter 'org' with no description in the schema (0% coverage). The tool description does not explain what 'org' represents (e.g., organization ID or name) or how it affects results. This is a critical gap for correct parameter usage.
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 'List of managed databases (DBaaS) of an organization,' which clearly identifies the tool's purpose (listing databases) and scope (per organization). However, it lacks an explicit verb like 'list' or 'retrieve,' though it is implied. There are no sibling tools with similar names, so distinction is not an issue.
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any prerequisites or constraints. Sibling tools are for different resources (apps, keys), so confusion is low, but guidance is still absent.
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 adds behavioral context: the tool is disabled by default, requires HAMRAVESH_ALLOW_WRITE=1, and supports a dry-run mode. However, it lacks details on whether the redeploy is destructive, reversible, or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but packs multiple pieces of information (purpose, disabled status, activation instruction, dry run). It could be better structured, but it is not excessively long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description fails to cover prerequisites, return values, error conditions, or parameter details. It is minimally adequate for a simple redeploy tool but missing essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description does not explain the parameters (app_id, org). It only mentions the high-level operation, leaving the agent to guess parameter meanings.
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 'redeploy app from latest commit/build', specifying the verb (redeploy) and resource (app). However, the note about being disabled and requiring activation introduces some ambiguity about its current usability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like hamravesh_restart_app. The dry run and activation notes are provided but do not contextualize appropriate usage scenarios.
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; description only says 'list' without mentioning permissions, side effects, or behavior like read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but too brief; lacks structure for important details.
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?
No output schema, no parameter descriptions, and no behavioral details. Incomplete for reliable agent 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 description does not explain parameters app_id or org.
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 lists pods/containers of an app. It distinguishes from siblings as no other tool lists containers.
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?
No explicit guidance on when to use or alternatives. It is implied as the only container list tool, but lacks context.
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?
Description adds value by noting the tool is disabled without HAMRAVESH_ALLOW_WRITE=1 and the dry-run preview. But it doesn't disclose irreversibility or necessary permissions for a delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the action. All sentences serve a purpose, though the structure could be more formal.
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 delete tool, the description is missing crucial context like permanent effects, how to obtain the id, and the role of the org parameter. Annotations are absent, leaving 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?
Only the 'id' parameter is clarified (by id, not value). The 'org' parameter receives no explanation, and schema coverage is 0%, so the description insufficiently compensates.
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 deletes an API key by ID, distinguishing it from create/list tools. However, it could be more explicit that this is for deletion only.
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 direct guidance on when to use this tool vs alternatives like delete_app. The disabled note implies caution but doesn't elaborate on prerequisites or contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the disabled-by-default safety mechanism and the dry-run preview mode. It also states the expected effect (all pods restart). However, it does not detail consequences like downtime or whether the operation is asynchronous.
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 very concise, stating the operation and key behavioral notes in a single line with parentheticals. No unnecessary words.
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 lacks return value information, error scenarios, and parameter descriptions. Given the complexity of a write operation with safety mechanisms and the presence of similar sibling tools, the description is incomplete.
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 description provides no information about the parameters (app_id, org). With 0% schema coverage, the description fails to compensate, leaving the agent with no semantic guidance for the input fields.
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 'Restart an app (all pods restart)', providing a specific verb and resource. It distinguishes from sibling tools like redeploy by specifying that all pods restart, though it does not explicitly compare.
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 mentions that the tool is disabled by default (requires HAMRAVESH_ALLOW_WRITE=1) and has a dry-run preview mode, giving context on when it is usable. However, it does not provide guidance on when to use this tool versus alternatives like redeploy.
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 exist, so the description is the only source. It discloses the masking behavior of env values by default and how 'reveal_secrets' controls it, but does not mention other behavioral aspects like authentication requirements, rate limits, or side effects.
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 efficient sentence that front-loads key information (what is returned) and adds the masking behavior. No unnecessary words, but could be slightly more structured (e.g., using separate sentences).
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 3 parameters and no output schema. The description covers the return fields (env, domain, etc.) and the masking behavior, but does not explain the 'org' parameter or the exact return structure. It is adequate but has clear 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 coverage is low (33%), with only 'reveal_secrets' having a description in the schema. The description provides additional context for 'reveal_secrets' but does not clarify 'app_id' or 'org', leaving ambiguity. Given the low coverage, the description should compensate better.
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 retrieves full details of an app, listing specific fields (env, domain, resources, build, status). While it doesn't explicitly distinguish from siblings like 'hamravesh_list_apps' or 'hamravesh_app_builds', the purpose is clear and specific.
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 full app details are needed, but it provides no explicit guidance on when to use this tool versus alternatives, nor any conditions 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 carries the full burden. It discloses that the tool defaults to the last ~200 lines, which is helpful. However, it omits behavioral details such as mutation (likely read-only), rate limits, or what happens with custom index parameters.
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, effectively front-loading purpose and critical usage guidance. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema, low schema coverage), the description is incomplete. It does not explain return values, pagination, or how to interpret logs. The prerequisite instruction is useful but insufficient for full agent understanding.
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 33% (3 of 9 parameters described). The description adds context for endpoint-related parameters (from_index, to_index, reference_index) but does not clarify the remaining 6 parameters or their roles. It relies heavily on the schema, which is inadequate for a tool with many parameters.
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 'logs of an app' which clearly indicates the tool retrieves logs. It also provides a prerequisite step referencing a sibling tool, helping distinguish from other app-related tools. However, it lacks an explicit verb like 'retrieve' or 'get', slightly reducing clarity.
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 instructs to first use hamravesh_app_containers to obtain the pod name, providing clear sequential guidance. It also mentions that the tool sets reasonable defaults, but does not specify when to avoid using this tool or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It discloses that the tool is disabled by default (requires env variable), the HTTP method (POST), and dry_run support. However, it does not mention permissions needed, idempotency, throttling, or whether the operation is destructive. Mutation is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but includes extraneous details such as the full endpoint URL and debug flags. It could be streamlined to focus on essential usage instructions without technical internals. The mixed Persian/English may hinder clarity for non-Persian speakers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested object body, no output schema), the description adequately explains the workflow (list products first) and dry_run. However, it does not describe the return value or error scenarios, leaving gaps for an agent to understand what response to expect.
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?
Description adds meaningful context beyond the schema: explains that 'body' must contain product-specific fields from listing products, and describes 'dry_run' as preview-only. However, 'org' parameter is not explained, and schema coverage is 67%—the description compensates for the omitted parameter by focusing on the critical ones.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a marketplace SaaS service (e.g., GitLab Runner, WordPress) and distinguishes from sibling tools like hamravesh_get_saas or hamravesh_list_saas. However, it does not explicitly differentiate from other create tools (e.g., hamravesh_create_app), though the mention of 'marketplace' provides implicit distinction.
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 step-by-step guidance: first use hamravesh_list_marketplace_products to inspect product fields, then pass the complete body. Also mentions dry_run capability. Does not specify when to avoid using this tool or alternatives for non-marketplace resources.
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?
Discloses irreversibility, permission requirement, disabled default, and dry_run option. Without annotations, description carries full burden and does so reasonably well. Missing details on return values or error handling.
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?
Short and packed with key info (action, irreversibility, permission, dry_run). Front-loaded with 'complete deletion'. Some technical details could be reorganized, but overall efficient.
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?
Adequate for a delete tool given sibling context. Lacks parameter explanations and output/return info. Schema and output schema are minimal, so description should compensate more.
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?
No parameter descriptions in schema (0% coverage). Description does not explain app_id or org. Fails to add meaning beyond schema, which is critical for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'complete deletion' and 'irreversible', identifying the action and resource. It distinguishes from sibling tools (no other delete app tool). However, 'Darkub app' is not fully explanatory for external users.
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?
Mentions requirement for ALLOW_DELETE permission and that the tool is disabled by default (requires HAMRAVESH_ALLOW_WRITE=1). Mentions dry_run preview mode. Does not explicitly compare with alternatives, but siblings are mostly non-deletion actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool is disabled by default and supports a dry-run preview. It also hints at a safe workflow. However, it does not explicitly state whether the operation is destructive or what happens to existing settings beyond auth, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loaded with purpose. It packs multiple pieces of info (purpose, removal, workflow, disabled flag, dry run) into a compact form. The mixing of languages slightly reduces clarity but overall structure is efficient.
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 4 parameters, no output schema, and no annotations, the description covers purpose, removal, safe workflow, and activation requirement. However, it misses the 'org' parameter, does not describe error conditions or return values, and could be more explicit about the exact effect on the ingress configuration.
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 description must add meaning. It explains username and password as the credentials for auth, and implies app_id as the target app. However, the 'org' parameter is not mentioned at all, and no format or constraints are provided for any 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 clearly states the tool sets Basic Auth on an app's ingress for protection with username/password. It also mentions removing protection by leaving fields empty. This distinguishes it from sibling tools which handle other aspects like builds, logs, or scaling.
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 context: it mentions a secure workflow (GET → merge → PUT) and that the tool is disabled by default, requiring an environment variable to activate. It also explains how to remove auth, giving clear usage guidance. However, it does not compare to alternative auth methods or explicitly state when not to use.
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 present, so the description carries the full burden. It does not disclose read-only nature, permissions, rate limits, or any behavioral traits beyond the output list. For a simple retrieval tool, stating it is read-only would add value.
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 concise sentence in Persian that front-loads the key outputs. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description provides a reasonable list of returned items. However, it omits details like format or nesting, but for a simple whoami tool, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description cannot add parameter meaning. Baseline for 0 parameters is 4. The description adds context about the output, which is sufficient.
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 returns the user profile and lists of organizations, roles, budgets, and clusters. The verb 'returns' is implicit via the Persian phrase meaning 'profile + list of...'. This distinguishes it from sibling tools that focus on apps, billing, etc.
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 only lists what it returns, without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool is disabled by default (requires HAMRAVESH_ALLOW_WRITE=1) and offers a dry-run preview. However, it lacks crucial behavioral details such as whether the creation is synchronous or asynchronous, required permissions, error handling, or idempotency. The description is insufficient for an agent to safely invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and packs multiple instructions into a single paragraph. It is reasonably concise for the amount of information, though it could benefit from bullet points or better organization for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no output schema), the description provides important operational context like unit guidelines and preview mode. However, it does not explain the actual API call details, error conditions, or result format, leaving gaps for an AI agent to invoke it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema: it explains units for cpu, ram, disk; clarifies num_of_standbys default; directs how to obtain plan from a separate endpoint; specifies engine casing requirements; and notes that cluster_id/namespace_id come from existing resources. This compensates for the 67% schema coverage, though not all parameters are explicitly explained.
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 'Create a managed database (DBaaS)', which is a specific verb+resource. It distinguishes from sibling tools like list_databases, get_database, and delete_database by focusing on creation. The added units and instructions further clarify the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on prerequisites: how to obtain plan, engine format requirements, and sourcing cluster_id/namespace_id. It also mentions the disabled state and preview mode. However, it does not explicitly state when to use this tool over alternatives like list or get, nor does it list 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, and the description does not disclose behavioral traits such as read-only nature, rate limits, or authentication requirements. It is neutral but leaves gaps for a mutation-sensitive agent.
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, well-structured sentence that immediately communicates the tool's purpose and output fields. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists expected output fields, which compensates slightly for the lack of an output schema. However, it does not explain the scope or behavior when the org parameter is omitted, though the schema provides partial context.
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 100% and the parameter description in the schema is clear (optional org name with default). The tool description adds no further parameter semantics, but the schema suffices.
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 explicitly states the tool lists apps of an organization and lists the included fields (status, domain, resources, replicas). It clearly distinguishes this list tool from sibling tools like 'hamravesh_get_app' which retrieves a single app.
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 gives no explicit guidance on when to use this tool versus alternatives. The usage is implied as a list operation, but no conditions or exclusions 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?
No annotations are provided, so the description carries the full burden. It discloses method permissions (GET always allowed, write methods require ALLOW_WRITE, DELETE requires ALLOW_DELETE). However, it does not mention other behavioral aspects like rate limits, idempotency, error handling, or the raw response format. This is a minimal disclosure for a generic request tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the purpose and then specifying permission rules. Every sentence is essential and informative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a generic raw request endpoint with no output schema. The description should explain the response format, error handling, and potential side effects. It only covers permissions and references a file for paths. For a fallback tool, this is incomplete; the agent cannot understand what to expect from the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 6 parameters with 67% description coverage (4 of 6 have descriptions). The description adds permission context for method but does not explain 'org', 'params', or 'headers' beyond what is in the schema. It states that 'body' is for write methods, which is implicit. Overall, the description adds marginal value over 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 purpose: making raw requests to any Hamravesh endpoint not covered by dedicated tools. It uses a specific verb ('raw request to any endpoint') and distinguishes from siblings by limiting to tasks without dedicated tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (tasks without dedicated tools) and specifies permission requirements for methods (GET always allowed, POST/PUT/PATCH require ALLOW_WRITE, DELETE requires ALLOW_DELETE). It references ENDPOINTS.md for the full path list. However, it does not explicitly state when not to use it (e.g., if a dedicated tool exists, use that).
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, the description carries full weight. It discloses the tool's disabled status, the need for an activation environment variable, and the dry-run preview option, providing critical behavioral context beyond the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) but packs essential caveats. It is front-loaded with the primary action, though the mix of Persian and English and the use of parentheses for the notes could be slightly clearer.
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 write tool with no output schema, the description covers the core purpose, activation requirement, and preview mode. However, the lack of parameter documentation leaves gaps, making it only moderately complete.
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 description does not explain any of the three parameters (app_id, replicas, org). Schema coverage is 0%, so the description should compensate, but it only vaguely describes the overall action without parameter details.
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 changes the replica count of an app, using a specific verb and resource. It is distinct from sibling tools like restart, redeploy, etc., which focus on other app lifecycle operations.
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 notes the tool is disabled by default and requires setting HAMRAVESH_ALLOW_WRITE=1 to activate, and mentions a preview mode with dry_run. However, it does not provide alternatives or contraindications among siblings.
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 bears full responsibility. It discloses that the tool is a write operation, has a dry-run mode, and is disabled by default (needs HAMRAVESH_ALLOW_WRITE=1). However, it does not discuss side effects like billing, idempotency, or required permissions beyond the disabled flag.
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 paragraph that efficiently conveys purpose, required context, and configuration flags. It is front-loaded with the main action. No extra words, but the structure could be slightly improved with clearer separation of notes.
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 14 parameters (7 required) and no output schema or annotations, the description covers the core creation logic and pre-requisites. However, it lacks information about return values, error conditions, or post-creation behavior, which would be beneficial for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds value by explaining how to derive values for plan, namespace, and organization from hamravesh_get_app, and notes that the name is immutable after creation. This goes beyond listing parameter names.
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 it creates a new Docker-image app in Darkub, with specific resource types (plan, namespace, organization) required. This distinguishes it from sibling tools like hamravesh_create_database or hamravesh_create_saas, which create different 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 tells the agent to obtain plan, namespace, and organization from hamravesh_get_app, providing a clear usage pattern. It also mentions dry_run and write permission flags. However, it does not explicitly state when not to use this tool or list alternatives, but the context is sufficient for differentiation.
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 fully discloses irreversibility, permission requirements, activation condition, and preview mode. No contradictions.
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?
Single sentence containing all critical information: action, irreversibility, permissions, activation, and preview. No wasted words.
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?
Covers behavioral context well but lacks parameter documentation and return value information. With no output schema, the agent may not know what to expect after deletion.
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?
Input schema has 2 parameters (app_id required, org optional) with 0% schema description coverage. The description does not explain the meaning or role of these parameters, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (complete deletion), resource (DBaaS database), and irreversibility. It distinguishes from siblings like list, get, create by specifying deletion and irreversibility.
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?
Describes required permission (ALLOW_DELETE), activation flag (HAMRAVESH_ALLOW_WRITE=1), and preview mode (dry_run). Provides clear context for when the tool can be used, though doesn't explicitly mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses critical behavior: the tool replaces the entire given arrays (not incremental update), is disabled by default, and supports dry-run. However, it does not specify authentication requirements, error handling, or idempotency. The disclosed traits are significant but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose first, then parameter details, then cautionary notes. It is somewhat verbose but each sentence adds value. It could be slightly trimmed, but overall it is efficient and front-loaded.
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?
Given the tool has 4 parameters, no output schema, and no annotations, the description adequately covers the necessary context: it explains the replacement behavior, the disabled state, the dry-run option, and references the related read tool. This provides sufficient completeness for an agent to use the tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, and the description adds meaning by explaining the format of envs and secret_envs as arrays of {name, value} objects and stating that at least one of them is required. This goes beyond the schema's required field (only app_id). However, it does not describe the org parameter or provide additional syntax details for the arrays.
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 it updates environment variables of an app, distinguishing between normal and secret envs. It specifies the format and that at least one of the two arrays must be provided. This verb+resource purpose is distinct from sibling tools like hamravesh_get_app and hamravesh_scale_app.
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 explicitly advises to first use hamravesh_get_app to see the current state, warns that the call replaces the entire arrays (not merge), and notes the tool is disabled by default requiring HAMRAVESH_ALLOW_WRITE=1. It also mentions dry-run capability. These provide clear when-to-use and what-to-avoid guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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