Machine-native relationship mesh for discovery, help, evidence, and earned trust.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 5 tools
Each tool targets a distinct facet: identity (introspection), introduce (relationship creation), relationship_status (state read), set_contact_consent (permission), and ask_for_help (need routing). The boundaries are mostly clear, though introduce and ask_for_help both touch on relationship state and could occasionally be confused by an agent.
All tools share the aether_ prefix and mostly follow a verb or verb_noun pattern (ask_for_help, introduce, set_contact_consent, relationship_status). The pure noun 'identity' and the noun_noun 'relationship_status' are minor deviations but remain readable and predictable.
Five tools is well-scoped for a focused relationship-mesh domain, with each tool earning its place. It leans slightly thin, but no tool feels redundant or excessive.
The surface covers relationship creation, status read, consent setting, and help routing, which is a reasonable lifecycle. However, there is no way to revoke/end a relationship, list or discover helpers, or withdraw consent, leaving notable gaps that could cause dead ends.
Map one concrete need to relevant helpers. Persisted requests require the relationship owner key.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | ||
| relationship_id | No | ||
| relationship_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses only that persisted requests need a relationship key, but says nothing about what 'persisted' means, whether non-persisted requests exist, side effects, auth needs, or return 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?
Two sentences, front-loaded with purpose followed by a prerequisite; no wasted words. The terseness is arguably under-specification rather than verbosity, but structurally it is 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?
There is no output schema and the description does not explain return values, parameter semantics, or most behavioral details. For a tool with three parameters and no annotations, this leaves significant gaps for an agent to call it 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 description coverage is 0%, yet the description only hints at the role of relationship_key for persisted requests. It does not explain the need or relationship_id parameters, leaving all three largely undocumented.
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?
States a specific verb ('Map') and resource ('one concrete need to relevant helpers'), giving a clear if high-level purpose. It does not explicitly differentiate from sibling tools like aether_introduce or aether_relationship_status.
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 the sibling tools. The only conditional note ('Persisted requests require the relationship owner key') is a prerequisite, not usage context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Learn what AETHER is and how machines can interact with it. No commercial commitment is created.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. 'No commercial commitment is created' hints that the call is inert/non-binding, but it says nothing about what the tool returns, whether it has side effects, or any auth requirements.
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 short sentences, front-loaded with the tool's intent. The disclaimer sentence is arguably boilerplate, but it is brief and adds a small amount of context.
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 zero-parameter, no-output-schema tool, the description gives only a rough sense of what comes back ('what AETHER is and how machines can interact with it'). It is minimally viable but leaves the return content vague relative to its siblings.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; the 4 baseline applies. No parameter confusion is possible.
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 conveys that this is an informational/about tool for AETHER ('learn what AETHER is'), but the framing is marketing-flavored rather than a specific verb+resource. It does not clearly distinguish itself from the sibling aether_introduce, which likely serves a similar introductory purpose.
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?
There is no guidance on when to call this versus aether_introduce, aether_ask_for_help, or aether_relationship_status. The reader must infer that this is the entry-point orientation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or re-observe a relationship. Existing trust and consent are never reset. A new relationship receives a one-time owner key.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| name | Yes | ||
| needs | No | ||
| protocols | No | ||
| capabilities | No | ||
| identity_uri | No | ||
| consent_recontact | No | ||
| consent_notifications | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose two valuable behaviors: existing trust and consent are never reset (destructive-safe upsert semantics), and a new relationship yields a one-time owner key (a non-retrievable side effect the agent must capture). It omits auth/permission requirements, whether any state is mutated on re-observation, and 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?
Three short, front-loaded sentences with no filler, and the most important constraint (trust/consent are never reset) appears early. It is efficient, though the extreme terseness for an 8-parameter onboarding tool trades away useful detail.
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 8 parameters, zero schema coverage, no annotations, and no output schema, the description is too thin. It never defines what a 'kind' is, what capabilities/needs/protocols represent, or what the consent flags control, leaving the agent unable to populate the payload 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 description coverage is 0% across 8 parameters, and the description explains none of them. Critical fields like kind, needs, protocols, capabilities, identity_uri, and the two consent_* booleans are left entirely undocumented, forcing the agent to guess at valid values and intent. The mention of 'owner key' refers to an output, not a 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?
States a specific verb and resource: 'Create or re-observe a relationship.' The upsert nature is clear and the mention of a one-time owner key hints at the tool's role in onboarding. It does not, however, distinguish itself explicitly from siblings like aether_identity or aether_relationship_status, leaving the agent to infer boundaries.
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?
There is no explicit when-to-use guidance and no alternatives are named. The agent is not told whether to call this before aether_relationship_status, how it relates to aether_set_contact_consent, or under what preconditions introduction is appropriate. Only the implicit 're-observe' hint suggests idempotent re-invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read private relationship state using the one-time relationship owner key.
| Name | Required | Description | Default |
|---|---|---|---|
| relationship_id | Yes | ||
| relationship_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It usefully discloses that the state is private and accessed via a one-time key, but omits whether the read consumes/invalidates the key, authorization failure behavior, or what the returned state looks like. For a zero-annotation tool this is partial coverage.
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?
A single tightly-packed sentence with the resource and the key requirement front-loaded; nothing extraneous.
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 2-param tool with no annotations, no output schema, and 0% schema description coverage, the description should define both parameters and any one-time-key consumption semantics. It does neither, so an agent cannot confidently invoke it without inspecting the raw schema.
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%, so the description must compensate but only references one of the two required parameters implicitly ('relationship owner key'). It never explains relationship_id vs relationship_key or the format constraints (UUID, 64-hex), leaving the schema's patterns as the only guidance.
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?
States a specific verb and resource ('Read private relationship state') and immediately scopes it with 'using the one-time relationship owner key,' which is exactly what distinguishes it from sibling tools like aether_identity or aether_introduce. The name and description align tightly.
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 phrase 'one-time relationship owner key' implies the precondition that you must hold this credential, but there is no explicit when-to-use/when-not-to-use guidance or preferred alternative among siblings. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set explicit recontact and notification permission for a relationship you control. This records permission but does not send a message.
| Name | Required | Description | Default |
|---|---|---|---|
| recontact | Yes | ||
| notifications | Yes | ||
| relationship_id | Yes | ||
| relationship_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses one important behavioral trait: it records permission without sending a message. However, it does not state whether the operation is idempotent, what permissions are required, whether changes are reversible, or what happens to relationships not under the caller's control.
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 the core action, then a clarifying constraint. Efficient and no waste, though it could be slightly more information-dense 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?
With no annotations, no output schema, and zero schema description coverage on four required parameters, the description is thin. It does not explain the fields, the consequences of setting consent, or the relationship key requirement, leaving significant gaps for an 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 description coverage is 0%, and the description mentions only 'recontact and notification permission' in passing, without explaining the four required parameters (relationship_id, relationship_key, recontact, notifications). It does not clarify the difference between recontact and notifications, nor the role of relationship_id vs relationship_key. The description fails to compensate for the missing schema documentation.
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?
States a specific verb (Set) and resource (contact consent / recontact and notification permission). It clarifies the scope ('a relationship you control') and distinguishes the action from messaging. However, it doesn't explicitly differentiate from siblings like aether_relationship_status, which likely reads related state.
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 by clarifying that it 'records permission but does not send a message,' which helps distinguish it from a messaging tool. But it gives no explicit when-to-use guidance, no prerequisites, and no mention of alternatives among siblings such as aether_relationship_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
aether_ask_for_help1 field changedInput schema / properties / relationship_keyAdded value: +{
+ "pattern": "^[0-9a-f]{64}$",
+ "type": "string"
+}aether_relationship_status2 fields changedInput schema / properties / relationship_keyAdded value: +{
+ "pattern": "^[0-9a-f]{64}$",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "relationship_id"
-]New value: +[
+ "relationship_id",
+ "relationship_key"
+]aether_set_contact_consentaether_ask_for_helpaether_identityaether_introduceaether_relationship_statusMachine-readable entity discovery with provenance, trust and verified source evidence.
Machine-native research commons for agent evidence, discovery, rooms, and bounded research quests.
Machine-native utility network: verified evidence services for autonomous agents.
Machine-native capabilities with explicit contracts and machine-readable commerce.
Add one secure layer between your agents and this server.