symbiote-hello-world
OfficialClick 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., "@symbiote-hello-worldGreet Alice with a personalized hello"
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.
Symbiote MCP example
A local Python tool you can call from Symbiote chat. It takes a name and returns
Hello, <name>!.
Run the MCP server and CLI on your computer. The CLI's microagent connects to Symbiote and forwards tool calls back here for execution.
Install
The MCP server needs Python 3.11+ and FastMCP >=3.2,<4 in its runtime
environment. The setup below installs FastMCP for you. The working example uses
Python 3.12.12 and FastMCP 3.4.7; the dependency versions are recorded in uv.lock.
These requirements apply to the MCP server; the standalone Symbiote CLI bundles
its own runtime.
Studios using Rez can package both the CLI and MCP server; see Studio packaging.
On macOS or Linux, install the Symbiote CLI:
curl -fsSL https://raw.githubusercontent.com/symbiote-labs/symbiote-cli-dist/main/install.sh | sh
export PATH="$HOME/.local/bin:$PATH"
symbiote --profile demo versionWith Git and uv installed:
git clone https://github.com/symbiote-labs/symbiote-mcp-example.git
cd symbiote-mcp-example
uv sync --locked --python 3.12Related MCP server: my-first-mcp
Log in
Use your Symbiote server URL and sign in through the browser:
symbiote --profile demo login --server https://symbiote.example.com --agent-path /agent
symbiote --profile demo statusdemo is a local profile name. Use the same profile in the commands below.
The /agent option depends on your server's routing; omit it for a direct
agent endpoint. Ask your administrator for the correct URL and prefix.
Connect your local tool
cp agent-config.example.yaml agent-config.yaml
uv run python -c 'import shutil; print(shutil.which("symbiote-hello-world"))'Paste the printed executable path into command in agent-config.yaml:
agent:
name: hello-world
mcp_servers:
example:
type: stdio
command: '"/your/checkout/.venv/bin/symbiote-hello-world"'
allowed_paths: []Keep the inner double quotes for paths with spaces. Use an absolute path;
~ and $HOME are not expanded here.
symbiote --profile demo microagent start --config agent-config.yamlYou should see Discovered 1 tool(s) followed by Connected. Leave this
terminal running. The CLI starts the MCP server for you.
Try it in chat
In another terminal, check that hello-world is connected with one tool:
symbiote --profile demo microagent status --jsonOpen Symbiote chat, sign in with the same account as the CLI, and send:
Call
hello-world:example_hello_worldthroughmicroagent_call_toolwithnameset toWorld. Show the actual tool result.
Expected result: Hello, World!
Or send the chat request from a second local terminal:
symbiote --profile demo query 'Call hello-world:example_hello_world through microagent_call_tool with name "World". Show the actual tool result.' --jsonLook for a microagent_call_tool call and a successful tool result containing
Hello, World!. The chat response alone isn't proof that the tool ran.
Stop the proxy with Ctrl+C. Restart it after adding or changing tools. If the connection drops, run the start command again.
Run in your own environment
Run the microagent on a computer that can reach Symbiote and the system your
integration uses. Set command to start your MCP server with the dependencies
and environment it needs. This can be an installed executable or a launcher
script; use absolute paths unless your environment manager supplies PATH.
See Studio packaging for Rez, Conda, and container setups.
The microagent's tools belong to the Symbiote account it logs in with. Another user's chat does not automatically have access to them.
Make it yours
Edit the server. Replace the greeting
with a call to your API, or add another @mcp.tool() function. Types and
docstrings describe the inputs to Symbiote. Prefix tool names for your
integration to avoid collisions.
Return text or JSON-serializable data. Keep stdout for MCP; use a log file for debugging, since the microagent discards stderr. FastMCP's guide covers tool authoring.
Run the local tests:
uv run python -m unittest discover -s tests -vIf discovery finds zero tools, check the executable path and run the tests. If chat can't reach the tool, check the account, profile, and proxy terminal. If the session expires, log in again and restart the proxy.
Available Tools
1 toolexample_hello_worldA
Return a greeting from the local computer running this MCP server.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The person or test phrase to greet. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It usefully discloses that the greeting originates from the local computer running the server, which clarifies local execution behavior. The description implies a safe, read-only operation, though it does not explicitly state side effects or failure modes.
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, front-loaded sentence with no wasted words. It communicates the action and origin efficiently.
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 one-parameter greeting tool with an output schema present, the description is complete enough. The agent has all essential information to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the only parameter ('name'). The description adds no extra parameter-level meaning, so the baseline of 3 applies.
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 a specific verb ('Return') and resource ('greeting from the local computer running this MCP server'), making the tool's basic function clear. With no sibling tools, there is no need for sibling differentiation, so this is just below the top 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 gives clear context that this is a local greeting generator, so an agent can infer when to invoke it. There are no sibling tools or exclusions to mention, and no additional usage guidance is needed for such a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
example_hello_world
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion. The tool's purpose is clearly distinct and unambiguous.
As the sole tool, naming is trivially consistent. The verb_noun pattern is clear and appropriate for the function.
A single tool for a hello-world server is minimal but appropriate, fully covering the narrow scope. It falls slightly short of the typical 3-15 tool range but is justified by the server's simplicity.
The tool fully satisfies the server's stated purpose of returning a greeting. There are no missing operations or dead ends for the hello-world domain.
Maintenance
Related MCP Connectors
Send friendly, personalized greetings by name. Switch to a playful pirate voice for themed salutat…
Generate quick, friendly greetings by name. Personalize salutations for any context. Explore the o…
Greet anyone by name with a friendly message. Explore the origin of 'Hello, World' to add context…
Send friendly, personalized greetings on command. Explore the origin of 'Hello, World' for quick c…
Related MCP Servers
- FlicenseNot gradedqualityBmaintenanceA lightweight MCP server that bridges Claude AI with local Python execution, enabling personalized greetings and demonstrating local tool integration.-
- AlicenseNot gradedqualityCmaintenanceExposes a greet tool that takes a name and returns a greeting message.5 npmISC
- AlicenseNot gradedqualityBmaintenanceA simple MCP server that exposes a 'greet' tool which returns a friendly greeting for a given name.5 npmISC
- FlicenseNot gradedqualityCmaintenanceEnables a simple greeting tool over MCP, demonstrating schema validation and transport communication.-