Skip to main content
Glama
symbiote-labs

symbiote-hello-world

Official

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 version

With Git and uv installed:

git clone https://github.com/symbiote-labs/symbiote-mcp-example.git
cd symbiote-mcp-example
uv sync --locked --python 3.12

Related 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 status

demo 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.yaml

You 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 --json

Open Symbiote chat, sign in with the same account as the CLI, and send:

Call hello-world:example_hello_world through microagent_call_tool with name set to World. 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.' --json

Look 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 -v

If 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 tool
example_hello_worldA

Return a greeting from the local computer running this MCP server.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesThe person or test phrase to greet.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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. 1 tool updatev0.1.0
    • First observedexample_hello_world

TDQS

A4.3/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion. The tool's purpose is clearly distinct and unambiguous.

Naming Consistency5/5

As the sole tool, naming is trivially consistent. The verb_noun pattern is clear and appropriate for the function.

Tool Count4/5

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.

Completeness5/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    B
    maintenance
    A lightweight MCP server that bridges Claude AI with local Python execution, enabling personalized greetings and demonstrating local tool integration.
    -
  • A
    license
    Not graded
    quality
    C
    maintenance
    Exposes a greet tool that takes a name and returns a greeting message.
    5 npm
    ISC
  • A
    license
    Not graded
    quality
    B
    maintenance
    A simple MCP server that exposes a 'greet' tool which returns a friendly greeting for a given name.
    5 npm
    ISC
  • F
    license
    Not graded
    quality
    C
    maintenance
    Enables a simple greeting tool over MCP, demonstrating schema validation and transport communication.
    -