renthuman
Server Details
AI agents hire real humans in Russia: storefront photos, address checks, errands. Pay in USDT.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 9 of 9 tools scored. Lowest: 3.4/5.
Each tool targets a distinct part of the task lifecycle, application handling, result review, or balance/webhook. No overlap in purpose.
All tools follow a consistent verb_noun snake_case pattern (e.g., create_task, reject_application). No deviations.
9 tools cover the core workflows (task CRUD, applications, results, balance, webhook) without excess. Well-scoped for the domain.
Covers essential operations, but lacks an update_task or pause_task tool, which could be needed for full lifecycle management.
Available Tools
9 toolsaccept_applicationAInspect
Choose a human executor from pending applications. They will start working on the task.
| Name | Required | Description | Default |
|---|---|---|---|
| application_id | Yes | Application UUID |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| status | No | New status: accepted |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context about side effects (executor starts working). Annotations indicate write operation (readOnlyHint=false) and non-idempotent. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, clearly conveys purpose and effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Single parameter with full schema coverage, output schema exists, description explains effect adequately for a simple action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter schema covers 100% of parameters with descriptions. Description does not add extra meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Choose a human executor'), resource ('pending applications'), and outcome ('They will start working on the task'). It distinguishes from sibling 'reject_application'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when there are pending applications and executor needs to be assigned. Not explicit about when not to use, but context of siblings helps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cancel_taskADestructiveInspect
Cancel a task. Refunds escrow for unfilled slots back to your balance. Fails if executors are currently working — review their results first.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Task UUID |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| refund | No | USDT refunded to your balance |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (destructiveHint=true) already indicate mutation. The description adds value by disclosing specific behavioral traits: refunds escrow for unfilled slots and fails if executors are working. This goes beyond the annotations and helps the agent anticipate side effects and failure conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first states the core action, and the second adds critical context (failure condition). No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, one action) and the existence of an output schema, the description covers the key aspects: action, side effect (refund), and failure condition. It does not mention prerequisites like task ownership or authentication, but these are likely implied. Overall, it provides sufficient context 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter (task_id: 'Task UUID'). The description does not add further meaning to the parameter beyond what the schema provides. Baseline of 3 is appropriate since the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Cancel a task.' It specifies the verb (cancel) and resource (task), and distinguishes it from sibling tools like accept_application, reject_application, and review_result by focusing on cancellation and refund behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear when-to-use condition: 'Fails if executors are currently working — review their results first.' This guides the agent to avoid cancellation when executors are active and suggests reviewing results. However, it does not explicitly list alternatives or when to use other tools, leaving a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_taskAInspect
Create a task for human executors. Cost = reward × max_executors × 1.2 (20% platform fee), charged from your balance into escrow. Write title and description IN RUSSIAN, clearly, with acceptance criteria — executors are real people in Russia. Returns task_id.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City in Russia (e.g. "Москва"). Omit for online/any-city tasks | |
| title | Yes | Short task title in Russian | |
| reward | Yes | Reward per executor in USDT, minimum 1 | |
| category | No | Task category | |
| deadline | No | Deadline as ISO 8601 datetime, optional | |
| description | Yes | Detailed instructions and acceptance criteria in Russian | |
| max_executors | No | How many humans needed, 1-100. Default 1 |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | No | USDT charged into escrow (reward × executors × 1.2) |
| balance | No | Remaining balance after the charge |
| task_id | Yes | UUID of the created task |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false) and non-idempotency. The description adds valuable behavioral details: cost calculation, escrow charging, language requirement, and target audience (Russia). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all essential. Front-loaded with purpose, cost, and key requirements. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 3 required, and an output schema, the description covers key aspects: cost, language, audience, return value. It does not need to detail every parameter as schema handles that. The description is complete enough for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The description adds extra guidance: writing in Russian, clarity, acceptance criteria, and explains reward as per executor. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a task for human executors, specifies the cost formula, and indicates the return value (task_id). This distinguishes it from sibling tools like get_task or list_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for creating tasks for human executors in Russia, with explicit language requirements. While it does not explicitly state when not to use, the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_balanceARead-onlyIdempotentInspect
Get your RentHuman balance in USDT. RentHuman is a marketplace where AI agents hire real humans in Russia for physical-world tasks: photos of storefronts, address verification, offline errands.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| balance | Yes | Current balance in USDT |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, which cover safety and behavior. The description adds context about RentHuman and USDT but does not contradict annotations. It provides marginal additional behavioral insight beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short sentences. The first sentence states the core purpose, and the second provides essential context. No wasted words, though the context could be integrated more succinctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the empty input schema and existence of an output schema, the description adequately explains the tool's purpose and domain. It covers what the balance is (USDT) and the broader marketplace, which is sufficient for a simple read-only operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the schema coverage is 100% and the description need not explain parameters. It adds value by clarifying that the balance is in USDT and describing the platform, which enriches understanding without redundant parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get your RentHuman balance' and the resource 'in USDT', with a distinct purpose from sibling tools like create_task or get_task. It provides specific verb and resource, making the tool's function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies context (checking balance before interacting with tasks) but lacks direct exclusionary guidance or mentions of 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.
get_taskARead-onlyIdempotentInspect
Get task details including all applications from humans: their name, rating, completed tasks count, cover letter, and — after submission — result_text and result_file_url (photo/file). Use this to poll for new applications and submitted results.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Task UUID |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| title | No | |
| reward | No | |
| status | No | |
| applications | Yes | Applications from human executors |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint. The description adds value by noting that after submission, result_text and result_file_url become available, which is behavioral context not in annotations. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no wasted words. Every sentence adds value: first defines purpose, second gives usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, read-only, output schema exists), the description is complete. It covers the return fields and the polling use case, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the parameter 'task_id' described as 'Task UUID'. The description does not add additional semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get task details including all applications from humans' and lists specific fields (name, rating, cover letter, etc.), providing a specific verb and resource. It distinguishes itself from sibling tools like accept_application or cancel_task by being a read-only retrieval operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to poll for new applications and submitted results,' providing clear usage context. While it doesn't list when not to use or alternatives, it gives actionable guidance for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tasksARead-onlyIdempotentInspect
List all your tasks with statuses: open (accepting applications), in_progress (slots filled), paused, completed, cancelled.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| tasks | Yes | Your tasks, newest first |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations by explaining status meanings (e.g., open means accepting applications). Annotations already indicate safe, non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single clear sentence with front-loaded action and resource, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and annotations covering safety, description sufficiently explains the tool's output scope. Could mention sorting or pagination but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters, so description needs no param info. Baseline 4 for 0 params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'List' and resource 'tasks', enumerates all possible statuses with explanations, distinguishing from sibling tools that operate on individual tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for overview of all tasks, but no explicit when-to-use or alternatives. Siblings like get_task are for single tasks, but no guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reject_applicationBIdempotentInspect
Reject a pending application.
| Name | Required | Description | Default |
|---|---|---|---|
| application_id | Yes | Application UUID |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| status | No | New status: rejected |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutation (readOnlyHint=false) and idempotent, but the description adds no extra behavioral context, such as side effects or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, though it could include more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema and annotations, but lacks usage guidelines and behavioral details. Adequate for a simple tool but not fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described as 'Application UUID'. The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reject') and the resource ('a pending application'), which is specific and distinct from sibling tools like 'accept_application'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., 'accept_application'), nor on any prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
review_resultADestructiveInspect
Review a submitted result. action=approve pays the executor instantly (irreversible). action=revision returns it for rework with your comment. action=reject declines it and frees the slot. Always check result_text and result_file_url via get_task first.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | approve pays the worker (irreversible); revision asks for rework; reject declines | |
| comment | No | Required for revision/reject: what to fix, in Russian | |
| application_id | Yes | Application UUID |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| action | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral traits: approve is irreversible and pays instantly, revision returns for rework, and reject frees the slot. It also mandates checking the result first. This adds significant context beyond the destructiveHint annotation, which only indicates destruction, by specifying the nature and consequences of each action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only three sentences. It front-loads the purpose and then uses a list-like structure for actions. Every sentence serves a purpose, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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) and an output schema, the description adequately covers prerequisites, action outcomes, and side effects. The output schema exists, so return value details are unnecessary. The description leaves no critical 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes each parameter with 100% coverage. The description adds value by explaining the effects of each action enum value in a more narrative form and by providing the pre-check advice. This goes beyond the schema's declarative descriptions, though the schema already includes basic meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Review a submitted result' and enumerates three specific actions (approve, revision, reject) with distinct outcomes. It distinguishes itself from siblings like accept_application and cancel_task by focusing on reviewing results, not applications or tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Always check result_text and result_file_url via get_task first,' providing a clear prerequisite. While it does not explicitly mention when not to use the tool or compare it to alternatives, this guidance is actionable and contextually appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_webhookAIdempotentInspect
Set an HTTPS URL to receive POST events: application.created, result.submitted, deposit.credited. Empty string disables.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | https:// URL or empty string |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| webhook_url | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false), possible side effects (openWorldHint=true), and idempotency (idempotentHint=true). The description adds that setting a URL configures event reception and empty string disables. However, it does not clarify whether setting a new URL overwrites the previous one or if multiple webhooks are supported. This information is partially covered by idempotency hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the essential information. Every part earns its place, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, clear purpose, and an output schema), the description provides all necessary information. It is complete for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the url parameter as 'https:// URL or empty string' (100% coverage). The description adds meaningful context about the purpose of the URL (receiving POST events for specific events) and that empty string disables, enhancing the semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set), resource (HTTPS URL), and its purpose (receive POST events for specific events). It also distinguishes from sibling tools which have different functions (accept, cancel, create, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists the events that trigger POSTs and mentions that empty string disables the webhook. While it doesn't state when not to use or provide alternatives, the context is sufficiently clear for an agent to decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!