NEUS MCP
Server Details
NEUS MCP: identity, authority, trust receipts, and Vault secrets before sensitive AI actions.
- 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.6/5 across 12 of 12 tools scored. Lowest: 2.7/5.
Each tool has a clearly distinct purpose: agent creation vs linking, proofs check vs get, secret CRUD, separate verify modes. No overlap in functionality.
All tools follow a consistent 'neus_<descriptive_name>' pattern using snake_case, making the set predictable and easy to navigate.
12 tools is well-scoped for an identity and verification server, covering agent setup, proofs, secrets, verifier catalog, and verification without being excessive.
Core workflows (context, agent, proofs, secrets, verification) are covered. Minor gap: no explicit tool to delete proof records, but revocation covers secrets and agents.
Available Tools
12 toolsneus_agent_createAInspect
Creates agent identity and access receipts. Uses the authenticated session first (no browser when the profile can authorize). Falls back to hosted verify only when session cannot complete. Confirm with neus_agent_link when done.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | ||
| scope | No | ||
| preset | No | ||
| skills | No | ||
| agentId | Yes | ||
| 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?
No annotations provided, so description carries burden. Discloses authentication behavior (session vs hosted verify) and follow-up step. Lacks potential side effects or error handling 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?
Three sentences, each serving a purpose: purpose, process, follow-up. No fluff, 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?
Despite clarity on purpose and flow, the tool has 23 parameters, nested objects, and no output schema. Description is far too brief to guide effective use for such complexity.
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?
With 23 parameters and 0% schema description coverage, description should explain parameter meanings but does not. It mentions no parameter, not even the required agentId.
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 'Creates agent identity and access receipts', specifying the verb 'creates' and resource 'agent identity and access receipts'. It distinguishes from sibling tool neus_agent_link which is for confirmation.
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?
Provides clear usage context: uses authenticated session first, falls back to hosted verify, and advises to confirm with neus_agent_link when done. Does not explicitly state when not to use, but implies the flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
neus_agent_linkAInspect
Readiness check for an agent wallet: returns linked when identity and access receipts exist. When setup is missing and the caller is authenticated, call neus_agent_create next — browser is fallback only.
| Name | Required | Description | Default |
|---|---|---|---|
| principal | No | ||
| agentWallet | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses return condition ('linked') and next action, but omits details on authentication requirements, error handling, or behavior for unauthenticated callers.
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 with no extraneous words. The structure front-loads core purpose and follows with conditional 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?
For a simple readiness check, description covers core logic and next steps. However, it lacks details on return values beyond 'linked' and omits error handling, leaving minor 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 description coverage is 0%, but description does not elaborate on parameters. It mentions 'agent wallet' but does not explain 'principal' or how parameters affect behavior, failing to compensate for the schema gap.
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 explicitly states it is a readiness check for an agent wallet, returning 'linked' when identity and access receipts exist. It clearly distinguishes the tool's purpose from siblings like neus_agent_create by specifying when to use that tool.
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?
Description provides explicit guidance: when setup is missing and caller authenticated, use neus_agent_create; browser is fallback only. This clearly indicates when to use this tool versus alternatives.
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: current mode, signed-in profile context, verifier summary, reuse-first workflow, tools, and safety rules. Call once at session start.
| 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 present, so the description must disclose behavioral traits. It mentions safety rules but does not elaborate, nor does it state read-only or idempotency. The call-once instruction implies no side effects, but not explicitly.
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 sentence with a concise list and action instruction. No wasted words; front-loaded with purpose.
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 exists, but description enumerates the key output categories (mode, profile, verifier summary, etc.), providing sufficient context for an initialization tool.
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 description does not need to explain them. Baseline is 4 for 0-param tools. The description adds value by detailing the output content.
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 lists the context items provided (mode, profile, verifier summary, etc.), giving a clear idea of what the tool returns. It distinguishes from siblings which handle specific actions like creating agents or verifying 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 states 'Call once at session start', providing clear when-to-use guidance. Does not exclude alternatives, but no sibling tool serves the same initialization purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
neus_meBInspect
Refresh signed-in Profile context, or look up a public Profile by wallet/DID.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and description only states two actions without disclosing behavioral traits like authentication needs, 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?
Single sentence covers core functionality without redundancy. Efficient and front-loaded.
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?
Lacks explanation of return values for both operations. Without output schema, description should at least hint at what the agent can expect.
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?
Description adds meaning by suggesting 'identifier' is a wallet address or DID, compensating for 0% schema coverage. However, format examples or constraints are missing.
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 two purposes: refreshing signed-in profile context and looking up a public profile by wallet/DID. However, it does not differentiate from sibling tool 'neus_context' which might be related.
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 when to use (refresh context or lookup profile) but provides no explicit exclusions or alternatives compared 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 Proof Receipts satisfy required checks. Eligibility only; never creates proofs. Omit wallet when signed in to use the session profile wallet.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | No | ||
| 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 adds behavioral trait 'never creates proofs' but lacks details on authorization, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted 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?
No output schema; description doesn't explain return values or what 'satisfy' means. Adequate for a simple check tool but could be more complete.
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?
Only wallet parameter gets usage instruction; other parameters (verifiers, minCount, requireAll) remain unexplained despite 0% schema coverage.
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 'checks' and resource 'Proof Receipts'. Distinguishes from siblings like 'neus_proofs_get' (retrieval) and 'neus_verify' (verification).
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?
Provides specific guidance on omitting wallet when signed in. Lacks explicit when-to-use vs alternatives, but context implies usage for eligibility checking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
neus_proofs_getBInspect
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?
No annotations are provided, so the description must carry the transparency burden. While 'Reads' implies a read-only operation, the description does not explicitly confirm safety, auth requirements, rate limits, or side effects. It lists what is read but lacks detail on behavioral traits beyond the obvious.
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: the first explains the tool's function, the second offers a usage hint. The description is concise with no wasted words, but it could be better structured to include parameter 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 high parameter count (12), no output schema, and no annotations, the description is incomplete. It does not explain how parameters affect results, what the return structure looks like, or how to effectively use the tool. The hint about receipt references is vague and insufficient.
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?
With 12 parameters and 0% schema description coverage, the description adds no information about any parameter. The property names offer some hints, but many (e.g., 'q', 'tagPrefixesAll') are unclear. The description should compensate for the lack of schema descriptions but fails to do so.
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 'Reads' and specifies the resources: proof records, tags, delegated agent reads, Profile summary fields, and live proof state. Among sibling tools like neus_proofs_check or neus_verify, this tool is distinctly a read operation, providing clear purpose differentiation.
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 includes a hint to use returned proof records as receipt references, implying a usage context, but it does not explicitly state when to use this tool versus alternatives like neus_proofs_check or neus_verify, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
neus_secret_createAInspect
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 |
Tool Definition Quality
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 secret is AES-256-GCM sealed, never returned in plaintext, and stored as an ownership-basic proof. While more details (e.g., authentication needs) could help, this is adequate for a secure write operation.
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 tightly focused sentences with no redundancy. The first sentence defines the primary action, the second adds technical context, and the third a key security constraint. 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?
The description lacks details about return values, side effects, or post-conditions. It implicitly states the plaintext is not returned, but the agent needs to know what the tool does return (e.g., a proof ID). Given no output schema, this is a significant gap.
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%, yet the description does not explain individual parameters. It hints at tags and env-style secrets but fails to map to walletAddress, alias, content, or secretType. This leaves the agent guessing, despite some contextual clues.
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: storing an env-style secret as an encrypted proof, with verbs 'store' and 'creates'. It distinguishes the tool from siblings like neus_secret_list and neus_secret_revoke by focusing on creation.
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 given on when to use this tool versus alternatives. There is no mention of conditions, prerequisites, or when not to use it, leaving the agent to infer from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
neus_secret_listAInspect
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 |
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. It clearly states that only metadata (qHash, alias, type, updatedAt) is returned and that values are never exposed. This discloses key behavioral aspect, though it could mention if there are any side effects or permissions needed.
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 two sentences with zero waste. The first sentence states the primary purpose, and the second sentence clarifies the return format and a critical behavioral guarantee. It is front-loaded and 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?
Given there is no output schema, the description appropriately lists the metadata fields returned and emphasizes that values are not included. It covers the main purpose and key constraints. Some details about pagination (limit/offset) or error behavior are missing, but for a list tool this is generally acceptable.
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 no descriptions (0% coverage), and the description does not explain the parameters. It only implies walletAddress as the wallet identifier, but limit and offset are left entirely unexplained. The description adds minimal value beyond the schema property names.
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 explicitly states 'List env-style secret proofs for a wallet' – a clear verb+resource combination. It distinguishes itself from siblings like neus_secret_create and neus_proofs_get by specifying that it only returns metadata and never exposes values.
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 clearly indicates the tool is for listing secret proofs and notes that values are not exposed. However, it does not explicitly state when to use this tool versus sibling tools like neus_proofs_get for retrieving actual proof values, nor does it mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
neus_secret_revokeAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It reveals the destructive nature (removes proof, cleans up bindings) and the ownership requirement. However, it omits details on side effects, idempotency, or what happens if the qHash does not exist.
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 with no wasted words. Key information is front-loaded: action and identifier in the first sentence, then effects and precondition in the second.
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 revocation tool with no output schema, the description covers the main action, parameters, and a precondition. However, it lacks information on success/error responses and behavior for missing proofs, which would enhance completeness.
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%, so description must add meaning. It explains qHash as the identifier and implies walletAddress is the owner, but provides no format or constraints beyond the property names.
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 (revoke), the target (stored secret proof), and the identifier (qHash). It distinguishes from sibling tools like neus_secret_create and neus_secret_list by specifying revocation and cleanup.
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 says 'Requires authenticated ownership', indicating a prerequisite, but does not explicitly state when to use this tool versus alternatives or when not to use it. The context of revocation against creation/list is implicit but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?
No annotations are provided, so the description fully carries the burden of behavioral disclosure. It mentions preconditions but does not describe side effects, destructive nature, authorization requirements, rate limits, or return behavior. For a tool that creates or continues verification, this lack of transparency is a significant gap.
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, consisting of two sentences that front-load important conditional logic. While it is not verbose, every sentence serves a purpose. It could be slightly more structured but remains effective.
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, no schema description, no output schema) and the lack of annotations, the description is insufficiently complete. It fails to explain return values, failure modes, or how to use the parameters, leaving the agent uninformed about critical aspects of 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?
The input schema has 7 parameters with 0% coverage in description. The description does not explain any parameter except indirectly referencing 'wallet' and 'signing'. Despite the complexity (nested objects, 2 required params), the description adds no value beyond the schema structure.
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 purpose: creating or continuing verification under specific preconditions. It distinguishes from sibling tools like neus_verify_or_guide by emphasizing that it only proceeds when certain conditions are met, though it could be more specific about what 'verification' entails.
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 explicit conditions for use ('only when Profile access, wallet, and signing already satisfy NEUS') and a hint to check existing receipts. However, it does not mention when not to use the tool or identify alternative sibling tools like neus_verify_or_guide, which might serve as a fallback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
neus_verify_or_guideBInspect
Trust autopilot: reuse existing Proof Receipts when eligible, otherwise return the single next step (continue in MCP or open hosted verify). Omit walletAddress when signed in.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | ||
| chain | No | ||
| options | No | ||
| requireAll | No | ||
| verifierIds | Yes | ||
| walletAddress | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the conditional branching (reuse vs. return next step) and mentions possible actions (continue in MCP or open hosted verify). However, it lacks details on side effects, authentication requirements, or what happens to state, making it only partially transparent.
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 only two sentences and avoids unnecessary words. However, the phrase 'Trust autopilot' is somewhat vague and could be removed for greater conciseness. Overall, it is well-structured and front-loaded.
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?
There is no output schema, and the description does not detail the return value structure (what the 'next step' looks like). Combined with the nested object parameters and no annotations, the description leaves significant gaps for an agent to act effectively.
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?
With 0% schema description coverage, the description must compensate. It only addresses the walletAddress parameter ('Omit walletAddress when signed in'), leaving the other five parameters (verifierIds, data, chain, options, requireAll) unexplained. This is insufficient for an agent to use the tool correctly.
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 dual purpose: reusing existing Proof Receipts when eligible, otherwise returning a next step. It distinguishes from the sibling 'neus_verify' by incorporating guidance logic, but the term 'Proof Receipts' is not explained, reducing clarity slightly.
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 implies usage through 'Trust autopilot' and gives a specific note about omitting walletAddress when signed in. However, it does not explicitly contrast with the sibling 'neus_verify' or state when not to use this tool, leaving some ambiguity.
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!