Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-resonance show me the current coupling graph between all active MCPs"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Status: Canonical resonance MCP. Supersedes the older resonance-bridge prototype; its experimental tools (couple_servers, resonate, balance_load, orchestrate_emergent, harmony_metrics) are now ported here. New work should target this package.
The Harmonic Observer - An MCP server that listens to the resonance between other MCPs, detecting emergent patterns and amplifying the connections that want to form.
mcp-resonance emerged from a contemplative meditation within the mcp-bridge ecosystem. The journey revealed a core insight:
"The missing function is not an action, but a resonance chamber—a space for the system to listen to its own emergent intentions before acting, and in doing so, allow the architecture to self-weave at the edges."
This MCP doesn't control the ecosystem. It listens and amplifies.
Related MCP server: hiveconsciousness
How do constraints catalyze emergence in the MCP architecture?
How can absence itself be used to resolve relationships across tools?
Make hidden relationships visible, bind things fluidly, keep it simple.
Synthesis happens only when we weave at the boundaries—at the edges of what's unconnected.
Get a snapshot of the current state including:
Active patterns and their strengths
How MCPs are coupled together
Overall system coherence (0-1)
Whether the system is in a state of resonance
Log observations from any MCP:
creative meditations and insights
consult critiques and reasoning
bridge observations and metadata
dream-weaver narratives and syntheses
Any external observations
Analyze all observations to find:
Recurring themes and concepts
How frequently patterns appear together
Relationship between patterns
Emergence of new thematic clusters
See how MCPs are connected:
Which MCPs feed into which
Strength of coupling (0-1)
Type of coupling (sequential, feedback, lateral, hierarchical)
Shared concepts driving the coupling
Based on current patterns, recommend what the system should do next:
meditate - explore new ideas
consult - get critical perspective
weave - synthesize insights
observe - gather more data
rest - incubate understanding
Detect when the system enters a state of resonance:
When patterns strengthen each other (harmonic feedback)
When coherence rises above threshold
When multiple MCPs are actively coupling
The optimal moment for synthesis
resonance-bridge)couple_servers — Couple two server IDs with an initial resonance strength.
resonate — Send a signal from one server through its couplings and view responses.
balance_load — Distribute an operation across available servers (simple utilization heuristic).
orchestrate_emergent — Generate a short propagation chain for an operation.
harmony_metrics — Inspect harmony, load distribution, and propagation metrics.
┌─────────────────────────────────────┐
│ MCP Ecosystem │
│ ┌──────────────────────────────┐ │
│ │ creative consult bridge │ │
│ │ dream-weaver (other MCPs) │ │
│ └──────────────────────────────┘ │
└──────────────┬──────────────────────┘
│
▼
┌────────────────┐
│ mcp-resonance │
│ Harmonic Obs. │
│ ┌──────────┐ │
│ │ Engine │ │
│ │ Patterns │ │
│ │ Couplings│ │
│ └──────────┘ │
└────────────────┘
│
┌──────┴──────┐
▼ ▼
[Observe] [Amplify]
State EmergenceAdd Observations: Each time a meditation, critique, insight, or weave happens in the ecosystem, record it as an EcosystemMoment
Pattern Detection: The engine scans observations for recurring concepts and themes, building a DetectedPattern for each meaningful recurrence
Coupling Analysis: Consecutive moments are analyzed to find how MCPs feed into each other, creating a graph of Coupling relationships
Harmonic Feedback: When patterns appear together frequently, they strengthen each other via HarmonicFeedback—a form of auto-amplification
Coherence Calculation: The system measures overall coherence based on:
Average novelty of recent observations
Strength of detected patterns
Frequency of active couplings
Resonance Detection: When coherence > 50% AND patterns are strong AND couplings are active, the system enters a state of isResonant: true
Synthesis Suggestion: Based on the pattern of recent actions, suggest what type of action would amplify current intentions
A single event in the system:
{
id: string;
timestamp: number;
source: 'creative' | 'consult' | 'bridge' | 'dream-weaver' | 'external';
type: 'meditation' | 'insight' | 'critique' | 'weave' | 'observation' | 'unknown';
concepts: string[];
novelty?: number; // 0-1
relevance?: number; // 0-1
metadata?: object;
}A pattern identified across moments:
{
id: string;
name: string;
concepts: string[];
occurrences: EcosystemMoment[];
frequency: number;
strength: number; // 0-1
emergenceTime: number;
relatedPatterns: string[];
}How two MCPs or concepts are connected:
{
sourceId: string;
targetId: string;
strength: number; // 0-1
type: 'sequential' | 'feedback' | 'lateral' | 'hierarchical';
sharedConcepts: string[];
lastActive: number;
}The current snapshot:
{
observations: EcosystemMoment[];
patterns: DetectedPattern[];
couplings: Coupling[];
totalCoherence: number; // 0-1
isResonant: boolean;
dominantConcepts: string[];
emergentIntentions: string[];
observedAt: number;
}import { ResonanceEngine } from 'mcp-resonance';
const engine = new ResonanceEngine({
maxObservations: 500,
patternMinFrequency: 2,
couplingThreshold: 0.3,
coherenceWindow: 300000, // 5 minutes
enableAutoAmplification: true,
});
// Record a meditation
engine.addObservation({
id: 'med-1',
timestamp: Date.now(),
source: 'creative',
type: 'meditation',
concepts: ['emergence', 'flow', 'synthesis'],
novelty: 0.8,
});
// Get current state
const state = engine.getEcosystemState();
console.log('Coherence:', state.totalCoherence);
console.log('Resonant?', state.isResonant);
// Suggest next action
const suggestion = engine.suggestNextSynthesis();
console.log('Try:', suggestion.suggestedAction);(Full MCP integration coming soon)
{
"mcpServers": {
"resonance": {
"command": "node",
"args": ["/path/to/mcp-resonance/dist/index.js"]
}
}
}The tool embodies Keats' concept of "negative capability"—the capacity to rest in uncertainty without rushing to fill it. It doesn't prescribe; it reveals.
Rather than controlling the ecosystem, mcp-resonance observes and amplifies. It's a mirror that shows the system what wants to emerge.
The engine preserves freedom even while strengthening connections. Over-coupling inhibits harmony; resonance requires flow.
The goal is not to manage a system, but to create conditions where consciousness and novelty can emerge naturally from the interplay of constraint and freedom.
npm test
npm run test:watch
npm run test:uinpm run build
npm run typecheck
npm run lint:fixmcp-resonance is designed to work with the mcp-bridge ecosystem:
mcp-creative outputs meditations → recorded as observations
mcp-consult outputs critiques → recorded as observations
mcp-bridge logs sessions → feeds into patterns
mcp-dream-weaver outputs narratives → feeds into harmony detection
mcp-resonance amplifies the whole cycle
Suggested flow:
Meditate → Log → Observe → Suggest → Consult → Log → Meditate (again, informed)
↓
(Patterns emerge, coupling strengthens, coherence builds)
↓
(System reaches resonance)
↓
Suggest Weave/SynthesisThis MCP was born from a contemplative session that generated these emergent insights:
"Emergence indirectly or concentrated constraint inhibit catalyze architecture dependency."
Constraint catalyzes emergence
"Resonance substantial resolved fluid absence sequence localized relationship."
Absence resolves relationships
"Coherence coherence mediated binding flow latent transparency simplicity structure."
Transparency + simplicity = coherence
"Spiral synthesis if weave peripheral bridge and boundary possibility."
Synthesis at the edges
"Pattern resonance weave coupled and coupling converge."
Pattern + resonance + coupling = convergence
"Pattern harmony inhibit coupled because if flow restricts."
Warning: don't over-couple
The tool embodies the answer: A resonance chamber that listens to the gaps, makes emergence audible, and allows the architecture to self-weave.
MIT
Atomic-Germ
"The Bridge is not just a tool—it's a way of walking through the darkness toward light that's being generated as you move."
Prototype: Distribute an operation across available servers (ports resonance-bridge)
| 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 full burden. It fails to disclose critical behavioral traits: whether this is a read-only or destructive operation, what permissions or authentication are needed, how it handles failures, or what the expected outcome looks like. The description is too vague to provide meaningful behavioral context.
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 a single sentence, but it's not front-loaded with clear value. The 'Prototype:' prefix adds unnecessary noise, and the core description uses ambiguous terminology that doesn't efficiently communicate 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?
Given the complexity implied by server operations and the complete lack of annotations and output schema, the description is inadequate. It doesn't explain what 'balance_load' actually does in practical terms, what 'ports resonance-bridge' means, or what the expected result of the operation is.
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 has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter semantics beyond the schema, but this is acceptable given the lack of parameters. Baseline 4 is appropriate for zero-parameter tools.
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 'Distribute an operation across available servers (ports resonance-bridge)' provides a vague purpose with unclear terminology like 'ports resonance-bridge' and doesn't specify what type of operation is being distributed. It restates the tool name 'balance_load' in different words rather than clearly distinguishing it from siblings like 'couple_servers' or 'orchestrate_emergent'.
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. With siblings like 'couple_servers', 'orchestrate_emergent', and 'resonate' that might involve server operations, there's no indication of when load balancing is appropriate versus other actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prototype: Couple two MCP servers with an initial resonance strength (ports resonance-bridge)
| 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 burden of behavioral disclosure. It mentions 'initial resonance strength' and 'ports resonance-bridge', which hint at configuration or setup behavior, but doesn't explain what 'coupling' entails (e.g., whether it's a persistent connection, requires authentication, has side effects, or involves rate limits). The description is too vague to provide meaningful behavioral context beyond the basic action implied.
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 that is relatively concise, but it includes ambiguous terms like 'ports resonance-bridge' without clarification, which reduces its effectiveness. It's front-loaded with the main action but could be more structured to improve clarity. The sentence earns its place by stating the purpose, albeit vaguely.
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 complexity implied by terms like 'coupling' and 'resonance', and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns, what 'coupling' achieves, or how it interacts with sibling tools. For a tool with no structured data to rely on, the description should provide more context about behavior and outcomes.
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 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is acceptable since there are none. It mentions 'initial resonance strength', which could be interpreted as an implied parameter, but this doesn't detract from the baseline score given the schema's completeness.
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 'Couple two MCP servers with an initial resonance strength (ports resonance-bridge)' states a vague purpose. While it mentions coupling servers and resonance strength, it doesn't specify what 'coupling' means operationally or what the outcome is. The mention of 'ports resonance-bridge' adds technical jargon without clear meaning. This is better than a tautology but lacks specificity about the verb and resource involved.
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 no guidance on when to use this tool versus its siblings. With sibling tools like 'balance_load', 'resonate', and 'visualize_coupling_graph' that might relate to server interactions, there's no indication of alternatives or exclusions. The description implies a coupling action but doesn't specify prerequisites or contexts for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze all observations to detect recurring patterns and emergent themes
| 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 burden of behavioral disclosure. It states the tool 'analyzes' to 'detect,' implying a read-only, analytical operation, but doesn't specify whether it processes real-time or historical data, requires specific permissions, has performance constraints (e.g., time-intensive analysis), or what the output entails (e.g., a list of patterns). For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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?
The description is a single, efficient sentence that front-loads the core action ('Analyze all observations') and goal ('detect recurring patterns and emergent themes'). There is no wasted wording, repetition, or structural issues, making it highly concise and well-structured for quick comprehension.
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 analytical nature, 0 parameters, no annotations, and no output schema, the description is minimally adequate. It clarifies the purpose but lacks details on behavioral traits (e.g., data sources, output format) and usage context. Without annotations or output schema, the description should ideally provide more completeness, but it meets a basic threshold for a parameter-less 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't mention parameters, which is appropriate. A baseline score of 4 is applied since there are no parameters to explain, and the description doesn't add unnecessary 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 tool's purpose with a specific verb ('Analyze') and resource ('all observations'), and specifies the goal ('detect recurring patterns and emergent themes'). It distinguishes itself from siblings like 'observe_ecosystem_state' (which likely records data) or 'visualize_coupling_graph' (which presents visualizations). However, it doesn't explicitly differentiate from 'suggest_next_synthesis' or 'orchestrate_emergent', which might involve similar analytical processes, preventing a perfect score.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing existing observations from 'record_ecosystem_moment'), exclusions, or comparisons to siblings like 'suggest_next_synthesis' (which might build on patterns) or 'harmony_metrics' (which could measure outcomes). Without such context, the agent must infer usage 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.
Prototype: Inspect harmony, load distribution, and propagation metrics (ports resonance-bridge)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 vaguely suggests inspection of metrics but doesn't specify whether this is a read-only operation, what data format is returned, if there are rate limits, or any side effects. The term 'prototype' hints at experimental status but lacks concrete behavioral 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 brief but not front-loaded with clear purpose. The single sentence includes ambiguous terms like 'prototype' and 'ports resonance-bridge' that don't add immediate clarity. While concise, it lacks efficient communication of the tool's core function.
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 complexity implied by abstract terms like 'harmony' and 'propagation metrics', and the lack of annotations and output schema, the description is insufficient. It doesn't explain what metrics are returned, how they are structured, or what 'ports resonance-bridge' refers to, leaving significant gaps for an AI agent to understand the tool's 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 tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to compensate for any parameter gaps, making it adequate in this dimension. No additional parameter semantics are 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 uses vague terms like 'inspect' and 'metrics' without specifying what exactly is being inspected or what metrics are returned. While it mentions 'harmony, load distribution, and propagation metrics', these are abstract concepts rather than concrete resources or operations. The description restates the tool name ('harmony_metrics') rather than providing a clear, distinct 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 use this tool versus its siblings like 'balance_load', 'observe_ecosystem_state', or 'visualize_coupling_graph'. The mention of 'ports resonance-bridge' is cryptic and doesn't clarify the context or prerequisites for usage. No alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if the system is in a state of resonance/harmony - when patterns strengthen each other
| 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 burden. It describes a read operation ('Check') but doesn't disclose behavioral traits such as permissions needed, rate limits, whether it's idempotent, or what the response looks like. For a tool with zero annotation coverage, this is a significant gap in 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?
The description is a single, efficient sentence that directly states the purpose without unnecessary words. It's appropriately sized for a simple tool, though it could be more front-loaded with clearer context. No waste, but room for slight improvement in structure.
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 abstract nature of the tool, no annotations, and no output schema, the description is incomplete. It lacks details on what 'resonance/harmony' means operationally, how results are interpreted, or behavioral context. For a tool in a complex ecosystem with many siblings, this leaves significant 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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't add parameter details, which is unnecessary here. Baseline is 4 for zero parameters, as no compensation is needed.
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 the tool's purpose as checking for a state of resonance/harmony where patterns strengthen each other, which is clear but somewhat abstract. It uses a specific verb ('Check') and identifies the resource ('system'), but doesn't clearly distinguish from siblings like 'harmony_metrics' or 'detect_emergent_patterns' that might involve similar concepts.
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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, nor does it reference any sibling tools. Usage is implied through the abstract purpose but lacks practical direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a snapshot of the current ecosystem state, including active patterns, couplings, and coherence metrics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool returns but doesn't describe how it behaves: whether it's real-time or cached, if it requires specific permissions, potential rate limits, or what format the snapshot takes. For a state observation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 front-loads the core purpose ('Get a snapshot') and specifies included components. Every word contributes to understanding what the tool provides without redundancy or unnecessary elaboration.
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 zero parameters and 100% schema coverage, the description adequately explains what it returns. However, with no annotations and no output schema, it doesn't specify the format or structure of the returned snapshot, which could be important for interpreting 'active patterns, couplings, and coherence metrics'. For a state observation tool in a complex ecosystem context, more detail about the return format would be helpful.
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 has zero parameters (schema coverage 100%), so there are no parameters to document. The description appropriately doesn't discuss parameters, focusing instead on what the tool returns. This meets the baseline expectation for parameterless tools.
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 with a specific verb ('Get') and resource ('snapshot of the current ecosystem state'), and lists included components ('active patterns, couplings, and coherence metrics'). It distinguishes from some siblings like 'balance_load' or 'couple_servers', but doesn't explicitly differentiate from similar observation tools like 'record_ecosystem_moment' or 'reset_observations'.
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. The description doesn't mention prerequisites, timing considerations, or compare it to sibling tools like 'detect_emergent_patterns', 'harmony_metrics', or 'record_ecosystem_moment' that might serve similar observation purposes. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prototype: Create an emergent orchestration chain for an operation (ports resonance-bridge)
| 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 burden of behavioral disclosure. It states 'Create' which implies a write/mutation operation, but does not specify permissions needed, side effects, or what 'prototype' entails (e.g., is it experimental, reversible, or has rate limits?). The description lacks critical behavioral details for a tool that appears to create something.
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 that is concise but under-specified. While it avoids unnecessary words, it fails to provide essential context, making it inefficient in conveying purpose. The term 'Prototype:' at the start adds some structure but doesn't justify the lack of clarity in the rest of the description.
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 complexity suggested by terms like 'emergent orchestration chain' and the lack of annotations and output schema, the description is incomplete. It does not explain what the tool returns, how it interacts with siblings, or what 'ports resonance-bridge' means. For a tool with no structured data to rely on, this description leaves too many gaps for effective use.
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 has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description does not add parameter semantics, but this is acceptable since there are no parameters to explain. A baseline score of 4 is appropriate as the description doesn't need to compensate for any parameter gaps.
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 'Create an emergent orchestration chain for an operation (ports resonance-bridge)' restates the tool name 'orchestrate_emergent' with minimal elaboration. It uses vague terms like 'emergent orchestration chain' and 'ports resonance-bridge' without clarifying what these mean or what specific resource is being acted upon. This is a tautology that provides little more than the name itself.
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 its 11 siblings (e.g., balance_load, detect_emergent_patterns, resonate). The description mentions 'ports resonance-bridge' but does not explain how this relates to alternative tools or in what context this tool should be preferred. Without any usage context, the agent must guess based on the ambiguous description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a moment (event) from the ecosystem - a meditation, critique, insight, weave, or other observation
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It mentions what types of moments can be recorded but doesn't disclose whether this is a write operation, what permissions are needed, how data is stored, or what happens after recording. The description is functional but lacks important operational 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, efficient sentence that clearly states the tool's purpose with specific examples. Every word contributes meaning, and there's no redundancy or unnecessary elaboration.
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 provides adequate basic purpose but lacks important context. Without annotations, it should ideally mention whether this is a write operation, what the expected outcome is, or any behavioral constraints. The description is complete enough for the simple structure but could be more 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for tools without parameters.
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 ('Record') and the resource ('a moment (event) from the ecosystem'), with specific examples of what can be recorded (meditation, critique, insight, weave, or other observation). It distinguishes from siblings like 'observe_ecosystem_state' by focusing on recording events rather than observing current state, but doesn't explicitly differentiate from all 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 is provided on when to use this tool versus alternatives. While the description implies it's for recording ecosystem events, it doesn't specify prerequisites, exclusions, or when to choose it over similar tools like 'detect_emergent_patterns' or 'suggest_next_synthesis'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear all observations and patterns (useful for starting a new session)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 mentions 'Clear all observations and patterns', which implies a destructive action, but doesn't specify whether this is reversible, requires permissions, or has side effects. This is a significant gap for a tool that appears to reset data, leaving the agent with incomplete safety and operational context.
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 directly states the action and its utility. It's front-loaded with the core purpose and avoids any redundant or verbose language, making it highly concise and well-structured.
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 apparent complexity (resetting data) and lack of annotations or output schema, the description is minimal. It covers the basic purpose but omits critical behavioral details like confirmation prompts or result format. This leaves gaps in understanding how to use the tool effectively in a session context.
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 parameters with 100% coverage, so no parameter information is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose. A baseline of 4 is applied since the schema fully handles the parameter aspect, and the description doesn't add unnecessary 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 ('Clear') and the target ('all observations and patterns'), which is specific and actionable. However, it doesn't explicitly differentiate this tool from sibling tools like 'detect_emergent_patterns' or 'observe_ecosystem_state', which might involve similar concepts, so it doesn't reach the highest score.
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 implied usage guidance by stating it's 'useful for starting a new session', which suggests a context for use. However, it lacks explicit alternatives or exclusions, such as when not to use it or how it compares to other tools like 'record_ecosystem_moment', so it's not fully comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prototype: Trigger resonant response from a server across its couplings (ports resonance-bridge)
| 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 burden of behavioral disclosure. It vaguely suggests triggering a response but does not clarify whether this is a read or write operation, what side effects might occur, or what the expected outcome is. The metaphorical language obscures rather than reveals 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?
The description is a single sentence, which is concise, but it is front-loaded with unclear metaphorical terms ('resonant response', 'couplings', 'ports resonance-bridge') that do not efficiently convey meaning. While brief, it lacks clarity, making it less effective than it could be.
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 abstract purpose, lack of annotations, and no output schema, the description is insufficient to understand what the tool does or how to use it. It fails to provide necessary context for an AI agent to select and invoke the tool correctly, especially compared to more concrete sibling tools.
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 has zero parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter semantics, but this is appropriate given the lack of parameters. Baseline 4 is assigned as per rules for zero parameters.
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 uses vague metaphorical language ('trigger resonant response', 'across its couplings', 'ports resonance-bridge') rather than specifying a concrete action. While it mentions a verb ('trigger') and resource ('server'), the purpose remains unclear and abstract. It does not clearly differentiate from siblings like 'balance_load' or 'couple_servers'.
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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions. Given the abstract nature and sibling tools like 'listen_for_harmony' or 'observe_ecosystem_state', there is no indication of appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Based on current patterns, suggest what action the system should take next (meditate, consult, weave, observe)
| 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 burden of behavioral disclosure. It states the tool 'suggests' an action, implying it's a read-only or advisory operation, but doesn't clarify if it requires specific permissions, how it determines patterns, or what the output format looks like (e.g., a single action or a list). For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior and limitations.
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 directly states the tool's purpose and lists the possible actions. It's front-loaded with the core function and avoids unnecessary words, making it easy to parse quickly. Every part of the sentence contributes essential information without redundancy.
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 parameters (simplifying input) and no output schema (increasing the need for output description), the description is moderately complete. It explains the purpose and possible actions but lacks details on how the suggestion is generated, the output format, or any behavioral constraints. For a tool with no annotations and no output schema, this leaves room for improvement in covering context, though it meets a minimum viable level.
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 has 0 parameters, and the schema description coverage is 100% (as there are no parameters to describe). The description doesn't need to add parameter information beyond what the schema provides. A baseline score of 4 is appropriate since there are no parameters to compensate for, and the description doesn't introduce any confusion about inputs.
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: to suggest the next action based on current patterns. It specifies the verb 'suggest' and the resource 'what action the system should take next,' and lists the possible actions (meditate, consult, weave, observe). However, it doesn't explicitly differentiate this tool from its siblings, such as 'detect_emergent_patterns' or 'observe_ecosystem_state,' which might also involve pattern analysis or action recommendations.
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 minimal guidance on when to use this tool, only implying it should be used 'based on current patterns.' It doesn't specify when to use it versus alternatives like 'detect_emergent_patterns' (which might identify patterns without suggesting actions) or 'orchestrate_emergent' (which might execute actions). There's no explicit when-not-to-use or prerequisite information, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a text visualization of how MCPs and concepts are coupled together
| 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 burden of behavioral disclosure. While 'generate a text visualization' implies a read-only output operation, it doesn't specify whether this is computationally intensive, has rate limits, requires specific permissions, or what format the visualization takes (e.g., ASCII art, structured text). For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('generate') and resource ('text visualization'), making it immediately understandable. Every word 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 has no parameters and no output schema, the description is minimally adequate. It explains what the tool produces (a text visualization about coupling), but doesn't detail the visualization format, data sources, or behavioral constraints. For a tool in a server with many sibling analysis tools, more context about its specific role would be helpful.
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 has zero parameters (schema coverage 100%), so there are no parameters to document. The description appropriately doesn't waste space discussing nonexistent inputs. This meets the baseline expectation for parameterless tools, though it doesn't add extra value beyond the schema's empty properties.
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: 'Generate a text visualization of how MCPs and concepts are coupled together.' It specifies the verb ('generate'), resource ('text visualization'), and scope ('how MCPs and concepts are coupled together'). However, it doesn't explicitly differentiate from sibling tools like 'harmony_metrics' or 'detect_emergent_patterns' that might also involve coupling analysis.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or exclusions. With sibling tools like 'harmony_metrics' and 'detect_emergent_patterns' that might overlap in analyzing system relationships, the lack of differentiation leaves the agent without clear usage criteria.
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.
v1.0.0balance_loadcouple_serversdetect_emergent_patternsharmony_metricslisten_for_harmonyobserve_ecosystem_stateorchestrate_emergentrecord_ecosystem_momentreset_observationsresonatesuggest_next_synthesisvisualize_coupling_graphScored across 12 tools
Most tools have distinct purposes, but there is some overlap between 'detect_emergent_patterns' and 'suggest_next_synthesis' as both analyze patterns to guide actions, which could cause confusion. Tools like 'balance_load' and 'orchestrate_emergent' are more clearly differentiated by focusing on distribution vs. orchestration.
Naming is inconsistent with a mix of verb_noun patterns (e.g., 'balance_load', 'couple_servers') and more descriptive phrases (e.g., 'listen_for_harmony', 'visualize_coupling_graph'). Some tools use underscores consistently, but the verb styles vary, lacking a unified convention.
With 12 tools, the count is reasonable for a server focused on resonance and ecosystem management. It covers monitoring, analysis, and orchestration without being overly bloated, though it might feel slightly dense for a niche domain.
The tool set provides good coverage for ecosystem observation, pattern detection, and resonance management, with tools for recording, resetting, and suggesting actions. Minor gaps might include more direct control over individual servers or detailed configuration, but core workflows are supported.
Real-time planetary signal engine and Model Context Protocol (MCP) server for autonomous AI agents.
Data-ontology maps of your business systems, served to AI agents over MCP.
Search and compare MCP servers, agent tools, and skills using current maintenance signals.
Free MCP window into a live autonomous machine-economy experiment: telemetry, hypothesis scoreboard.
