NEUS MCP
Server Details
NEUS hosted MCP: verifiers, proofs, verify flows, agents. Always call neus_context first.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- neus/network
- GitHub Stars
- 11
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 3.1/5 across 9 of 9 tools scored. Lowest: 2.3/5.
Most tools have distinct purposes (agent, context, profile, proofs, verifiers, verify), but neus_verify and neus_verify_or_guide both handle verification, with the latter as a fallback, causing slight potential confusion.
All tools follow a consistent neus_ prefix with snake_case verb-noun pattern (e.g., neus_agent_create, neus_proofs_check), creating a predictable and readable structure.
Nine tools cover the core workflows (agent setup, proofs, verifiers, verification, context) without unnecessary duplication or missing steps, fitting the domain well.
The set covers main operations: agent onboarding, proof checking/getting, verifier catalog, verification, and fallback orchestration. Missing explicit proof creation, but that is part of the verification process.
Available Tools
12 toolsneus_agent_createCInspect
Prepares agent-identity and agent-delegation payloads (signatures and/or hostedVerifyUrl). Does not finalize receipts; confirm with neus_agent_link after signing. Skills/services fields are metadata only, not secrets.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | ||
| scope | No | ||
| preset | No | ||
| skills | No | ||
| agentId | Yes | ||
| purpose | No | ||
| maxSpend | No | ||
| services | No | ||
| agentType | No | ||
| expiresAt | No | ||
| agentLabel | No | ||
| agentWallet | No | ||
| description | No | ||
| permissions | No | ||
| capabilities | No | ||
| instructions | No | ||
| defaultRuntime | No | ||
| controllerWallet | No | ||
| delegationSkills | No | ||
| delegationInstructions | No | ||
| delegationDeniedActions | No | ||
| delegationRuntimePolicy | No | ||
| delegationAllowedActions | No | ||
| delegationApprovalPolicy | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds one behavioral note: 'Listed skills/services are descriptive metadata, not secrets or substitute credentials.' With no annotations, this is insufficient—other behaviors like side effects, permissions, or state changes are not disclosed.
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 very short (two sentences), but it is under-specified and lacks necessary detail. Conciseness is compromised by insufficient content.
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?
With 18 parameters, no schema descriptions, no output schema, and no annotations, the description is far too brief. It fails to provide essential context for the agent to 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?
Schema coverage is 0% for 18 parameters. The description only vaguely mentions skills/services as metadata, offering no meaningful explanation for any parameter.
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 states 'Starts delegated agent onboarding (identity and delegation proofs)', which gives a specific verb and resource. It distinguishes from siblings like neus_agent_link and neus_verify, but does not fully clarify the outcome or what is created.
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 guidelines are provided on when to use this tool vs alternatives, such as prerequisites or context. The description offers no when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
neus_agent_linkCInspect
Readiness check for an agent wallet: returns linked when agent-identity and agent-delegation proofs exist; otherwise link_required with hostedVerifyUrl.
| Name | Required | Description | Default |
|---|---|---|---|
| principal | No | ||
| agentWallet | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose whether the operation is read-only, has side effects, or requires authentication, lacking critical behavioral information.
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—concise but potentially too brief, omitting context that could be included without bloat.
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?
Does not explain return values, the setup flow context, or how this tool relates to siblings like neus_agent_create, leaving significant gaps for an agent.
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 description coverage is 0% and the description adds no explanation for parameters 'principal' and 'agentWallet', failing to clarify their meanings or usage.
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 confirms agent identity and delegation readiness or returns next setup step, distinguishing it from create and verify siblings.
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 on when to use this tool versus alternatives like neus_agent_create or neus_verify, leaving the agent without selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
neus_contextAInspect
NEUS MCP session home: product summary, setup, access-key mode, verifier summaries, reuse-first workflow, tools, and safety rules. Always call first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
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 lists the contents (product summary, setup, safety rules) but does not disclose behavioral traits like side effects, auth requirements, or whether it is read-only. It implies it is safe to call first but lacks explicit transparency.
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, zero waste. The first sentence lists the contents, the second gives the instruction. Very efficient.
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?
For a tool with no parameters and no output schema, the description is adequate but not fully complete. It tells what the tool provides and that it should be called first, but does not describe the return format or what happens if not called first. An agent might need more detail on expected response structure.
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?
There are zero parameters, so baseline is 4. The description adds no parameter meaning, but none is needed since the schema already implies no input is required.
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 it is a 'session home' that provides product summary, setup, and other context. It also explicitly says 'Always call first', indicating its role as the initial tool. This distinguishes it from sibling tools like neus_agent_create or neus_verify.
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 'Always call first', which is clear usage guidance. However, no when-not or alternatives are mentioned, but given its unique role as an introductory tool, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
neus_meCInspect
Returns the signed-in NEUS Profile when a personal access key from Profile → Account is configured on this MCP session.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry all behavioral disclosure. It mentions a prerequisite (access key configured) but does not specify behavior if the prerequisite is unmet (e.g., error), side effects, or output details.
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 concise sentence with no redundant information. It is efficient but could benefit from a clearer structure separating the action from the prerequisite.
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 no output schema, no annotations, and an unexplained parameter, the description is insufficient for complete understanding. It omits error conditions, return format, and how the optional identifier affects behavior.
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 one optional parameter 'identifier' with zero schema description coverage (0%). The description fails to explain the purpose or usage of this parameter, leaving the agent without necessary context.
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 verb 'Returns' and the resource 'signed-in NEUS Profile', making the purpose unambiguous. However, it does not explicitly differentiate this tool from siblings like neus_context, which might also return user-related data.
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 explicit guidance on when to use this tool versus alternatives is provided. The description implies usage when needing the signed-in profile and having configured an access key, but no when-not or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
neus_proofs_checkAInspect
Checks whether existing proofs satisfy verifier IDs. Eligibility only; never creates proofs.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | ||
| minCount | No | ||
| verifiers | Yes | ||
| requireAll | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description clarifies it never creates proofs, which is key. However, does not explicitly state read-only nature or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Front-loaded with purpose and key constraint.
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?
No output schema and 4 parameters with no descriptions. Description provides overall purpose but lacks parameter details and result format, insufficient for agent to use confidently.
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 description coverage is 0%. Description only mentions 'verifier IDs', providing minimal context for the 'verifiers' parameter. No explanation for 'wallet', 'minCount', or 'requireAll'.
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 states specific verb 'checks whether existing proofs satisfy verifier IDs' and adds 'Eligibility only; never creates proofs', clearly distinguishing from sibling tools that may retrieve or create proofs.
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?
Explicitly says 'Eligibility only; never creates proofs', telling when to use and what not to do. Lacks explicit alternatives but implies boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
neus_proofs_getCInspect
Reads proof records, tags, delegated agent reads, Profile summary fields, and live proof state. Use returned proof records as receipt references.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| tags | No | ||
| limit | No | ||
| scope | No | ||
| offset | No | ||
| tagPrefix | No | ||
| identifier | Yes | ||
| verifierId | No | ||
| agentWallet | No | ||
| searchQuery | No | ||
| tagContains | No | ||
| tagPrefixesAll | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares read operation and notes qHashes are authoritative, but with no annotations, carries full burden; lacks details on auth, side effects, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff, but could benefit from more structure to highlight key information like parameters.
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?
With 11 parameters, no output schema, and no annotations, the description is insufficient; lacks parameter details and comprehensive behavioral info.
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 0% and description does not explain any of the 11 parameters, leaving agents without necessary context.
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 it reads various proof-related data, but does not distinguish from sibling tools like neus_proofs_check.
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 on when to use this tool over alternatives; lacks context for selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
neus_secret_createInspect
Store an env-style secret as an encrypted proof. Creates an ownership-basic proof with secret-storage tags. Values are AES-256-GCM sealed and never returned in plaintext via MCP.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| alias | Yes | ||
| content | Yes | ||
| secretType | No | ||
| walletAddress | Yes |
neus_secret_listInspect
List env-style secret proofs for a wallet. Returns metadata only (qHash, alias, type, updatedAt). Values are never exposed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| walletAddress | Yes |
neus_secret_revokeInspect
Revoke a stored secret proof by qHash. Removes the proof and cleans up any agent bindings. Requires authenticated ownership.
| Name | Required | Description | Default |
|---|---|---|---|
| qHash | Yes | ||
| walletAddress | Yes |
neus_verifiers_catalogAInspect
Full verifier directory with JSON schemas. Use after neus_context when payloads need exact fields beyond the summary.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns a directory with schemas, implying a read-only lookup. However, it lacks details about response format, pagination, or any side effects. For a parameterless tool, it is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose and usage, with no unnecessary words. Every part adds value.
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 zero parameters, no output schema, and clear sibling context, the description fully covers the tool's purpose and when to use it. It is complete for a simple directory lookup.
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?
There are no parameters in the input schema, so the baseline is 4. The description adds no param-specific information, which is acceptable as there are none to describe.
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 it's a 'Full verifier directory with JSON schemas', identifying the tool as a provider of detailed schemas. It distinguishes from siblings by specifying its use after neus_context when exact fields are needed.
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 after neus_context when payloads need exact fields beyond the summary', giving a clear usage context. It does not mention when not to use or alternatives, but the guidance is direct and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
neus_verifyCInspect
Creates or continues verification only when Profile access, wallet, and signing already satisfy NEUS for this verifier. Check existing receipts first.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | ||
| chain | No | ||
| options | No | ||
| signature | No | ||
| verifierIds | Yes | ||
| walletAddress | Yes | ||
| signedTimestamp | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose more behavioral details. It hints at stateful behavior (creates/continues) and prerequisites, but lacks information on side effects, errors if conditions fail, or authentication needs.
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 sentences front-load the purpose and a key prerequisite. No wasted words, though it could be slightly more informative without losing conciseness.
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 complexity (7 parameters, nested objects, no schema descriptions, no output schema), the description is severely incomplete. It fails to explain return values, parameter details, or the verification workflow.
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 0% description coverage and 7 parameters. The description does not explain any parameter's meaning or role, leaving the agent to guess how 'walletAddress', 'verifierIds', or 'signature' relate to the mentioned conditions.
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 or continues verification under specific conditions, and mentions checking receipts. It distinguishes from sibling 'neus_verify_or_guide' by implying this tool is for when conditions are already met.
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 instructs to 'Check existing receipts first' and specifies conditions for use, but does not explicitly compare with alternatives like 'neus_verify_or_guide' or explain when not 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.
neus_verify_or_guideCInspect
Fallback orchestration after reuse checks: use only when proof, profile, payment, provider, wallet, or delegation setup is missing.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | ||
| chain | No | ||
| options | No | ||
| requireAll | No | ||
| verifierIds | Yes | ||
| walletAddress | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely labels the tool as 'fallback orchestration' without detailing side effects, authorization requirements, return values, or operational traits. The behavioral information 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence and gets to the point quickly. It is concise, but could benefit from a slightly more structured format, e.g., separating purpose and usage hints.
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?
This tool has six parameters, no annotations, and no output schema. The description is only one sentence and does not cover the parameters' roles, return values, or orchestration steps. It is severely incomplete for the complexity involved.
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 description does not explain any of the six parameters, and the input schema has 0% description coverage. The description mentions 'proof, profile, payment, provider, wallet, or delegation' but these are not parameters. The tool fails to add meaning to 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 it is a fallback orchestration after reuse checks, used when specific setups (proof, profile, payment, provider, wallet, or delegation) are missing. This provides a specific verb and resource, and implicitly distinguishes it from siblings like neus_verify or neus_proofs_check by framing it as a fallback.
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 prescribes when to use this tool: 'use only when proof, profile, payment, provider, wallet, or delegation setup is missing.' This gives clear context, though it does not provide when-not-to-use or name alternative tools explicitly.
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!