Skip to main content
Glama
DIodide

DillyDallyMCP

by DIodide

DillyDallyMCP

A Model Context Protocol (MCP) server ready for Dedalus deployment.

Setup

1. Initialize Git Repository

cd dedalus-mcp
git init
git add .
git commit -m "Initial commit: Dedalus MCP server"

2. Create Remote Repository

Create a new repository on GitHub/GitLab/etc. named DillyDallyMCP, then:

git remote add origin <your-repo-url>
git branch -M main
git push -u origin main

3. Configure Environment Variables

Create a .env.local file in the dedalus-mcp folder:

CONVEX_URL=https://your-deployment.convex.cloud

You can find your Convex URL in:

  • The monorepo root .env.local file (if running locally)

  • Your Convex dashboard

  • By running npx convex dev from the monorepo root

Note: The .env.local file is gitignored and should not be committed.

4. Install Dependencies

npm install

5. Build

npm run build

Related MCP server: MCP Boilerplate

Testing Locally

STDIO Mode (for MCP clients)

npm run dev:stdio

HTTP Mode (for testing/debugging)

npm run dev:http

The server will start on http://localhost:3002

Using MCP Inspector

npm run build
npm run inspector

Deployment to Dedalus

This server follows Dedalus deployment standards:

  • ✅ Entry point: src/index.ts (or index.ts at root)

  • ✅ TypeScript server structure

  • ✅ Proper package.json configuration

Simply connect your repository to Dedalus and it will automatically detect and deploy the MCP server.

Project Structure

dedalus-mcp/
├── index.ts              # Main entry point
├── server.ts             # MCP server implementation
├── cli.ts                # CLI argument parsing
├── lib/                  # Shared utilities
│   └── convexClient.ts  # Convex client setup
├── tools/                # MCP tools
│   ├── index.ts
│   ├── addIntegers.ts
│   ├── getRecentActivity.ts
│   ├── getLastSession.ts
│   ├── getProductivityStats.ts
│   ├── getSessionDetails.ts
│   └── getAttentionMetrics.ts
├── transport/            # Transport implementations
│   ├── index.ts
│   ├── http.ts
│   └── stdio.ts
├── package.json
├── tsconfig.json
└── .env.local            # Environment variables (create this)

Available Tools

  • add_integers: Adds two integers together

  • get_recent_activity: Get recent activity snapshots from DillyDally

  • get_last_session: Get details of the most recent DillyDally session

  • get_productivity_stats: Get productivity statistics over a time range

  • get_session_details: Get detailed information about a specific session

  • get_attention_metrics: Get attention/focus metrics from camera snapshots

License

MIT

Available Tools

1 tool
add_integersB

Adds two integers together

ParametersJSON Schema
NameRequiredDescriptionDefault
aYesFirst integer
bYesSecond integer

TDQS

B3.1/5.0
Behavior2/5

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 only states the basic operation without mentioning error handling, performance characteristics, or any behavioral traits like overflow handling or precision limitations.

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 perfectly concise with a single, clear sentence that communicates the core functionality without any unnecessary words. It's appropriately sized for this simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple mathematical tool with no annotations and no output schema, the description adequately covers the basic operation but lacks information about return values, error cases, or behavioral context that would be helpful for an AI agent.

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 both parameters. The description doesn't add any meaning beyond what the schema provides, maintaining the baseline score for high schema coverage.

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 clearly states the tool's purpose with a specific verb ('adds') and resource ('two integers'), making it immediately understandable. It doesn't need to distinguish from siblings since none exist, but it could be more specific about the mathematical operation context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives or in what context it's appropriate. The description simply states what it does without any usage context, prerequisites, or limitations.

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 updatev1.0.0
    • First observedadd_integers

TDQS

B3.2/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap, as there are no other tools to confuse it with. The tool's purpose is singular and clearly defined.

Naming Consistency5/5

Since there is only one tool, it inherently follows a consistent naming pattern. The tool name 'add_integers' uses a clear verb_noun format, which is appropriate and consistent within this minimal set.

Tool Count2/5

A single tool is too few for most practical server purposes, as it severely limits functionality and scope. This feels thin and inadequate for any meaningful domain coverage, indicating a likely trivial or incomplete implementation.

Completeness1/5

With only one tool that performs a basic arithmetic operation, the server is severely incomplete. There is no domain coverage, no lifecycle operations, and obvious gaps for any coherent purpose, making it impossible for agents to perform meaningful tasks.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    A minimal, production-ready MCP server with a simple addition calculator tool that demonstrates integration with the Model Context Protocol.
    8 npm
    1
    MIT
  • F
    license
    C
    quality
    D
    maintenance
    A demonstration MCP server that provides a simple addition tool for learning how to create and deploy servers following the Model-Context-Protocol specification. Serves as a basic example for developers getting started with MCP server development.
    1
    -
  • F
    license
    B
    quality
    D
    maintenance
    A demonstration MCP server providing basic tools for returning greetings and performing mathematical addition. It serves as a practical workshop guide for setting up and configuring Model Context Protocol servers from scratch using Python.
    2
    4
    -